Review cable.nml

[JhanSrbinovsky]

On-going discussion, however a few details to follow

[JhanSrbinovsky]

Hey @SeanBryan51, perhaps you can explain this to me - I was playing with implementation of a namelist reader. Being in AM3 at the time I used an existing CABLE reader as a template. This is a JAC version and so has a million and one checks&balances as per JULES' request - at least back then anyway (most of which require JULES/UM modules). So I had to start stripping crap out. When I got to the actual OPEN(), READ(), I was reminded of how we did it in CABLE years ago - exactly like that - OPEN(), READ() CLOSE(). That was part of the efficiency of using a Fortran namelist. And then I got to the broadcast over MPI section in the JAC version.

I couldn't remember how we did that. It has since changed a bit, but enough is the same to remind me. I don't think we did do anything with broadcasting it over MPI. We just READ the nml on pe=0 and set MODULE variables. From then on the model just USEs them through there? Which then makes me wonder why UM/JULES bothers with broadcasting them?

[JhanSrbinovsky]

Maybe it is because it could already be decomposed by the time it is READ? In which case, in CABLE we don't do this right?

[SeanBryan51]

The main namelist is read here for CABLE offline (both serial and MPI):

CABLE/src/offline/cable_driver_common.F90

Lines 134 to 137 in dfafe87

	! Open, read and close the namelist file.
	OPEN(NEWUNIT=unit, FILE=CABLE_NAMELIST, STATUS="OLD", ACTION="READ")
	READ(unit, NML=CABLE)
	CLOSE(unit)

In the MPI case, every process currently opens and reads the namelist file.

[JhanSrbinovsky]

hmmm - OK so it is already decomposed. This raises another issue then that I was talking to @Whyborn about in the related AM3 issue/PR. The conclusion being that it is "better" to read it once on the master node and then broadcast it across al the workers. This is how it is already set up in AM3 BUT this is not something I really want to tackle in CABLE offline. Certainly not right now. Should we proceed assuming we do it the same way as in cable_driver_common for now. There has been talk about reinventing the MPI for many years. Is this still on the cards?

[JhanSrbinovsky]

Having started on this in AM3, and now attempting to implement it in offline first - some preparation/scoping of the problem has been done. Although it is a much bigger problem here. The reason being that in CABLE:main it is more of an issue to finalize/resolve fully the issue. In AM3 the threshold was less burdonesome.

Nonetheless, after making a start I think it is going to be beneficial to proceed in broadly the same stepwise manner. Several PRs will make up the full resolution of this issue.

The overarching goal is to have a more appropriate means of namelist configuration. At present we have a single namelist that absorbs (or at least potentially does) all possible, runtime configurable data. This includes (but is not limited to):

• pathnames to lookup files
• pathnames to desired output
• swiches for desired output
• switches to use specific models (CABLE wide)
• parameter values (CABLE wide)

I propose we separate these into 2 broad categories.

• science configs
• model configs

Where science includes configuration of switches specific to science schemes. i.e. soilsnow, canopy, casa-cnp etc

And model configs would include configuration of switches specific to the applications etc. i.e. offline single site with BGC, coupled (AM3) with BGC turned on.

It is true that model_configs could completely obfuscate science_configs anyway, but the same science_configs could be used across applications. Not so for model_configs. For example e.g. filename% output% are all meaningless in coupled but essential offline.

On the back end we can have MODULEs for science_opts, model_opts where everything is declared, namelist reading is organized etc.

On the front end we can have a file per namelist or one big file that has all the namelists and values to support a particular configuration. For example at present cable.nml in the offline/ directory is set up to run serial cable at Tumbarumaba. We might have a file called "config_tumba.nml" that contains:

&soilsnow
/

&canopy
/

&offline
/

&model
/

&surface_types
/

You know what - I find myself thinking "why?". Then I'm reminded of where this started. In CMIP6 I removed reading the namelist reading capability and hard-wired the values we wanted in the interface (long story as to why, discussed here). To recouple to UM13.1 for AM3 I borrowed a lot from CMIP6, meaning I dodged reading a namelist at runtime. It is I think pretty important that we re-establish this in CMIP7. So If I have to establish this all over again, I was hesitant in going to all that trouble to read a cable.nml that has become a junk drawer over the last 15 or so years. Especially cable_user%.

Anyway, my plan (even here) was to implement one .nml per PR. Keep cable_user% etc intact for now and just overwrite the values immediately after the read. When they are all done then revise the science code etc accordingly so I can drop the overwrite and kill cable_user etc. This is all quite a bit of work and then this would require changing the docs. All of this and we may get our marching orders next week - so I may just organize to read cable.nml in AM3 and park this for now.