-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Facilitate hybrid runs #159
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One small change to the logic in MOM_input.yaml
, and a question about buildnml
that may or may not turn into another change request... I'll look at the MOM6 PR later today
param_templates/MOM_input.yaml
Outdated
$RUN_TYPE != "hybrid" or $CONTINUE_RUN == True and $OCN_GRID in ["gx1v6", "tx0.66v1", "tx2_3v2", "tx0.25v1"]: | ||
True | ||
else: | ||
False |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add parenthesis to these? ($RUN_TYPE != "hybrid" or $CONTINUE_RUN == True) and $OCN_GRID in ["gx1v6", "tx0.66v1", "tx2_3v2", "tx0.25v1"]
and $RUN_TYPE != "hybrid" or ($CONTINUE_RUN == True and $OCN_GRID in ["gx1v6", "tx0.66v1", "tx2_3v2", "tx0.25v1"])
are different statements, and I'm not clear on what the order of operations are. If I had to guess, since and
is multiply and or
is addition, the second one is what python is actually doing?
Just checked, and I guessed right:
>>> True or True and False
True
>>> True or (True and False)
True
>>> (True or True) and False
False
So if CONTINUE_RUN
is True and the grid is one of the global grids we support, or if RUN_TYPE
is not hybrid, then INIT_LAYERS_FROM_Z_FILE
is True. Otherwise (RUN_TYPE
is hybrid and either CONTINUE_RUN
is False or we aren't on a supported grid) it is False. Is that what we want?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reading through MOM_state_initialization module, it actually looks like the check for CONTINUE_RUN
is unnecessary, so I'll remove it once I confirm that is indeed the case. Hence, there should be no need for parantheses, but thanks for catching this.
# check if the restart file is present in rundir | ||
if run_type in ["branch", "hybrid"] and not continue_run and not get_refcase: | ||
restart_file = os.path.join(rundir, f'./{run_refcase}.mom6.r.{run_refdate}-{run_reftod}.nc') | ||
assert os.path.exists(restart_file), f"Missing restart file {run_refcase}.mom6.r.{run_refdate}-{run_reftod}.nc in rundir." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are you creating the restart_file
from the case instead of reading the rpointer
file? Alternatively, why are you checking for the existence of an rpointer
file if you aren't reading it here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For continuation runs, MOM6 reads the rpointer file regardless of run type. Therefore, a check is performed to confirm its existence.
However, in the case of initial hybrid runs, MOM6 does not read rpointer but instead reads the initial condition files listed in MOM_input. So, for an initial hybrid run (and for initial branch runs too), the above block disregards the rpointer file and determines the required restart file name from the reference case properties. Maybe for initial branch runs, a check may be added to confirm that reference case and rpointer are consistent.
The reason I check for the existence of rpointer file when it's an initial hybrid run is because of CESM conventions, but I am happy to update the check to be performed only for continuation runs and branch runs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanation! I think this block of code makes sense given the structure of updates in the companion MOM6 PR.
A key capability of It would be good to confirm that MOM6 sets the model date to |
For hybrid runs, MOM6 disregards the date in restart files, as they are treated merely as IC files in hybrid mode. The MOM Date logs confirm that that is indeed the case, i.e., that MOM Date starts from RUN_STARTDATE and not from RUN_REFDATE. |
This PR is ready for merge unless there are further change suggestions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks for answering those questions!
This PR adds several pre checks for hybrid runs and introduces/modified MOM_input parameters to facilitate hybrid CESM runs. The modified parameters are mainly the IC file names, which are now automatically set to the restart files of the reference case specified via xml commands.
This PR should be evaluated in conjunction with NCAR/MOM6#273
Usage:
The users can now run hybrid CESM-MOM6 runs by setting the following xml variables:
After setting the above xml variables, the MOM_input file will automatically be updated to run a hybrid case. Optionally, the following may be set to automatically link the necessary restart file: