How the tile data is read
RCF_ANCIL_ATMOS
- Creates the list ANCILS2UPDATE
- Reads the headers of ancils, by calling INANCILA_RCF_INANCILA
- Reads the data in ancil, by calling REPLANCA_RCF_REPLANCA
- Puts any 2D data into 1D land grid, by calling COMPRESS_TO_MASK
- Writes ancillary fields to dump, by calling RCF_WRITFLDS
RCF_INIT_FIELD_ON_TILES
In RCF_INIT_FIELD_ON_TILES for a single layer
- Read field into FLD_TILES_IN, by calling RCF_READ_FIELD
- Copy field description of FLD_TILES_IN into FLD_TILES_OUT,
by calling RCF_FIELD_EQUALS
- Allocate space for data for FLD_TILES_OUT.
- Convert between data types, and any horizontal interpolation
(here, we're probably going from REAL*4 to REAL*8), by calling
RCF_INTERPOLATE
- Data is then mapped into the right tile dimension in
FLD_TILES % DATA using TILE_MAP and
tile_map_tmp(:)=tile_map(1:ntiles)
IF ( MAXVAL(tile_map) < 0 ) tile_map_tmp(:) = 1
IF ( ntiles > 1 ) THEN
DO i = 1, ntiles
fld_tiles % DATA(:,i) = fld_tiles_out % DATA(:,tile_map_tmp(i))
-
The fields of interest
| STASH | Field | Source |
[recon] method of calculation due to difference in tiles |
| 225 | ACCUMULATED LEAF TURNOVER RATE PFTS |
1 (Allow recon to find default source) |
-1 |
| 229 | CANOPY WATER ON TILES KG/M2 |
8 (Initialise field via recon calculation routines) |
-FieldCalcs- |
| 230 | CANOPY CAPACITY ON TILES KG/M2 |
6 (Set to a specified constant) |
-1 |
| 231 | SNOW GRAIN SIZE ON TILES MICRONS | 8 |
-FieldCalcs- |
| 233 | SURFACE TEMPERATURE ON TILES K | 8 |
-FieldCalcs- |
| 234 | ROUGHNESS LENGTH ON TILES M | 6 |
-1 |
| 236 | TILE MODIFIED INFILTRATION RATE |
3 (Set to zero) |
-set-to-zero- |
| 237 | DOWNWARD SW RADIATION ON TILES W/M2 | 3 |
-set-to-zero- |
| 240 | SNOW AMOUNT ON TILES KG/M2 | 8 |
-FieldCalcs- |
| 241 | CANOPY SNOW CAPACITY KG/M2 | 8 |
-FieldCalcs- |
| 242 | SNOW BENEATH CANOPY KG/M2 | 8 |
-FieldCalcs- |
| 376 | SNOW DEPTH ON GROUND ON TILES (M) |
9 (Initialise field with dependency on other fields in
output dump)
| Field_Dependent_Calcs |
| 377 | SNOWPACK BULK DENSITY (KG M-3) | 9 |
Field_Dependent_Calcs |
| 380 | NUMBER OF SNOW LAYERS ON TILES | 9 |
Field_Dependent_Calcs |
| 381 | SNOW LAYER THICKNESSES ON TILES (M) | 9 |
Field_Dependent_Calcs |
| 382 | SNOW LYR ICE MASS ON TILES(KG M-2) | 9 |
Field_Dependent_Calcs |
| 383 | SNOW LYR LIQUD MASS ON TILES(KG M-2) | 9 |
Field_Dependent_Calcs |
| 384 | SNOW LAYER TEMPERATURE ON TILES (K) | 9 |
Field_Dependent_Calcs |
| 385 | SNOW LAYER DENSITY ON TILES (KG M-3) | 9 |
Field_Dependent_Calcs |
| 386 | SNOW LYR GRAIN SIZE ON TILES(MICRON) | 9 |
Field_Dependent_Calcs |
| 490 | DECOUPLED SCREEN TEMP ON TILES K |
4 (Set to missing data) |
-MDI- |
| 491 | DECOUPLED SCREEN TEMP ON SEA/ICE K | 4 |
-MDI- |
| 492 | TIME SINCE TRANSITION S | 4 |
-MDI- |
tile_map
I think
- If the tile pseudo level for input dumps (ainitial file) and
the order in [namelist:jules_surface_types]/tile ancillaries match,
the tile_map will automatically be set
so to 1, 2, ..., because tile level 1 of input dump matches tile
level 1 of ancillary and so on.
- However, if there is a mismatch, such as when I changed the tile
IDs for the non-vegetation tiles or we increase the number of tiles
- the source value for several stash fields is altered, because
it is assumed that the data can no longer be read from the input
dump
- if tile_map, is not set then tile_map_tmp is set to 1 for
1 for all relevant elements - i.e. I think only the first field
in ancillary files is used for all tiles - in both
rcf_init_field_on_tiles_mod.F90 and rcf_ml_snowpack_mod.F90
l_rcf_init_flexi
Comments from Richard Gilham
- Nearly 50 commits to be debug branches later, here’s a brief overview of the breadcrumb trail…
- The coupled model was crashing on the first call
- The problem was traced to a huge change in snow mass on the
first timestep
- A debug of the snow scheme showed that this was due to a
dodgy-looking value of sice
- Debugging showed that the variable was sensibly passed down
from the UM. The JULES code was not to blame
- Interrogation of the start dump showed that the value was
present there. The UM code was not to blame.
- Interrogation of the dump used for reconfiguration did not
show the problem. The reconfiguration was to blame.
- Exploration showed that the dodgy value for sice came from
the snowpack routine.
- Detailed debugging showed that the relevant calculation was
behaving as expected, and was being thrown by a dodgy value of ds.
- Detailed debugging then showed that the ds calculation was OK
and was being thrown by a dodgy (large) value for snowdepth
- Exploration showed that the snowdepth value was coming from
the init_snowdepth routine, which when compared to the input dump
was approx. 2.5 times different over Greenland, explaining the
magnitude of the change.
- Further exploration and debugging showed that this
calculation was being called when it didn’t need to be,
compliments of a slightly complicated IF statement.
- Consultation with John led to the suggestion of changing
l_rcf_init_flexi
- This ‘bug’ also exists in the triffid esm test at vn10.5. There
was no testing of l_rcf_init_flexi=.true. at 10.4.1. There’s a
couple of lessons to learn there I think.
Comments from John Edwards
- I agree with Richard [Gilham], but it may help to be aware of
the history. L_rcf_init_flexi was the original control on
flexible tiling, but then Maggie implemented tile_map that gives
much better control. I strongly suspect that l_rcf_init_flexi is
effectively obsolete, whatever the rose metadata may say. In
particular, I think
http://fcm5/projects/JULES/wiki/FlexiTiles#Reconfiguration is
out of date; it goes back to initial planning for flexible tiling.
As Richard says it’s only actually used ion one IF-test and I
think we could replace that with the tile-map containing 1 in each
element when going from a aggregate global dump.
- I think the semantic difficulty is
in the word “fix,” which suggests some sort of undesirable hack.
From the point of view of the operations that the computer will
carry out in the input fields, turning off l_rcf_init_flexi will
cause exactly the right things to happen. There is , however, a
problem with the documentation, which is out of date and with
the fact that the code does not issue a warning. In fact, I am
fairly certain that we should now remove this logical, but we do
need to think about that very carefully first, since, as you will
appreciate, it’s so easy to go wrong in this area.
- John Edwards has suggested we set this to False.
- The only place this seems to be used is in rcf_calc_tiles_mod.F90,
and it controls which bit of an IF branch is followed
- Both sections of the IF branch look to call roughly the same
rountines (mostly the RCF_INIT_* routines)
- The main difference looks to be that setting l_rcf_init_flexi
to false helps to take the branch using the DOMINANT TILE concept.
