This issue documents the developments identified during & since the creation of the Rivers standalone executable used in LFRic-GC coupled via OASIS to the LFRic atmosphere-land component. Development began under MOSRS. The relevant tickets are listed below with work still required from each described. These enhancements would reduce the dependencies of the executable and naturally break the processing of the rivers ancillary data into smaller more manageable chunks.
#89 identified the need to be able to initialised inland_flow_rp & rivers_outflow_rp to a constant instead of using a dump or a file. This is required as a matter of urgency.
mosrs-jules:#1252 - Separate out fluxes used by rivers to simplify Rivers-standalone build
The Rivers-standalone build added with mosrs-jules:#1084 has each routine explicitly specified in make-river.cfg to identify areas where Rivers-standalone can be simplified and to prevent the dependencies from inadvertently growing. This ticket will simplify the Rivers-standalone build by separating out the fluxes use by the rivers from fluxes_mod to river_fluxes_mod.
init_drive could also be made more modular and split into a Rivers-standalone version calling the same routines as necessary.
mosrs-jules:#1558 - Refactor init_rivers_props and the processing of the rivers ancillary data
While the file size of init_rivers_props was vastly reduced under mosrs-jules:#1525 the routines it calls are too large and require splitting up to be coherent, more easily understood and to improve code management.
The namelist jules_rivers_props should be split into at least two; jules_rivers_grid & jules_rivers_props akin to jules_input_grid and the ancillary info namelists. mosrs-jules:#78 did not add the rivers ancillary to the dump stating "Care will be needed with rivers as current namelists are a mixture of grid information and actual ancillary information." Splitting the namelist into two should also mean that Rivers-standalone should no longer need information about the jules_input_grid reducing the dependencies of Rivers-standalone. This would also remove the grid info from jules_rivers leaving it for science options only.
NB. A complication to removing jules_input_grid which needs to be kept in mind, is the land fraction needs to be read in by Rivers-standalone, which is required by mosrs-jules:#1528 (inland basin flow as an OASIS send field for LFRic-GC5), which currently prevents the JULES grid info from being removed. Adding land fraction as an allowed variable to jules_rivers_props could be explored though to remove this dependency.
mosrs-jules:#1593 - Shared allocate routine for Rivers variables
The allocatable arrays for Rivers need some work noting that mosrs-jules:#1176 added these to an allocate routine, but are commented out. The number of rivers points are not calculated until the ancillaries are read so these need to be in two different routines one for those on the 2D river grid and one for those on river points.
Also it is inappropriate for all the allocatable Rivers arrays to belong to the same TYPE. Many of these allocatable arrays are only required during the initialisation. Therefore there needs to be a separate TYPE for the initialisation so they are not passed around the science code.
There is also more separation required between what is required by UM_TRIP. The fix from Dan Copsey for the Rivers component in LFRic-GC5 for ex1a mosrs-jules:#1608, correctly allocates an array that is only actually required by UM_TRIP.
mosrs-jules:#1609 - Add Rose stem test for Rivers standalone using LFRic-GC configuration
Difficulties porting LFRic coupled GC5 rivers component to ex1a highlighted a need for a GC standalone configuration in Rose stem. Diving data needs to be created from the LFRic coupled app OASIS send fields.
A separate Rivers-standalone Rose stem, test rather than the existing opts file nested inside a JULES run, will also highlight when the upgrade macro will not work for lfric_couple_rivers and if lsm_id != 3: needs to be added as in changeset:30603. It will also indicate when an LFRic apps branch is required to upgrade lfric_coupled_rivers, as this app keeps getting left behind.
This issue documents the developments identified during & since the creation of the Rivers standalone executable used in LFRic-GC coupled via OASIS to the LFRic atmosphere-land component. Development began under MOSRS. The relevant tickets are listed below with work still required from each described. These enhancements would reduce the dependencies of the executable and naturally break the processing of the rivers ancillary data into smaller more manageable chunks.
#89 identified the need to be able to initialised
inland_flow_rp&rivers_outflow_rpto a constant instead of using a dump or a file. This is required as a matter of urgency.mosrs-jules:#1252 - Separate out fluxes used by rivers to simplify Rivers-standalone build
The Rivers-standalone build added with
mosrs-jules:#1084has each routine explicitly specified in make-river.cfg to identify areas where Rivers-standalone can be simplified and to prevent the dependencies from inadvertently growing. This ticket will simplify the Rivers-standalone build by separating out the fluxes use by the rivers from fluxes_mod to river_fluxes_mod.init_drivecould also be made more modular and split into a Rivers-standalone version calling the same routines as necessary.mosrs-jules:#1558 - Refactor init_rivers_props and the processing of the rivers ancillary data
While the file size of
init_rivers_propswas vastly reduced undermosrs-jules:#1525the routines it calls are too large and require splitting up to be coherent, more easily understood and to improve code management.The namelist jules_rivers_props should be split into at least two;
jules_rivers_grid&jules_rivers_propsakin tojules_input_gridand the ancillary info namelists.mosrs-jules:#78did not add the rivers ancillary to the dump stating "Care will be needed with rivers as current namelists are a mixture of grid information and actual ancillary information." Splitting the namelist into two should also mean that Rivers-standalone should no longer need information about thejules_input_gridreducing the dependencies of Rivers-standalone. This would also remove the grid info fromjules_riversleaving it for science options only.NB. A complication to removing
jules_input_gridwhich needs to be kept in mind, is the land fraction needs to be read in by Rivers-standalone, which is required by mosrs-jules:#1528 (inland basin flow as an OASIS send field for LFRic-GC5), which currently prevents the JULES grid info from being removed. Adding land fraction as an allowed variable to jules_rivers_props could be explored though to remove this dependency.mosrs-jules:#1593 - Shared allocate routine for Rivers variables
The allocatable arrays for Rivers need some work noting that
mosrs-jules:#1176added these to an allocate routine, but are commented out. The number of rivers points are not calculated until the ancillaries are read so these need to be in two different routines one for those on the 2D river grid and one for those on river points.Also it is inappropriate for all the allocatable Rivers arrays to belong to the same TYPE. Many of these allocatable arrays are only required during the initialisation. Therefore there needs to be a separate TYPE for the initialisation so they are not passed around the science code.
There is also more separation required between what is required by UM_TRIP. The fix from Dan Copsey for the Rivers component in LFRic-GC5 for ex1a
mosrs-jules:#1608, correctly allocates an array that is only actually required by UM_TRIP.mosrs-jules:#1609 - Add Rose stem test for Rivers standalone using LFRic-GC configuration
Difficulties porting LFRic coupled GC5 rivers component to ex1a highlighted a need for a GC standalone configuration in Rose stem. Diving data needs to be created from the LFRic coupled app OASIS send fields.
A separate Rivers-standalone Rose stem, test rather than the existing opts file nested inside a JULES run, will also highlight when the upgrade macro will not work for lfric_couple_rivers and if
lsm_id != 3:needs to be added as in changeset:30603. It will also indicate when an LFRic apps branch is required to upgrade lfric_coupled_rivers, as this app keeps getting left behind.