Please reply to this topic if you have feedback on the ACCESS-OM3 release. Feedback can be to point out problems encountered, or positive to highlight what worked well.
Thanks to everyone involved in setting up OM3-25km, it’s great to have the beta version available now! I had a look at the instructions how to run the model and did a 1 year test run - it worked well.
Below is minor feedback I have on the instructions, having new users in mind. Overall, it’s really clear and with a good balance regarding the information load.
Under “Download and run ACCESS-OM3 configuration” → laboratory directory: could add information that it will be created when the model is run/payu setup. I.e. not when downloading the code.
worth noting that the experiment name will look slightly different in /archive, something like *-expt-9fs89ef8, I believe this comes from payu/version control?
“Change run length” link does not work (redirects to top of page).
Green box under “Run configuration“: Maybe worth re-iterating that the model won’t run if there is a work directory? (for people who only read the boxes…)
typo: “Edit ACCESS-OM3 configuration“: first sentence needs an “a”
typo: The run length is controlled by “stop_option” (empty space missing)
Regarding the restart options: I think the text could be clearer here, in particular on the difference between “restart period” and “restart_frq” (mentioned further down). I don’t have a good suggestion right now on how to change it though.
typo - full stop missing in paragraph “However, …” under “Pruning model restarts”
“Other configuration options“: I think the phrasing here could be more positive/supportive. It sounds a little like this is only something for more experienced people and is rarely done. However, I cannot think of many use cases where someone will want to learn how to run the model to only run the standard control case - that model output is available already. I understand that each perturbation is unique, and detailed info on manipulating the code is out of scope for this tutorial. But I think it would be nice to acknowledge that most (all?) people will want to change something, e.g. by listing common perturbations (changing the input files, parameterisations, vertical grid, …?) + giving a link to the OM3 configuration where more detailed info is given.
Hi @wghuneke, thanks very much for your feedback! These kinds of comments really lead to a better full release down the road. We’ve set up an issue to action this feedback but do get in touch if you’d like to provide further feedback or discussion on how your suggestions are implemented.
Note that there is a bug in the version of MOM6 used in the release-MC_25km_jra_ryf-1.0-beta configuration that means that the scalar diagnostics of global/area mean temperature and salinity are the model prognostic temperature and salinity, but are always reported as potential temperature and practical salinity.
The following diagnostics included by default in the release-MC_25km_jra_ryf-1.0-beta configuration are affected:
thetaoga (long_name: “Global Mean Ocean Potential Temperature”) is actually conservative temperature
tosga (long_name: “Global Area Average Sea Surface Temperature”) is actually conservative temperature
soga (long_name: “Global Mean Ocean Salinity”) is actually absolute salinity
sosga (long_name: “Global Area Average Sea Surface Salinity”) is actually absolute salinity
A fix for this bug has already been implemented in MOM6 and will be included in the next ACCESS-OM3 release