@Jhan would you be able to put your version of the STASHmaster for ACCESS-ESM atmosphere restarts somewhere on Gadi (or send it to me), so I can compare to the STASH I’ve been told is the correct one? The STASHmaster that I have doesn’t appear to contain any entry for the Albedo. I suspect my lack of knowledge about what CABLE in ACCESS-ESM requires is causing my problems here.
@lachlanswhyborn - albedo is probably derived from other fields - I’m just always a bit vague about which ones.
/scratch/public/jxs599/Lachlan/STASHmaster_A
I think you’ll find that it is the same (effectively) as the official version. The xconv tool used for visualising restarts, diagnostics that are straight out of the model (i.e. in UM binary format) also looks at the STASHmaster_A file for guidance on how to identify things. The official version of STASHmaster_A is quite capable of identifying the right field, BUT the descriptive long name (which will show up as the main difference(s)) is missing in the official version. The additional information to accompany this is that xconv settings (button) has an option to point it to a STASHmaster. If you point it to this one, you get the proper names which is very handy if you’ve wasted too much time trying to. work out what the dozens of ITEM numbers are referring to.
What Albedo are you expecting to see? Rachel is right - it is constructed from a bunch of other fields. In the UM, the radiation model computes the downward shortwave. CABLE (and JULES to a lesser degree) computes the albedo of each land point depending on the soil moisture/temperature, whether there is vegetation, is there snow, how much of the canopy is still exposed, what sort of vegetation is it, how old iand dirty is the snow etc. In principle every timestep, in all of our CMIP models to date it is only once per hour. Actually CM2 is once per hour, I’m not certain about the ESM. The calculated albedo then goes back to the UM and it calculates the Net SW (downward) considering this part is reflected. A bit later in the model the UM calls the land again and passes this Net SW to it. It works a bit differently in JULES compared to CABLE, but essentially the same result. In short though CABLEs albedo calc is way more sophisticated than JULES.
Nonetheless it is dynamic and does not require a prognostic/precribed field. Although, the STASHmaster is not limited to prognostic fields. It seems if it is a field to be considered by the STASH system then it has to be in there. There is a horrible document paper all about the STASH system if you are super bored and masochistic:
Thanks for this Jhan, this STASHmaster is much more comprehensive than the one I had been supplied with.
Is this also how it works in CABLE offline? The intention is to be able to run CABLE offline as if it was in the ACCESS model (I know there are many changes between CABLE now, either main or POP_TRENDY, and CABLE as it was in ACCESS-ESM1.5). For this, we need a gridinfo file that matches as close as possible the information given to CABLE in the ACCESS model. The CABLE gridinfo supplies an albedo by radiation band (actually it supplies 2 albedo fields, for reasons unknown to me). Is this albedo used in CABLE offline?
Hi @lachlanswhyborn, @jhan,
These posts have reminded me that the albedo in the gridinfo file is just the soil albedo. As I understand it, this is prescribed - though I think at one point there was also the option for a parameterised soil albedo based on soil colour. Anyway, soil albedo is basically what you’d get if you didn’t have vegetation so it would then be used as part of the albedo calculation.
From my look at the gridinfo file, ‘albedo2’ matched the soil albedo fields that were used in the UM at the time the 1x1 gridinfo was created. I don’t know the origins of the data in the ‘albedo’ field. In the standalone, single site tests I was doing, I can’t remember if I had to set which albedo I wanted it to use. I do remember that even though I wasn’t using ‘albedo’, it still got checked so I had to give it a sensible number (i.e. between 0 and 1) to pass the check.
I’m assuming the gridinfo albedo2 is soil albedo for longwave, shortwave diffuse and shortwave direct radiation? Do you remember which are order they are in? Or is my best bet just to do some qualitative comparisons between the existing CABLE gridinfo and the reported DIRECT/DIFFUSE SURFACE ALBEDO ON SW BANDS and SNOW-FREE ALBEDO OF SOIL fields in the UM (it’s not immediately clear to me which field should represent the long wave albedo)?
I think it is called AlbSoil in albedo(). Potentially snow can still clobber it. In the UM it comes from soil_alb ancillary. STASH number = 220. The file is at $ROSE_DATA/etc/ancil/qrparm.soil. Martin Dix will be able to tell you what $ROSE_DATA is. You could compare this with the values in grid info. The problem is they are on different grids. Would be good to know where we populated the UM field from, I don’t think we wrote it down anywhere. 
This 220 field should be in an AM3 restart. I’ll find it for you if that helps.
The soil colour albedo stuff is still in there @RachelLaw 
Actually, you already have it.
@lachlanswhyborn - ‘albedo2’ in gridinfo_CSIRO_1x1 is only dimensioned longitude, latitude. It doesn’t have separate values for the different radiation components. In the gridinfo file, the long_name is given as ‘UM SNOW-FREE ALBEDO OF SOIL’.
Albedo is dimensioned for types of radiation and the long_name says ‘ISLSCP2 snow-free bareground albedo’ but I don’t know if any applications are using this albedo data.
Ah that is the longwave albedo? I wasn’t sure if it was just the long wave, or some sort of averaged across bands albedo. I’ll inspect the source code to work out precisely what order the bands should be in for the gridinfo.
Oh yep, I got albedo and albedo2 mixed up.
What are the units of CABLE SNOW DEPTH LAYER X in the restart file? I’m imagining mm, but the numbers in the restart seem quite high for that, and the distribution does not look right either. There appears to be snow everywhere in world, including central Africa and tropical regions. I must be either interpreting this field wrong, or the names of the fields are incorrectly reported?
I’ve attached some choice plots of what is reported to be CABLE SNOW DEPTH LAYER 1 from /g/data/vk83/configurations/inputs/access-esm1p5/modern/pre-industrial/restart/atmosphere/PI-02.astart-01010101, using Jhan’s STASHmaster_A as the reference for field names (I couldn’t get xconv to produce images with background, so view them on light mode).
iveg=1
iveg=9
Hi @lachlanswhyborn,
comparing with one of my restart files, it looks like you are plotting snow density (field 828) not snow depth. My guess is that whatever value is represented by the green colour - this is a default used when there is no snow.
While it looks like there are many grid-cells with crops, most of these probably have a very tiny tile fraction, at least in 1850. ACCESS is set up to run for all tiles that will be needed across the length of the simulation, so some are carried with a tile fraction of 1e-5 until they are needed.
It seems that the reference stash is incorrect in some locations- these snow variables are definitely wrong. Fields with Stash code=819,820,821 are reported to be CABLE SNOW TEMPERATURE LAYER 1,2,3 by Jhan’s stash (or it may be that xconv is reading the stash incorrectly?), but the values seem much more in line with the snow depth as you reported.
In my notes I have 819-820 as snow depth, 822-824 as snow mass, 825-827 as snow temperature and 828-830 as snow density. 831 as mean snow density and 832 as snow age.
Yep, that looks correct based on the actual numbers in the fields, ignoring what name the stash gives to the fields. Might have to dig into the history of this stash. It’s definitely being read correctly by xconv, which means the stash is incorrect.
Can you point me to the STASHmaster file that you are using?
It’s the one I got from Jhan- I’ve put a copy at /g/data/rp23/experiments/2024-03-12_CABLE4-dev/lw5085/CABLE-as-ACCESS/STASHmaster_A. I think the one that Jhan placed in scratch/public expired.