Support for simple simulated orbits

[Dave Offiler]

Helpdesk enquiry from Stephan Junker (UniBwM) 2/8/2012:

Hello,

I have simulated phase and amplitude measurements for RO events
with an adaption of the GFZ software "simend2end", which uses
analytical refractive profiles and turns them into phase
measurements by using inverse FSI. In parallel, the orbits of LEO
and GPS satellites (occ+ref) are simulated. The simulated orbit
move exclusively in the x,y plane and therefore the z-value for all
satellites is always '0.0'.

Now my question regarding the ropp-6.0 package. When I use the
ropp_pp_occ_tool the preprocessor is exiting the processing with
the statement: "invalid coordinate values". Is the described
satellite constellation the problem or are there other reasons for
this behaviour?

Thank you and kind regards,
Stefan Junker

After a quick look, my reply was:

Stefan,

This check and error message comes from the preprocessor source
code file:
  ropp_pp/preprocess/ropp_pp_preprocess.f90
and can be triggered by *any* X,Y,Z coordinate of the LEO *or* the
GPS satellite having a 'missing data' value. We'd need to trace
backwards to see which satellite(s), and which coordinate
component(s) have this special flag value, and why.

I suspect that if any single coordinate value over a profile is a
constant zero, this is assumed to be an error condition (it's
certainly not valid for real satellites!), but I don't know this
code well enough myself to be sure if this sort of test is done
(the author is on holiday at the moment...)

I do know for certain that if all three X,Y,Z values are zero, this
is a flag for the satellite location to be 'missing'

If possible, could you please try to:
(a) ensure that all 6 coord values are within sensible range (and
none are [0,0,0])
(b) set a non-zero Z-value (1.0 (metres) shouldn't make any
practical difference to the simulation)
(c) print out the 2 sets of coordinates (line 104 of the above
source code file - obviously this would mean re-compiling the
pre-process module)

ROPP wasn't designed for the orbits you are simulating, so we will
revisit the code to see if there are tests and/or assumptions that
can be relaxed to support your simulations (for a future release or
patch update), or if a simple data change (like not having
constant-zero coordinate values) might get past these checks.

Stephan later confirmed that setting his Z-values to 0.1m (my option (b) works, allowing the Helpdesk item to be closed.

So I would hazard that somewhere in the ROPP code, there's a check for all X, Y or Z POD elements in a profile being zero (within some tolerance), but is happy if all value are non-zero (even if identical.

We should now re-visit the code to decide whether this test can be relaxed, or merely that setting non-zero Z-values (or any POD element?) for simple simulated orbits should be noted in the UG.

[Ian Culverwell]

The culprit is a couple of lines in ropp_io_rancheck:

    DO j = 1, 3
      DO i = 1, Lev1a%Npoints
        IF ( Lev1a%r_GNS(i,j) < Lev1a%Range%r_GNS(mn) .OR.    &
             Lev1a%r_GNS(i,j) > Lev1a%Range%r_GNS(mx) .OR.    &
             Lev1a%r_GNS(i,j) == ropp_ZERO )       &
             Lev1a%r_GNS(i,j) = ropp_MDFV
      END DO
    END DO


    DO j = 1, 3
      DO i = 1, Lev1a%Npoints
        IF ( Lev1a%r_LEO(i,j) < Lev1a%Range%r_LEO(mn) .OR.    &
             Lev1a%r_LEO(i,j) > Lev1a%Range%r_LEO(mx) .OR.    &
             Lev1a%r_LEO(i,j) == ropp_ZERO )    &
             Lev1a%r_LEO(i,j) = ropp_MDFV
      END DO
    END DO

I don't see why we can't just suppress the checks against ropp_ZERO.

[Ian Culverwell]

Or maybe just a check that sqrt(x*x+y*y+z*z) .GT. something small and .LT. something big (eg upper limit of range). That would allow simulated data to pass but filter out rubbish POD data. (Set x, y, and z all to mdi if it fails this test.)

Could maybe apply the same idea to the velocities.

[Ian Culverwell]

Stefan has kindly supplied some data to allow us to test whatever fix we implement. See attached zip file.

[Ian Culverwell]

Eventually decide to go with:

    DO j = 1, 3
      DO i = 1, Lev1a%Npoints
        IF ( Lev1a%r_LEO(i,j) < Lev1a%Range%r_LEO(mn) .OR.    &
             Lev1a%r_LEO(i,j) > Lev1a%Range%r_LEO(mx) )       &
             Lev1a%r_LEO(i,j) = ropp_MDFV
      END DO
    END DO

    DO i = 1, Lev1a%Npoints
      IF ( SUM(Lev1a%r_LEO(i,:)**2) > Lev1a%Range%r_LEO(mx)**2 ) &
           Lev1a%r_LEO(i,:) = ropp_MDFV
    END DO

    DO i = 1, Lev1a%Npoints
      IF ( SUM(Lev1a%r_LEO(i,:)**2) < 0.01_wp*Lev1a%Range%r_LEO(mx)**2 ) &
           Lev1a%r_LEO(i,:) = ropp_MDFV
    END DO

and sim for r_GNS, v_LEO and v_GNS. So we require each component to lie within [min, max], and the magnitudes to lie within [0.1, 1]*max. Note that this implies a change to test2ropp, which generated "valid" data within a cube, not a shell.

Works OK after passing Stefan's test data through ropp_pp_occ_tool.

Previously :

INFO (from ropp_pp_cutoff_amplitude):  Cut-off (amplitude/LCF criterion). Keep data        1 to     4802
 
WARNING (from ropp_pp_preprocess):  Invalid coordinate values. Exiting processing.

Now:

INFO (from ropp_pp_cutoff_amplitude):  Cut-off (amplitude/LCF criterion). Keep data        1 to     3736
INFO (from ropp_pp_preprocess):  CHAMP data preprocessing
INFO (from ropp_pp_cutoff):  Cut-off (bangle/impact criterion). Keep data        1 to     3488
INFO:  Retrieving bending angle profiles by GEOMETRIC OPTICS 

INFO:        3488 data points in output between 6381.0km and 6516.8km 

INFO:  Correcting bending angle profile by STATISTICAL OPTIMISATION 

INFO:        1273 data points in output between 6380.9km and 6508.1km 

INFO:  Retrieving refractivity profile by LIN ABEL TRANSFORM with STAT OPT 

INFO:  Writing output altitude scales with respect to EGM96 GEOID

(Different number of points retained by ropp_pp_cutoff_amplitude, because the input data are generated by gfz2ropp, which itself calls ropp_io_ranchk, ie the z's are already different (missing and zero resp) before ropp_pp_occ_tool gets to grips with them. This means in particular that the inferred occultation points are different: (-84.21E, -86.46N) and (-84.04E, 0.00N) resp, as well as the impact parameters. Hence different amplitude cutoffs.

Going in at ROPP6.1.

[Ian Culverwell]

Actually, the

DO i = 1, Lev1a%Npoints
      IF ( SUM(Lev1a%r_LEO(i,:)**2) < 0.01_wp*Lev1a%Range%r_LEO(mx)**2 ) &
           Lev1a%r_LEO(i,:) = ropp_MDFV
    END DO

business causes problems when, as for instance in COSMIC data, the valid range of r_leo is 1000 times too large(!). Obviously then |r| is not < 0.1*max, and we wrongly flag valid data as invalid. Although this is clearly a data issue, it's probably safer to just hardwire

    DO i = 1, Lev1a%Npoints
      IF ( SUM(Lev1a%r_GNS(i,:)**2) < 6.2e6_wp**2 ) & !6.2e6 = GeoRange%roc(mn)
           Lev1a%v_GNS(i,:) = ropp_MDFV
    END DO

+ sim for r_leo. And simply omit the min test for v_gns and v_leo, since they appear not be used anyway.

[Ian Culverwell]

Passes test folder. Closing ticket.