Hi team,
Running the UM nesting suite vn13.1, I am getting the following error in the Regn1_resn_1_RA2M_um_createbc_000 task:
? Error code: 4
? Error from routine: LAM_INCLUSION
? Error message: Eastern boundary at 506.1782500 not within source LAM with 146.1647500
? Error from processor: 0
? Error number: 2
It appears that 360 degrees is being added to my eastern boundary somewhere, but I’m not sure why, as this routine has worked in the past for me and as far as I can tell has not changed (from the met office log files). I’ve checked the output files so far (inc. the ancillary files, the ERA5 grib files and the ec_cb000 files) and they all look correct.
If anyone can offer up any advise I’d be most grateful!
Also, I am wondering if this is the most suitable place for help or should I be posting this to the access help desk?
just pointing out that I mentioned the helpdesk specifically for the error with era5grib as we (CMS-CLEX) maintain that and it was just by accident that I noticed your question on the forum. So it’s a different case from your current question.
Cheers,
Paola
Hi Sonya, what are the boundaries of both your lam domain and of the ERA5 grib data? There is an option in the ERA5grib settings to include all longitudes which may be needed if working at the date line or near the poles
Aidan
(Aidan Heerdegen, ACCESS-NRI Release Team Lead)
6
I don’t know if this helpful, but Monika Krysta had a similar error code
Ah yes the other thing to check is that the era5 domain needs to be a bit larger than the nest domain for the boundaries to work - say 10 to 20 grid lengths on each side, so if you had a 0.1 degree grid size on your nest then you’d want the era5 domain to be 1 to 2 degrees larger than the nest domain on each side.
This would show up in the error message as the boundaries only having a small difference though, so not likely to be the case here
I am trying to run near Cape Grim in Tassie (though I did stuff up my lats here - so not quite right), so there shouldn’t be an issue being near the poles or date line (though I note Zhangcheng is running close to the pole with a similar issue).
In the more recent versions, the nesting suite doesn’t ask you to define the boundaries itself, rather it takes them from a file generated from the Ancillary suite: grid.nl :
I am wondering if I should just change the points lambda/phi target to 200 to reduce the domain the nesting suite is after, in a similar way to what we did previously?
Well thats the thing possibly - I think they are the same, as in at least the GUI there is now nowhere to set them differently that I can see? I’ve looked that the grib files created by the ERAgrib task and they look ok - ie. they are slightly bigger than the domain I have set.
Ah right. So how this works is it starts off with the GRIB era5 data, it will then convert that GRIB data to UM format by running it through the reconfiguration, then the CREATEBC task will pull out the boundary data from the UM format file.
When the GRIB to UM step is run the reconfiguration needs a set of ancillary files to fill in extra fields, which is set at dm_ec_lam_ancil_dir:
These ancillaries should be created by the regional ancillary suite, at around 0.1 degree resolution (in case the UM grid doesn’t exactly match up with the ERA5 grid) and covering a somewhat larger area than the target domain as I said above which will be important for the CREATEBC step.
Ok I’ve worked out a pretty hacky way of making it run: I’m running the ancillary suite twice - once with a larger grid (220 points) and then with a smaller grid (200 points). In the nested suite I then point the driving model dm_ec_lam_ancil_dir to the larger grid and the rg01_rs01_ancil_dir to the smaller grid. I’ll see if that solves Zhangchengs problem as well closer to the pole!
In the nci_era5grib app set POLAR=True. With this set rather than selecting just the LAM region to convert to GRIB format the tool will restrict only by latitude.
Thanks for that Scott - a few more questions (for now at least) if you or anyone else has the time.
On the nesting suite wiki (https://git.nci.org.au/bom/ngm/documentation/-/wikis/Supported-Suites#regional-nesting-suite) it explicitly says to ensure the ERA5 is not on a rotated pole. I did try to rotate it anyway (for a domain over Davis) and the resulting grib files are definitely garbage. Can you tell me if there is a work around for this, so that we could use ERA5 on a rotated pole? I’ve tried a few things so far, but not having much luck.
I’ve also tried to run the nesting suite driving model using initial conditions from one of my ACCESS runs, but it runs into problems with I think something to do with the land surface, which may not be that surprising given the different land schemes?
? Error from routine: RCF_CALC_TILES
? Error message: Try two-step recon: Change in grid for n-to-1 not currently supported for STASHcode 231
So I guess I want to know if there is either a way to use ACCESS runs for the initial conditions without running into these problems (I’m not sure how to do a two-step recon a suggeted in error?) or if there is a UM global configuration suite that I can set up to generate the initial conditions?
Lastly, does anyone have advice about running the nested suite freely or not? Is it much like the global model in the sense that there are pros and cons for both and it just depends on what science you’re doing, or is there a good reason for one over the other?
