Custom Query (3332 matches)


Show under each result:

Results (10 - 12 of 3332)

1 2 3 4 5 6 7 8 9 10 11 12 13 14
Ticket Resolution Summary Owner Reporter
#863 fixed accessing the $RUNID environment variable from a FAMOUS handedit annette ggjhtw

Hi there

I'm a researcher at Bristol Uni running FAMOUS.

I'm using a handedit (~ggjhtw/scripts/optimum_params_v3 on PUMA) to change some of the parameters in the CNTLATM and CNTLOCN files. I need it to work generically (i.e. for an arbitrary RUNID). The previous incarnation of this handedit (optimum_params_v2) has the explicit RUNID included instead of $RUNID. The $RUNID environment works fine when inserted within the UMUI itself, for example in the specification of the location of the executable. Is there a way of getting the handedit to recognise this variable?

Many thanks

Jonny Williams

#889 fixed Reducing model output annette SimonDriscoll


in order to conserve space I wanted to reduce model output to only the diagnostics I wished or may needed to analyse. I was advised that to do this I should change things in:

Atmosphere—>STASH—>STASH. Specification of Diagnostic requirements

and then once I'm in there I choose the Incl option from Y to N if I don't want it to be outputted.

And the same for Ocean, i.e.:

Ocean—>STASH—>STASH. Specification of Diagnostic requirements

The 'incl' option seems possible to be referring to actually 'using' rather than outputting some schemes/data, but I tried this anyway.

In my job xhlaf with which I tried this I get complaints and it doesn't run (HECToR's not available currently so I can't detail the specific complaint) - xhlaf is a copy of a job that has run perfectly fine without these changes to the STASH.

Could you tell me the correct way to reduce model output?

Many thanks,


#892 completed Error when reconfiguring a minimal start dump without physics annette rmbyoung


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


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?



1 2 3 4 5 6 7 8 9 10 11 12 13 14
Note: See TracQuery for help on using queries.