Regarding conversion of OISST netcdf to grib file for MPAS

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

E

EMMANUEL

Member
I would like to request if anyone can suggest to me the conversion of NetCDF OISST (containing lsm+sst+sice) to grib file

I tried converting the grib file using CDO but its strange to see the values DATA(1,1) after ungribing with WPS

Kindly can you suggest on this

FIELD = SEAICE
UNITS = proprtn DESCRIPTION = Ice flag
DATE = 2010-01-01_00:00:00 FCST = 0.000000
SOURCE = unknown model and orig center
LEVEL = 200100.000000
I,J DIMS = 1440, 720
IPROJ = 0 PROJECTION = LAT LON
REF_X, REF_Y = 1.000000, 1.000000
REF_LAT, REF_LON = -89.875008, 0.125000
DLAT, DLON = 0.250000, 0.250000
EARTH_RADIUS = 6367.470215
DATA(1,1)=-1000000015047466219876688855040.000000

================================================
FIELD = SKINTEMP
UNITS = K DESCRIPTION = Skin temperature
DATE = 2010-01-01_00:00:00 FCST = 0.000000
SOURCE = unknown model and orig center
LEVEL = 200100.000000
I,J DIMS = 1440, 720
IPROJ = 0 PROJECTION = LAT LON
REF_X, REF_Y = 1.000000, 1.000000
REF_LAT, REF_LON = -89.875008, 0.125000
DLAT, DLON = 0.250000, 0.250000
EARTH_RADIUS = 6367.470215
DATA(1,1)=-1000000015047466219876688855040.000000
 
Since your intermediate files show
Code: 
REF_LAT, REF_LON = -89.875008, 0.125000
the (1,1) element borders the South Pole, which should be a land point (i.e., not a water point).

Is it possible that -1000000015047466219876688855040.000000 is being used as a missing value in your SEAICE and SKINTEMP fields?
 
mgduda said:
Since your intermediate files show
Code: 
REF_LAT, REF_LON = -89.875008, 0.125000
the (1,1) element borders the South Pole, which should be a land point (i.e., not a water point).

Is it possible that -1000000015047466219876688855040.000000 is being used as a missing value in your SEAICE and SKINTEMP fields?
Click to expand...

Yes, but how do I resolve this issue of large number. Is it ok to be used like this for the surface update file creation.
 
My guess is that the decimal number -1000000015047466219876688855040.000000 is the closest representable 32-bit floating-point number to -1e30, which is used as a missing value by the code that interpolates surface update fields. So in that sense there should be no problem.

Note that you'll also need to ensure that a LANDSEA mask field is included in your intermediate files, since the code that interpolates surface update fields first checks that a LANDSEA field is present.
 
mgduda said:
My guess is that the decimal number -1000000015047466219876688855040.000000 is the closest representable 32-bit floating-point number to -1e30, which is used as a missing value by the code that interpolates surface update fields. So in that sense there should be no problem.

Note that you'll also need to ensure that a LANDSEA mask field is included in your intermediate files, since the code that interpolates surface update fields first checks that a LANDSEA field is present.
Click to expand...

Thank you for the suggestion. Yes I ll try to add up landsea mask
 
You must log in or register to reply here.
Back
Top