reconcile with ESM1.6 version of CABLE - science

[JhanSrbinovsky]

Minor differences here - discussed below

Essentially no changes required here HOWEVER the few changes to be made:

Port back to ESM16

[JhanSrbinovsky]

EezyPeezy

casa_sumcflux.F90.esm16
casa_feedback.F90

offline (CABLE:main) has changed a comment from cable_driver to cable_serial
- just accept this on ESM16 side

Too hard basket: UM_CBL

bgcdriver.F90

#define UM_CBL
#ifndef UM_CBL
USE pop modules

Removing the #define means including all the pop subroutines in the build.

@bschroeter @ccarouge

come to think of it - this is only a legacy exclusion. Given that ESM16 is effectively an ad-hoc application - we can d whatever we want with it. Im inclined towards just including all this code in the build eve if it is never called. Of course it needs to be verified whether this is even possible.

- Test this in sister issue in UM7 repo
- In the first instance can just leave it and in UM7 I will remove "!" before building

casa_inout.F90.

same issue as above. except that in this instance the module it wants to USE is casa_offline_inout_module. There is no need for this online of course and as it intersects with netcdf modules for IO (which is also redundant online) it could open a can of worms including it.

- In the first instance can just leave it and in UM7 I will remove "!" before building

casa_rplant.F90

same issue as above. except that in this instance the module it wants to USE is landuse_constant. I'm not sure where this leads or the impact or if indeed it is necessary to switch on LUC when we move to post PI runs

- In the first instance can just leave it and in UM7 I will remove "!" before building

[JhanSrbinovsky]

cable_climate.F90

same issue as above. except that (from memory) #ifdef () is around whole subroutine

- In the first instance can just leave it and in UM7 I will remove "!" before building

[JhanSrbinovsky]

cbl_soilsnow_init_special.F90

CABLE:main version is more up to date.

Port back to ESM16

cbl_soilsnow_main.F90

CABLE:main version is more up to date.

Port back to ESM16

[ccarouge]

EezyPeezy

casa_sumcflux.F90.esm16 casa_feedback.F90

offline (CABLE:main) has changed a comment from cable_driver to cable_serial - just accept this on ESM16 side

Too hard basket: UM_CBL

bgcdriver.F90

#define UM_CBL
#ifndef UM_CBL
USE pop modules

Removing the #define means including all the pop subroutines in the build.

@bschroeter @ccarouge

come to think of it - this is only a legacy exclusion. Given that ESM16 is effectively an ad-hoc application - we can d whatever we want with it. Im inclined towards just including all this code in the build eve if it is never called. Of course it needs to be verified whether this is even possible.

- Test this in sister issue in UM7 repo
- In the first instance can just leave it and in UM7 I will remove "!" before building

casa_inout.F90.

same issue as above. except that in this instance the module it wants to USE is casa_offline_inout_module. There is no need for this online of course and as it intersects with netcdf modules for IO (which is also redundant online) it could open a can of worms including it.

- In the first instance can just leave it and in UM7 I will remove "!" before building

casa_rplant.F90

same issue as above. except that in this instance the module it wants to USE is landuse_constant. I'm not sure where this leads or the impact or if indeed it is necessary to switch on LUC when we move to post PI runs

- In the first instance can just leave it and in UM7 I will remove "!" before building

All the files listed here are stated to come in with the shuffle of files and be tested in the build then. I would propose we run the shuffle script instead, open the branches for UM7 and CABLE with the result, check the result is correct (most likely will need some changes) and then test builds from there instead of having several pieces of work doing the same thing.

[JhanSrbinovsky]

note - this didnt go to PR as there ae no files to change in CABLE repo . The !commnts can come in whenever. The #fpp related stuff will impact what we are actually bringing in via the library. ATM these #um_cbl instances date back to CMIP6 at least. They are pretty redundant now in the sense that the entire POP code etc is there anyway. The problem is whether this code will actually build in the UM. ATM they are excluded as dependencies