penguian
commented
2 years ago @jxs599@nci.org.au commented
JULES Ticket #1223 on top of released vn 6.2 has diverged to use the term "work" variables. Where we have declared the type YET it remains empty. As these variables are ID-ed post implementing CABLE in full, they will comprise two types of variables. Those which are required to be kept across pathways AND those that are required to be kept across timesteps. Those that are required to be kept across timesteps should be elevated to prognostic status. This is postponed for now as it requires further fiddling with the JULES io (and later the UM io as well).
keyword_keepgitowner:jxs599@nci.org.autype_defect| by srb001@csiro.auCABLE code is divided into modules which broadly represent a particular (scientific)field or area of processes. i.e. radiation, canopy, roughness etc. CABLE defines a dozen or so TYPEs. Each of these TYPEs concerns variables that are predominantly used within a particular field. i.e. rad%, canopy%, rough% etc. Some of these variables do need to be maintained across a timestep.
Offline this is "naturally" achieved by instantiating the TYPEs at the PROGRAM level. Thus the scope of the TYPEs is global. Online in CMIP versions to date, this is achieved by using the SAVE attribute. Thus, even though the TYPEs are instantiated deep within a timestep, the memory space is forcibly/artifically maintained.
JAC, NGMS will not tolerate this. We can of course instantiate the TYPES at the PROGRAM level and pass them to CABLE. However, the sheer size of the data "package" that would need to be passed is concerning, and quite likely would not be accepted.
Fortunately there is a solution that also supports an intended direction in CABLE development. As noted above, CABLE defines multiple TYPEs. Broadly corresponding to a particular field. i.e. rad%, canopy%, rough% etc. Some of these variables do need to be maintained across a timestep BUT only a very small fraction of them. Thus, the theust of this ticket is to isolate these variables, which we denote as being of TYPE "state", which we can pass along to CABLE in JAC alongside those prognostics and parameters we have already.
This will be easily testable. For example, deallocating the members of the TYPEs each timestep will have zero impact UNLESS indeed that variable is required to be kept across timesteps. NB. I can't remember where, but there is an instance where this backfires and the var that is SEEMINGLY required to be kept across timesteps, shouldn't be.
The "data structure" of CABLE (i.e. all the TYPEs) can be left untouched [for now].
Issue migrated from trac:312 at 2023-11-27 11:39:22 +1100