Opened 13 years ago

Closed 13 years ago

#238 closed defect (fixed)

incorrect use of ro_data%georef%time_offset -variable in wave-optics processing of GRAS data

Reported by: kmk Owned by: Ian Culverwell
Priority: normal Milestone: 5.1
Component: ropp_pp Version: 4.1
Keywords: Cc:

Description

In line 179 of ropp_pp_preprocess there is a call to ropp_pp_openloop which gets passed as a first argument the time given as:

ro_data%Lev1a%dtime+ro_data%georef%time_offset

The intention here is to pass dtime plus the time since the last full hour. It is important that the time be given as absolute since determination of internal navbits relies on knowing the exact times when new navbit frames kick in at the GPS satellite (i.e. when the navbit could potentially flip).

Accordingly the grasrs2ropp tool tries to write the time since the last full hour in the time_offset variable. This is in line 241:

ro_data%GEOref%time_offset = readreal

(and the lines just above where readreal is defined).

The problem is that this is not the intended use of the time_offset variable and its assigned variable range does not support this use.


I recommend as a fix the definition of a new variable to hold the time in seconds since the last full hour and with a variable range from 0s to 3600s.

This new variable should then be used instead of ro_data%georef%time_offset both in line 179 of ropp_pp_preprocess and in line 241 of the grasrs2ropp tool.

As an alternative fix: the time since last hour could just be calculated inside ropp_pp_preprocess right before the call to ropp_pp_openloop.

Another alternative: I am almost certain that the time since the last second is sufficient since new navbit frames kick in twice a second at the full second and the half second mark. This time is found in the variable ro_data%DTocc%Msec and so line 179 of ropp_pp_preprocess could be edited so that the first argument to ropp_pp_openloop is:

ro_data%Lev1a%dtime+ro_data%DTocc%Msec


As a side effect: Solving this problem will largely remove the impact of the problem described in ticket #226 since the times will almost never be negative (not true if the last solution above is implemented). Ticket #226 should still be solved as recommended in the comment to that ticket as it can still come into play.

Change history (3)

comment:1 by Ian Culverwell, 13 years ago

Owner: set to Ian Culverwell
Status: newassigned

comment:2 by Ian Culverwell, 13 years ago

Milestone: 6.05.1

I agree that defining a new variable would be best, but changing the GEOtype structure has a lot of "downstream" implications (updating I/O routines, documentation, updating reference files for IO tests, etc), so for this relatively small change I prefer Kjartan's second solution.

So, we define a new variable secs_past_hour in ropp_pp_preprocess.f90, which is calculated from known variables as

secs_past_hour = ro_data%DTocc%Minute*60 + ro_data%DTocc%Second + ro_data%DTocc%Msec*1.0e-3

This is then used in the call to ropp_pp_openloop:

CALL ropp_pp_openloop(ro_data%Lev1a%dtime+secs_past_hour &...

The incorrect setting of %time_offset has been removed from grasrs2ropp, so it remains at its default value of ropp_MDFV. This should uncover any incorrect usages.

Put in ROPP5.1 base code.

comment:3 by Ian Culverwell, 13 years ago

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.