Even with the same soil ancillary information across tiles within the same grid-cell, the state variables like moisture and temperature should be different for each tile/pft due to different albedos, leaf area index, root distribution etc. I’m not sure if anyone has ever looked carefully to see how different they are across a grid-cell - it is something I’ve wondered about especially when we are looking for the impacts of forestation etc.
1 Like
@RachelLaw I have a question about the original script you used. Am I right in thinking that even if a grid cell on the new vegetation map contains the same vegetation types as on the old vegetation map (or at least shares some fraction), a local area averaging is still applied?
For example, a sample grid cell on the old vegetation map contains 50% evergreen broadleaf and 50% C3 grass, and on the new vegetation map, the grid cell contains 50% evergreen broadleaf and 50% C4 grass. The nutrient pools for the evergreen broadleaf tile on this grid cell in the new restart would be the average value over the neighbourhood of cells in the old restart, rather than being taken as is from the tile in the old restart.
Am I interpreting your script correctly? And if yes, why is this so? I imagined we’d get closer to the quasi-equilibrium on the tile by taking the old tile values where available. Or does it not really matter since we’ll have to do some spinning up anyway?
Hi @lachlanswhyborn - I’m pretty sure that if the pft already existed in that grid-cell then I just used that value. It’s also true that we will be needing to run many years of spin-up but starting with something similar to the values from the original run might make it easier to get a quicker idea of the sensitivity to the change in vegetation map.
Ahh yep I’d missed the one liner handling fillcase==0.
Hi @lachlanswhyborn,
thanks for working on the restart file with the new vegetation fractions. Do you have an estimate on how long this is going to take? We would like to set up a new simulation with those updated vegetation fractions as soon as possible so that we can assess the impact this would have on the climate and the whole system. This is essential for progressing with the ESM1.6 spin-up.
Please let us know if there is still some information missing or if you need help.
Thank you.
Cheers,
Tilo
I’m currently at the stage where I’m putting the new fields back into the UM restart file. At the moment, the current workflow is:
- Convert the CABLE related fields in the original dump file to NetCDF. CABLE fields are located by checking the dimensions of the field- if it is 192x145x17, then it is considered a CABLE field. The NetCDF variable names are picked up via the combination of the default UM STASHmaster file and the supplementary stash supplied with the ESM1.5 payu configuration.
- Remap the fields to the new vegetation map, by comparison between the “FRACTION OF SURFACE TYPES” field in the restart file to Rachel’s
newvegfrac.1850.nc. The remapping process for nutrient pools is the same as what Rachel described above, with the 0/360 line correctly handled, while variables more in the geophysics realm (e.g. soil temperature, soil moisture) are averaged across existing tiles in a cell. Creates a new NetCDF file with the specified variables as variable names in the file. - Place these created fields back into the appropriate fields in the UM restart file and save to a new file. This is stage I’m at now.
The only thing I’m not sure of is the phenology phase. Is this calculated within the model? I did look at @RachelLaw’s way of filling this variable, but I could not make rhyme or reason of it.
Thanks for the update. It looks like you are almost there. Well done. I don’t know how @RachelLaw has assigned the phenology phase and it would be great if @RachelLaw could confirm.
Cheers,
Tilo
I have created a new restart file. Obviously haven’t had the chance to test it yet, but what would people like to see for some first-glance validation at the CABLE4 meeting? I can prepare some slides if I know what people would like to see.
The restart file is available on p66 at /g/data/p66/lw5085/ACCESS-ESM1p6-restarts/PI-02-WithLUH3VegetationMap.astart (does the name need to include the date as with the original?). I am currently writing up a plain text document describing in detail the process used to go from the original restart to this one, which will be contained in the same directory.
That’s great @lachlanswhyborn. Thank you for getting this done so efficiently. We will try to set up a short test run to see if it works. I’ll let you know how it goes.
Cheers,
Tilo
I don’t think the name of the restart file matters. There might be a limit on the length of the filename though, but we can change this if needed.
Cheers
Tilo
Hi @lachlanswhyborn. I did a quick test run with ESM1.5 (still using scripts, not payu), but the model is time stepping with the new restart file. I will keep this running for a couple of years to do some sanity checks, but all looks good so far. Also asked @Jhan to set up a similar test run with ESM1.6.
Thanks again.
Cheers,
Tilo
That’s great, it’s pretty rare that something just works first try.
Phenology phase is used in casa - it is an integer value that determines what part of the phenology cycle you are in for any given pft at any latitude. If I remember correctly, 0 is the dormant phase i.e winter, then it switches to 1 for when leaves appear, after 14 days it switches to 2 which is basically summer growth, 3 is another 14 day period when leaves start to fall. This is all determined by the data in the modis_phenology.txt file, at least for ESM1.5/1.6.
Phenology phase is calculated in the code but seems to be done relative to phenology phase at the previous call to CASA, which I presume is why it is carried in the restart file. I would have thought that the calculation could be set up as just dependent on the data in the modis file so it wouldn’t need to be carried, but perhaps that is less efficient??