Opened 7 years ago

Last modified 5 years ago

#508 assigned task

New interpolation strategy in grib2bgrasc.f90?

Reported by: Stig Syndergaard Owned by: Ian Culverwell
Priority: normal Milestone: ROPP possible
Component: ropp_io Version: 9.0
Keywords: Cc:

Description

Does the full-level interpolation changes made here:

https://trac.romsaf.org/ropp/changeset/5409/ropp_src/branches/dev/Share/dmi_trunk_8.1/ropp_fm https://trac.romsaf.org/ropp/changeset/5417/ropp_src/branches/dev/Share/dmi_trunk_8.1/ropp_fm

warrant similar changes in grib2bgrasc.f90?

Investigate and implement.

Change history (2)

comment:1 by Stig Syndergaard, 5 years ago

In grib2bgrasc.f90 things are a bit complicated due to possible time interpolation. First variables like P0 (surface pressure), P (pressure profile), Q (humidity profile), T (temperature profile), Z0 (surface geopotential height) are extracted from GRIB files. This happens with calls to extract_prof_from_GRIB in which P is calculated from the Lev2d%level_coeff_a, Lev2d%level_coeff_b, and P0 in the old way (near the end in Section 6.3). Then P0, P, Q, T and Z0 are interpolated in time (in Section 4.2.2). The interpolated P0, Q, T, and Z0 are then used as input to generate_GPH, which calculates Z (geopotential height). The interpolated P is not used for this.

The new way of calculating P (Simmons and Burridge, 1981, eq. 3.18; see #498) uses many of the variables defined in the subroutine generate_GPH. In similar calculations in ropp_fm/model_ecmwf/ropp_fm_state2state_ecmwf.f90 (see r6130) these variable are readily available, but they are not readily available in grib2bgrasc.f90 at the place where the current calculation of P is made. One solution could be to include the calculation of P in the generate_GPH subroutine, i.e., only time interpolate Z0, P0, T and Q, but not P. And then both P and Z are calculated from time interpolated variables. This would also make P fully consistent with Z.

The root of the problem is that the code in the generate_GPH subroutine in grib2bgrasc.f90 is more or less identical to that of ropp_fm_state2state_ecmwf.f90 in the ropp_fm module, but without the calculation of P in the generate_GPH subroutine. For maintenance it is unfortunate to have similar codes in two different places. People tend to forget that changes made in one place should perhaps also be made in other places. Maybe a better solution than the one suggested above would be to put these calculations in a common place (e.g., in ropp_fm), and let both grib2bgrasc.f90 and ropp_fm_state2state_ecmwf.f90 be based on those. That would require grib2bgrasc.f90 (preferably with a different name) to be moved to ropp_fm. This could perhaps be justified in that calculating P and Z from variables in GRIB files is part of the forward modeling. Another solution could be to have these calculations in ropp_utils or some other lower level module then used by both grib2bgrasc.f90 and ropp_fm_state2state_ecmwf.f90.

comment:2 by Stig Syndergaard, 5 years ago

Milestone: DMI ROPP developmentsROPP possible
Owner: changed from Johannes K. Nielsen to Ian Culverwell
Status: newassigned

The suggested solution to include the full-pressure calculation in the generate_GPH subroutine is planned to be implemented in the dmi_trunk (#662) before the next ROM SAF reprocessing.

A possible more long-term solution, including restructuring of codes in ROPP modules, is left for future ROPP development and not something foreseen to be done at DMI.

Note: See TracTickets for help on using tickets.