Nml draft3 #588
Nml draft3 #588
Conversation
…91 - 0 failed, 20 passed reading subroutine for namelist that can be used aacross apps
|
I can test this outside of benchcab although I am curious how to specify different namelists (or set of namelists) for the development branch. @SeanBryan51 do you know, or know who would know? |
|
OK - so MPI build is failing.Not surprising as I haven't made same Changes to MPI driver. Have more urgent matters to address right now |
|
@JhanSrbinovsky you likely won't be able to test the changes here with benchcab. Benchcab is currently hard wired to search for only the namelist files cable.nml, pft_params.nml and cable_soil_parm.nml, and so the other namelist files you have introduced won't get picked up. This is a bit of a flaw in how benchcab was designed IMHO since CABLE configurations and their details such as input files should ideally be kept out of the benchcab source code and be runnable outside of benchcab (see issue: CABLE-LSM/benchcab#294). Unfortunately we haven't addressed this yet. I assume these changes won't be backwards compatible? If not, these changes will likely need to be accompanied by changes to benchcab and any other existing CABLE configurations as it will likely break those configurations. |
|
@SeanBryan51 thanks. A further complication to that, and hopefully to address your backwards compatibility question is that main: using cable.nml should yield identical results as nml_draftX: using a modified cable.nml & x.nml & y.nml etc. For the moment I dont plan on changing anything. The additional benefit to having numerous nml files is that it is not onerous to include every switch in there and set them as default or just comment them out. This is what JULES does and has been helpful to know what switches are even possible without digging through code. Not to mention what arena you're in. I mean for example if you have no interest in BGC then you're not gonna look in the bgc.nml |
|
As Sean highlighted, this change has a lot of dependencies on other things. I understand the appeal of it both in terms of organising the CABLE namelists and synchronising the coupled and offline developments. But I do not think, the current period is the best time to look into this. |
|
I have already had to write namelist readers for online applications. Ideally we would benefit from a few more. AM3 is already reading a cable surface_types.nml, model_env.nml. (In addition to the pftparams.nml, soilparams.nml) The majority of what is in currently in cable.nml, is hard-coded. This has to be moved up to namelist status. This all takes place outside of CABLE: main's purview so it can be done independently. I was going to do it for offline at the same time, but the blocker is benchcab, otherwise I have done it (or at least started on it. It was a while back but I probably added the first in as a proof of concept test.) And it checks out in our original test suite. Although I neglected to do an MPI test. Which it will fail ATM. ESM1.6 is most likely retiring after CMIP7 (although the throughput is a huge advantage) so back-porting is not on my dance card right now. |
Description
There has been movement in the coupled applications of CABLE to use namelists where possible. The current namelist, cable.nml has not been reviewed for ~15 years and just had extra things thrown in. In the coupled space, namelists are more nuanced and far greater in number than just one. Rather a seperate namelist exists per specific usage. For example. using a recent development as an example, we have a cable_surface_types.nml, in which the cable_surface_types are declared at runtime, or pft_params.nml initialises the PFT parameters. It is envisaged that model specific namelists (e.g. canopy.nml) will be developed where for example cable_user%ssnow_POTEV can be replaced by a more descriptive , meaningful, better placed and documented model switch like "soil_potential_evap_model" can be used.
cable_user % TYPE - many moons ago when CABLE was first established as a community model, we endeavoured to make it easy for community members to submit their developments back to CABLE, through the repo. Our requirement was simple, wrap the development under a switch and with switch off, the output should be reproducible. cable_user TYPE was a simple mechanism for "users" to simply add a member to the TYPE and initialise it at runtime. Needless to say that this needs cleaning up after years of misuse (by me as well).
However, in the first instance, we have split cable.nml into cable.nml (to be read across apps) and offline.nml that is specific to offline applications only. A consideration to be kept in mind is that readers etc should be consistent with what will (and in some cases already is) working in AM3. We are not going to worry about ESM1.6. It may be possible, but that is yet another version of the UM, and significantly we want the code locked down soon, and this is likely its last run around the block anyway.
Type of change
Please delete options that are not relevant.
Checklist
This requires corresponding updates to the namelists in benchcab. Also require proper documentation.
Testing
Are the changes bitwise-compatible with the main branch? If working on an optional feature, are the results bitwise-compatible when this feature is off? If yes, copy benchcab output showing successful completion of the bitwise compatibility tests or equivalent results below this line.
Are the changes non bitwise-compatible with the main branch because of a bug fix or a feature being newly implemented or improved? If yes, add the link to the modelevaluation.org analysis versus the main branch or equivalent results below this line.
Please add a reviewer when ready for review.
📚 Documentation preview 📚: https://cable--588.org.readthedocs.build/en/588/