esm16 directory is faulty

[JhanSrbinovsky]

It was intended that the coupled/ESM1.5 should be frozen (if not removed altogether) and replaced (at least for now) with an esm1.6 directory, where in future development should take place (or at least that was my understanding).

The contents of ESM1.5, esm16 directories are below:

I have no idea what these files facilitate as they appear to be a mixture of random files not required, duplicates and those that most definitely are required, are not there.

ESM1.5/
├── CABLEfilesFromESM1.5
│   ├── allocate_soil_params_cbl.F90
│   ├── allocate_veg_params_cbl.F90
│   ├── cable_cbm.F90
│   ├── cable_define_types.F90
│   ├── cable_explicit_driver.F90
│   ├── cable_hyd_driver.F90
│   ├── cable_implicit_driver.F90
│   ├── cable_iovars.F90
│   ├── cable_rad_driver.F90
│   ├── cable_um_init.F90
│   ├── cable_um_init_subrs.F90
│   └── cable_um_tech.F90
├── cable_pft_params.F90
├── cable_soil_params.F90
├── cable_surface_types.F90
├── casa_landuse.F90
├── casa_types.F90
└── casa_um_inout.F90

1 directory, 18 files
gadi:coupled> tree esm16/
esm16/
├── cable_define_types.F90
├── cable_iovars.F90
├── cable_LUC_EXPT.F90
├── cable_phenology.F90
├── cable_surface_types.F90
├── casa_landuse.F90
├── casa_ncdf.F90
├── casa_offline_inout.F90
└── casa_um_inout.F90

[JhanSrbinovsky]

@har917, @rml599gh - our conversation this morning seems rather obsolete. i.e. We can't use this repo. as is. Perhaps it would be better to just use the UM7 repo. Transfer any science/ changes back here and perhaps leave the interface layer here as it will only ever apply here anyway. Although - the interface layer between future coupled apps we want as close as possible, so maybe there is a need to keep a coupled/shared directory.

[JhanSrbinovsky]

If the esm16 directory is removed it is equivalent then to what's in UM7 repo. I was of the impression that all we were doing was

mv ESM1.5/ to ESM16/

and restore the tagged ESM1.5/ from the CMIP6 version. This builds. It isnt running ATM, Ill get back to you when I know why

[JhanSrbinovsky]

ok - rectified. @har917 @rml599gh

The UM7 side had the sf_impl side of the increment mod that Ian made recently, but when I reverted to main@HEAD on the CABLE side - I didnt have the corresponding implicit_driver side arg list and so things got messed up. Chalk up 1 for UM7 side development. Also, potentially, 2 for the UM7 side, if indeed we are going to use spack builds etc. we need the UM7 version of CABLE to have immediate access to those developments. 3. Some of thouse may sit across both UM & CABLE as this one did. 4. We can negotiate to port science changes back to CABLE:main quickly if indeed there is someone in as urgent a position as us to put Fastback together in the next week. 5. Most of the proposed change (if not all) dont impact cable offline anyway. They do UM7, so why first do them on CABLE side?

[har917]

Some brief (probably self-evident and not that helpful) comments:

• it's likely that we need to work to an interim solution for the current ESM1.6 work, then convert to a more sensible structure later.
• most of the challenge here is because we don't have a clear (stable, documented etc.) picture of what we're aiming for.
• the critical area for design is the form of the interface layers (so offline drv<->science, offline drv <-> output, um <-> coupled drv <-> cbm<-> science, drvs <-> initialisation) - this is likely the best place to draw any boundaries between repos and a CABLE library (though we also need to keep in mind JAC).
• (I think) we will need a step between CABLE in CABLE3:MAIN and CABLE in the ESM or AM3 - i.e. likely need 2 instances of CABLE even though we're trying to avoid this. It is unlikely that we'll get our offline developers to build the requisite coupled-side changes so there needs to be at least a check before offline devs can be tested in coupled.
• we need a better way to connect code changes on the UM and CABLE sides (something like the UKMO svn linked tickets but within git).

More generally - aside from the technicalities of getting the coupled models to work - all CABLE dvs should be tested within offline first. Ideally we should be working towards a codebase where there doesn't really need to be differences (in the science or initialisation) between coupled and offline.

[JhanSrbinovsky]

When I say rectified - I just mean the model runs again - post ad-hoc removal of the faulty esm16 directory which is still an issue