Opened 15 years ago

Closed 15 years ago

#172 closed defect (fixed)

1dVar logq behaviour

Reported by: Huw Lewis Owned by: Huw Lewis
Priority: normal Milestone: 4.0
Component: ropp_1dvar Version: 3.0
Keywords: logq Cc:

Description

Email from Kjartan:

I remember you were talking about some testing of the two algorithms
you had performed.

I have generally been using the MINROPP minimiser but recently I 
tried running with LEVMARQ instead and saw quite a number of bad 
1D-Var solutions as a consequence.

Generally these solutions show a large (sometimes very large) spike 
in the specific humidity somewhere around the tropopause where my 
observation error description changes. The same files processed with 
the MINROPP minimiser show nothing out of the ordinary.

I am attaching an example [SEE ATTACHMENT TO THIS TICKET]:

ate* is the observation file with error description added
bgr* is the background with error description
ecmwf* is the background error correlation
cor* is the observation error correlation

I have also attached two plots marked LM and MR.

This file was by no means the only one. Using LEVMARQ is saw above 
20 solution profiles in a day being rejected because the humidity 
was above saturation as against only 2 using MINROPP. Also the O-B 
statistic clearly showed that something was going on in this region.

Looking at the LEVMARQ generated solution file above I am also 
somewhat mystified by the low value of J_scaled as it does not seem 
to me to be consistent with the very high values in the J_obs vector 
(also in the solution file).

This requires investigation and a fix!

Attachments (2)

LM_20090401_064201_M02_1270337828_plot.eps (181.3 KB ) - added by Huw Lewis 15 years ago.
LevMarq results using ROPP 3.0 with logq option
MR_20090401_064201_M02_1270337828_plot.eps (182.9 KB ) - added by Huw Lewis 15 years ago.
minropp solution using ROPP-3 (logq option)

Download all attachments as: .zip

Change history (4)

by Huw Lewis, 15 years ago

LevMarq results using ROPP 3.0 with logq option

by Huw Lewis, 15 years ago

minropp solution using ROPP-3 (logq option)

comment:1 by Huw Lewis, 15 years ago

Initial response from Huw:

I tested the sample files you found, and indeed found the same results. 

I then re-tested using the 'default' ROPP sigma values in the observation 
file. This was generated running the /ropp_1dvar/errors/ropp_generate_Osigma.pro 
IDL routine on the observation netcdf file you sent. I do not see the same 
behaviour using these ob errors. If you plot the errors (see n_errrors.eps), 
you'll notice that the ROPP errors (red dash line) are much larger around 
the 10 km region which caused the problems than your errors. Note this is 
a tropical profile, and the ROPP errors are inflated here. Are you using 
latitudinally-varying errors?

Also, I noted very different cost function values with the two sets of errors used.

e.g. KK: 357 -> 66 (minropp); ROPP 36 -> 19 (minropp)

This suggests to me that the ROPP errors are more suitable?

 

So, the 'simple' answer may be to use the ROPP errors. This isn't 
entirely satisfactory though (given that your error description is 
still reasonable). I also stumbled across a few other oddities with 
this profile.

1) the 'spike' disappears if I switch 'use_logq' config option off, 
even using your errors

2) the third levmarq iteration 'explodes' to J > 18000 

3) when testing with Met Office background data, I get NaN values 
within the minropp minimisation (use_logq).

comment:2 by Huw Lewis, 15 years ago

Resolution: fixed
Status: newclosed

See #2217.

  • Added new shum saturation check when using logq option
  • Use log(g/kg) and log(hPa) units in state vector when using logq and logp options respectively.
  • Limit increments in levmarq and minropp routines to within bounds of state vector magnitude.

This solution has been tested on the original data supplied by Kjartan and a number of OPS output Met Office background profiles. There should be no change in behaviour when using 1dVar without logq or logp flags set.

Ticket closed as fixed.

Note: See TracTickets for help on using tickets.