Opened 5 years ago

Closed 5 years ago

#1538 closed help (answered)

Reconciling old start dumps to model input requirements

Reported by: kieranmrhunt Owned by: um_support
Component: UM Model Keywords: HadGEM3-A
Cc: Platform: ARCHER
UM Version: 8.2

Description

Hi there,

I'm trying to use an old MO start dump (July 2007) in a basic job copied from the umui example list. The problem is that I invariably get the error message at reconfiguration:

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

Initially I overcame this by filling in the required field in the STASHmaster file, fixing it to zero in the user prognostics, and rerunning (to find the next missing field), but as a trial and error method this is extremely slow. Is there a quick fix to zero out all missing fields? If not, is there somewhere where I can find a list of required fields to compare the start dump to?

For reference, this is job xlhbc.

Thanks,
Kieran

Change History (8)

comment:1 Changed 5 years ago by willie

Hi Kieran,

The required fields depends on the science set up in your model. If your start dump doesn't have these then you usually use reconfiguration to select the source. See my ARCHER utilities

~wmcginty/bin/reqd_fields
~wmcginty/bin/dump_fields

So do one run to get it complaining, the use the first on the leave file and the second on the start dump. The compare to find the differences.

regards

Willie

comment:2 Changed 5 years ago by kieranmrhunt

Hi Willie,

Thanks - that got it past the reconfiguration stage. It now builds but (unlike the experiment it was copied from) doesn't seem to produce any output. I'm probably missing something simple but I can't work out why from the leave file. Could you point me in the right direction?

Thanks,
Kieran

comment:3 Changed 5 years ago by willie

Hi Kieran,

It has failed at the first time step:

GCR( 2 ) failed to converge in  100  iterations.

This usually indicates a problem with the initial set up. Either the start dump is wrong, or in this case, I think the ancillary fields may not be present, or have the incorrect data. Check them individually.

Regards

Willie

comment:4 Changed 5 years ago by kieranmrhunt

Hi Willie,

It's a direct copy of an example umui job - so I assume the problem wouldn't be in the ancillary fields (unless I'm missing something obvious). When doing the dump/reqd fields comparison from above, I set all missing fields to zero, is there something among them that might need to be pointed to an ancillary file (I'm thinking especially the gridbox area field…)?

Thanks,
Kieran

comment:5 Changed 5 years ago by willie

  • Keywords HadGEM3-A added

Hi Kieran,

You appear to have taken a copy of xkvua and replaced the start dump. This caused the mismatch in fields which you have attempted to correct using your ~kieranmrhunt/packing_fixes2 user STASH file. There are a large number of fields involved and you have set them to zero. I am not familiar with this type of run, but this looks unusual. If you replace the original start dump and switch off your user STASH does the job then run?

Regards

Willie

comment:6 Changed 5 years ago by kieranmrhunt

Hi Willie,

Yes, with the original start dump and without my user STASH file it runs fine (and is, at that point, essentially just a copy of the original). Is there a more suitable example umui job to use that start dump with?

Thanks,
Kieran

comment:7 Changed 5 years ago by kieranmrhunt

Just realised I misunderstood the question. When I run it with the original start dump and with my user STASH file it fails at reconfiguration - I can't work out why though…

Cheers,
Kieran

comment:8 Changed 5 years ago by annette

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

This ticket has been superseded by #1558

Note: See TracTickets for help on using tickets.