state2state_ecmwf (and state2state_meto) prevents ice supersaturation

[Johannes K. Nielsen]

The background profiles are modified by ropp_fm_bg2ro_1d. shum is automatically adjusted to be below ice supersaturation and liquid water supersaturation levels IF the logq option is chosen.

First one would not expect ropp_fm_bg2ro_1d to change the input variables.

Secondly, and more important, I do not think that supersaturation over ice should be prevented at all since it happens in nature from time to time. It is also allowed by ECMWF.

Third is has some indirect consequences on the stability of the costfunction evaluation if ropp_fm_bg2ro_1d is used during postprocessing

Suggestion: Make the check_qsat optional, with default beeing no-check jkn

[Ian Culverwell]

No one objected to this at the ROPP-GG meeting on 20th June 2012. Need to update documentation accordingly.

[Ian Culverwell]

Prepared mods for ROPP6.1. ropp_fm_bg2ro_1d, ropp_fm_bg2ro_2d, ropp_1dvar_refrac and ropp_1dvar_bangle now have a -check_qsat switch to switch on the check that q is not saturated, whether or not -use_logq is in effect. (Previously, there was no option to call check_qsat unless one was using --use_logq.) By default, no such check is made, ie supersaturation is allowed.

Details

Key codes: ropp_fm/model_ecmwf/ropp_fm_state2state_ecmwf.f90 and ropp_fm/model_meto/ropp_fm_state2state_meto.f90. Replace

  IF (x%use_logq) THEN
    x%shum = EXP(x%state(x%n_lev + 1: 2*x%n_lev)) / 1000.0_wp
    CALL check_qsat(x%shum, x%temp, x%pres)
  ELSE
    x%shum = x%state(x%n_lev + 1: 2*x%n_lev)
    WHERE (x%shum <= 0.0_wp)
      x%shum = 1.0e-9_wp
    ENDWHERE
  ENDIF

by

  IF (x%use_logq) THEN
    x%shum = EXP(x%state(x%n_lev + 1: 2*x%n_lev)) / 1000.0_wp
    IF (x%check_qsat) CALL check_qsat(x%shum, x%temp, x%pres)
  ELSE
    x%shum = x%state(x%n_lev + 1: 2*x%n_lev)
    IF (x%check_qsat) CALL check_qsat(x%shum, x%temp, x%pres)
    WHERE (x%shum <= 0.0_wp)
      x%shum = 1.0e-9_wp
    ENDWHERE
  ENDIF

I haven't bothered updating the TL or AD codes, because they didn't involve any calls to check_qsat anyway. This is probably wrong.

Results

ropp_fm

ropp6.0 -use_logq = ropp6.1 -use_logq -check_qsat to within rounding error of +/-1e-15.

ropp6.0 (no options) = ropp6.1 (no options) exactly. (Why the difference? -use_logq implies use of EXP(ALOG(q)), and perhaps these are treated slightly differently at ropp6.0 and 6.1?)

Impact of -check_qsat at 6.1: dq ~ 1e-3 g/kg at upper levels, whether or not -use_logq is on. Reasonable.

ropp_1dvar_refrac

use_logq=.false. by default. +/- check_qsat typically gives ~0.01K in temp; 0.10 g/kg in shum. Concentrated lower down? For some profiles it's exactly zero, which makes sense. Reasonable. (The cntl, ie without -check_qsat, seems to take more iterations in general.) use_logq=.true. ==> more similar convergence histories, but rather larger diffs in T and q.

ropp_1dvar_bangle use_logq=.false. by default. dshum ~ 0.01 g/kg (concentrated towards bottom); dtemp ~0.1K (all levs). Two profiles untouched. use_logq=.true. ==> rather larger changes in shum and temp, but still OK.

All this with minropp. Not bothering with LevMarq.

[Ian Culverwell]

Asked Joe for some test data on 14/12/2013:

Hi Joe,

I've coded a fix for this.  Could you give me an example data set where the unmodified code causes trouble, so I can test it please?

Thanks,
Ian.

[Ian Culverwell]

Joe replied on 11/1/2013:

Hi Ian
I have not forgot this ticket. Sorry for not responding. The thing is that I tried to
generate some examples in December. But I got confused because it turned out that the
ECMWF forecasted  profiles were cut of at RH = 100%. Previously I had some examples
with RH > 100 % in the ECMWF forecast. I need some time to sort it out.
Could it wait until February? I am on a field campaign (exceptionally) from 17-31 Jan.
joe

Didn't really have time to postpone ROPP6.1 any more, so closing ticket. Joe can reopen at ROPP7.0 if he's unhappy with the above solution.