Opened 10 years ago

Closed 9 years ago

#645 closed help (fixed)

UM idealised set up - surface friction?

Reported by: beh27 Owned by: um_support
Component: UM Model Keywords:
Cc: Platform:
UM Version: 7.5


I've been trying to set up an idealised UM run. I have successfully run the 'schar problem' UMUI job and have now adapted this to fit my requirements. The current job I am working on is xgdyg which has the following criteria:

# 400x400 0.11 lat/lon spacing LAM domain
# 73 levels in vertical (standard vertical namelist)
# No orography (I eventually want to put in idealised and real orography, but for now I'm looking for getting the initial atmospheric conditions correct.)
# Constant velocity at all heights (in this case u = -10 m/s, v = 0 m/s)
# f-plane at latitude 68 degrees
# No moisture
# Constant temperature gradient in the vertical (stable atmosphere)
# Pressure balance in initial conditions
# Fixed LBCs (by setting the namelist avriable L_fixed_lbcs - I believe this overwrites a dummy LBC file - whish I generated using xgdye - with the initial conditions)
# Free slip surface

It is this last point that I think I am having trouble with - it isn't set in my idealised namelist (/work/n02/n02/beh27/namelists/idealise_fplane_pressbal) but is set in the 'Model testing and running backwards' window as a tick box. I'm not sure the run is using this though as in theory the lowest level should experience no surface friction and immediately after the run starts, the near surface fields start veering to the left (as would be expected with geostrophic flow and friction). This creates a problem with my LBCs which (at the moment) are fixed at v = 0 m/s. There is hence a huge amount of convergence at the southern boundary which affects the fields in the whole domain due to the vertical circulations set up there. I am happy with the rest of the set up, the pressure balance looks like it is working well for the rest of the domain and the LBCs look fine too.

Can you inform me of anything about my set up that might be negating the free slip option or producing the effect seen near the surface?


Change History (11)

comment:1 Changed 10 years ago by grenville


Have you tried running with the 'free slip boundary conditions' option switched off - just to see what might be happening?


comment:2 Changed 10 years ago by beh27

Hi Grenville,

Thanks for the suggestion. I have tried it now with the free slip turned off, but the results are the same. Maybe this suggests that this option must get over-ridden in the code run from an idealised namelist? Having looked at the output a little more closely it seems that maybe my initial diagnosis was off. Even after the first time step, there is a small southward velocity of 0.1 m/s at all heights in the model (stronger at the surface). As the hours progress, the largest southward velocities aren't found at the surface (as might be expected if this was a surface frictions problem) but in a broad region above the boundary layer (after 4 hours this is -6 m/s!). This maybe suggests that it isn't so much the free slip boundary conditions which is at fault but maybe the initial pressure balance is wrong in the interior? - I did a rough calculation based on the meridional pressure field in the LBCs and it looks like it should support the prescribed magnitude zonal wind field so maybe that explanation is wrong also. Any suggestions? Thanks! Benjamin

comment:3 Changed 10 years ago by willie

Hi Benjamin,

There are no obvious errors in the output. However, I notice that in your later runs you are getting,

?????    Is your height_domain too high ?????

Could this be a problem?



comment:4 Changed 10 years ago by beh27

Hi Willie,

Are you referring to job xgdyh for this error message? I set this job up as a test bed to try a few things out on such as reducing the number of levels which caused that particular error message. I am using that job to play around with for the time being, but the job xgdyg is the one with the set up as I want it… As you say, there dont appear to be any errors from that job so the model at least is running smoothly. It just surprises me that with no surface friction (in theory, but I am unconvinced this is being used due to the lack of difference between runs with or without the free slip tick box) and a pressure balanced, uniform, zonal wind distrubution that any meridional velocities should exist at all, let alone at height in the interior as soon as 2.5 mins after the start and becoming 6 m/s after 4 hours… puzzling… any other suggestions? Thanks!



comment:5 Changed 10 years ago by beh27

I've solved one of the problems - I noticed that even though I am setting up a dry atmosphere, the surface fluxes were still on and the atmosphere was hence filling up with moisture during the run which was perturbing the geostrophic balance. I turned this off by setting IdlSurfFluxSeaOption? to 1 in the idealised namelist (even though, according to the UM doc 33, this should be the default anyway). I now have a set up which looks very much like surface friction is causing all the problems. I have run the model again with the surface set to slip free or regular and there is still no difference in the output. Would you agree then that the 'free-slip' check box is being over-ridden when the code gets compiled? Is there anyway of modifying the code or including an option in the namelist to ensure this doesn't occur?



comment:6 Changed 10 years ago by grenville


We are getting advice from our Met Office colleagues and will contact you when we have further information.


comment:7 Changed 10 years ago by beh27

Thank you very much for enquiring about this for me!

Just to update you, I have been playing around a bit more and have found this link:

which suggests that if a boundary layer scheme is used then this overrides the choice of free-slip in the UMUI. I am therefore attempting to turn the boundary layer scheme off to see if this makes a difference - I am attempting this in xgdyh. There are problems with doing this - the UMUI tries to make you change inconsistent settings in the 'hydrology' and 'vegetation' schemes. I have ignored this for the time being (simple changes to them makes the model fail in reconf) and have just turned off the boundary layer scheme and have a run which reconfigures fine but then fails in the run (see xgdyh000.xgdyh.d11187.t113454.leave)… something to do with a bad input value for FRAC_SNOW_SUBL_MELT in namelist. I will try further experiments to try and work out what is going wrong. Just wanted to let you know what I had diagnosed from my end if this helps…

Anyway, I look forward to hearing back from you once you've discussed this with folks at the MO.



comment:8 Changed 10 years ago by beh27


Any word on this at all? I have been running a few other tests based on things I've been thinking of, but as of yet no luck…



comment:9 Changed 10 years ago by grenville


I thought I already sent this to you and that you were in direct contact with Terry Davies.

Carol, Benjamin

The free-slip lower boundary condition is there to test inviscid flows
over orography since for sloping surfaces w is NOT 0 for inviscid flows.
The switch is there so that the appropriate w is calculated at the
surface. Note that for horizontal surfaces, w=0 even for inviscid flows
so where there is no orography it does not matter whether the switch is
active or not. Also for real flows the switch has little impact due to
the surface friction and boundary layer parametrizations.

The pressure balance option is used to balance flows at the start even
in the presence of orography. Note that this changes the temperature and
pressure fields regardless as to the initial profiles selected and is
only balance in the shallow atmosphere sense (to derive analytical
relations needs a constant distance from the centre of the Earth at all
levels). For spherical coordinates, v must be set to zero but for
cartesian f-plane both u and v can be set. For the kind of problems you
are running you probably do not want to use the pressure balance but
allow the model to spin up from the initial settings. This is also why
you have a problem with the v=0 lbc.

When using a constant temperature profile you need to make sure that
your lowest level is low enough since the UM assumes that the lowest
layer is isentropic (constant potential temperature) when calculating
the horizontal pressure gradient term. This is the one drawback for the
Charney-Philips vertical staggering since for real flows obtaining the
temperature at the first wind (rho) level really involves using the
physics (since you cannot just take the average of the surface value and
the first temperature level due to the diurnal variations at the


Terry Davies Expert Scientist Dynamics Research
JCMM Meteorology Building
The University of Reading
PO Box 243 Reading RG6 6BB United Kingdom
Tel: +44 (0)118 3785617 FAX: +44 (0)118 378791
Email: terry.davies@…


comment:10 Changed 10 years ago by beh27


Thanks for this, I have now contacted Terry and hope to get this resolved shortly…


comment:11 Changed 9 years ago by ros

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.