Custom Query (3351 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (43 - 45 of 3351)

Ticket Resolution Summary Owner Reporter
#261 fixed upgrading to 7.0/7.1 willie beh27
Description

I have recently been running some jobs that I have converted from the standard UMUI jobs for LAMs. I've had some success, but I have since reviewed some of the material from the UM training day and it seems sensible that I should be working with the FCM system and version 7.0 or later of the UM considering I am at the beginning of my PhD and will most likely be using the UM for the next three years. Does this make sense? Is there any plan to provide a nested model standard job similar to the one for 6.1?

Thanks… Benjamin

#262 fixed output nan issue willie beh27
Description

I have been trying to get a LAM run with um6.1 running (xdwua: global with LBC output, xdwub: LAM). These are both based on the standard nested umui jobs. The LBC output from the global model looks fine so I'm happy that the first stage is running fine. The second job (xdwub) also runs fine, but there is a problem with the output. The .start file looks fine. I haven't changed the STASH so I'm getting 3 hourly output. For the wind data, for example, after the first three hours, NaNs? have taken over much of the domain leaving an area with data over a small area with high topography (center of Greenland) and data for the boundaries. After subsequent three hour dumps, only boundary data remains. This is the same for most other fields I've checked as well. I get the feeling that the data existing over high topography may indicate that the reconfiguration step with the topography is to blame, but if anyone has any experience of this kind of problem or can think of what is wrong then I'd be grateful to hear what they think!

Thanks, Benjamin

#265 fixed using LAMPOS willie mjm
Description

We installed LAMPOS on our cluster, ECDF, following the LAMPOS web page (setting alias, using $HOME/lampos).

  1. When the window opens there is no grid. Therefore,
  1. We tried to load a grid from a previous job, which for us meant that we created a ~/umui_jobs/xdukb directory and copied SIZES into it.

child process exited abnormally child process exited abnormally

while executing

"exec grep -i EWSPACEA= $file | perl -pe s{.*EWSPACEA=\\s*(\\S+),.*}{\\1}i"

(procedure "getgridfromjob" line 57) invoked from within

"getgridfromjob"

invoked from within

".view.rd.scr.lw.apply invoke"

("uplevel" body line 1) invoked from within

"uplevel #0 [list $w invoke]"

(procedure "tk::ButtonUp?" line 22) invoked from within

"tk::ButtonUp? .view.rd.scr.lw.apply"

(command bound to event)

We also tried installing LAMPOS on PUMA, but it rejected the processor type "athlon". Next we tried to use lampos_i386 directly, avoiding the top script, also failed as follows: mjm@puma:/export/puma/data-01/home/mjm> cd lampos mjm@puma:/export/puma/data-01/home/mjm/lampos> lampos_i386/lampos lampos.tcl Error in startup script: couldn't execute "../../bin/lltoeq.exec": no such file or directory

while executing

"open "|echo $scale $plon $plat $xshift $yshift $coast | ../../bin/lltoeq.exec" r "

(procedure "drawmap" line 21) invoked from within

"drawmap"

(procedure "main" line 272) invoked from within

"main"

(file "lampos_i386/lampos.tcl" line 31)

So our questions are:

  1. is it better to have this on PUMA or on our own cluster?
  1. Can you give guidance to help it work on one or the other, please.

Regards Mike

Note: See TracQuery for help on using queries.