Skip to content

jhan_JaCAux_Proposal

Jump to bottom
Paul Leopardi edited this page Oct 8, 2024 · 15 revisions

Proposals: Jhan

This is modified since our meeting to include more detail.

Aiming to get CABLE in for JULES-5.8

  • This push will leaves CABLE (lsm_id=2) non-compliant with LFRic - to the point of being unusable in LFRic (for now) but that has pretty much always been the case anyway

Assumptions:

  • Ticket #940 at least makes it into JULES-5.7
  • Martin’s land/sea separation work makes it into JULES-5.7

Proposal 1: Jhan

Prior to release of JULES-5.7 we need to :-

  • merge HAC into 5.6 and working on Gadi (3 working days)

      -- [[Update HAC|jhan_JaCAux_Proposal_updateHAC5.6_draft1]] to branch off JULES trunk@HEAD(16253 - currently [this is 5.6+])

  • merge Ticket 940 into HAC-5.6 (5 working days) -- Yet to be seen BUT I think there are modifications which I have made that will conflict with a straight-forward merge - AND I am sure there are additional requirements in the initialisation/ that have not yet been addressed. Regardless I think this will erquire more intensive collaboration between myself and Danny

  • Clean up HAC as much as possible

  • isolate and migrate vars to top-level scope

  • Clean up HAC as much as possible

  • Declare CABLE model types as they exist now (more or less - the types do need to be dramatically cleaned up. Probably halved!!) at highest level in JULES

    ```
* Pass them to CABLE

* But do not allocate them until we get to CABLE (I've tested this can be done albeit in a dummy model)

* Probably don't need to this for rad% vegin% etc
```

  • From here on CABLE is a work in progress

    * Separate canopy/soilsnow

* Work on these separately

* etc  etc etc

Some commentary from Ian - not sure if useful or not===========

Is it worth bundling/organising the necessary Tickets according to action? e.g. Tickets linked to

* inputs (any remaining to do?)
* output (any urgent changes needed? e.g. for tiled soils)
* internal to CABLE
* directory structure
* implementing the definitions/allocations of CABLE TYPED variables
* passing additional data layers to cable_radiation through JULES control (and the UM?)
* passing additional data layers and variables to cable_explicit through JULES control (and the UM?)
* passing additional data layers and variables to/from cable_implicit through JULES control (and the UM?)
* ?passing additional data layers and variables to cable_extras
* adjustments to the CABLE-JULES layers in response to Martin's land/sea split etc.
* (LATER) corresponding changes in UM to get variables/data to the appropriate places

NB: since CABLE needs additional variables/data layers in the surf_couple_explicit etc. argument list even though this effort is focused on JULES stand-alone we will need to create dummy variables in some UM code (unless #ifdef are still allowed)

Internal to CABLE we have (at least)

* removing USE statements as a means to pass data around -> argument lists
* removing the hardwired indices (and other 'roadblock' coding standards issues
* removing the use of internal memory between calls (both from rad-explicit-implicit-extras but also between time steps)
* adjusting how the prognostic bank structure works in cable_implicit (because it uses internal memory between calls)

One key decision that needs some thought concerns how/where CABLE updates it's soil temperatures/moisture: At the moment CABLE updates it's soil state variables on the second call to cable_implicit then uses internal memory to pass to cable_extras for use in the output diagnostics. We will either need to generate a means of getting the soil information out of cable_implicit, up to JULES control/UM, and back down OR recalculate the entire energy balance in cable_extras.

A discussion around whether CABLE could have a TYPED variable inside JULES so that we can pass stuff like this around in one structure.

Previous

Clone this wiki locally