Opened 9 years ago

Closed 7 years ago

#892 closed help (completed)

Error when reconfiguring a minimal start dump without physics

Reported by: rmbyoung Owned by: annette
Component: UM Model Keywords: reconfiguration, vegetation, no physics, dry model, free-slip
Cc: Platform: Other
UM Version: 8.2



I have two related queries, one specific and one more general.

The specific query:

I am setting up the UM to run with physics and moisture both turned off, with a free-slip bottom boundary (i.e. a pure dynamical core). To make the compiled code and the input dump as compact as possible I have also manually disabled all the scientific sections except for the dynamics-relevant ones 10-13. Within each of those disabled sections I have also manually unchecked all the boxes I could find, and set all the ancillary files to 'Not used'.

This compiles fine, but there are errors when I run the reconfiguration. The input to the reconfiguration is the input dump supplied with the ExtUM vn8.2 tarball.

The specific error is

? Error in routine: Rcf_Set_Data_Source

? Error Code: 30

? Error Message: Section 0 Item 50 : Required field is not in input dump!

? Error generated from processor: 0

? This run generated 0 warnings

Item 50 is "VEGETATION FRACTION AFTER TIMESTEP". What I don't understand is: Why does the reconfiguration need this field if the section it is relevant to (vegetation - section 19) has been completely disabled? The relevant part of the NLSTCATM namelist is

L_Q10 = T,

I can make the reconfiguration complete successfully by activating section 1A in the vegetation window (still with all check boxes unchecked in that window, and with all ancillary files set to 'Not used'). However, I would prefer not to activate any unnecessary physics packages to avoid conflicts when I add code later on.

If I leave the vegetation section deactivated but switch the ancillary files to 'Configured' in the VFRAC window under the vegetation section, then I no longer get this error, but it still doesn't complete. The error is then

? Error in routine: Rcf_Calc_Len_Ancil

? Error Code: 1

? Error Message: StashCode? is not a valid prognostic variable, Stash Code 216

? Error generated from processor: 0

? This run generated 2 warnings

the stash code quoted varies depends on which ancillary file I activate (it can be 217 too). This doesn't make sense to me either, as both fields 216 (FRACTIONS OF SURFACE TYPES) or 217 (LEAF AREA INDEX OF PLANT FUNC TYPES) are listed under stash section 0 (i.e. as prognostic variables). I am using the supplied ancillary files qrparm.veg.frac and qrparm.veg.func.

I hope this makes sense - is there anything obvious I'm doing wrong here? I can post output or umui basis files if necessary. I appreciate my use of the code isn't really what it was designed for so perhaps this is just something that wasn't tested, but the fact that I have completely disabled the vegetation section and the reconfiguration still needs vegetation fields makes me think I have made a straightforward mistake somewhere.

The general query:

When various scientific sections are disabled, why does a reconfigured dump file still contain a large number of fields that are only relevant for these sections? For example, in the case above, when I disable all but sections 10-13, there are still cloud, soil, snow, surface, ice, orography, and vegetation fields in the reconfigured dump. Presumably the run won't use these, so why do they remain in the dump?



Attachments (6)

basis_yaada_v1 (147.4 KB) - added by rmbyoung 9 years ago.
basis_yaada_v2 (147.4 KB) - added by rmbyoung 9 years ago.
basis_yaada_v3 (147.4 KB) - added by rmbyoung 9 years ago.
yaada000.yaada.d12235.t112403.rcf.leave (62.6 KB) - added by rmbyoung 9 years ago.
yaada000.yaada.d12235.t171127.rcf.leave (80.2 KB) - added by rmbyoung 9 years ago.
yaada000.yaada.d12235.t171947.rcf.leave (56.5 KB) - added by rmbyoung 9 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 9 years ago by annette

Hi Roland,

Can you send the output and basis files please? You can post them here or place them on puma somewhere we can see them.


Changed 9 years ago by rmbyoung

Changed 9 years ago by rmbyoung

Changed 9 years ago by rmbyoung

Changed 9 years ago by rmbyoung

Changed 9 years ago by rmbyoung

Changed 9 years ago by rmbyoung

comment:2 Changed 9 years ago by rmbyoung

Hi Annette,

Here is some output.

basis_yaada_v1 is the basis file for the case with vegetation switched off and no ancillary files activated. I get the first error ("item 50"). The output logfile for this run is yaada000.yaada.d12235.t112403.rcf.leave.

basis_yaada_v2 has the vegetation section switched on and completes successfully. Its output logfile is yaada000.yaada.d12235.t171127.rcf.leave.

basis_yaada_v3 has vegetation switched off but the first ancillary file under VFRAC is "Configured". This gives me the second error ("item 216"); its output logfile is yaada000.yaada.d12235.t171947.rcf.leave.



comment:3 Changed 8 years ago by annette

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

Hi Roland,

Sorry for the long delay in replying to this. We have been thinking about your problem though.

Have you made any further progress yourself?

One thing that occurred to me was whether you should be running an idealised problem (see the options under "Model testing and running backwards in the UMUI"), another source of useful information may be the Idealised Model documentation (UMDP33) available from the CMS webpage (you will need to log in to the site to see it):

If you still have questions we can probably put you in touch with someone at the Met Office who may be able to help further.

Best wishes,

comment:4 Changed 8 years ago by ros

  • Platform set to Other
  • Resolution set to fixed
  • Status changed from assigned to closed

comment:5 Changed 8 years ago by rmbyoung


I have been working on other things for the last 6 months but have returned to this now. I think I was probably making things too complicated for myself and there is probably an easier way to do what I am trying to do.

I want to take the dynamical core of the UM, and then add in some simple physics parametrizations appropriate for the giant planets: Newtonian cooling, simple clouds, simple convection (e.g. dry adiabatic adjustment), vertical diffusion, with a free-slip (or otherwise customised) bottom boundary, all which I already have from work with vn4.5. I have been looking over the idealised problems documentation in UMDP33 and this looks like pretty much what I am after. I think making changes to the Idealised Problems code activated through the Model Testing window is probably the best thing to do.

Do you think it would be better to start with the Test Problem 2. Dynamical core or with option 3. Idealised Problem? I have been able to run test problem 2 by itself without any problems.

After reading UMDP 33 I have a few specific questions about the idealised problems:

  • If I want to add my own simple physics packages later on, do I need to turn on the Include Physics option, or should I add these directly to the idl_force.F90 part of the code? I am wary of turning on this option and turning off all the individual physics options manually (as suggested on p10 of UMDP33), as there may be something left that I missed.
  • If I run Test Problem 2, can I turn off the bottom boundary by checking "Running with free-slip", or will the simple friction term mentioned in UMDP 33 Sect. 5.4 mean this option is ignored for this Test Problem?
  • What is the difference between Test Problems 3 and 4? Is 4 just a normal UM run, but with extra options / override options provided via a namelist?
  • If I select Test Problem 2 are most of the contents of the namelist file ignored (for example, if I turned on L_Baroclinic would it ignore it if I had selected test problem 2)?

What I was trying to do before (I think - I have forgotten some of the details) was to tick the Running a dry model and Running with free-slip boxes, leaving everything else in the Model Testing window unchecked (i.e. no idealised problem turned on). I think this might have been the source of the problems in the exchange above.

comment:6 Changed 8 years ago by rmbyoung

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:7 Changed 8 years ago by grenville

Hi Roland

Sorry for the slow response to this query - I really think this needs to be directed to an expert at the MO. We will try to find the right person.


comment:8 Changed 8 years ago by rmbyoung

Thanks Grenville.

I have been making some progress looking through the source code for the idealised model and can probably answer some of those questions myself now, but it would be useful to have someone confirm if I am taking the most sensible approach.


comment:9 Changed 7 years ago by ros

  • Resolution set to completed
  • Status changed from reopened to closed

Questions moved to UM collaboration newsgroups

Note: See TracTickets for help on using tickets.