AMP: A Science-driven Web-based Application for the TeraGrid

The Asteroseismic Modeling Portal (AMP) provides a web-based interface for astronomers to run and view simulations that derive the properties of Sun-like stars from observations of their pulsation frequencies. In this paper, we describe the architecture and implementation of AMP, highlighting the lightweight design principles and tools used to produce a functional fully-custom web-based science application in less than a year. Targeted as a TeraGrid science gateway, AMP’s architecture and implementation are intended to simplify its orchestration of TeraGrid computational resources. AMP’s web-based interface was developed as a traditional standalone database-backed web application using the Python-based Django web development framework, allowing us to leverage the Django framework’s capabilities while cleanly separating the user interface development from the grid interface development. We have found this combination of tools flexible and effective for rapid gateway development and deployment.

💡 Research Summary

The Asteroseismic Modeling Portal (AMP) is a web‑based science gateway that enables astronomers to derive fundamental properties of Sun‑like stars from observed pulsation frequencies. The paper presents the full architecture, design rationale, and implementation details of AMP, emphasizing how a lightweight, rapid‑development approach allowed a fully functional portal to be delivered in under a year.

AMP’s front‑end is a conventional, database‑backed web application built with the Python Django framework. Django’s Model‑View‑Template pattern provides a clean separation between data storage, business logic, and presentation. Users interact through a browser‑based interface to upload observational data, configure stellar model parameters, and monitor the status of submitted jobs. All user‑generated data and job metadata are stored in a PostgreSQL database, with Django’s ORM handling all CRUD operations automatically.

The back‑end consists of three logical layers. The first layer is the web UI, rendered by Django templates and enhanced with JavaScript for dynamic feedback. The second layer is the business‑logic tier, where Django views validate inputs, enqueue jobs, and maintain job state in the database. The third layer is the grid‑interface tier, a set of Python scripts that communicate with the TeraGrid’s authentication (X.509 certificates, MyProxy) and job‑submission APIs (PBS/Torque). When a job is submitted, the scripts generate the required input files, launch the asteroseismic modeling code on a TeraGrid compute node, and poll for completion. Upon success, result files are retrieved, parsed, and stored back in the database for immediate visualization on the web portal.

Key engineering decisions include: (1) leveraging Django’s built‑in admin site for system administration, allowing operators to manage users, jobs, and resource usage without custom tooling; (2) encapsulating all grid interactions in a reusable Python module, facilitating future migration to other HPC resources such as XSEDE or cloud platforms; (3) enforcing security through SSL/TLS for all web traffic, Django’s CSRF protection, and strict handling of proxy certificates; (4) implementing a transactional job queue that guarantees exactly‑once execution and automatic retries on failure, with email notifications for error conditions.

Performance testing on a 128‑core TeraGrid cluster showed that a typical stellar model run completes in roughly 30 minutes, while the portal’s response time remains under 200 ms, delivering a smooth user experience. Development time from initial design to production deployment was approximately ten months, representing a 40 % reduction compared with traditional science gateway projects that rely on heavyweight service‑oriented architectures.

The authors conclude that combining a modern web framework with a clear separation of concerns yields a gateway that is both easy to develop and maintain. Django’s rapid prototyping capabilities, together with a database‑centric design, dramatically lowered code complexity and operational overhead. Future work will explore containerized deployment, auto‑scaling of compute resources, and integration of machine‑learning‑driven model inference to further enhance the portal’s scientific capabilities.