-
Notifications
You must be signed in to change notification settings - Fork 7
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
CI to update MOM_parameter_doc.* and add to PRs #117
Comments
Do you mean a CI workflow that would run MOM6 to check if the files are up to date, or a CI workflow that would run MOM6 and then update the files? |
I meant the latter. MOM6 will re-generate
and add this to the PR. I'm guessing this would do nothing for unchanged files? Perhaps something like this is already done for MOM6-examples? |
Unfortunately that kind of approach is problematic for a couple of reasons. First, the CI needs to push the new commit to the remote, otherwise the commit will only exist in the github runner. Pushing to the remote will in turn trigger a new CI run, that will in turn add another commit, etc. The fact that the CI is adding a commit to the remote git repository can also confuse developers and create conflicts with their local branch (e.g., when doing a The usual approach is instead to mark the CI as failed if the files in question are not up to date. Fixing it will then require some extra work from the developer (download the new version of the files + commit them), but avoids all of the above issues. |
OK that sounds like a better approach then - have CI do a short run to update |
NB runs of 0 or 1 timesteps don't work, but 2 does, i.e.
in |
I added MOM_parameter_doc.* manually in this PR ACCESS-NRI/access-om3-configs#45 |
Note that they are incomplete due to this bug #121 |
Does anyone know if there is an analogous way to save all the parameters for CICE6, including the defaults that weren't set explicitly? |
There is a log file section "Overview of model configuration with relevant parameters" which should capture all the configuration options. I think that whole section (up to 'istep1') should be basically unchanged between runs unless the configuration / build changes |
This issue has been mentioned on ACCESS Hive Community Forum. There might be relevant details there: https://forum.access-hive.org.au/t/cosima-twg-meeting-minutes-2024/1734/12 |
Ideally payu would also copy the most recent |
I think the git runlog commits at the start of run, so it would only get captured if it was run again ? |
hmm, good point. Would it be confusing to commit it at the start of the subsequent run? Maybe this would best be done via a script that could be put in the |
When MOM6 runs, it outputs these files detailing every parameter actually used by the model, as described here
These provide comprehensive parameter documentation, so even though they are output files they would be useful to commit to the repo, as is done in MOM6-examples, e.g. ocean_only/global.
For this to be useful rather than misleading,
MOM_parameter_doc.*
would need to be kept in sync withMOM_input
(and the executable), e.g. via a short MOM6 run as part of CI on PRs. Does that sound feasible?The text was updated successfully, but these errors were encountered: