[develop] Configs for compiling and running online-cmaq on cheyenne.

[padhrigmccarthy]

DESCRIPTION OF CHANGES:

Configurations for Cheyenne HPC, to facilitate building and running online-cmaq on cheyenne.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• [ x] New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

TESTS CONDUCTED:

Tested on cheyenne with intel.

DEPENDENCIES:

Submitting additions to UFS_UTILS and AQM_utils as well.

[MichaelLueken]

@padhrigmccarthy

For the change to modulefiles/tasks/cheyenne/miniconda_regional_workflow.lua, is there a reason that you needed to load conda? Loading miniconda3/4.12.0 and then activating with conda activate regional_workflow should be fine.

For ush/machine/cheyenne.yaml, is there a reason that you moved the data location away from the ufssrw location? While the WE2E tests successfully ran and passed for both Intel and GNU, I believe that the data location should continue to point to the current location, until the time that the maintaining of data is transitioned to EPIC.

[padhrigmccarthy]

Hi Mike- These comments agree with Chan-Hoo's suggestions. It took a LOT of trial-and-error to get these conda environments to load as expected, so the 'load("conda")' calls are remnants of those attempts. Thanks for the feedback. I will simplify and test, then push these suggested changes.

…

-Paddy.

On Wed, Mar 8, 2023 at 3:58 PM Michael Lueken ***@***.***> wrote: ***@***.**** commented on this pull request. @padhrigmccarthy <https://github.com/padhrigmccarthy> For the change to modulefiles/tasks/cheyenne/miniconda_regional_workflow.lua, is there a reason that you needed to load conda? Loading miniconda3/4.12.0 and then activating with conda activate regional_workflow should be fine. For ush/machine/cheyenne.yaml, is there a reason that you moved the data location away from the ufssrw location? While the WE2E tests successfully ran and passed for both Intel and GNU, I believe that the data location should continue to point to the current location, until the time that the maintaining of data is transitioned to EPIC. ------------------------------ In ush/machine/cheyenne.yaml <#656 (comment)> : > @@ -29,4 +31,4 @@ platform: FIXshp: /glade/p/ral/jntp/UFS_SRW_App/develop/NaturalEarth data: ics_lbcs: - FV3GFS: /glade/p/ral/jntp/UFS_CAM/COMGFS/gfs.${yyyymmdd}/${hh} + FV3GFS: /glade/collections/rda/data/ds084.1/${yyyy}/${yyyymmdd} While the WE2E tests for both Cheyenne Intel and Cheyenne GNU run without issue with this change, I think that we should point to the directories maintained by ufssrw, until such time that they are transitioned to EPIC. Further input would be appreciated. ------------------------------ In modulefiles/tasks/cheyenne/miniconda_regional_workflow.lua <#656 (comment)> : > @@ -1,4 +1,5 @@ unload("python") +load("conda") I don't think this should be added. The necessary regional_workflow conda environment is loaded below this point. No python or conda should be loaded until miniconda3/4.12.0 has been loaded. @padhrigmccarthy <https://github.com/padhrigmccarthy> Is there a reason that load("conda") was added before the load of miniconda3/4.12.0? — Reply to this email directly, view it on GitHub <#656 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGGS25LW4A7G2Z6R4HXV3W3DXJFANCNFSM6AAAAAAVT7RBCM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[padhrigmccarthy]

@padhrigmccarthy
For ush/machine/cheyenne.yaml, is there a reason that you moved the data location away from the ufssrw location? While the WE2E tests successfully ran and passed for both Intel and GNU, I believe that the data location should continue to point to the current location, until the time that the maintaining of data is transitioned to EPIC.

@MichaelLueken It seems we need time-dependent data for FV3GFS, rather than a fixed time. Here is what I heard back from Rajesh Kumar, the scientist leading our project at NCAR:

Hi Paddy,
The default location of the GFS forecasts should be /glade/collections/rda/data/ds084.1. This is automatically populated with the new GFS data. The directory /glade/p/ral/jntp/UFS_CAM/COMGFS looks like a test set up.
Rajesh

I've pushed the change to revert this to the ufssrw location and made the use of time-dependent data part of our local configuration instructions.

[MichaelLueken]

@padhrigmccarthy Thank you very much for making the changes! Just a brief note, the ush/machine/${machine}.yaml files point to the directories that contains the staged data for the WE2E tests on the various machines, which is why it should ultimately point to the ufssrw location (where the WE2E test data is contained). The Jenkins tests passed without issue, so I am now approving this work.