Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#1677 closed help (fixed)

problem in outputting at specified locations

Reported by: ggxmy Owned by: um_support
Component: UM Model Keywords: STASH timeseries profile
Cc: gmann Platform: ARCHER
UM Version: 8.4


Dear CMS,

I'm trying to output diagnostics at locations of observational
stations. So I added a 'time series domain profile' DTHET_LD to a
copy (tdzim) of my existing (and running) job (tdzie) and
requested a few diagnostics for that profile.

However, the run fails and


contains the following messages;

???!!!???!!!???!!!???!!!???!!!???!!! ERROR ???!!!???!!!???!!!???!!!???!!!???!!!?
? Error in routine: check_iostat
? Error Code:  4324
? Error Message:  Error reading namelist domain. Please check input list against code.
? Error generated from processor:     0
? This run generated   5 warnings

Near the end of the .leave file, it suggests the model might have
encountered a problem when it was trying to read in the STASHmaster

STASH_MSTR: /work/n02/n02/hum/vn8.4/ctldata/STASHmaster/STASHmaster_A

But this file does exist.
-rw-r—r— 1 hum n02 1104610 Mar 27 2014 /work/n02/n02/hum/vn8.4/ctldata/STASHmaster/STASHmaster_A

I talked with Graham Mann here in Leeds and he says he had the same
problem when he tried to run xlkzq on ARCHER. But he also said that
an equivalent job (xlkwf) seemed to have run OK without crashing on
the IBM MONSOON (although he had got some corrupted outputs
which might have been due to the time profile setting).

Do you have any idea about what is causing this problem and how we
can fix it?

Thank you.
Masaru Yoshioka

Change History (6)

comment:1 Changed 4 years ago by annette

Hi Masaru,

The error is to do with your new domain profile Error reading namelist domain; the STASHmaster_A bit is a red-herring!

I have not used domain time-series profiles before, so don't know much about it. However I noticed there is a hard-limit of 250 points per domain in the code, whereas your new domain has 16*85=1360 points which is why the model fails.


comment:2 Changed 4 years ago by ggxmy

Hi Annette,

Thank you for your reply. Do you (or anybody around you) know where in the code this hard limit is set?

Graham says when we used this station-data for EUCAARI we certainly ran with interpolating over more points than 250. We had about 24 stations and we output on vertical levels.

But this might have been made possible by modifying the code. If we know where the hard limit is set, we may be able to modify it so that we can output diagnostics at 16 stations for 85 levels.


Best regards,

comment:3 Changed 4 years ago by ggxmy

We found we have actually got help from Mohit about this issue a few months ago.

Based on it, Graham created a branch for UM vn8.4;

fcm:um_br/dev/gmann/vn8.4_incr_tser_limit r19399

I'm testing if this works.


comment:4 Changed 4 years ago by ggxmy

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

comment:5 Changed 4 years ago by grenville


I think the time profile needs to be a time series - neither of your 0 004 stash items have time series profiles — please check Graham's working IBM job where he uses T3HRAD as the time series time profile.


comment:6 Changed 4 years ago by grenville

Masaau, Graham

The diagnostics going to UPC and UPG, in xlkwe fr or example, have either T3HRAD or T1HUKCA time profiles. Both these profiles have the Time series option checked - see attached.

These profiles appear to work fine in Graham's output


Masaru — I think this was not the case in your job.


From: Graham Mann [G.W.Mann@…]
Sent: 27 October 2015 23:48
To: Masaru Yoshioka
Cc: 'Grenville Lister' (g.m.s.lister@…)
Subject: RE: [NCAS Computational Modelling Services] #1677: problem in outputting at specified locations

Hi Masaru,
I think Grenville is referring to my job xlkwd.
See there that job has two sets of DTHET_LD diagnostics:
1) hourly instantaneous timeseries data going to UPC (theta, q, p, ozone[34001], CN[38437], CCN70[38440]).
2) 3-hourly instantaneous timeseries data going to UPG (theta, q, p, ext550 [2-114], ext1020 [2-120], abs1020 [2-121])

But I don't understand what he means when he says:

"I think the time profile needs to be a time series - neither of your 0 004 stash items have time series profiles — please check Graham's working IBM job where he uses T3HRAD as the time series time profile."

My understanding is that whether it is a timeseries or not is controlled by the domain profile not the time profile.

The 0-004 which has UPC usage profile uses DTHET_LD domain profile — which specifies it is timeseries data in the domain profile panel there.

So I agree with you Masaru — I don't know what Grenville is referring to there.

Also looking back now I can't seem to find the data files for xlkwd — somehow they seem to have been deleted…?

I'm sure when I first got that code running I checked the .pc files and they looked OK.
My memory tells me I was still resolving a problem with the radiative diagnostics whereby the T3HRAD didn't quite work.
I'm 99% sure I successfully checked the hourly CN and CCN profile data in xconv and it worked.
But as I say the .pg files didn't work — those subsequent runs were attempts to fix that but they all showed the same problem.

So I basically got stuck and haven't been able to fix it.

I have the data for successive test runs xlkwe, xlkwf, xlkwg, xlkwh and xlkwi, see:


And when I open the .pg and .pc files for those the data seems to be there.
However, when I try to look at the data I get failure in xconv with "error extracting data values".

Note: See TracTickets for help on using tickets.