Opened 13 years ago

Closed 13 years ago

#138 closed help (fixed)

updating ancil more frequently than times in file

Reported by: agt Owned by: jeff
Component: UM Model Keywords:
Cc: Platform:
UM Version:


Hi folks,

[vn4.5.1 A-only]

I'm not sure if I'm trying to do something which isn't possible. I would like to be able to "update" snow depth (only) from qrclim.smow.newA (or my own adaptations of this) every day (or possibly even hour) over a short integration.

Is it not possible to have frequency > monthly for a qrclim with only 12 months? Yet daily interpolation obviously works with sea ice and sst, which leads me to think this should work….

xdbaf is an example of a job which works when updating is set to every 30 days, but fails when set to every day.

The leave file for a failed job can be seen at: /hpcx/home/n02/n02/agt/um/umui_out/xdbaf000.xdbaf.d08140.t172614.leave

The error part that I have found is as IOT/Abort trap on all the processors, just before which there was a REPLANCA 109 error code.

From UM doc C7 (pc007_vn45.pdf, page 10), this leads me to believe that I have reached the EOF before first data point is read from the ancil. Is it trying to read (for example) the end of the month (time 30) in a file with only 12 time points?

Is qrclim.smow.newA not set up as a periodic file?

Or could this be a problem with the snow edge field which also resides in the same file?

many thanks in advance for any advice,


Change History (15)

comment:1 follow-up: Changed 13 years ago by jeff

  • Owner changed from um_support to jeff
  • Status changed from new to assigned

Hi Andy

I'm not sure what is going wrong, the first problems comes from this line in the .leave file

Im_ident,Sec,Item: 1 0 27

This is for the snow edge field. To get any further with this I will need to run your job and put in some print statements. To do this I will need read access on ~agt/um/ancil/qrclim.ozone.li30.


comment:2 in reply to: ↑ 1 ; follow-up: Changed 13 years ago by agt


ok I've given read access to the ozone ancil.

((When I create my own ancil I want to try and set all the edge data to missing, as all 12 monthly snow depths will be constant and hence it will not need to find out the fractional melting time during interpolation. This also seems non-trivial given that both depth and edge share the same ppcode=93 —> my mkancil seems to change them both at the same time. But this is another issue and perhaps I will try xancil0.40 instead of mkancil to get round this…))

comment:3 in reply to: ↑ 2 Changed 13 years ago by agt

Additional information:

I've also tried job xdbag, which forces with ~/um/ancil/qrclim_clim.smow.newA2, which is some "climatological" snow depth the same for 12 months, and snow edge set to missings for all xy and at all 12 months. This jobs fails in the same way.


comment:4 follow-up: Changed 13 years ago by jeff

Hi Andy

I've still looking into why your job fails. If your snow depth is constant then why are you updating it, won't it always be the same? If so then can't you configure it instead?


comment:5 in reply to: ↑ 4 Changed 13 years ago by agt


there are two possibilities for experiment:
1) run ensembles using configured snow starting in April, and examine behaviour in the June-September period. This will run fine using configured snow and is not the issue here.

BUT aspects of the land surface (snow, sm, soil temps etc) will not be in balance with either each other or the atmos. What several other studies have done is:

2) apply snow late the year before (Nov or December). However I still want the snow to be my chosen anomaly by April, hence it needs updating between November and April. In April the members are allowed to run free. On tests with monthly updating between November and April, the snow quickly drifts away from its update at the start of each month, presumably to agree somehow with the atmos or rest of land surface. This is why I want to try daily updating, giving more chance for agreement between snow/soil/atmos by the time they can be let loose from constraint in April. In April I switch my ensemble to configure the snow, and then it will melt at different rates depending on the anomaly I chose.



comment:6 follow-up: Changed 13 years ago by jeff

Hi Andy

I think I have solved your problem, the way the UM is set up I don't think updating snow depth will work, except for 30 day updating because that doesn't need to do time interpolation of snow depth hence the snow edge data is not needed. To get updating snow depth to work you need to add this user prestashmaster file /home/jeff/umui_jobs/userprestash/snowdepth_update (on puma) to your umui job.

Try this and let me know if it works.


comment:7 in reply to: ↑ 6 ; follow-up: Changed 13 years ago by agt


It certainly runs for a few months (eg see xdbag). However it is not updating, indeed it is not even configuring. Look at, for example, the north hem. snowdepth field in:
/hpcx/devt/n02/n02-ncas/agt/um/xdba files xdbag.start and xdbaga.dah8b20 and compare these with the order of magnitudes in any month of ~/um/ancil/qrclim_clim.smow.newA

In fact the .start file here is full of missings. I'm trying another now, but with supplied qrclim.smow.newA


comment:8 in reply to: ↑ 7 Changed 13 years ago by agt

The above ancil should read .newA2 not .newA

comment:9 Changed 13 years ago by agt

Jeff, here's a more thorough analysis showing that daily updating isn't working.

Jobs xdaud vs. xdaue
Start 1November. Both use ~/um/ancil/qrclim_clim.smow.newA3 as input
ancil has 12 equal months of snow depth = 200kg/m2 over most of Europe/Asia?, unchanged from existing ancil elsewhere. Snow edge=missing over Eurasia, and unchanged from existing elsewhere.

xdaud = daily updating snow depth + ~/jeff/umui_jobs/userprestash/snowdepth_update
xdaue = monthly updating snow depth, snow_update preuserstash removed

looking at snowdepth daily data in:
/hpcx/devt/n02/n02-ncas/agt/um/xdau/xdaud/xdauda.pah8nov and

—> xdaue has values in the 200 ball-park, especially to the north BUT xdaud has values of order <10.

looking at first day of december in:
/hpcx/devt/n02/n02-ncas/agt/um/xdau/xdaud/xdauda.pah8dec and

—> xdaue has snapped back to nearly 200 in north Eurasia, BUT xdaud again has values <10.



comment:10 follow-up: Changed 13 years ago by jeff

Which is the output file for xdaud? The only one I can see (xdaud000.xdaud.d08143.t152211.leave) looks like it crashed, is this the right file and do you know why it crashed? It would be useful to see the job output for daily updating so I can see what the UM thinks its doing.

comment:11 in reply to: ↑ 10 ; follow-up: Changed 13 years ago by agt


yes, that's the right one. As soon as I had a few days output from December I cancelled the job. (The datestamps of leave and the pah8dec file match up).

I will put in xdauf (cp xdaud) and xdaug (cp xdaue) again, each to run for 3 months. Also I'll put out daily dumps in case they are useful.


comment:12 in reply to: ↑ 11 Changed 13 years ago by agt

Ok, xdauf has run now,

output in /hpcx/devt/n02/n02-ncas/agt/um/xdau/xdauf and of course in ~/um/umui_out

That is the repeated run attempting to daily update. Let me know if you want the monthly updating one putting in (xdaug=xdaue).


comment:13 follow-up: Changed 13 years ago by jeff

Hi Andy

If you look at the snow edge field in /hpcx/home/n02/n02/agt/um/ancil/qrclim_clim.smow.newA3, with xconv (plot not view), you will see some values are not quite equal to the missing data value. These points have the value -1073700000.0 and the missing data value is -1073741824.0 (-2.030). This causes the UM to treat these points as fractional data and the snow depth values get set to 0 here. Try the run again with a fixed smow file and hopefully it will work.


comment:14 in reply to: ↑ 13 Changed 13 years ago by agt



thanks very much for your persistence. Fixing the MDI has solved the problem in conjunction with the userprestash thing.



comment:15 Changed 13 years ago by jeff

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.