jhan_JaC_Redux_Comments

Just noting comments from email discussions along the way:

Exactly – without the need to calculate land_alb in cable_rad_driver we have everything we need from the ancillaries/restart file to call our albedo code on the first time step – indeed we can get rid of JULES’ tile_albedo code from the CABLE branch (noting that we will need to do something about albobs_sc_ij).

          ```

What struck me was that we were passing a SW so we could calculate the albedo and update the SW, but i dont think it is from the previous timestep?

I don’t think we need it – the only reason why we need SW (from any time step) in cable_rad_driver is because we need it to calculate LAND_ALB_CABLE. At that point in the code both surf_sw_down and sw_down have to be form the previous timestep as they don’t get updated in rad_ctl until after the call to surf_couple_radiation

The validity of the JaC approach is currently being questioned, primarily because it is going to take years at this rate.

So I am currently shoving CM2-CABLE into JULES standalone 5,3. All the JULES side work looks to be done - except that I need to call CABLE.

On the radiation call - in the first instance possibly keep this as it is ?
 

I have decided to proceed with keeping as close as possible to CM2, possibly cleaning up some things along the way.

As of Thursday 14th February I manged to build and run with CABLE format, reading in CABLE progs using JULES IO running in StandAlone-Loobos - HOWEVER - there were no calls to CABLE. Friday afternoon started revision to explicit pathway of 5.3.

I have made changes necessary to all code and calls BUT this is following CM2 - So some vars, especially thosed USEd through modules do not exist - or live elsewhere in JULES - we have to find these and organize passing of everything from surf_couple_* down so that we can just use sf_* I hope as close as possible to existing.


[[Previous|jhan_JaC_Redux]]