CAM
CAM copied to clipboard
ESCOMP
Add defaults for various MPAS-A meshes in namelist_defaults_cam.xml as unsupported configurations
At present the MPAS-A dycore in CAM can be run with only a patchwork of various resolutions (meshes) and compsets. Moving forward, it would be desirable to be able to configure the MPAS-A dycore for the Cartesian product of resolutions {mpasa480, mpasa240, mpasa120, mpasa60, mpasa30, mpasa15, mpasa15-3-conus, mpasa7.5, mpasa3.75} and compsets {FHS94, FKESSLER, QPC6, F2000climo}. These configurations do not need to be Supported at present.
- Regarding the production of bnd_topo files:
- For climate configurations / "CAM workhorse" configurations, it's not clear yet what smoothing radius should be used for topography
- For producing analyses using DA, NWP time-scale applications, etc., we tentatively plan to use bnd_topo files produced using half the smoothing radius that is typically used for other dycores; e.g., produce topography for the 7.5-km mesh with an
nc6000intermediate cubed-sphere grid and a smoothing radius ofCo0004.
Can you define what you mean by "complete ... support"? In CESM land, we have these levels of support:
- Scientific support: There is a paper on this compset / resolution combination.
- Supported: There is a test for this combination (i.e., pre-CAM tag, pre-CESM alpha tag, or pre-CESM beta tag).
- Unsupported: No test or a test but marked as unsupported.
The issue I see is the expense of running al these tests in addition to the hundreds of tests we already run. The two highest-res grids together with the CAM6 physics runs are pretty expensive and would significantly slow down either the CAM tag process or the CESM tag process.
I would like some feedback on what level of commitment we can afford here: @andrewgettelman? @PeterHjortLauritzen? @JulioTBacmeister? @swrneale?
At least initially, I think what we're after is "unsupported." I see now that the word support has very specific meaning in CESM. I'll update the Issue accordingly.
In that case, I think we should have an MPAS test category we could use to make sure all the cases can run in principle. We don't have this right now but I think we should create a CIME test that makes sure that all the required default input files for a case are available in the input data repository. That would increase our confidence that we are at least providing minimal support.
In that case, I think we should have an MPAS test category we could use to make sure all the cases can run in principle. We don't have this right now but I think we should create a CIME test that makes sure that all the required default input files for a case are available in the input data repository. That would increase our confidence that we are at least providing minimal support.
The ability to verify that all required input files for a case are available in the input data repository sounds like a good idea to me. Are you suggesting this should be opened as a separate issue in CIME, or that the implementation of these tests belongs as part of this issue?
How was topography smoothing for MPAS done originally? It sounds like @adamrher is saying the smoothing for MPAS from previous methods corresponds to about 0.5 of what is currently used in CESM topography processing for FV latlon at the same nominal resolution, ie., a smoothing radius of Co=~30 instead of 60 for "one degree" resolution. Is this correct? Where can I see a smoothed topo file for MPAS done the original way?
Would it be possible to add some of these configurations into the CAM and/or the CESM test suites? Specifically it would be helpful to have tests for ... compsets: FHS94, FKESSLER, QPC6, F2000climo resolutions: mpasa120 and mpasa30 compiler: intel is fine for now test type: maybe just SMS, but ERS could also be helpful It looks like just FHS94 @ mpasa480 is being tested in the CESM test suite and I'm having difficulties running the others right out the box.
@mgduda and @PeterHjortLauritzen met to discuss this.
Current process for generating MPAS initial conditions is (@mgduda please correct me if I am wrong here):
- generate horizontal grid (standalone MPAS tool)
- generate ESMF grid descriptor file
- define ASCII file with vertical grid (convert CAM pressure levels to z using algorithm from CGD; not sure who?)
- Run topo tool to generate surface height (https://github.com/NCAR/Topo)
- Use 3 and 4 to generate vertical grid using MPAS tool (vertical grid is not analytic)
- Generate IC file based on, e.g., analysis.
To support current ~1 degree applications in CAM for real-world applications we would need L32 (CAM6 vertical grid), L58 (CAM7 low top), L93 (CAM7 high top) as well as L70 (WACCM6), L135 (WACCM7) and WACCM-x vertical grid. We could, of course, reduce the scope but this is what we are targeting with SE (with a possible exception of L70).
Excluding high top applications (here defined as >80km) that is 3 IC files for one horizontal resolution. Note that these IC files can not be used for Aquaplanet configurations since the MPAS IC files have surface height in them (which must be consistent with PHIS=0).
To support simpler model configurations we would need L32, L58 and L93 for Aqua-planet, baroclinic wave (FKESSLER; has idealized topography), other baroclinic waves with z=0 and Held-Suarez.
Clearly the number of IC files is huge!
Some simplifications to reduce the number of files:
- Use analytic initial conditions (US standard atmosphere; might add moisture profile to it!) for Aquaplanet configurations (@brianpm is on board with that). Then we might get away with just needing the levels defined. Held-Suarez would also only need levels defined. FKESSLER will still need a non-zero z unless next item gets implemented.
- @mgduda will look into doing inline smoothing (definition) of coordinate surfaces in MPAS so that CAM-MPAS can define the vertical coordinate from the topo file so that step 5 can possibly be removed.
We need to decide on variable resolution support as well. Guidance from SIMA requested.
Other but related items:
- @mgduda will look into generating a 10 degree MPAS grid for regression testing (similar to fv and se 10 degree grids).
- @briandobbins requested to have a series of horizontal resolutions for performance testing (120,60,30,15,7.5,3.75km). We could do that with Aqua-planets (then we don't need land files etc. but the computational performance should be similar to real world simulations in terms of the CAM component).
More to be added as discussions continue.
We need to decide on variable resolution support as well. Guidance from SIMA requested.
I've tried to determine whether we can provide functional support for convective permitting MPAS VR grids in time for the CESM3 release. After speaking with a number of folks, the main dev obstacles to providing this support are:
- Xingying is getting errors running her 60->3 km Pacific Northwest grid on the newest code bases on Derecho.
- Convection permitting mods have not been validated in the coarse region yet (in particular the all-or-nothing cloud fraction needed by the microphysics, and the behavior of ZM using a ~20 s physics time-step).
I am putting the probability as low, given the lack or resources and upcoming CESM3 deadlines. I propose we aim for the next release CESM3.1 to provide VR support for MPAS.
