ESM1.5 reconciliation: cable_data.F90

[rml599gh]

src/coupled/ESM1.5/CABLEfilesFromESM1.5/cable_data.F90 has ifdef ESM15 cases (for umin, LAI_THRESH and RAD_THRESH) but it is not clear to me whether the constants set here are even used. If I'm following this correctly, parameters set in cable_data.F90 end up in C%parameter_name. However, in the science code parameters now seem to be named Cparameter_name and are taken from the appropriate *_mod. For example, this statement from science/canopy/cable_canopy.F90. USE cable_phys_constants_mod, ONLY : CUMIN => UMIN

The *_mod files can be found in /src/params :

cable_maths_constants_mod.F90 
cable_other_constants_mod.F90  
cable_params_mod.F90  
cable_photo_constants_mod.F90  
cable_phys_constants_mod.F90

So, @JhanSrbinovsky, am I correct that in almost all cases, the constants are being picked up and used from these routines and the ESM1.5-specific cable_data.F90 is redundant? In this case, we could certainly remove the ifdefs, but to remove further confusion, it would be better if we could remove the routine completely.

So far I've found one case whereC%grav and C%capp are used in src/coupled/ESM1.5/CABLEfilesFromESM1.5/cable_cbm.F90

      IF( cable_runtime%um_explicit ) THEN
        CALL ruff_resist( veg, rough, ssnow, canopy, veg%vlai, veg%hc, canopy%vlaiw )
         met%tk = met%tk + C%grav/C%capp*(rough%zref_tq + 0.9*rough%z0m)
      ENDIF

but I notice this has been commented out in the CM2 code with this comment ! Height adjustment not used in ACCESS CM2. See CABLE ticket 197 @har917 - would you recommend removing this from the ESM1.5/6 version as well?

[JhanSrbinovsky]

This sounds familiar to a discussion I think we've had before. Probably in that 368_ branch I think I did remove this instance of _thresh, which as you say is unused and just a source of confusion. I'll have to go over this again. Just to clarify - using the CABLE main repo would be appropriate for you?

[JhanSrbinovsky]

In science/misc/cable_climate.F90, there are the following instances of ESM15:

science/misc/cable_climate.F90:# ifndef ESM15 science/misc/cable_climate.F90:# ifndef ESM15 science/misc/cable_climate.F90:# ifndef ESM15 science/misc/cable_climate.F90:# ifndef ESM15

at least in the CABLE: main/ version of this file ESM15 is NEVER defined, therefore all of these are executed. There is a `

ifndef UMCBL

`

around the entire module. Which again in the offline version is !!commented out so the module is always included. I will test this again in AM3 when rose-cylc is up again. I have done this before, blocked a module even if not called as there presence in the UM build necessitates that all modules USEd within are also supplied, and if someone down the line references for e.g. cable_parameters, we have a problem as this is an offline only thing. Nonetheless we might be able to work around this too.

[JhanSrbinovsky]

re: the cable_data issue. I will remove it and instances if that works for you ? And pass it by you to review the PR? All instances of USEing it are in ESM1.5 drivers.

[rml599gh]

It would be good to come up with some short tests that will confirm the expected behaviour, and perhaps do this as separate steps. We also need Ian's input on the line of code that is in ESM1.5 but not CM2. So maybe the sequence is Step 1: remove the ifdef and the ESM1.5 values for umin/lai_thresh/rad_thresh we suspect aren't used anyway. In theory this should make no difference to an ESM1.5 run - check with a 1 month test. Step 2: remove all code from the file except that needed for C%grav and C%capp. Again, should make no difference when running, unless we've missed other uses of C%. Step 3: Consult with Ian on removing the met%tk calculation that uses C%grav, C%capp. This will impact the run so we need some idea of what change to expect. The original ticket referenced in the comment talked about energy balance. Step 4: If we are comfortable with the impact of step 3 then I assume we can remove cable_data.F90 completely.

[JhanSrbinovsky]

Apart from that met%tk issue, all this does is say to to get the constants directly from cable_*_constants, rather than indirectly via cable_data. There was always the chance that a value of the constant was revised in the interim, but it seems the only constants in question were Tfrz, CAPP and GRAV. CAPP and GRAV have never changed. There has been a revision in the past decade of using 273.15 and 273.16 consistently as the freezing temp. ESM1.5 "might" be caught up in this. There was one instance of rad_thresh as well which I can't entirely vouch for.

[JhanSrbinovsky]

I guess what I mean is that the met%tk/ energy balance thing can be treated as a seperate issue. I wouldn't be surprised at all if Ian suggests it is less than straight forward, and it might not be a quick fix. The values of Capp and grav are the same wherever they come from

[rml599gh]

OK - I can see now from the changes that you've made how it is possible to swap in the cable_*_constants, and that you found many more places that needed changing that I'd noticed. It would still be good to do a before and after one month ESM1.5 run to confirm that this makes no change. Then some report of the test can go on the pull request.

[JhanSrbinovsky]

Absolutely. I always test everything to be sure. But you shouldn't need a month to find out if there is no change. If there is a change it is likely due to the *thresh values

[har917]

quick comment - the line met%tk = met%tk + ... HAS to be removed - it is incorrect scientifically and its location in the code (in cable_explicit:cbm, i.e after init_radiation is called in the albedo code but before the radiation is evaluated fully) is a key source of energy imbalance.

[JhanSrbinovsky]

quick comment - the line met%tk = met%tk + ... HAS to be removed - it is incorrect scientifically and its location in the code (in cable_explicit:cbm, i.e after init_radiation is called in the albedo code but before the radiation is evaluated fully) is a key source of energy imbalance.

I'll do this in a 2nd issue. not this cable_data issue