Opened 8 years ago

Closed 8 years ago

#848 closed help (fixed)

MOGREPS vn7.8 run taking far too long

Reported by: abarrett Owned by: willie
Component: UM Model Keywords:
Cc: Platform:
UM Version: 7.8



I have created a version of MOGREPS-R to run on vn7.8, but it seems to be taking too long to run. It uses the NAE domain and has 18km grid spacing, 70 levels and runs to T+30.

The control member (xhbxl) runs in about 2.5 hours, but the perterbed member (xhbxn) fails to complete in 12 hours (and doesn't seem to have reached 3 hours into the simulation - I expect a dump after 3 hours).

Other similar jobs run in the past (not by me, e.g. xdycb) have run in 20-30 minutes, admittedly with an earlier version (7.1) and lower resolution (24km x 38 levels).

What can I try to get the model to run in a normal time period?


Change History (8)

comment:1 Changed 8 years ago by willie

  • Owner changed from um_support to willie
  • Status changed from new to accepted

Hi Andrew,

There are some UMUI check setup errors:

  • I think you should switch off Analysis Correction (Atmos > data Assim > Top Level) - unless you need it, in which case you need to define the EXTERNALs
  • In Scientific sections Section 35 push RP and close the page so the UMUI recognisies the contents - you might have to repeat this after another check setup

To get more output, go to section 13 push DIAG PRN and then tick the flush print buffer button.

You did seem to get a lot of output on the 3rd May, possibly associated with switching the output LBCs off.



comment:2 Changed 8 years ago by abarrett

Thanks Willie,

This has helped a little, but I still have the problem. I have done some further tests and the problem seems to be coming from the random parameters scheme. Turning RP off allows the job to complete in 50 minutes, but with it on the job fails in the first timestep but continues very slowly with NaNs? until it times out. Do you know if this might be a vn7.8 problem, an issue with my setup or an issue with having 70 levels.

Any suggestions much appreciated.

comment:3 Changed 8 years ago by willie

Hi Andrew,

There are NaNs? in the first time step which suggests a set up problem. The input files seem OK. There is no need to run for long periods in this case. I would build the executable with the debug option switched on and (section 13) print the diagnostics every time step. It may help to switch on the two norm.

The help panel for the RP says that the numbers used depend on the resolution, so you may need new values - see UMDP 081.



comment:4 Changed 8 years ago by abarrett

Hi Willie,

I'm still having problems, seemingly with the RP scheme rather than the job itself. As an alternative I'm trying to run MOGREPS-R on vn7.1 using the umui jobs. Do you have a user STASHmaster file that will allow the vn7.1 job to run a using vn7.8 start dump? I see a similar file exists on your PUMA account to fix ticket #574, switching from 7.5 to 7.3.


comment:5 Changed 8 years ago by willie

Hi Andrew,

There is no specific file since it depends on the start dump. You'll need to switch reconfiguration on and see what entries it complains about. Then create your own user STASHmaster by copying the complained about entries from $UMDIR/vn7.8/ctldataSTASHmaster/STASHmaster_A.



comment:6 Changed 8 years ago by abarrett

Thanks Willie,

I seem to have stopped the complaints about the STASHmaster file following the method above, but I now get another error, which I don't understand at all.


ERROR!!! in reconfiguration in routine Rcf_PSLevCod
Error Code:- 2
Error Message:- Error from PSLevCod
Error generated from processor 0

Do you know what causes this error, and have any ideas about how to fix it?
Many Thanks

comment:7 Changed 8 years ago by willie

Hi Andrew,

The problem is the user STASH contains pseudo level codes (11) that were not thought of at 7.1. Since you presumably don't care about these fields, you could cheat by setting the codes to an acceptable value for 7.1 code - it looks like " 9" might work.

The format of the user STASH can be found in UMDP C4.



comment:8 Changed 8 years ago by willie

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