How to correctly add an integer multi-option switch to lfric_apps namelist and pass to UM physics?

[MichaelWhitall]

Hi all!

In my UM ticket:
https://code.metoffice.gov.uk/trac/um/ticket/7815
I've added a new multi-option integer switch (i_update_precfrac) to the microphysics namelist, to allow the user to select between different methods for calculating something.
Then in a linked lfric_apps ticket:
https://code.metoffice.gov.uk/trac/lfric_apps/ticket/467
I add the same integer switch to the lfric_apps namelist and attempt to copy it into the UM physics in mphys_inputs_mod.F90.

The branches as they stand do not correctly set i_update_precfrac in lfric_apps. The problem seems to be that in LFRic, specifying the meta-data for my new switch to have
values=1,2
doesn't seem to result in the namelist item in the autogenerated code actually being integer kind (whereas in the UM we always define integer switches this way). So when the code tries to copy the lfric namelist i_update_precfrac to the integer one in the UM physics, the resulting integer is garble (a huge positive number).

I tried explicitly stating in the lfric_apps rose-meta that i_update_precfrac has
type=integer
But then if I do this, it won't let me specify the allowed 'values' and 'value-titles' to display in the GUI (rose metadata-check complains these are not consistent with 'type=integer').

I know I could just let the lfric one be non-integer, and then use a SELECT CASE block in um_physics_init_mod.f90 to tediously set the UM physics integer version separately for each allowed value of the lfric namelist version. But I'd much rather just have the name, meta-data and kind of my namelist inputs be completely consistent between the UM and lfric to avoid confusion! Does anyone know a way I can do this?

Cheers!
Mike

[stevemullerworth]

Hi Michael, sorry, I think you should take the "tedious" route :-)

We went to great effort to get away from "magic numbers" that make little sense to the uninformed unless they go to the original documentation. I do appreciate that many of the benefits are lost when things are translated by the um interfacing routine, but I'd rather we were not held back by this history, particularly as the fork of the UM physics is somewhat imminent.

[MichaelWhitall]

Ah OK; is the plan then that after the fork, the existing UM physics namelist source files will be deleted in lfric_apps, and the rest of the UM physics source will use the lfric_apps namelist variables directly instead? So the plan is essentially to convert all the UM physics integer switches to character strings?

Would it make less work in the future then if instead of trying to input an integer switch in LFRic, I change the UM side to use a namelist character string instead of an integer?

I don't think calling the UM's input integer switches "magic numbers" is really fair; the UM rose meta-data makes them display as lists of clearly-named options in the rose GUI, and in the source-code the allowed values for the integers are stored as meaningfully-named parameters. Forcing developers to change them all to character strings after the fork might run the risk of creating extra work for little gain?

[iboutle]

Hi Mike,

The LFRic "enumeration" type is essentially an evolution of the integer inputs in the UM. As you say, in the UM we mandate that we avoid the integer magic numbers where possible (in the rose gui, and in the code itself), but these still appear in the rose namelist (which plenty of people edit by hand), so there is an inherent inconsistency in still having to know what magic number relates to what option. As Steve says, the LFRic enumeration is still an integer behind the scenes, you just never need to know what that integer is - you always refer to it by the name (in the gui, in the namelist, in the code).

You're right that it's a bit annoying at the moment having to then set the UM options from the LFRic namelist - I think we would (in time) want to get rid of the UM namelists from the physics code in LFRic post-fork and just use the LFRic entries directly. If you name stuff the same in both namelists, this should be as trivial as just changing the USE statement in the physics code - it doesn't matter if the actual integer value changes behind the scenes as long as the switch name and named options are the same!

[MichaelWhitall]

Awesome thanks both for the clarifications; so in the code the multi-option switches are still integers, its just that the value for each allowed option is determined by a random number generator "under the hood" instead of being set by the developer? That's a good point about the processed namelist files still containing magic numbers (even if those are replaced by meaningful labels if you use the GUI/meta-data), and the new way of doing it in lfric fixes that. My one reservation is that, for a developer trying to debug issues with multi-option switches using print statements etc, it is now completely opaque how / why the integer ends up with the value it has unless you are already in the know. The system would be much easier for developers to work with and debug if everything could be found-out by tracing things through the source code. The more the underlying workings are hidden from developers (in the name of "separation of concerns" I suppose), the more time we will waste trying to find things!

[iboutle]

I guess I don't follow why you would ever want/need to know what the integer value is, even when debugging, unless you were trying to assign some meaning to the value (which is the exact thing we're trying to avoid!)

It's more about trying to make things easier for the developer than separation of concerns - in the UM you have to go through a long and laborious process to add a new namelist item, one which requires a lot of knowledge about the exact process of fiddly steps you have to follow to get it working. The LFRic method still requires some knowledge about how to do it, but it's a much easier process because there's much less to do.

[stevemullerworth]

Hi Mike, I have regularly had to debug in science code in LFRic app science code that I don't understand and that has with lots of options. When I have wanted to be 100% sure that the options in the namelist were being passed correctly, I did have to print out both the variable and the option value and check they are matching up as expected. But that's printing only one extra thing.

I don't have a lot of experience adding code that has several options, so I appreciate Ian saying out that it is easier to do. We've generally got positive feedback on usability of LFRic, even though it's a new and different system. We would like to do more to improve it in amongst all the critical priorities of supporting PS49 etc.

[stevemullerworth]

Sorry, I didn't intend to be rude about the numbers - it's just a term used by software engineers for values that have no implicit meaning. The reality is that the someone reading the code, such as a code reviewer, may not want to keep referring to the metadata, and sometimes the link between a value and its metadata is not obvious. Historically, some numbering schemes have sometimes got quite complicated.

The LFRic system converts the strings in the metadata into integers in the code. But the code hides their values (which are actually set using a random number generator!). The choice and option values will be held in variables named after the namelist and the option names which hopefully makes it easier to find the relevant metadata.

I wouldn't suggest trying to anticipate what happens after the change, as whatever you do there will be work to change away from your method of defining the options to the method set by the LFRic configuration system (and some recent work in support of new science requirements may change aspects of how we do it).

The migration away from the UM interfacing routine may be done iteratively over time as it is recognised that there is a lot to do and there will be other things to do that have higher priority.