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)
Change history (4)
by , 15 years ago
Attachment: | LM_20090401_064201_M02_1270337828_plot.eps added |
---|
by , 15 years ago
Attachment: | MR_20090401_064201_M02_1270337828_plot.eps added |
---|
minropp solution using ROPP-3 (logq option)
comment:1 by , 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 , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
LevMarq results using ROPP 3.0 with logq option