-
Notifications
You must be signed in to change notification settings - Fork 0
jhan_JaCAux
*Find email from Ian that I have included somewhere here as useful correspondence
My impression of what we want to end up with - short of re-writing and fixing all of CABLE's faults is well currently it looks like this, whether it is the working ACCESS-CM2 or Hac (the only real difference being that the shared IO is different from the standalone IO). Ignoring calling radiation on the first timestep as it is a superfluous issue really.
JULES(io) -> coupling -> CABLE(io) -> CABLE science
We want to absorb the CABLE(io) into the JULES io. Thus JaC will look like
JULES(io) -> coupling -> CABLE science
=====================
The CABLE(io) that is being done and needs to be shuffled is the veg and soil parameters, and cable,nml. The veg and soil parameters are already declared and defined with default values as they should be for any namelist. The default values happen to be our best estimates at present anyway. So for CM2 I left it at this and didnt bother promoting them to NAMELIST/ vegin status, then organizing a call to read that namelist, and writing the namelist into rose-app.conf. A technicality wiill be that the namelist will be of the format
vegin%xxxx=17*yyy
The same goes for soil.
cable.nml is declared, has default values, is in rose-app.conf and is currently being read - BUT - it is being read from within CABLE so this read needs to be promoted to JULES io. Secondly the namelist needs to be split up. currently the version of cable,nml in rose-app.conf is tiny but there are actually dozens and dozens of switches/initializations/filenames etc belonging to cable.nml.
==========================
Calling CABLE "radiation" @t=1 is really an issue for:
coupling -> CABLE science
=======================================
So thinking of it this way we could just concentrate on updating JULES(io) to incorporate CABLE(io). So there isnt really anything new that needs to be done at this end, just re-arranging. Maybe we can call this JaC1.0
Lets now say that we insert CABLE into JaC1.0. So:
Jac2.0 = JaC1.0 -> coupling -> CABLE science
HaC1.0 = JULES(io) -> coupling -> CABLE(io) -> CABLE science
These should be identical.
We decided to make incremental steps towards a FULL cable implementation. If we had a complete JaC1.0 then we might next logically proceed in turn to each of the four calls.
However I am begining to question this as it is not really necessary and not really testable.
The skipped radiation call is a spanner in the works. BUT there is this issue of radiation at t=1 so we know that as to be resolved - so I am working on this bit and it makes sense to me to do this within HaC.
Jhan