Opened 9 years ago

Closed 9 years ago

#797 closed help (fixed)

Strange startup behaviour in radiation in nested LAM?

Reported by: kjp Owned by: willie
Component: UM Model Keywords: reconfiguration
Cc: Platform:
UM Version: 6.1


I'm running a 4km LAM (xgzmb) one-way nested in a 12km LAM (xgvuy). No PV tracer mods are involved in either. Looking at a vertical slice of the SW or LW increments in the 12km model produces sensible looking structures but the 4km has bright artificial bands running horizontally across the domain at a couple of levels.

Example netcdf files of the fields are:


Attachments (1)

SW_inc_after_1ts_4km.jpg (69.9 KB) - added by willie 9 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 9 years ago by kjp

I've tracked this to what seems to be a problem in the reconfiguration of the Ozone field for nested LAM jobs. The ozone in the start file created by the 12km job (dimensions 146x182x38) is sensible with values of 10-5 to 10-8. It was run from a global job start file (xghkd, ozone dimensions 1x481x50). The ozone in the start file generated by the 4km job (320x430x38) that is nested in the 12km and uses its start file is full of large positive and negative numbers ~105. I shall try using ozone from an ancilliary file instead and see what happens…

Changed 9 years ago by willie

comment:2 Changed 9 years ago by willie

  • Keywords reconfiguration added
  • Owner changed from um_support to willie
  • Status changed from new to accepted

Hi Kevin,

It looks like reconfiguration has failed in the 4km run, but only at a few levels. You could try changing the processor configuration and increasing the diagnostics level for the reconfiguration.

I hope that helps.



comment:3 Changed 9 years ago by willie

Hi Kevin,

Another thing you could try is to reduce the optimisation of the reconfiguration. See ticket #776, but this time add the override file to the compile options for the reconfiguration table.



comment:4 Changed 9 years ago by kjp


While plots of ozone from the .start file make it look as though there may only be a few columns wrong, the numbers are unphysical in the whole field.

Unfortunately, neither changing the processor config to 8x4 rather than 4x8 (xgzmm) or reducing the optimisation (xgzmo) worked. However, including the full 38 level ozone field as an ancilliary file with reconfiguration did resolve things (xgzmn).

I've checked with someone elses nested LAM at 6.1 and their ozone field shows the same issue so it might well be a general problem.



comment:5 Changed 9 years ago by willie

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