Opened 6 years ago
Closed 5 years ago
#563 closed task (fixed)
Skipping mapping of lon to [0:360] [?]
Reported by: | Ian Culverwell | Owned by: | Ian Culverwell |
---|---|---|---|
Priority: | normal | Milestone: | ROPP9.1 carry over |
Component: | ropp_io | Version: | 9.0 |
Keywords: | Cc: |
Description
Change history (4)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
(Actually the line
grib1%georef%lon = mod(grib1%georef%lon+180.0_wp,360.0_wp) - 180.0_wp
, just before Sec 5.3.2, is not in the official ROPP development branch.)
comment:3 by , 5 years ago
Using the ATAN2 formula in the code doesn't affect the longitudes in the netCDF file, which are (usually) range-checked into [-180, 180] anyway, and therefore equal -3.53 deg in the core test. (Note, however, that #562 makes range-checking optional.) But the output namelist is changed from
LON = 356.470000000000 ,
to
LON = -3.53000000000000 ,
, so the reference file needs to be changed.
Changes committed at r6234.
comment:4 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
While we're here, replace the risky
gribfile_lun = 12
by the safer
gribfile_lun = Get_IO_Unit()
in grib2bgrasc.f90 at r6235.
Closing ticket.
Note:
See TracTickets
for help on using tickets.
As Stig says, in ROPP longitudes lie in the range [-180, 180] deg. Neither of the two longitude 'wrappings' in grib2bgrasc.f90 does the job, as this quick test shows:
Both formulas generate longitudes outside the range [-180, 180] deg. What we need is the last column, which is
ATAN2(SIN(lon),COS(lon))
, aka the principal value of the argument of ei lon.