Add src/coupled/AM3 directory

[JhanSrbinovsky]

AM3 application specific see issue #370

Fixes #370

Type of change

Hopefully will cover CM3 as well

• [? ] New or updated documentation

Checklist

• [? ] The new content is accessible and located in the appropriate section.
• [?] I have checked that links are valid and point to the intended content.
• I have checked my code/text and corrected any misspellings

---

📚 Documentation preview 📚: https://cable--371.org.readthedocs.build/en/371/

[JhanSrbinovsky]

This file is later removed. In its stead is the standard version in utils/

[JhanSrbinovsky]

JAC adopts UM/JULES practice of declaring TYPE (and corresponding pointer) in its own file which also contains subroutines for allocation, deallocation, association, nullification, initialization

[JhanSrbinovsky]

JAC adopts UM/JULES practice of declaring TYPE (and corresponding pointer) in its own file which also contains subroutines for allocation, deallocation, association, nullification, initialization

[JhanSrbinovsky]

JAC adopts UM/JULES practice of declaring TYPE (and corresponding pointer) in its own file which also contains subroutines for allocation, deallocation, association, nullification, initialization

[JhanSrbinovsky]

JAC adopts UM/JULES practice of declaring TYPE (and corresponding pointer) in its own file which also contains subroutines for allocation, deallocation, association, nullification, initialization

[JhanSrbinovsky]

JAC adopts UM/JULES practice of declaring TYPE (and corresponding pointer) in its own file which also contains subroutines for allocation, deallocation, association, nullification, initialization

[JhanSrbinovsky]

JAC adopts UM/JULES practice of declaring TYPE (and corresponding pointer) in its own file which also contains subroutines for allocation, deallocation, association, nullification, initialization

[JhanSrbinovsky]

JAC adopts UM/JULES practice of declaring TYPE (and corresponding pointer) in its own file which also contains subroutines for allocation, deallocation, association, nullification, initialization

[JhanSrbinovsky]

JAC adopts UM/JULES practice of declaring TYPE (and corresponding pointer) in its own file which also contains subroutines for allocation, deallocation, association, nullification, initialization

[JhanSrbinovsky]

JAC adopts UM/JULES practice of declaring TYPE (and corresponding pointer) in its own file which also contains subroutines for allocation, deallocation, association, nullification, initialization

[JhanSrbinovsky]

JAC adopts UM/JULES practice of declaring TYPE (and corresponding pointer) in its own file which also contains subroutines for allocation, deallocation, association, nullification, initialization

[JhanSrbinovsky]

JAC adopts UM/JULES practice of declaring TYPE (and corresponding pointer) in its own file which also contains subroutines for allocation, deallocation, association, nullification, initialization

[JhanSrbinovsky]

JAC adopts UM/JULES practice of declaring TYPE (and corresponding pointer) in its own file which also contains subroutines for allocation, deallocation, association, nullification, initialization

[JhanSrbinovsky]

Phasing out - deliberately inheriting TYPEs from independent files as cable_def_types is USED throughout code. Also uses grid_constants - attempt to clarify single source where constants are defined. Offline, other apps can adopt this JAC-ified file after appropriate work done there (and of course independent TYPE files)

[JhanSrbinovsky]

explicit and implicit versions established to avoid nested/spaghetti IF conditions. Offline probably needs _impl version

[JhanSrbinovsky]

These are namelist read in AM3. Should be extended to JAC and offline. Should incorporate namelist reading for PFT, soil params. I will have to check PFT lookup and phenology issue again. From memory, I think I decided on an ancillary (spatial) approach there.

[JhanSrbinovsky]

analogous to jules_land_.....

i.e. surf_couple layer is the branching point.

SELECT CASE(  LSM_ID )
CASE( jules) 
  CALL jules_land_
CASE( cable) 
  CALL cable_land_

SUBROUTINE cable_land_

CALL cable_

[JhanSrbinovsky]

Essentially a JULES routine, still needs to be called but _cbl version differes substantially from corresponding _jls version

[JhanSrbinovsky]

Essentially a JULES routine, still needs to be called but _cbl version differes substantially from corresponding _jls version

[JhanSrbinovsky]

Essentially a JULES routine, still needs to be called but _cbl version differes substantially from corresponding _jls version

[JhanSrbinovsky]

this is from JAC - it was necessary as rad call is before main allocation of all TYPEs and not all were needed for rad call anyway. I think I have passed these on etc where necessary BUT now that we are declaring/allocating all TYPEs at top-level - this might be wasteful doubling up requiring compensating changes later on. Unless there is a fault with the way this is working I recommend we deal with this at a later time

[JhanSrbinovsky]

See cable_land_ discussion above

[JhanSrbinovsky]

This needs to be revised: same subroutiineexists

science/canopy/cbl_LAI_canopy_height.F90
coupled/JAC/control/shared/LAI_canopy_height_cbl.F90
coupled/AM3/control/cable/shared/LAI_canopy_height_cbl.F90

[JhanSrbinovsky]

Analogue of jules_fields_mod, the UM also has atm_fields_mod. Basically it is a data module where global fields are instantiated

[JhanSrbinovsky]

should expand this model reader to include other model switches e.g. Medlyn, or_evap. Here it is just for icycle. Implemented this so same executable could be used for CM3, ESM3.

[JhanSrbinovsky]

definitely include offline and do away with hard-wired versions in grid_constants

[JhanSrbinovsky]

from JAC

[JhanSrbinovsky]

declare params for vegin/soilin. Other TYPE dec files should be shared/ as well

[JhanSrbinovsky]

declare etc progs

[JhanSrbinovsky]

declare etc cable types canopy% etc

[JhanSrbinovsky]

compute "mp" at toplevel

[JhanSrbinovsky]

it appears this isnt even being used anywhere, however a remapping that was used in CM2

[JhanSrbinovsky]

set icycle from namelist

[JhanSrbinovsky]

initializations at interface init at t=1/update per dt

[JhanSrbinovsky]

initializations at interface init at t=1/update per dt

[JhanSrbinovsky]

initializations at interface init at t=1/update per dt - governs all per "module" calls

[JhanSrbinovsky]

map per PFT onto per mp

[JhanSrbinovsky]

technical packing of fields

[JhanSrbinovsky]

see cable_fields comment - this is the casa-cnp analogue

[JhanSrbinovsky]

cnp analogue

[JhanSrbinovsky]

cnp analogue

[JhanSrbinovsky]

unlike other apps I haven't setup namelist reader to read these values from namelist yet - however this can/has serve(d) as the declaration list for the namelist. Default values are same as those used in offline, JAC etc

[JhanSrbinovsky]

unlike other apps I haven't setup namelist reader to read these values from namelist yet - however this can/has serve(d) as the declaration list for the namelist. Default values are same as those used in offline, JAC etc

[JhanSrbinovsky]

@bschroeter, @ccarouge, Coming back from leave again I am trying to figure out what I was up to before I left. It seems I have been building other branches onto of a quasi-main branch that assumes these things are going to merge. Needless to say that this is less than ideal and messy. This particular "part" of the AM3 merge is by far the largest and independent of any other application. It would be good to get this in so I can go back to branching from main and not have to merge this OR branch from here etc etc

[ccarouge]

@JhanSrbinovsky Yesterday I was just discussing with Ben and we were wondering what is the purpose of the src/coupled/ directories? I'm not sure if these files are ever used and if the goal is to eventually use them. Could you clarify please?

[JhanSrbinovsky]

I'm assuming you mean these:

coupled/
├── ACCESS-CM2
├── ESM1.5
├── JAC
└── shared

These are all the drivers per coupled applications which "were" supported. So for ESM1.5, the CABLE component grabs

├── coupled/ESM1.5
├── coupled/shared
├── params
├── science
└── util

offline builds grabbed:

├── offline
├── params
├── science
└── util

coupled/ are somewhat redundant redundant as unless actually in the appropriate JULES/UM7.3 they are useless. It was more or less like not being able to throw them away. In theory, it is (and has) been the case that having them locally to at least consult (document) is useful. In theory specific application dirs should get smaller as things are dealt with in coupled/shared/, however the reality is that we've rarely had time AND a checkout of the relevant parent would be in the picture anyway.

[ccarouge]

This can go in.