Longitude coordinates for most satellites range from 0 to 360, in contrast to documentation

[borgstad]

When extracting all data from all satellites (3a,3b,c2,e1,e2,g1,gs ,j1,j2,j3,n1,pn,sa), without a region specified, the output coordinates in longitude should range from -180 to 180 according to the documentation. However, for all but sa and c2, the coordinates range from 0 to 360. The command we use for extracting the data is:

rads -S 3a -V time,lat,lon,adt,swh,swh_rms,wind_speed,range_numval -o /rads/output/

[borgstad]

Bump. I consider this issue critical, since processing the specified data with rads yields wrong coordinates. This also means historical data needs reprocessing.

[remkos]

As the documentation indicates, the output of rads2asc will by default have longitudes from -180 to 180. This is also the case, as I have just tested myself. E.g., the results of the following all have longitudes in that range.

rads2asc -S sa -V time,lat,lon --ymd=20190101,20190103 -o rads/
rads2asc -S c2 -V time,lat,lon --ymd=20190101,20190103 -o rads/
rads2asc -S 3a -V time,lat,lon --ymd=20190101,20190103 -o rads/
rads2asc -S j3 -V time,lat,lon --ymd=20190101,20190103 -o rads/

Tested with rads2asc4, version 4.3.6

[borgstad]

@remkos, could you try out the command I have provided? It does not work for rads

[remkos]

There is no command called rads.

[borgstad]

Sorry, I'm running the script through docker. The correct command should be rads2nc

[remkos]

If have just done this:

rads2nc -S 3a -V time,lat,lon,adt,swh,swh_rms,wind_speed,range_numval -o /rads/output/

The longitudes are in the range -180 to 180. An example is provided here:

$ ncdump /rads/output/3ap0770c002.nc | grep "lon ="
 lon = -76726002, -77122161, -77517713, -77912624, -78306861, -82204951, 

[milyra]

An example of what we've been doing is: rads2nc -S 3a --ymd 20191000,20191200 -V time,lat,lon,adt,swh -o /rads/milyra/3a-test.nc Which yields these values (read and assessed with R, in this case, but shows the same with Python):

> min(lon3a,na.rm=T)
[1] 0.000109
> max(lon3a,na.rm=T)
[1] 360

However, the same command for c2 gives:

> min(lonc2,na.rm=T)
[1] -179.9999
> max(lonc2,na.rm=T)
[1] 179.9999

[remkos]

Not on my side. What version of rads2nc are you running (rads2nc --version)?

The output message from rads2nc to the terminal will also include the following lines:

#                                           REJECTED  SELECTED       LOWER       UPPER         MIN         MAX        MEAN      STDDEV
# time [seconds since 1985-01-01 00:00:00       3655   3547829 190930/0000 191130/0000 190930/0000 191130/0000 191030/1222    1522113.
# latitude [degrees_north]                         0   3551484     -90.000      90.000     -78.695      81.428      -1.702      46.820
# longitude [degrees_east]                         0   3551484    -180.000     180.000    -180.000     180.000      -8.775     109.661

I suspect that you some configuration (rads.xml) file set up that has different limits depending on the mission. Or are you running in different directories with a rads.xml file that specifies different longitude limits? What is the output (as quoted above) telling you?

On a separate note: please note that --ymd 20191000,20191200 means from 2019/09/30 00:00:00 to 2019/11/30 00:00:00. I.e., day "00" is considered the day before "01", and a day starts at 00:00:00. You can see that also in the output above.

[milyra]

rads version is 4.3.4

These lines goes as follows for 3a:

# PASSES AND MEASUREMENTS READ                  1741   3551470
#
#                                           REJECTED  SELECTED       LOWER       UPPER         MIN         MAX        MEAN      STDDEV
# time [seconds since 1985-01-01 00:00:00       3655   3547815 190930/0000 191130/0000 190930/0000 191130/0000 191030/1222    1522112.
# latitude [degrees_north]                         0   3551470         NaN         NaN     -78.695      81.428      -1.702      46.820
# longitude [degrees_east]                         0   3551470         NaN         NaN       0.000     360.000     191.409      99.579

And for c2:

# PASSES AND MEASUREMENTS READ                  1830   3672935
#
#                                           REJECTED  SELECTED       LOWER       UPPER         MIN         MAX        MEAN      STDDEV
# time [seconds since 1985-01-01 00:00:00       2336   3670599 190930/0000 191130/0000 190930/0935 191129/2359 191030/1335    1513027.
# latitude [degrees_north]                         0   3672935         NaN         NaN     -87.983      80.010      -6.504      43.120
# longitude [degrees_east]                         0   3672935         NaN         NaN    -180.000     180.000       2.962     105.305

But you are right in your observation. We have been changing the limits, however, only in the sense that we've remove all limits from all parameters. I can imagine that the lack of limits means that the 360-degree shift of values above 180 is not included.

[remkos]

@milyra, you are right that the longitude boundaries determine the 360-degree shift. If you take the longitude limits away, longitudes will be output the same way as they are in the original data files, which can be a mix of -180/180 or 0/360, depending on the satellite. So if you really want to rid yourself of all the limits, then you still need to keep the longitude limits. You can set that to -180/180 or 0/360, whichever is most convenient for you. This, of course, is in the end still means that all data come through.

I suggest that this answers your problem and the issue can be closed. I'll check if any clarification in the documentation is warranted.

[milyra]

Thanks for the clarification and good with the clarification in the documentation.