-
Notifications
You must be signed in to change notification settings - Fork 132
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
verbose diagnostic output for model configuration #468
Conversation
This PR is responsive to #403 and #456. Here's a list of ES-DOC items not (yet) included in the overview section of the diagnostic file:
hardwired parameters - do we want to move any of these to namelist?
|
It would be good to have Pstar in the namelist. I would also suggest to include Cstar in the namelist. Thanks! |
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 fine to me. I had a look at the sample output file. I might play a bit more with the formatting so things align a bit more, but that's just me. I think it looks good. I'm fine with this being merged now and doing more work later. Or if you prefer to add more stuff now, that's OK too.
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.
This is a nice step toward better publication of CICE results.
I am running a base suite with the current version and will post results when they become available. I've decided not to move parameters into namelist in this PR, and will create an issue to do this. However I included commented-out write statements in the new diagnostic information for them, as placeholders: Pstar, Cstar, floediam, hfrazilmin. One of our tests were using kdyn=3, which is not a valid value, so I added an abort for that case and changed those tests to kdyn=0, which I think is equivalent to what was happening. Now that the diagnostic output is easier to interpret, I see that some of our test cases don't make sense from a physical standpoint. We can continue to improve this output, but I think this is a good start. I'm debating whether it's worth doing this for Icepack too. |
Test results: |
Regression test results with base_suite are here: I don't understand why the roundrobin tests worked on the v6.1.2 runs but not in the modified code. These have never worked on badger. I think this PR is ready to go. My last commit fixes the typo in the test report summary:
|
@eclare108213, you should feel free to merge PRs that are ready. I wasn't around much today but will merge it now. |
write(nu_diag,1007) ' k2 = ', k2, ' free parameter for landfast ice' | ||
write(nu_diag,1007) ' alphab = ', alphab, ' factor for landfast ice' | ||
write(nu_diag,1007) ' threshold_hw = ', threshold_hw, ' max water depth for grounding ice' | ||
write(nu_diag,1007) ' Ktens = ', Ktens, ' tensile strength factor' |
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.
@eclare108213, I think this was overlooked but Ktens
should not be inside the if (basalstress)
block...
Ktens
can be used even if the seabed stress parameterization is not used...
Thank you @phil-blain, I'll fix this in a separate PR. |
Add plain-English descriptions of high-level configuration and parameter choices to diagnostic output
E. Hunke
https://github.com/CICE-Consortium/Test-Results/wiki/0c07cbf2e1.badger.intel.20-06-13.001452.0
The intent here is to create an "overview" section near the top of the diagnostics file that can be easily referenced by users when writing model and/or configuration descriptions for publications. This block (or the whole output file) might also be published as supplementary information. I tried to pull out and highlight the information that would be most likely to appear in a refereed journal article's text, or that the CMIP6 ES-DOC requests, generally the high-level types of options. This PR currently covers much of the ES-DOC request, but not everything.
One difficulty is that this section is written before some of the needed variables have been read in or defined, so they can't appear until later (e.g. BGC, domain info). Should we wait to do all of the writing until the end of the initialization stage? The writes were originally implemented to aid debugging, not for documentation (which came later).
Another issue is that some of the parameter values for the ES-DOC request are hard-wired, and don't appear here. I may add to this PR, but wanted to get feedback before going further.
I have run a base suite without regression testing (linked above). The fails are the usual ones for badger (40 procs). I will go through each of the output diagnostic files to make sure that the output looks they way I expect it to. Here is a sample cice.runlog diagnostic output file:
cice.runlog.txt