Azimuth not copied by FM

[Ian Culverwell]

Axel von Engeln (EUMETSAT) points out that the azimuths in EPS-SG_SummerTestOrbit_GNSS_3profs.bg.nc (attached):

ncks -H -vazimuth EPS-SG_SummerTestOrbit_GNSS_3profs.bg.nc                                  
dim_unlim[0] azimuth[0]=53.772 
dim_unlim[1] azimuth[1]=0.275 
dim_unlim[2] azimuth[2]=17.199 

are not transferred to the output file when this file is passed through the forward model:

ropp_fm_bg2ro_1d EPS-SG_SummerTestOrbit_GNSS_3profs.bg.nc -f -o temp.nc

ncks -H -vazimuth temp.nc                                          

dim_unlim[0] azimuth[0]=0 
dim_unlim[1] azimuth[1]=-9.9999e+07 
dim_unlim[2] azimuth[2]=-9.9999e+07 

Not good.

Finding out why the first one is zero, not ropp_MDFV, might be a help.

This file comprises the first three profiles of a larger, 380-profile multifile (​https://www.dropbox.com/s/gt1597t8avbf7n9/EPS-SG_SummerTestOrbit_GNSS.bg.nc?dl=0). We get the same result when we extract profiles 2-4 instead, so it doesn't seem to be the result of anything singular about the first profile.

[Ian Culverwell]

EPS-SG_SummerTestOrbit_GNSS_3profs.bg.nc

[Ian Culverwell]

(It's still a problem without the -f.)

[warrick]

The problem was in ropp_fm_roprof2obs.f90, in the subroutine ropp_fm_roprof2obs1dbangle.

In the same file, the subroutine ropp_fm_roprof2obs2dbangle has this code to copy azimuth into the bending angle structure y:

  IF (isinrange(ro_data%georef%azimuth, ro_data%georef%range%azimuth)) THEN
    y%azimuth = ro_data%georef%azimuth 
  ELSE
    CALL message(msg_warn, "Azimuth out of range or missing.")
    CALL message(msg_warn, "Check input data and valid_range attributes")
    CALL message(msg_warn, "Set status flag obs%ok to FALSE")
    y%obs_ok = .FALSE.
  ENDIF

Adding this code to subroutine ropp_fm_roprof2obs1dbangle fixes the problem.

[warrick]

The reason why the first profile was ending up as zero while the subsequent ones end up as ropp_MDFV is that in ropp_fm_types.f90 the components of TYPE Obs1dBangle are declared but not given initial values. At the end of ropp_fm_bg2ro_1d, ropp_fm_free sets the components to ropp_MDFV

[warrick]

Fixed at r5749

[warrick]

Run forward model and show azimuth of input and output files

[warrick]

Update: the code change I previously committed set y%obs_ok to false if no azimuth found, causing some tests to fail. I have now updated the code to just warn about missing azimuth. changeset:5783

[Ian Culverwell]

Added some comments at r5862. When I run EPS-SG_SummerTestOrbit_GNSS_3profs.bg.nc through the ROPP 1D FM codes, I find:

ROPP9.1

azimuth[0]=0 
azimuth[1]=-9.9999e+07 
azimuth[2]=-9.9999e+07 

ROPP10.0

azimuth[0]=53.772 
azimuth[1]=0.275 
azimuth[2]=17.199 

which match the input values.

When I artificially set azimuth = -1000 in EPS-SG_SummerTestOrbit_GNSS_3profs.bg_wrong.nc (attached), ROPP10.0 tells me

...
WARNING (from ropp_fm_roprof2obs (1D bending angles)):  Azimuth (of -0.1E+09 deg) out of range or missing.
 
WARNING (from ropp_fm_roprof2obs (1D bending angles)):  Check input data and valid_range attributes.
 
WARNING (from ropp_fm_roprof2obs (1D bending angles)):  Continuing, as azimuth not needed for 1D bending angles.
...

before producing

azimuth[0]=0 
azimuth[1]=-9.9999e+07 
azimuth[2]=-9.9999e+07

for the reasons Francis explains.

[Ian Culverwell]

EPS-SG_SummerTestOrbit_GNSS_3profs.bg_wrong.nc