I’m looking to run a UKESM1.0 AMIP version of the UM. I would like to prescribe my own forcing through changes to the albedo climatology within JULES, but I haven’t been able to find where I could specify this.
In the JULES radiation options menu there is an option to select “l_albedo_obs” (Scale albedo of land-surface tiles to agree with obs) but ticking it doesn’t bring up any additional fields. The help for this tickbox says this “Allows the UM to read in an ancillary file containing albedos (either SW(STASH 243) or VIS(STASH 244) and NIR(STASH 245)). […]” ).
Can you advise where I would be able to specify these files? In the Configure ancils and initialise dump fields menu I was able to find a stash_req item with 244,245, which lists the ancilfilename as $UM_ANCIL_GENLAND_DIR/$UM_ANCIL_GENLAND_FILE, which is a directory I wasn’t able to find. I also didn’t find a stash_req item #243 to specify SW albedo and was wondering if it would work to just add it under the same item as the one containing 244,245?
Hi Michaela:
Have you had any luck?
To find the path to: $UM_ANCIL_GENLAND_DIR (according to one of my colleagues), look "in an ancil versions file - possibly something like:
Thanks for your help with this. Following your instructions, I found the desired directory listed as $ROSE_DATA/etc/ancil/qrclim.land.
Now that still left me wondering what directory $ROSE_DATA is referring to exactly, but I was then able to find a list of different qrclim.land files in /work/y07/shared/umshared/ancil/atmos (inspired by this post). A search in that folder returns several matches for “qrclim.land”, all of which are albedo files. I’m still not 100% clear on what the difference between all of them is and which one is being actually used in the run, as there are 15 different ones just for the n96e resolution, but they all seem to be in the same format so I think either will work for the creation of my own ancil file.
I will create my own SW albedo ancil file with forcings included and, unless anyone reading this thinks it’s an absolutely stupid idea and will not work, I am going to go ahead and change the existing stash request 244,245 to 243 so that I can input the SW albedo, instead of having to specify VIS and NIR separately (in Configure ancils and initialise dump fields).
Hi Michaela
I’m glad you figured things out, and I think your plan (at least on the surface) sounds good.
One small issue: isn’t the range of wavelengths for SW (shortwave) the same as for VIS? I would guess that the NIR range of wavelengths is the same as would be any LW (longwave) file. But I guess you’d have to check such things.
Patrick
I think this won’t be a problem; it seems that in JULES “SW flux” is defined as a combination of NIR and VIS (by default 50/50); this is at least my understanding of the “JULES radiation options” settings. This is also consistent with how MODIS defines SW for the purpose of albedo calculation. Hopefully the approach I outlined should therefore be fine (well, there might be other issues with it, but this is one fewer to worry about…)
Thanks for your help so far, sorry I haven’t replied earlier.
I managed to get the files and all, but am having trouble saving them after making the desired changes to them. I was hoping to use the existing albedo file, apply my forcings and use that instead as the ancil file instead. However, I am having trouble saving to the .land file. I am using iris, but because the albedo file is not a .nc file, I have not been able to save it with iris.
My code (even without applying any changes to the dataset):
Hi again, Michaela:
Maybe one thing you can try would be to use a different filename, without the dot before land? I think it might be trying to save it in a non-existent .land format. To save it in the default iris format, maybe try .pp or no extension?
Thanks, that’s a good idea; I assumed .land is some very specific file format, but it seems to be work when I save it as .pp and then rename to .land - I am still able to load the data.
I am however having issues when saving to .pp. The original cube* is 12x144x192 (month x lat x lon) but when saving it as .pp the time dimension is lost and it’s saved as 12 separate (144x192) cubes instead, with no time information attached to them. This happens regardless of whether I change the data at all, and only happens once I save the data, i.e. just making a copy of the data doesn’t cause any problems. It happens even without the .pp → .land renaming.
I’ve tried saving it as .nc file instead, which doesn’t have the same issue, but for some reason isn’t actually saving any changes I make to dataset_land_new… Again, this only happens once I try to save (or load?) the data. Currently trying to figure out why that is.
*) to be precise, there are 3 cubes in the original file, as there are 3 different albedo values. The separation into “flat” cubes happens to each of them, so I end up with 36 cubes in the newly saved file.
Hi Michaela:
That’s great that you can save in .pp format now.
Maybe you can try to save separately each of the 3 albedo cubes in the original file? Does that then still separate it into 12 monthly cubes?
Patrick
Hi again2, Michaela:
And have you tried iris.load_cube( ) instead of iris.load( ) ?
I think the former only loads a single cube, and the latter loads all cubes ?
The result of the latter is a cube list instead of a single cube.
I don’t see the iris equivalent of save_cube( ) that might be used instead of iris.save( ).
Patrick
I have tried all of the above but unfortunately none of it works… Even when loading just one of the cubes and then saving just one, it still ends up being split into 12 different cubes. Even without making a copy and just trying to save the original doesn’t help; it seems like the issue is with saving to the .pp file, which for some reason always splits the cubes.
I think I have found a solution by converting it to a .nc file instead. While I couldn’t make that work in iris, I have been able to in netCDF4. So what I do is:
Load the .land file in iris and save it as a .nc file, no changes made
Make the desired changes to the .nc file using netCDF4
Rename the changed file to .land again (literally just using os.rename, as it doesn’t seem possible to save a .land file directly using anything)
This seems to retain all information, so as far as I can tell now it works. Now I’m hoping this will not cause problems once I feed this info into the model; the original .land file was not a netCDF file, so the format is now different, but hopefully that won’t be an issue (I shall report back once I’ve tried it).
Hi Michaela
Thanks for trying all those suggestions.
It’s too bad they didn’t work, but I am glad you may have found a workaround.
Please do let me know if the data format of the new file works alright.
Patrick