Execute GEOS via calling gcm_run.j + rename marine suites -- part 1, 2, & 3#677
Execute GEOS via calling gcm_run.j + rename marine suites -- part 1, 2, & 3#677
Conversation
|
This is ready to go in and/or final testing. CI-workflows need to be modified to handle new suite names though. |
|
@Dooruk For the sake of clarity and simplicity, would it be possible to break down the PR in two for the Main change 1 and 2? They are two disctinct feature improvements here. That would also speed up and facilitate the reviews. Thanks a lot! |
I already did this. I'm running out of time before I go on FMLA so I won't be able to do that again. Main change 1 is just renaming suites anyway. I created this PR after your similar comment, it was only part 1 for a couple of months or so. @mer-a-o reviewed it and decided she will implement the Skylab approach to execute GEOS for compo, and we will collaborate for running NWP afterwards. This is not end all be all in terms of executing GEOS but it is needed urgently for marine group to run some experiments while I'm gone. |
|
Once GEOS-ESM/CI-workflows#32 goes in, this is good to go in but I need approvals |
|
I was able to run the |
mranst
left a comment
There was a problem hiding this comment.
Lots of changes, I appreciate the documentation upgrades. I don't fully know the intricacies of the change to gcm_run.j, but from what I can see, this looks great. Only one thing sticks out to me, which is the eva comparison task for observations uses the suite name, so if you could change the names of these files to reflect the new marine names, I can give an approval:
src/swell/suites/compare/eva/comparison_observations-3dfgat_cycle-geos_marine.yaml' 'src/swell/suites/compare/eva/comparison_observations-3dfgat_cycle-geos_marine.yaml
|
Can't keep up with the pace of changes in develop:) thank you all for reviews |
This is ready to go in. CI-workflows need to be modified to handle new suite names like so:
GEOS-ESM/CI-workflows#32
Main change 1:
SOCA (marine) suites are renamed:
3dvar -> 3dvar_marine
3dvar_cycle -> 3dvar_marine_cycle
3dfgat_cycle -> 3dfgat_marine_cycle
Main change 2:
Cylc calls
gcm_run.jdirectly inflow.cylc.With this new approach, SWELL can point to an existing GEOS experiment folder (the
experiment.yamlkey for that isgeos_homdir) and theforecastfolder is now located under experimentGEOSgcm/forecastdirectory. It is possible to hotstart. With this new approach, forecast directory is not erased and MAPL history outputs can be accumulated under there. I updated docs a bit but might add on more for GEOSgcm execution.For those who stumbled upon this PR, more details on change 2 below:
The main thing happening here is that Cylc (flow.cylc) now calls
gcm_run.jdirectly. To facilitate this aforecastdirectory was created under{swell_exp_dir}/GEOSgcm/forecast. Thisforecastfolder is a replication of a GEOS experiment folder, with only a few changes regarding where HOMDIR, EXPDIR are defined. Model execution happens under{swell_exp_dir}/GEOSgcm/forecast/scratchsimilar to typical GEOS model runs.Why was this change necessary:
/RCfiles) in the forecast directory. This creates incompatibility while running/testing different GEOSgcm versions. Between multiple products and update frequencies, this is an important requirement.forecastdir can't be updated inflow.cylcif it is templated in a time dependent way.subprocesssimply couldn't run GEOSv12 on Milan nodes. I tried many combinations, it didn't pass beyond the initialization stage.gcm_run.j. If users make mistake in terms of requesting sufficient SLURM nodes, GEOS tries submitting hundreds of instances to compensate lack of compute resources, then NCCS will yell at you.gcm_run.jandgcm_setup.jscripts are being or will be modernized. This is work underway but might take a long time (especiallygcm_run.j).gcm_run.jin SWELL, some parts should be erased or commented out. Or, my idea is that there could be conditional sections ingcm_run.jsaySWELL_active, thengcm_run.jcan skip those sections, which are mainlypostprocessinganyway.More details in below comment: #677 (comment)
Finally, little primer on
gcm_run.jLet's consider
gcm_run.jin 4 stages:In the current implementation, SWELL handles 2 & 3 via python and
subprocessand 1 is assumed to be set properly by the user, which caused trouble with the NCCS. For DA purposes 4, postprocessing is explicitly handled by SWELL but that is not the focus of this PR.In this proposed implementation, the main difference is that we rely on
gcm_run.jfor 2 and 3 by conducting surgical edits viaPrepCoupledGeosRundirat few locations and runninggcm_run.jdirectly from Cylc (which doesn't capture failed exit status):I created the
3dfgat_coupled_cyclesuite for testing, should work by default if anyone has time to check it out.