Reconfiguration in HadGEM2

Unified Model
1

Dear NCAS

I am using HadGEM2-ES on the local University of Birmingham machine. I have hit a problem when I try to reconfigure the orographic height. It works fine except when I attempt to change the height values which gives the following error:

ERROR!!! in reconfiguration in routine Rcf_vertical
Error Code:- 10
Error Message:- No interpolation, but data field sizes/levels are different!
Error generated from processor

I realise you don’t support this model any longer but could recommend someone who might know more about the reconfiguration code and/or whether this error has come up before?

Best wishes,
Peter

2

Peter

What do you mean attempt to change the height values - have you created a new ancillary file that you are trying to use in the reconfiguration?

Grenville

3

Hi Grenville,

Thanks for getting back to me. Yes I have a new orography ancil file produced in xancil that is based on the original but with a small difference applied (just for now as test) and it produces the error I mentioned. If I use the original orography ancil (qrparm.orog_new) it runs the reconfiguration without a problem.

Best wishes,
Peter

4

Peter

We’ll need to see both orography files to say anything sensible. Can you put them on JASMIN or ARCHER2?

Grenville

5

Hi Grenville,

The original and altered orography ancils are on my home drive on archer:

Original:

/home/n02/n02/hopcrofp/qrparm.orog_new

Altered:

/home/n02/n02/hopcrofp/qrparm.orog_test

Thanks,
Peter

6

Hi,

We cannot see these files. Could you

chmod -R g+rX /home/n02/n02/<your-username>
chmod -R g+rX /work/n02/n02/<your-username>

So we can access them now and any other files in the future.

Simon.

7

Hi Simon,

Sorry about that, hopefully you can read the files now:

/home/n02/n02/hopcrofp/qrparm.orog_new

/home/n02/n02/hopcrofp/qrparm.orog_test

Thanks,

Peter

8

I’ve had a look at the ancil headers, and there are some differences. However I can’t seem to reconcile these differences with the error message you’re seeing! The changed header items are:
UM version number
Calendar type
The vertical level type
Packing

Try changing these in xancil and see what happens. To do this:
In the General Configuration set UM version to 6.1 (this is the version of your working ancil)
In the Orography ancil window, switch “make field calendar independent” (if possible)
In the Grid Configuration set ENDGame
In the General Configuration turn on packing.

Simon.

9

Actually looking at the data, the Silhouette Orographic Roughness is incorrect. Looks like a copy of the Half Peak. Try correcting that before the changes suggested in my previous message.

Simon.

10

Thanks for your help with this.

I’ve corrected the silhouette orographic height and tried some of the changes to the header but I get the same interpolation error.

I’m wondering whether something is missing in my compilation of the reconfiguration code. I notice that the interpolation is working for the majority of fields but it fails at ‘calculating Exner’ (see below). Does that mean anything to you?

Iterpolating Field203 ( Section 33 ) ( Stashcode 156 ) EtOO MASS MIXING RATIO AFTER TSTEP

Interpolating Field204 ( Section 33 ) ( Stashcode 157 ) MeCO3 MASS MIXING RATIO AFTER TSTEP

Interpolating Field205 ( Section 33 ) ( Stashcode 158 ) n-PrOO MASS MIXING RATIO AFTER TSTEP

Interpolating Field206 ( Section 33 ) ( Stashcode 159 ) i-PrOO MASS MIXING RATIO AFTER TSTEP

Interpolating Field207 ( Section 33 ) ( Stashcode 160 ) EtCO3 MASS MIXING RATIO AFTER TSTEP

Interpolating Field208 ( Section 33 ) ( Stashcode 161 ) MeCOCH2OO MASS MIXING RATIO AFTER TS

Interpolating Field209 ( Section 33 ) ( Stashcode 162 ) O3PS MASS MIXING RATIO AFTER TS

Interpolating Field210 ( Section 33 ) ( Stashcode 163 ) O1DS MASS MIXING RATIO AFTER TS

Interpolating Field211 ( Section 33 ) ( Stashcode 164 ) OHS MASS MIXING RATIO AFTER TS

Interpolating Field212 ( Section 33 ) ( Stashcode 165 ) HO2S MASS MIXING RATIO AFTER TS

Interpolating Field213 ( Section 33 ) ( Stashcode 166 ) TROPOSPHERIC CH4 BURDEN (moles)

Interpolating Field214 ( Section 33 ) ( Stashcode 167 ) TROPOSPHERIC O3 BURDEN (moles)

Interpolating Field215 ( Section 33 ) ( Stashcode 168 ) TROPOSPHERIC OH BURDEN (moles)

Interpolating Field216 ( Section 33 ) ( Stashcode 169 ) STRATOSPHERIC CH4 BURDEN (moles)

Interpolating Field217 ( Section 33 ) ( Stashcode 170 ) PRESSURE OF PV-THETA TROPOPAUSE ¶

Interpolating Field218 ( Section 33 ) ( Stashcode 171 ) Strat CH4-OH rxn flux (moles/s)

Interpolating Field219 ( Section 33 ) ( Stashcode 172 ) Added Strat CH4 loss (moles/s)

Interpolating Field220 ( Section 33 ) ( Stashcode 173 ) Multi-purpose Diagnostic 23

Calculating Exner

11

Hi,

Could you sent me the full output from the job. Could you also send the output from the job that worked for comparison?

Simon.

12

Hi Simon,

here are the .leave files.

xpzhd is the job that does reconfigure but I use the same orography as in the dump file.

xpzhe is a copy of d above, but I use a slightly altered orographic height field and the reconfiguration fails. This job started running and so I had to cancel it and so the leave file didn’t get properly populated so I have attached the reconfiguration pe0 output.

If you want to compare the jobs they are on the umui under my username hopcrofp.

Thanks again,

Peter

(Attachment xpzhd.fort6.rcfa.pe0 is missing)

(Attachment xpzhe-20250127151143.leave is missing)

13

Hi Simon,

I’ve put those files in my home directory on ARCHER2:

/home/n02/n02/hopcrofp

Best wishes,
Peter

14

Hi Peter,

Sorry for the delay, I’ve been unwell.

I’ve had a look at the output you provided and the recon code, and I think I’ve worked out what’s happening in the reconfiguration, and it is to do with the Exner calculation, as you noticed.
The recon detects that the orography values have changed, and invokes vertical interpolation, it does this as changing the orography will change the model levels as they are terrain following at the bottom of the atmosphere. Hence

Vertical interpolation has been switched on due to a change in orography

seen in the output.

Various fields are interpolated without issue, however it fails right at the end when calculating Exner pressure with what looks like a bug in recalculating pstar. Somehow the logic is incorrect, and the interpolation routine thinks that interpolation isn’t required.

Ultimately the failure comes from the model detecting the orography values have changed. If they differ, even at the bit level, then the recon will turn on vertical interpolation.

One thing I’ve noticed is that your working ancil has packed 32bit data whilst the updated one is 64bit data, hence the difference in file size. This difference in data representation will be enough to tripper the interpolation. So to confirm, have you changed the actual base heights in the updated orography ancil? If so, I’ll look closer at the exner pressure code to see if I can work out the logic.

Simon

15

Hi Simon,

Many thanks for your help on this. I hope you’re feeling better now.

Yes I have changed the orography and I’ve done a few other tests with the same result.

I had wondered whether the problem is a bug in the reconfiguration code of HadGEM2 that got fixed at some point and just needs the right branch update?

Best wishes,
Peter

16

Hi Peter.

I think I know what’s going wrong. Could you copy your input dump /rds/projects/h/hopcrofp-hadgem2/dumps/xkvjaa@dam98c1 over to ARCHER2 so that I can check.

Also, if I’m correct, then for xpzhe, if you replace this file with the reconfigured file from xpzhd ie /rds/projects/h/hopcrofp-hadgem2/h/xpzhd/dataw/xpzhd.astart as the input dump then it could work. If it doesn’t, could you also copy the output to ARCHER2.

Simon.

17

Hi Simon,

The input dump file is on archer2 here:

/home/n02/n02/hopcrofp/xkvjaa@dam98c1

I have submitted a job with your suggestion below (initialising xpzhe with xpzhd.astart and with reconfiguration on) but the job is queued on our local machine.

Thanks again,
Peter

18

Hi Simon,
Your suggestion worked! Thanks very much. Could you explain why this solves the problem and would you recommend this as a work-around generally?
Best wishes,
Peter

19

Hi Peter,

I’ve had a look at your start dump, and it confirms my suspicions about what I think happened, basically there two pstar diagnostic fields in the original dump which the recon is misinterpreting as prognostics. In the configured dump, these fields have been removed, and the issue doesn’t trigger.

Using a pre-configured dump should work generally·

In detail:
Your orography changes requires a vertical interpolation of 3D variables of which one is exner pressure.
To calculate exner pressure, pstar is required as a temporary variable.
The reconfiguration searches the input dump for pstar (stash 409) and uses that is it exists.
In your original dump, there are two pstar fields. However, these are STASH diagnostics (these exist in the dump to allow meaning of the fields over resubmissions).
There must be a bug in the code and the recon considers these pstar fields as prognostics, so it attempts to copy them into the temporary pstar variable.
But, there are two pstar fileds, the recon code is expecting only one. This causes a failure in the consistency check, and the recon fails as seen.

In the configured dump, the diagnostic fields are removed so there’s no pstar.
As the reconfiguartion doesn’t find pstar in the input dump, it derives the temporary pstar it requires for exner calculation internally.
It then completes as expected.

Well, that’s what I think is happening.

Simon.