We need to build a federated MPAS App. This will require integrating MPAS UW drivers into Chiltepin as well as building Parsl Apps to install all necessary software and run the needed utilities. A user should be able to run an MPAS workflow both locally and remotely.
The initial design of these Parsl Apps could follow the example given by the implementation of the JEDI QG model used for development and testing. It is anticipated, but not required, that the UW-Tools API will be used rather than its CLI to keep the interface in native Python for clarity and simplicity.
It is preferable to build the MPAS App to be completely self-contained such that it does not depend on preexisting data or software on a given machine. To accomplish this, we will need Apps that do the following:
Use UWTools to run init_atmosphere_model to create ics and lbcs for model input
Use UWTools to run atmosphere_model to run a forecast
The integration of UW drivers via the uw-tools API will require adding the uw-tools Python package to our software stack, both in the container and in the ./install.sh scripts for local HPC systems. To minimize incompatibility problems and additional complexity across both HPC and containerized Spack environments, the uw-tools should first be tested using a pip installation rather than the conda-based install. This should be as simple as pip install uw-tools, but the command must be run with the pip that is installed in the Spack environment.
Finally, once completed, a CI workflow should be added to test the MPAS app for a low resolution (e.g. 480km) run. This CI file needs to run the MPAS app in the container. See here for an example of how to start the container and run commands in it. Note that the CI workflow for running the MPAS App need not build or push any container images. It only needs to "up" the container and issue commands to it with docker exec ...
This issue should be updated as futher details and plans emerge.
We need to build a federated MPAS App. This will require integrating MPAS UW drivers into Chiltepin as well as building Parsl Apps to install all necessary software and run the needed utilities. A user should be able to run an MPAS workflow both locally and remotely.
The initial design of these Parsl Apps could follow the example given by the implementation of the JEDI QG model used for development and testing. It is anticipated, but not required, that the UW-Tools API will be used rather than its CLI to keep the interface in native Python for clarity and simplicity.
It is preferable to build the MPAS App to be completely self-contained such that it does not depend on preexisting data or software on a given machine. To accomplish this, we will need Apps that do the following:
gpmetisexecutablegpmetisto obtain the necessary partitioning of the mesh files for running mpas executablesungrib.exeexecutableungrib.exeto produce ics and lbcsinit_atmosphere_modelto create ics and lbcs for model inputatmosphere_modelto run a forecastThe integration of UW drivers via the uw-tools API will require adding the uw-tools Python package to our software stack, both in the container and in the
./install.shscripts for local HPC systems. To minimize incompatibility problems and additional complexity across both HPC and containerized Spack environments, the uw-tools should first be tested using a pip installation rather than the conda-based install. This should be as simple aspip install uw-tools, but the command must be run with thepipthat is installed in the Spack environment.Finally, once completed, a CI workflow should be added to test the MPAS app for a low resolution (e.g. 480km) run. This CI file needs to run the MPAS app in the container. See here for an example of how to start the container and run commands in it. Note that the CI workflow for running the MPAS App need not build or push any container images. It only needs to "up" the container and issue commands to it with
docker exec ...This issue should be updated as futher details and plans emerge.