UM_CBL pre-processor flag: do we want to remove?

[ccarouge]

@rml599gh I thought at some point you were trying to remove the UM_CBL pre-processor flag. Was this limited to a specific place or were you looking to remove it altogether from the code base?

I've encountered it under science/casa-cnp/bgcdriver.F90. If we need to keep it, then we can't have a library for the science/ part of CABLE that works across applications. So I am wondering if we could take it off.

It seems to be used to fence off the use of cable_phenology_clim(veg, climate, phen) but this is already fenced off with a runtime option:

CABLE/src/science/casa-cnp/bgcdriver.F90

Lines 103 to 108 in 3879551

	# ifndef UM_CBL
	IF (trim(cable_user%PHENOLOGY_SWITCH)=='climate') THEN
	! get climate_dependent phenology
	call cable_phenology_clim(veg, climate, phen)
	ENDIF
	# endif

So wouldn't it be enough to prevent the runtime option to be set to climate when running ESM1.6?

@JhanSrbinovsky do you have any comment on this?

[rml599gh]

I worked through the ESM15 ifdefs to get rid of those - and then UM_CBL started being used for other reasons. It would be great if we could get rid of these. I assume they have been set correctly in the code that was copied into the UM repository.
I agree that the UM_CBL in bgcdriver appears to be redundant. I think the other cases were in the declaration section of subroutines so it was less clear to me how those were best resolved.

[JhanSrbinovsky]

Just guessing, but I can almost guarantee that this is another instance of - at build time it assumes the runtime switch could be anything - therefore where is cable_phenology? OK USE module for cable_phenology. I cant build this module without 1/2 the offline directory etc - including netcdf writers and all sorts of stuff that it seemed better to exclude from coupled apps. Given that cable_phenology is only used in offline apps, this was the easiest way to block it.

In terms of a library, the only way I can think of (other than tracing back through dependencies and including a bunch of dangling code - which I dont think JAC will like) is either having app specific libraries (which kinda defeats the purpose) OR trying to re-write the code

[ccarouge]

The other way is to move bgcdriver.F90 into offline/ directory and have a different version of it for coupled applications stored under coupled/X/. That's a bit of an intermediary step: it highlights something isn't great in this subroutine that prevents compatibility across apps but doesn't require a lot of work to put in place.

I just found that we have the same issue with casa_inout.F90. Again, from the name it seems it could very well be under offline/ instead of science/. It's using casa_offline_inout.F90 and that one is calling casa_ncdf.F90 which we probably don't want in coupled applications. I haven't checked the differences but I've noticed there is already a casa_um_inout.F90, no idea yet if it's related to the casa_offline_inout.F90.

@JhanSrbinovsky what do you think? It duplicates code so not an awesome solution in the long term, but I'm not even sure how you remember all the names of the pre-processor flags and remember to switch them on/off.

[JhanSrbinovsky]

There is only UM_CBL for any coupled and the ESM15 was inplace when we included CABLE3 but then NOT to build/run it was only to maintain reproducibility with CMIP6 version of ESM1.5 (I hope you still keep this in mind @rml599gh now that we've removed some of them and obliterated the reproducibility aspect)

On the issue of having a coupled only version of bgcdriver etc - temporarily creating extra divergence in order to restore greater convergence- is something which I've done over and over. My only hesitation is that a proposed ESM3 would probably look different again (I haven't thought hard about it). Actually an ESM3 should be able to deal with either fairly easily. It isnt really a stretch to assume we have different drivers for casa offline/online. We do for cable.

[ccarouge]

For information purposes, this is linked to https://github.com/ACCESS-NRI/UM7/issues/21

I guess the other option would be to use the pre-processor flag correctly and set the flag to TRUE at compilation time when building the library. Considering the UM7 issue 21, there are more occurrences of the UM_CBL flag outside drivers. So moving the files to offline/ might not be the best recourse for all files and setting the flags at compilation time might be the best option.

@bschroeter please chime in if you have a preference on how to deal with that.

[JhanSrbinovsky]

setting the flags at compilation (depenntding on requirement I suspect)

this would result in two libs no? 1 with UM_CBL=FALSE, 1 with UM_CBL=TRUE

[ccarouge]

We don't need a library for offline runs. The library for the moment needs to be different for ESM anyway (for example, cable_define_types.F90 is completely different). The idea is not to have the same library everywhere, the idea is to have only one version of the source code people need to work on. So if you need to change something in CABLE for the ESM, you go and change it in the CABLE repository. If you need to change something for offline, same thing you change it in the CABLE repository. If the compilation results in a different compiled code for each application doesn't matter, what matters is all the source code is collocated without copying. That's the mid-term goal. And then if we can have exactly the same compiled code, great but that's for even later.

[JhanSrbinovsky]

so if that is the case, then we could ignore a CABLE/ in UM7 altogether?

At the moment what is getting in the way is that if you/we make the changes in the CABLE repo you have to copy them to UM7 anyway. If the changes apply to the UM7 anyway (and no other CABLE app), then why bother with the double handling?

@aidan suggested at one stage that it would be possible to download from the CABLE repo in spack. The only obstacle I see here is that CABLE code has to be built by/within the UM. If this is possible there is no need of a library. Any FPP switches can (at least in the UM) can be switched at compile time - this is assuming we dont mange to get rid of them.