Opened 18 months ago

Closed 18 months ago

Last modified 18 months ago

#1717 closed help (duplicate)

UM-UKCA v8.4 ARCHER job xlrfv reconfiguration cannot find STASH section 34-163 in dump (but it's there!)

Reported by: gmann Owned by: um_support
Priority: normal Component: UM Model
Keywords: ukca Cc: eelrm
Platform: ARCHER UM Version: 8.4

Description

Dear NCAS-CMS helpdesk,

My UM-UKCA v8.4 job xlrfv on PUMA —> ARCHER is failing during reconfiguration. The job ran OK on Friday but on Monday I resubmitted it with the job set to re-initialise the
non-transported user-prognostic fields 34-151 to 34-163 from
values from an existing dump:

/work/n02/n02/gmann/UMdumps/xlrfca.da20101201_00

The error message I am getting is:

???????????????????????????????????????????????????????
???!!!???!!!???!!!???!!!???!!!???!!! ERROR ???!!!???!!!???!!!???!!!???!!!???!!!?
? Error in routine: Rcf_Set_Data_Source
? Error Code: 30
? Error Message: Section 34 Item 163 : Required field is not in input dump!
? Error generated from processor: 0
? This run generated * warnings
???????????????????????????????????????????????????????

See the rcf.leave files at:

/home/n02/n02/gmann/output/xlrfv000.xlrfv.d15306.t134329.rcf.leave

But I just opened that dump file

/work/n02/n02/gmann/UMdumps/xlrfca.da20001201_00

in xconv on ARCHER and the field 34-163 (which is actually
(CLOUD DROPLET NO CONC)-1/3 ) seems to be there (the index
of the field in xconv is 584) and the field seems to be
fine when I look at the surface distribution.

The other non-transported prognostics (34-151 to 34-162) seem
to be being picked up OK during the reconfiguration so I don't
understand why the 34-163 field is not able to picked up in the
same way.

Could there be an error in the user-STASH-master or STASHmaster_A
file for that particular item this is causing this error?

It looks like quite a tricky one.

Note that I've just updated the xlrfv job in the UMUI so that
it initialises 34-163 to zero field (set = 3 in initialisation
of user-prognostics panel) whereas it was initialising from the
dump (set = 1) in the run that I submitted.

I'm pretty sure that work-around of settings = 3 will work but
it looks like this is a bug in UKCA that needs repairing so
that other users do not come across this same issue.

Please can you advise what the issue might be here.

Many thanks for your help,

Cheers
Graham

Attachments (2)

CDNC_34162_xlrfc_2010Nov26.pdf (37.7 KB) - added by gmann 18 months ago.
Surface CDNC field (34-162)
onovrCDNCcbrt_34163_xlrfc_2010Nov26.pdf (46.6 KB) - added by gmann 18 months ago.
Surface one-over-cbrtCDNC field (34-163)

Download all attachments as: .zip

Change History (4)

Changed 18 months ago by gmann

Surface CDNC field (34-162)

Changed 18 months ago by gmann

Surface one-over-cbrtCDNC field (34-163)

comment:1 Changed 18 months ago by luke

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

Hi Graham,

This is a duplicate of #1324 and #1169. This is probably an issue with reconfiguration, and I'm not sure how to fix it to take the fields from the dump. A work-around solution, as Annette suggests, is to extract the field and make it up as an ancil file to be included, which does work.

If you aren't needing to reconfigure then just run from the dump. If you are only reconfiguring to change the date, but leaving all the fields inside the same, then use /work/n02/n02/hum/bin/change_dump_date:

change_dump_date : which changes the date in the file header

  change_dump_date dumpfile year month day hour minute second

all the date/time arguments are optional

See also: ToolsAndUtilities/UmFileTools

Thanks,
Luke

comment:2 Changed 18 months ago by luke

Just to add, when using change_dump_date, use it on a copy of the original dump, as it over-writes the fields I think.

Thanks,
Luke

Note: See TracTickets for help on using tickets.