Opened 4 weeks ago

Last modified 9 days ago

#2524 accepted help

UM8.2 run goes wrong somehwere in qsatmos but I cannot see where

Reported by: jcrook Owned by: willie
Priority: normal Component: UM Model
Keywords: ancillary, model stability Cc:
Platform: ARCHER UM Version: 8.2

Description

I have a UM8.2 run called xmhkf which I set to run for 8 days from 1st April. This all worked fine. I then took a copy of xmhkf called xmhkg, changed the start date to 5th April, changed the snow depth ancillary to be configured rather than updated once a month and requested a reconfiguration from the dump file for 5th April from xmhkf and then to run for 5 days from this point. I believe the reconfiguration step worked ok. It produced xmhkg.astart which I can open in xconv. However the run gets no further than creating the xmhkga.p* files for the 1st day. I have looked at the corresponding .leave files (see most recent ones) in /home/n02/n02/jcrook2/output/ on ARCHER but I cannot see what is going wrong.

Change History (15)

comment:1 Changed 4 weeks ago by grenville

Julia

The leave file says

RHS zero so GCR( 2 ) not needed

in the first timestep. This is likely caused by a problem with the input data.

The start file /work/n02/n02/jcrook2/VERA/um/xmhkg/xmhkg.astart has a very odd surface temperature field - it has a minimum temperature of 0K.

Grenville

comment:2 Changed 4 weeks ago by simon

The 0K surface values are inherited from the original dump, /work/n02/n02/jcrook2/VERA/um/xmhkf/xmhkfa.da20140405_00 There are a couple of 0K points, at 351.3,-2.664

Simon.

comment:3 Changed 3 weeks ago by willie

Hi Julia,

I've caught up now. There are some zero degree kelvin points in the original start dump as Simon has pointed out. This will cause the model to fail. So you need to look carefully at how the original start dump was generated.

Willie

comment:4 Changed 3 weeks ago by jcrook

I have looked at xmhkf, the run from which the dump file came. Its start dump xmhkf.astart looks fine but in its first output of surface temperature (at the 1st hour) the 0K values creep in. This run did however manage to run for 8 days. I have another run xmhkh which was reconfigured from the same dump file as xmhkf but with a different veg fraction and this has also run ok for 8 days and has no 0K surface temperature values.

I have looked at the .leave file for xmhkf and at timestep 30 I start to see something about courant number although the run carries on:
Atm_Step: Timestep 30 Model time: 2014-04-01 00:50:00
Maximum upward Courant number = limited at 5 points by reseting w and w_adv
Vertical Courant number = limited in 1 columns by reseting w and w_adv

These messages do not appear in the xmhkh run so I suspect they are indicative of a problem.

xmhkh should only differ from xmhkf in the veg fraction ancillary used.

comment:5 Changed 3 weeks ago by jcrook

After some analysis of ancillary files and which runs had the problem I have found that the veg fraction ancillary file for 4km current vegetation has 2 grid boxes in it over land with all veg types zero. These are the same 2 grid boxes for which Ts gets set to zero. It did affect Willie's run xmrjc as well as all the current vegetation runs I have done at 4km. The 1950s veg fraction used in xmhkh did not have these 2 grid boxes with no veg types and so this run worked ok.

It is concerning that xmrjc ran for 122 days and xmhkf ran for 8 days without us noticing any issues - the problem is it is only 2 grid boxes out of 1000's so you can't see it in a map easily. It can only have a strange effect very locally otherwise I'm sure we would have spotted something.

Sonja will create a new veg fraction file to fix this.

comment:6 Changed 3 weeks ago by willie

  • Keywords ancillary, model stability added

Hi Julia,

Thanks for letting us know. I'll close this ticket now.

Regards,

Willie

comment:7 Changed 2 weeks ago by willie

  • Resolution set to fixed
  • Status changed from new to closed

comment:8 Changed 2 weeks ago by jcrook

I'd like to keep this ticket open please because I have now done a run xmhki which used a fixed vegetation fraction file. xmhki ran for 5 days ok and has no 0K values so I assumed it should be good to use a dump file from this run as my input to xmhkg instead of the old xmhkf one. So for xmhkg I have taken the dump file from xmhki for 5/4/2014 and done the reconfiguration and then tried to run it. However I am getting a similar message to before in the .leave file, i.e. RHS zero so GCR( 2 ) not needed. So presumably there is still something in the input dump file that it doesn't like.

Is there anything else I can look for in the .leave file to indicate what might be wrong?

comment:9 Changed 2 weeks ago by willie

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:10 Changed 2 weeks ago by willie

  • Owner changed from um_support to willie
  • Status changed from reopened to accepted

Hi Julia,

It's failing at the first time step, so this suggests the start dump or the ancillary files are at fault.

The LAIs in xmhkia.da20140405_00 looks fine. However in xmkhg.astart all the LAIs are set to missing data. So it looks like the reconfiguration has gone wrong.

Regards
Willie

comment:11 Changed 2 weeks ago by grenville

Hi Julia

I'm a bit confused - as far as I can see (by diff'ing xmhki and xmhkg in the UMUI - that's not foolproof 'though) the suites differ only in the way they handle soil moisture updating - but as Willie mentions, there are differences between

xmhkg.astart

and

/work/n02/n02/jcrook2/VERA/um/xmhki/xmhkia.da20140405_00

(snow amount over land, sea salt for example).

What happens if you don't reconfigure xmhkia.da20140405_00 and run xmhkg with it?

Grenville

comment:12 Changed 2 weeks ago by jcrook

Our plan is to run a number of a pair of simulations with the same start dump but to have one of the pair using current veg fractions and the other having 1950s veg fractions. This does mean I need to reconfigure. I thought all my runs from xmhkf onwards were set up to update soil moisture on reconfiguration only. So xmhki does not have this set correctly. LAI is set to be updated monthly so I don't think there is a problem that LAI in xmhkg.astart has missing values because they should be filled in when xmhkg first starts (or do you think it should have left them as they were in the xmhki dump file?). Actually it should not really be a problem whether something is updated monthly or reconfigured if I am always going to start with a reconfiguration and only run for a few days so I could try changing the LAI to be configured.

comment:13 Changed 10 days ago by jcrook

I don't know and can't find any documentation to tell me how the model handles a variable being configured or updated. If it is set to configured, clearly the reconfiguration sets that variable to the value specified in an ancillary file. But if it is set to updated every month then when does it actually get updated and what happens to that variable in a reconfiguration? I assumed that for such variables they were left untouched by the reconfiguration and when the run started (whatever date that was) it would update the variable immediately and then a month later but may be this doesn't happen. It seems like the reconfiguration sets them to "missing value". My run xmhkf and xmhki start on 1st April so may be they do get updated immediately but my run xmhkg starts on 5th April and may be doesn't get updated. This would mean that you should only start a run that has been reconfigured at the beginning of the month if you have variables updated monthly. Or should the ancillary reference time be set to 5/4/2014?

comment:14 Changed 9 days ago by willie

Hi Julia,

On the update/configure issue, configuring is done once by reconfiguration. Each time an update is required, the leave file contains statements like,

REPLANCA: UPDATE REQUIRED FOR FIELD 27
  REPLANCA - time interpolation for field  27
  time,time1,time2  99.,  96.,  102.
  hours,int,period  99,  6,  -1
  Information used in checking ancillary data set: position of lookup table in dataset: 17
  Position of first lookup table referring to data type  1
  Interval between lookup tables referring to data type  1  Number of steps 16
  STASH code in dataset  31   STASH code requested  31
 'start' position of lookup tables for dataset in overall lookup array  489

so you can see what's happening.

I see that you've now solved the LAI problem in xmhkg.astart and completed another run of xmkhg. Is this now working properly?

Regards
Willie

comment:15 Changed 9 days ago by jcrook

Hi Willie

I changed all the ancillary fields that were updated once a month to be configured and this has meant it now works.

I can see REPLANCA statements in all my .leave files because some fields are updated every 6 hours (eg lateral boundary conditions and SSTs) so its difficult to spot the ones that are to do with my now configured variables.

Given that I am doing runs that are only 5 days long I only need to set everything at the start of the run in the reconfiguration step. The 6 hourly updates work.

I might have got round this by setting the ancillary reference time to be 5/4/2014 but I don't know what this means and I know it is working by using the reconfiguration.

Note: See TracTickets for help on using tickets.