[Met_help] [rt.rap.ucar.edu #81063] History for regrid_data_plane: not a valid data file
John Halley Gotway via RT
met_help at ucar.edu
Wed Sep 6 12:11:31 MDT 2017
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi,
I am trying to regrid one of my observation files in lat lon coordinate
grid to WRF curvilinear grid.
I ran bin/regrid_data_plane using a sample lat lon grid file and a file in
the WRF grid. But I got error as shown below:
yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/ND_grided_obs* $
~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/ND_grided_obs/sample_tmax.nc
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_maxminmean_1976.nc
/scratch/halstead/y/yoo108/ND_grided_obs/NDtoWRFgrid_sample_tmax.nc -field
'name="tmax";'
DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/ND_grided_obs/
sample_tmax.nc
ERROR : process_data_file() -> "/scratch/halstead/y/yoo108/ND_grided_obs/
sample_tmax.nc" not a valid data file
I wonder which part of the input file does not satisfy the MET's "valid
file" criteria.
ncdump output of the input file looks as below:
Input file was originally generated by VIC model and converted into cf
netcdf format.
Thank you in advance.
Regards,
Jinwoong
yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/ND_grided_obs* $ ncdump -h
sample_tmax.nc
netcdf sample_tmax {
dimensions:
T = 1 ;
X = 55 ;
Y = 65 ;
variables:
double T(T) ;
T:units = "days since 1915-01-01" ;
T:long_name = "Time" ;
double X(X) ;
X:units = "degrees_east" ;
X:long_name = "Longitude" ;
double Y(Y) ;
Y:units = "degrees_north" ;
Y:long_name = "Latitude" ;
double tmax(T, Y, X) ;
tmax:units = "degC" ;
tmax:long_name = "tmax calculated by VIC" ;
tmax:missing_value = -9999.f ;
// global attributes:
:production = "VIC output" ;
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Thu Jun 29 14:36:48 2017
Hi,
I got a similar result with a TRMM data.
Please see below:
yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $
~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/TRMM/
3B42RT_Daily.20051231.7.nc
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_maxminmean_1976.nc
/scratch/halstead/y/yoo108/TRMM/regrid_trmm_sample.nc -field
'name="precipitation";'
DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
3B42RT_Daily.20051231.7.nc
ERROR : process_data_file() -> "/scratch/halstead/y/yoo108/TRMM/
3B42RT_Daily.20051231.7.nc" not a valid data file
A part of ncdump output for the TRMM data is pasted below:
yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $ ncdump -h
subset_200003-200512/3B42RT_Daily.20051231.7.nc4.nc4
netcdf \3B42RT_Daily.20051231.7.nc4 {
dimensions:
lon = 59 ;
lat = 58 ;
variables:
short precipitation_cnt(lon, lat) ;
precipitation_cnt:units = "count" ;
precipitation_cnt:long_name = "Count of valid 3-hr precipitation
retrievals
for the day" ;
precipitation_cnt:coordinates = "lat lon" ;
precipitation_cnt:origname = "precipitation_cnt" ;
precipitation_cnt:fullnamepath = "/precipitation_cnt" ;
float uncal_precipitation(lon, lat) ;
uncal_precipitation:units = "mm" ;
uncal_precipitation:long_name = "Daily accumulated uncalibrated
precipitation" ;
uncal_precipitation:coordinates = "lat lon" ;
uncal_precipitation:_FillValue = -9999.9f ;
uncal_precipitation:origname = "uncal_precipitation" ;
uncal_precipitation:fullnamepath = "/uncal_precipitation" ;
short uncal_precipitation_cnt(lon, lat) ;
uncal_precipitation_cnt:units = "count" ;
uncal_precipitation_cnt:long_name = "Count of valid 3-hr uncal
precipitation retrievals for the day" ;
uncal_precipitation_cnt:coordinates = "lat lon" ;
uncal_precipitation_cnt:origname = "uncal_precipitation_cnt" ;
uncal_precipitation_cnt:fullnamepath = "/uncal_precipitation_cnt" ;
float precipitation(lon, lat) ;
precipitation:units = "mm" ;
precipitation:long_name = "Daily accumulated precipitation (combined
microwave-IR) estimate" ;
precipitation:coordinates = "lat lon" ;
precipitation:_FillValue = -9999.9f ;
precipitation:origname = "precipitation" ;
precipitation:fullnamepath = "/precipitation" ;
short randomError_cnt(lon, lat) ;
randomError_cnt:units = "count" ;
randomError_cnt:long_name = "Count of randomError for the day" ;
randomError_cnt:coordinates = "lat lon" ;
randomError_cnt:origname = "randomError_cnt" ;
randomError_cnt:fullnamepath = "/randomError_cnt" ;
float randomError(lon, lat) ;
randomError:units = "mm" ;
randomError:long_name = "Daily total error of combined microwave-IR
precipitation estimate" ;
randomError:_FillValue = -9999.9f ;
randomError:origname = "randomError" ;
randomError:fullnamepath = "/randomError" ;
float lat(lat) ;
lat:units = "degrees_north" ;
lat:long_name = "Latitude" ;
lat:origname = "lat" ;
lat:fullnamepath = "/lat" ;
float lon(lon) ;
lon:units = "degrees_east" ;
lon:long_name = "Longitude" ;
lon:origname = "lon" ;
lon:fullnamepath = "/lon" ;
Thank you.
Regards,
Jinwoong
On Thu, Jun 29, 2017 at 3:11 PM, met_help at ucar.edu via RT
<met_help at ucar.edu
> wrote:
> NOTE: THE MET TEAM HAS LIMITED AVAILABILITY BETWEEN 5/23/17 AND
5/30/17.
> RESPONSES MAY BE DELAYED.
>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "regrid_data_plane: not a valid data file",
> a summary of which appears below.
>
> There is no need to reply to this message right now. Your ticket
has been
> assigned an ID of [rt.rap.ucar.edu #81063].
>
> Please include the string:
>
> [rt.rap.ucar.edu #81063]
>
> in the subject line of all future correspondence about this issue.
To do
> so,
> you may reply to this message.
>
> Thank you,
> met_help at ucar.edu
>
>
-------------------------------------------------------------------------
> Hi,
>
> I am trying to regrid one of my observation files in lat lon
coordinate
> grid to WRF curvilinear grid.
>
> I ran bin/regrid_data_plane using a sample lat lon grid file and a
file in
> the WRF grid. But I got error as shown below:
>
> yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/ND_grided_obs* $
> ~/met-6.0_bugfix/bin/regrid_data_plane
> /scratch/halstead/y/yoo108/ND_grided_obs/sample_tmax.nc
>
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_maxminmean_1976.nc
> /scratch/halstead/y/yoo108/ND_grided_obs/NDtoWRFgrid_sample_tmax.nc
-field
> 'name="tmax";'
>
> DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/ND_grided_obs/
> sample_tmax.nc
>
> ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/ND_grided_obs/
> sample_tmax.nc" not a valid data file
>
> I wonder which part of the input file does not satisfy the MET's
"valid
> file" criteria.
> ncdump output of the input file looks as below:
> Input file was originally generated by VIC model and converted into
cf
> netcdf format.
>
>
> Thank you in advance.
> Regards,
>
> Jinwoong
>
>
>
>
> yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/ND_grided_obs* $
ncdump
> -h
> sample_tmax.nc
>
> netcdf sample_tmax {
>
> dimensions:
>
> T = 1 ;
>
> X = 55 ;
>
> Y = 65 ;
>
>
> variables:
>
> double T(T) ;
>
> T:units = "days since 1915-01-01" ;
>
> T:long_name = "Time" ;
>
>
> double X(X) ;
>
> X:units = "degrees_east" ;
>
> X:long_name = "Longitude" ;
>
>
> double Y(Y) ;
>
> Y:units = "degrees_north" ;
>
> Y:long_name = "Latitude" ;
>
>
> double tmax(T, Y, X) ;
>
> tmax:units = "degC" ;
>
> tmax:long_name = "tmax calculated by VIC" ;
>
> tmax:missing_value = -9999.f ;
>
> // global attributes:
>
> :production = "VIC output" ;
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Mon Jul 03 09:41:53 2017
Hi,
I noticed that TRMM data dimension was (lon, lat).
So I switched their order to (lat, lon) and ran the command again.
However, I got the same error message as below.
yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/TRMM/
trmm_daily.20051231.7.nc
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_maxminmean_1976.nc
/scratch/halstead/y/yoo108/TRMM/regrid_trmm_sample.nc -field
'name="precipitation";'
DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
trmm_daily.20051231.7.nc
ERROR :
ERROR : process_data_file() -> "/scratch/halstead/y/yoo108/TRMM/
trmm_daily.20051231.7.nc" not a valid data file
Thank you.
Regards,
Jinwoong
On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong Yoo <jinwoong.yoo at gmail.com>
wrote:
> Hi,
>
> I got a similar result with a TRMM data.
> Please see below:
>
> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $
> ~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/TRMM/
> 3B42RT_Daily.20051231.7.nc /scratch/halstead/y/yoo108/ND_
> grided_obs/daily_T2m_maxminmean_1976.nc
/scratch/halstead/y/yoo108/TRMM/
> regrid_trmm_sample.nc -field 'name="precipitation";'
>
> DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
> 3B42RT_Daily.20051231.7.nc
>
> ERROR : process_data_file() -> "/scratch/halstead/y/yoo108/TRMM/
> 3B42RT_Daily.20051231.7.nc" not a valid data file
>
>
> A part of ncdump output for the TRMM data is pasted below:
>
>
> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $ ncdump -h
> subset_200003-200512/3B42RT_Daily.20051231.7.nc4.nc4
>
> netcdf \3B42RT_Daily.20051231.7.nc4 {
>
> dimensions:
>
> lon = 59 ;
>
> lat = 58 ;
>
> variables:
>
> short precipitation_cnt(lon, lat) ;
>
> precipitation_cnt:units = "count" ;
>
> precipitation_cnt:long_name = "Count of valid 3-hr precipitation
> retrievals for the day" ;
>
> precipitation_cnt:coordinates = "lat lon" ;
>
> precipitation_cnt:origname = "precipitation_cnt" ;
>
> precipitation_cnt:fullnamepath = "/precipitation_cnt" ;
>
> float uncal_precipitation(lon, lat) ;
>
> uncal_precipitation:units = "mm" ;
>
> uncal_precipitation:long_name = "Daily accumulated uncalibrated
> precipitation" ;
>
> uncal_precipitation:coordinates = "lat lon" ;
>
> uncal_precipitation:_FillValue = -9999.9f ;
>
> uncal_precipitation:origname = "uncal_precipitation" ;
>
> uncal_precipitation:fullnamepath = "/uncal_precipitation" ;
>
> short uncal_precipitation_cnt(lon, lat) ;
>
> uncal_precipitation_cnt:units = "count" ;
>
> uncal_precipitation_cnt:long_name = "Count of valid 3-hr uncal
> precipitation retrievals for the day" ;
>
> uncal_precipitation_cnt:coordinates = "lat lon" ;
>
> uncal_precipitation_cnt:origname = "uncal_precipitation_cnt" ;
>
> uncal_precipitation_cnt:fullnamepath = "/uncal_precipitation_cnt" ;
>
> float precipitation(lon, lat) ;
>
> precipitation:units = "mm" ;
>
> precipitation:long_name = "Daily accumulated precipitation (combined
> microwave-IR) estimate" ;
>
> precipitation:coordinates = "lat lon" ;
>
> precipitation:_FillValue = -9999.9f ;
>
> precipitation:origname = "precipitation" ;
>
> precipitation:fullnamepath = "/precipitation" ;
>
> short randomError_cnt(lon, lat) ;
>
> randomError_cnt:units = "count" ;
>
> randomError_cnt:long_name = "Count of randomError for the day" ;
>
> randomError_cnt:coordinates = "lat lon" ;
>
> randomError_cnt:origname = "randomError_cnt" ;
>
> randomError_cnt:fullnamepath = "/randomError_cnt" ;
>
> float randomError(lon, lat) ;
>
> randomError:units = "mm" ;
>
> randomError:long_name = "Daily total error of combined microwave-IR
> precipitation estimate" ;
>
> randomError:_FillValue = -9999.9f ;
>
> randomError:origname = "randomError" ;
>
> randomError:fullnamepath = "/randomError" ;
>
> float lat(lat) ;
>
> lat:units = "degrees_north" ;
>
> lat:long_name = "Latitude" ;
>
> lat:origname = "lat" ;
>
> lat:fullnamepath = "/lat" ;
>
> float lon(lon) ;
>
> lon:units = "degrees_east" ;
>
> lon:long_name = "Longitude" ;
>
> lon:origname = "lon" ;
>
> lon:fullnamepath = "/lon" ;
>
>
>
>
> Thank you.
>
> Regards,
>
>
> Jinwoong
>
> On Thu, Jun 29, 2017 at 3:11 PM, met_help at ucar.edu via RT <
> met_help at ucar.edu> wrote:
>
>> NOTE: THE MET TEAM HAS LIMITED AVAILABILITY BETWEEN 5/23/17 AND
5/30/17.
>> RESPONSES MAY BE DELAYED.
>>
>> Greetings,
>>
>> This message has been automatically generated in response to the
>> creation of a trouble ticket regarding:
>> "regrid_data_plane: not a valid data file",
>> a summary of which appears below.
>>
>> There is no need to reply to this message right now. Your ticket
has been
>> assigned an ID of [rt.rap.ucar.edu #81063].
>>
>> Please include the string:
>>
>> [rt.rap.ucar.edu #81063]
>>
>> in the subject line of all future correspondence about this issue.
To do
>> so,
>> you may reply to this message.
>>
>> Thank you,
>> met_help at ucar.edu
>>
>>
-------------------------------------------------------------------------
>> Hi,
>>
>> I am trying to regrid one of my observation files in lat lon
coordinate
>> grid to WRF curvilinear grid.
>>
>> I ran bin/regrid_data_plane using a sample lat lon grid file and a
file in
>> the WRF grid. But I got error as shown below:
>>
>> yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/ND_grided_obs* $
>> ~/met-6.0_bugfix/bin/regrid_data_plane
>> /scratch/halstead/y/yoo108/ND_grided_obs/sample_tmax.nc
>>
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_maxminmean_1976.nc
>> /scratch/halstead/y/yoo108/ND_grided_obs/NDtoWRFgrid_sample_tmax.nc
>> -field
>> 'name="tmax";'
>>
>> DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/ND_grided_obs/
>> sample_tmax.nc
>>
>> ERROR : process_data_file() -> "/scratch/halstead/y/yoo108/ND
>> _grided_obs/
>> sample_tmax.nc" not a valid data file
>>
>> I wonder which part of the input file does not satisfy the MET's
"valid
>> file" criteria.
>> ncdump output of the input file looks as below:
>> Input file was originally generated by VIC model and converted into
cf
>> netcdf format.
>>
>>
>> Thank you in advance.
>> Regards,
>>
>> Jinwoong
>>
>>
>>
>>
>> yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/ND_grided_obs* $
ncdump
>> -h
>> sample_tmax.nc
>>
>> netcdf sample_tmax {
>>
>> dimensions:
>>
>> T = 1 ;
>>
>> X = 55 ;
>>
>> Y = 65 ;
>>
>>
>> variables:
>>
>> double T(T) ;
>>
>> T:units = "days since 1915-01-01" ;
>>
>> T:long_name = "Time" ;
>>
>>
>> double X(X) ;
>>
>> X:units = "degrees_east" ;
>>
>> X:long_name = "Longitude" ;
>>
>>
>> double Y(Y) ;
>>
>> Y:units = "degrees_north" ;
>>
>> Y:long_name = "Latitude" ;
>>
>>
>> double tmax(T, Y, X) ;
>>
>> tmax:units = "degC" ;
>>
>> tmax:long_name = "tmax calculated by VIC" ;
>>
>> tmax:missing_value = -9999.f ;
>>
>> // global attributes:
>>
>> :production = "VIC output" ;
>>
>>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Mon Jul 03 09:56:53 2017
Hi,
TRMM data comes in as netCDF-4 classic model.
I changed it to netCDF classic and run the same command for a test.
But I got the same error as below.
yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/TRMM/
trmm_daily_nc3.20051231.7.nc
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_maxminmean_1976.nc
/scratch/halstead/y/yoo108/TRMM/regrid_trmm_sample.nc -field
'name="precipitation";'
DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
trmm_daily_nc3.20051231.7.nc
ERROR :
ERROR : process_data_file() -> "/scratch/halstead/y/yoo108/TRMM/
trmm_daily_nc3.20051231.7.nc" not a valid data file
Thank you.
Regards,
Jinwoong
On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong Yoo <jinwoong.yoo at gmail.com>
wrote:
> Hi,
>
> I noticed that TRMM data dimension was (lon, lat).
> So I switched their order to (lat, lon) and ran the command again.
> However, I got the same error message as below.
>
> yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
> ~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/TRMM/
> trmm_daily.20051231.7.nc /scratch/halstead/y/yoo108/ND_
> grided_obs/daily_T2m_maxminmean_1976.nc
/scratch/halstead/y/yoo108/TRMM/
> regrid_trmm_sample.nc -field 'name="precipitation";'
>
> DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
> trmm_daily.20051231.7.nc
>
> ERROR :
>
> ERROR : process_data_file() -> "/scratch/halstead/y/yoo108/TRMM/
> trmm_daily.20051231.7.nc" not a valid data file
>
>
> Thank you.
>
> Regards,
>
>
> Jinwoong
>
>
>
> On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> wrote:
>
>> Hi,
>>
>> I got a similar result with a TRMM data.
>> Please see below:
>>
>> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $
>> ~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/TRMM/
>> 3B42RT_Daily.20051231.7.nc /scratch/halstead/y/yoo108/ND_
>> grided_obs/daily_T2m_maxminmean_1976.nc
/scratch/halstead/y/yoo108/TRMM/
>> regrid_trmm_sample.nc -field 'name="precipitation";'
>>
>> DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
>> 3B42RT_Daily.20051231.7.nc
>>
>> ERROR : process_data_file() -> "/scratch/halstead/y/yoo108/TRMM/
>> 3B42RT_Daily.20051231.7.nc" not a valid data file
>>
>>
>> A part of ncdump output for the TRMM data is pasted below:
>>
>>
>> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $ ncdump -h
>> subset_200003-200512/3B42RT_Daily.20051231.7.nc4.nc4
>>
>> netcdf \3B42RT_Daily.20051231.7.nc4 {
>>
>> dimensions:
>>
>> lon = 59 ;
>>
>> lat = 58 ;
>>
>> variables:
>>
>> short precipitation_cnt(lon, lat) ;
>>
>> precipitation_cnt:units = "count" ;
>>
>> precipitation_cnt:long_name = "Count of valid 3-hr precipitation
>> retrievals for the day" ;
>>
>> precipitation_cnt:coordinates = "lat lon" ;
>>
>> precipitation_cnt:origname = "precipitation_cnt" ;
>>
>> precipitation_cnt:fullnamepath = "/precipitation_cnt" ;
>>
>> float uncal_precipitation(lon, lat) ;
>>
>> uncal_precipitation:units = "mm" ;
>>
>> uncal_precipitation:long_name = "Daily accumulated uncalibrated
>> precipitation" ;
>>
>> uncal_precipitation:coordinates = "lat lon" ;
>>
>> uncal_precipitation:_FillValue = -9999.9f ;
>>
>> uncal_precipitation:origname = "uncal_precipitation" ;
>>
>> uncal_precipitation:fullnamepath = "/uncal_precipitation" ;
>>
>> short uncal_precipitation_cnt(lon, lat) ;
>>
>> uncal_precipitation_cnt:units = "count" ;
>>
>> uncal_precipitation_cnt:long_name = "Count of valid 3-hr uncal
>> precipitation retrievals for the day" ;
>>
>> uncal_precipitation_cnt:coordinates = "lat lon" ;
>>
>> uncal_precipitation_cnt:origname = "uncal_precipitation_cnt" ;
>>
>> uncal_precipitation_cnt:fullnamepath = "/uncal_precipitation_cnt" ;
>>
>> float precipitation(lon, lat) ;
>>
>> precipitation:units = "mm" ;
>>
>> precipitation:long_name = "Daily accumulated precipitation
(combined
>> microwave-IR) estimate" ;
>>
>> precipitation:coordinates = "lat lon" ;
>>
>> precipitation:_FillValue = -9999.9f ;
>>
>> precipitation:origname = "precipitation" ;
>>
>> precipitation:fullnamepath = "/precipitation" ;
>>
>> short randomError_cnt(lon, lat) ;
>>
>> randomError_cnt:units = "count" ;
>>
>> randomError_cnt:long_name = "Count of randomError for the day" ;
>>
>> randomError_cnt:coordinates = "lat lon" ;
>>
>> randomError_cnt:origname = "randomError_cnt" ;
>>
>> randomError_cnt:fullnamepath = "/randomError_cnt" ;
>>
>> float randomError(lon, lat) ;
>>
>> randomError:units = "mm" ;
>>
>> randomError:long_name = "Daily total error of combined microwave-IR
>> precipitation estimate" ;
>>
>> randomError:_FillValue = -9999.9f ;
>>
>> randomError:origname = "randomError" ;
>>
>> randomError:fullnamepath = "/randomError" ;
>>
>> float lat(lat) ;
>>
>> lat:units = "degrees_north" ;
>>
>> lat:long_name = "Latitude" ;
>>
>> lat:origname = "lat" ;
>>
>> lat:fullnamepath = "/lat" ;
>>
>> float lon(lon) ;
>>
>> lon:units = "degrees_east" ;
>>
>> lon:long_name = "Longitude" ;
>>
>> lon:origname = "lon" ;
>>
>> lon:fullnamepath = "/lon" ;
>>
>>
>>
>>
>> Thank you.
>>
>> Regards,
>>
>>
>> Jinwoong
>>
>> On Thu, Jun 29, 2017 at 3:11 PM, met_help at ucar.edu via RT <
>> met_help at ucar.edu> wrote:
>>
>>> NOTE: THE MET TEAM HAS LIMITED AVAILABILITY BETWEEN 5/23/17 AND
>>> 5/30/17. RESPONSES MAY BE DELAYED.
>>>
>>> Greetings,
>>>
>>> This message has been automatically generated in response to the
>>> creation of a trouble ticket regarding:
>>> "regrid_data_plane: not a valid data file",
>>> a summary of which appears below.
>>>
>>> There is no need to reply to this message right now. Your ticket
has
>>> been
>>> assigned an ID of [rt.rap.ucar.edu #81063].
>>>
>>> Please include the string:
>>>
>>> [rt.rap.ucar.edu #81063]
>>>
>>> in the subject line of all future correspondence about this issue.
To do
>>> so,
>>> you may reply to this message.
>>>
>>> Thank you,
>>> met_help at ucar.edu
>>>
>>> ------------------------------------------------------------
>>> -------------
>>> Hi,
>>>
>>> I am trying to regrid one of my observation files in lat lon
coordinate
>>> grid to WRF curvilinear grid.
>>>
>>> I ran bin/regrid_data_plane using a sample lat lon grid file and a
file
>>> in
>>> the WRF grid. But I got error as shown below:
>>>
>>> yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/ND_grided_obs* $
>>> ~/met-6.0_bugfix/bin/regrid_data_plane
>>> /scratch/halstead/y/yoo108/ND_grided_obs/sample_tmax.nc
>>>
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_maxminmean_1976.nc
>>>
/scratch/halstead/y/yoo108/ND_grided_obs/NDtoWRFgrid_sample_tmax.nc
>>> -field
>>> 'name="tmax";'
>>>
>>> DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/ND_grided_obs/
>>> sample_tmax.nc
>>>
>>> ERROR : process_data_file() -> "/scratch/halstead/y/yoo108/ND
>>> _grided_obs/
>>> sample_tmax.nc" not a valid data file
>>>
>>> I wonder which part of the input file does not satisfy the MET's
"valid
>>> file" criteria.
>>> ncdump output of the input file looks as below:
>>> Input file was originally generated by VIC model and converted
into cf
>>> netcdf format.
>>>
>>>
>>> Thank you in advance.
>>> Regards,
>>>
>>> Jinwoong
>>>
>>>
>>>
>>>
>>> yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/ND_grided_obs* $
>>> ncdump -h
>>> sample_tmax.nc
>>>
>>> netcdf sample_tmax {
>>>
>>> dimensions:
>>>
>>> T = 1 ;
>>>
>>> X = 55 ;
>>>
>>> Y = 65 ;
>>>
>>>
>>> variables:
>>>
>>> double T(T) ;
>>>
>>> T:units = "days since 1915-01-01" ;
>>>
>>> T:long_name = "Time" ;
>>>
>>>
>>> double X(X) ;
>>>
>>> X:units = "degrees_east" ;
>>>
>>> X:long_name = "Longitude" ;
>>>
>>>
>>> double Y(Y) ;
>>>
>>> Y:units = "degrees_north" ;
>>>
>>> Y:long_name = "Latitude" ;
>>>
>>>
>>> double tmax(T, Y, X) ;
>>>
>>> tmax:units = "degC" ;
>>>
>>> tmax:long_name = "tmax calculated by VIC" ;
>>>
>>> tmax:missing_value = -9999.f ;
>>>
>>> // global attributes:
>>>
>>> :production = "VIC output" ;
>>>
>>>
>>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: John Halley Gotway
Time: Mon Jul 03 10:46:16 2017
Jinwoong,
I see that you're having trouble reading a TRMM NetCDF file into MET.
Can
you please post the problematic file to our anonymous ftp site so I
can
take a look?
http://www.dtcenter.org/met/users/support/met_help.php#ftp
Thanks,
John Halley Gotway
On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>
> Hi,
>
> TRMM data comes in as netCDF-4 classic model.
> I changed it to netCDF classic and run the same command for a test.
> But I got the same error as below.
>
> yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
> ~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/TRMM/
> trmm_daily_nc3.20051231.7.nc
>
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_maxminmean_1976.nc
> /scratch/halstead/y/yoo108/TRMM/regrid_trmm_sample.nc -field
> 'name="precipitation";'
>
> DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
> trmm_daily_nc3.20051231.7.nc
>
> ERROR :
>
> ERROR : process_data_file() -> "/scratch/halstead/y/yoo108/TRMM/
> trmm_daily_nc3.20051231.7.nc" not a valid data file
>
> Thank you.
>
> Regards,
>
>
> Jinwoong
>
> On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> wrote:
>
> > Hi,
> >
> > I noticed that TRMM data dimension was (lon, lat).
> > So I switched their order to (lat, lon) and ran the command again.
> > However, I got the same error message as below.
> >
> > yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
> > ~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/TRMM/
> > trmm_daily.20051231.7.nc /scratch/halstead/y/yoo108/ND_
> > grided_obs/daily_T2m_maxminmean_1976.nc
/scratch/halstead/y/yoo108/TRMM/
> > regrid_trmm_sample.nc -field 'name="precipitation";'
> >
> > DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
> > trmm_daily.20051231.7.nc
> >
> > ERROR :
> >
> > ERROR : process_data_file() -> "/scratch/halstead/y/yoo108/TRMM/
> > trmm_daily.20051231.7.nc" not a valid data file
> >
> >
> > Thank you.
> >
> > Regards,
> >
> >
> > Jinwoong
> >
> >
> >
> > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> I got a similar result with a TRMM data.
> >> Please see below:
> >>
> >> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $
> >> ~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/TRMM/
> >> 3B42RT_Daily.20051231.7.nc /scratch/halstead/y/yoo108/ND_
> >> grided_obs/daily_T2m_maxminmean_1976.nc
/scratch/halstead/y/yoo108/
> TRMM/
> >> regrid_trmm_sample.nc -field 'name="precipitation";'
> >>
> >> DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
> >> 3B42RT_Daily.20051231.7.nc
> >>
> >> ERROR : process_data_file() -> "/scratch/halstead/y/yoo108/TRMM/
> >> 3B42RT_Daily.20051231.7.nc" not a valid data file
> >>
> >>
> >> A part of ncdump output for the TRMM data is pasted below:
> >>
> >>
> >> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $ ncdump
-h
> >> subset_200003-200512/3B42RT_Daily.20051231.7.nc4.nc4
> >>
> >> netcdf \3B42RT_Daily.20051231.7.nc4 {
> >>
> >> dimensions:
> >>
> >> lon = 59 ;
> >>
> >> lat = 58 ;
> >>
> >> variables:
> >>
> >> short precipitation_cnt(lon, lat) ;
> >>
> >> precipitation_cnt:units = "count" ;
> >>
> >> precipitation_cnt:long_name = "Count of valid 3-hr precipitation
> >> retrievals for the day" ;
> >>
> >> precipitation_cnt:coordinates = "lat lon" ;
> >>
> >> precipitation_cnt:origname = "precipitation_cnt" ;
> >>
> >> precipitation_cnt:fullnamepath = "/precipitation_cnt" ;
> >>
> >> float uncal_precipitation(lon, lat) ;
> >>
> >> uncal_precipitation:units = "mm" ;
> >>
> >> uncal_precipitation:long_name = "Daily accumulated uncalibrated
> >> precipitation" ;
> >>
> >> uncal_precipitation:coordinates = "lat lon" ;
> >>
> >> uncal_precipitation:_FillValue = -9999.9f ;
> >>
> >> uncal_precipitation:origname = "uncal_precipitation" ;
> >>
> >> uncal_precipitation:fullnamepath = "/uncal_precipitation" ;
> >>
> >> short uncal_precipitation_cnt(lon, lat) ;
> >>
> >> uncal_precipitation_cnt:units = "count" ;
> >>
> >> uncal_precipitation_cnt:long_name = "Count of valid 3-hr uncal
> >> precipitation retrievals for the day" ;
> >>
> >> uncal_precipitation_cnt:coordinates = "lat lon" ;
> >>
> >> uncal_precipitation_cnt:origname = "uncal_precipitation_cnt" ;
> >>
> >> uncal_precipitation_cnt:fullnamepath = "/uncal_precipitation_cnt"
;
> >>
> >> float precipitation(lon, lat) ;
> >>
> >> precipitation:units = "mm" ;
> >>
> >> precipitation:long_name = "Daily accumulated precipitation
(combined
> >> microwave-IR) estimate" ;
> >>
> >> precipitation:coordinates = "lat lon" ;
> >>
> >> precipitation:_FillValue = -9999.9f ;
> >>
> >> precipitation:origname = "precipitation" ;
> >>
> >> precipitation:fullnamepath = "/precipitation" ;
> >>
> >> short randomError_cnt(lon, lat) ;
> >>
> >> randomError_cnt:units = "count" ;
> >>
> >> randomError_cnt:long_name = "Count of randomError for the day" ;
> >>
> >> randomError_cnt:coordinates = "lat lon" ;
> >>
> >> randomError_cnt:origname = "randomError_cnt" ;
> >>
> >> randomError_cnt:fullnamepath = "/randomError_cnt" ;
> >>
> >> float randomError(lon, lat) ;
> >>
> >> randomError:units = "mm" ;
> >>
> >> randomError:long_name = "Daily total error of combined microwave-
IR
> >> precipitation estimate" ;
> >>
> >> randomError:_FillValue = -9999.9f ;
> >>
> >> randomError:origname = "randomError" ;
> >>
> >> randomError:fullnamepath = "/randomError" ;
> >>
> >> float lat(lat) ;
> >>
> >> lat:units = "degrees_north" ;
> >>
> >> lat:long_name = "Latitude" ;
> >>
> >> lat:origname = "lat" ;
> >>
> >> lat:fullnamepath = "/lat" ;
> >>
> >> float lon(lon) ;
> >>
> >> lon:units = "degrees_east" ;
> >>
> >> lon:long_name = "Longitude" ;
> >>
> >> lon:origname = "lon" ;
> >>
> >> lon:fullnamepath = "/lon" ;
> >>
> >>
> >>
> >>
> >> Thank you.
> >>
> >> Regards,
> >>
> >>
> >> Jinwoong
> >>
> >> On Thu, Jun 29, 2017 at 3:11 PM, met_help at ucar.edu via RT <
> >> met_help at ucar.edu> wrote:
> >>
> >>> NOTE: THE MET TEAM HAS LIMITED AVAILABILITY BETWEEN 5/23/17 AND
> >>> 5/30/17. RESPONSES MAY BE DELAYED.
> >>>
> >>> Greetings,
> >>>
> >>> This message has been automatically generated in response to the
> >>> creation of a trouble ticket regarding:
> >>> "regrid_data_plane: not a valid data file",
> >>> a summary of which appears below.
> >>>
> >>> There is no need to reply to this message right now. Your
ticket has
> >>> been
> >>> assigned an ID of [rt.rap.ucar.edu #81063].
> >>>
> >>> Please include the string:
> >>>
> >>> [rt.rap.ucar.edu #81063]
> >>>
> >>> in the subject line of all future correspondence about this
issue. To
> do
> >>> so,
> >>> you may reply to this message.
> >>>
> >>> Thank you,
> >>> met_help at ucar.edu
> >>>
> >>> ------------------------------------------------------------
> >>> -------------
> >>> Hi,
> >>>
> >>> I am trying to regrid one of my observation files in lat lon
coordinate
> >>> grid to WRF curvilinear grid.
> >>>
> >>> I ran bin/regrid_data_plane using a sample lat lon grid file and
a file
> >>> in
> >>> the WRF grid. But I got error as shown below:
> >>>
> >>> yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/ND_grided_obs*
$
> >>> ~/met-6.0_bugfix/bin/regrid_data_plane
> >>> /scratch/halstead/y/yoo108/ND_grided_obs/sample_tmax.nc
> >>>
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_maxminmean_1976.nc
> >>>
/scratch/halstead/y/yoo108/ND_grided_obs/NDtoWRFgrid_sample_tmax.nc
> >>> -field
> >>> 'name="tmax";'
> >>>
> >>> DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/ND_grided_obs/
> >>> sample_tmax.nc
> >>>
> >>> ERROR : process_data_file() -> "/scratch/halstead/y/yoo108/ND
> >>> _grided_obs/
> >>> sample_tmax.nc" not a valid data file
> >>>
> >>> I wonder which part of the input file does not satisfy the MET's
"valid
> >>> file" criteria.
> >>> ncdump output of the input file looks as below:
> >>> Input file was originally generated by VIC model and converted
into cf
> >>> netcdf format.
> >>>
> >>>
> >>> Thank you in advance.
> >>> Regards,
> >>>
> >>> Jinwoong
> >>>
> >>>
> >>>
> >>>
> >>> yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/ND_grided_obs*
$
> >>> ncdump -h
> >>> sample_tmax.nc
> >>>
> >>> netcdf sample_tmax {
> >>>
> >>> dimensions:
> >>>
> >>> T = 1 ;
> >>>
> >>> X = 55 ;
> >>>
> >>> Y = 65 ;
> >>>
> >>>
> >>> variables:
> >>>
> >>> double T(T) ;
> >>>
> >>> T:units = "days since 1915-01-01" ;
> >>>
> >>> T:long_name = "Time" ;
> >>>
> >>>
> >>> double X(X) ;
> >>>
> >>> X:units = "degrees_east" ;
> >>>
> >>> X:long_name = "Longitude" ;
> >>>
> >>>
> >>> double Y(Y) ;
> >>>
> >>> Y:units = "degrees_north" ;
> >>>
> >>> Y:long_name = "Latitude" ;
> >>>
> >>>
> >>> double tmax(T, Y, X) ;
> >>>
> >>> tmax:units = "degC" ;
> >>>
> >>> tmax:long_name = "tmax calculated by VIC" ;
> >>>
> >>> tmax:missing_value = -9999.f ;
> >>>
> >>> // global attributes:
> >>>
> >>> :production = "VIC output" ;
> >>>
> >>>
> >>
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Mon Jul 03 11:20:31 2017
Hi John,
Thank you for your reply.
I uploaded my data as in Yoo_data4.tar on the ftp site.
I included several files for the message of ID of [rt.rap.ucar.edu
#81074]
as well.
Thank you.
Regards,
Jinwoong
On Mon, Jul 3, 2017 at 12:46 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Jinwoong,
>
> I see that you're having trouble reading a TRMM NetCDF file into
MET. Can
> you please post the problematic file to our anonymous ftp site so I
can
> take a look?
>
> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>
> Thanks,
> John Halley Gotway
>
> On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >
> > Hi,
> >
> > TRMM data comes in as netCDF-4 classic model.
> > I changed it to netCDF classic and run the same command for a
test.
> > But I got the same error as below.
> >
> > yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
> > ~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/TRMM/
> > trmm_daily_nc3.20051231.7.nc
> >
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_maxminmean_1976.nc
> > /scratch/halstead/y/yoo108/TRMM/regrid_trmm_sample.nc -field
> > 'name="precipitation";'
> >
> > DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
> > trmm_daily_nc3.20051231.7.nc
> >
> > ERROR :
> >
> > ERROR : process_data_file() -> "/scratch/halstead/y/yoo108/TRMM/
> > trmm_daily_nc3.20051231.7.nc" not a valid data file
> >
> > Thank you.
> >
> > Regards,
> >
> >
> > Jinwoong
> >
> > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > I noticed that TRMM data dimension was (lon, lat).
> > > So I switched their order to (lat, lon) and ran the command
again.
> > > However, I got the same error message as below.
> > >
> > > yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
> > > ~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/
> TRMM/
> > > trmm_daily.20051231.7.nc /scratch/halstead/y/yoo108/ND_
> > > grided_obs/daily_T2m_maxminmean_1976.nc
/scratch/halstead/y/yoo108/
> TRMM/
> > > regrid_trmm_sample.nc -field 'name="precipitation";'
> > >
> > > DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
> > > trmm_daily.20051231.7.nc
> > >
> > > ERROR :
> > >
> > > ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TRMM/
> > > trmm_daily.20051231.7.nc" not a valid data file
> > >
> > >
> > > Thank you.
> > >
> > > Regards,
> > >
> > >
> > > Jinwoong
> > >
> > >
> > >
> > > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> I got a similar result with a TRMM data.
> > >> Please see below:
> > >>
> > >> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $
> > >> ~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/
> TRMM/
> > >> 3B42RT_Daily.20051231.7.nc /scratch/halstead/y/yoo108/ND_
> > >> grided_obs/daily_T2m_maxminmean_1976.nc
/scratch/halstead/y/yoo108/
> > TRMM/
> > >> regrid_trmm_sample.nc -field 'name="precipitation";'
> > >>
> > >> DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
> > >> 3B42RT_Daily.20051231.7.nc
> > >>
> > >> ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TRMM/
> > >> 3B42RT_Daily.20051231.7.nc" not a valid data file
> > >>
> > >>
> > >> A part of ncdump output for the TRMM data is pasted below:
> > >>
> > >>
> > >> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $ ncdump
-h
> > >> subset_200003-200512/3B42RT_Daily.20051231.7.nc4.nc4
> > >>
> > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
> > >>
> > >> dimensions:
> > >>
> > >> lon = 59 ;
> > >>
> > >> lat = 58 ;
> > >>
> > >> variables:
> > >>
> > >> short precipitation_cnt(lon, lat) ;
> > >>
> > >> precipitation_cnt:units = "count" ;
> > >>
> > >> precipitation_cnt:long_name = "Count of valid 3-hr
precipitation
> > >> retrievals for the day" ;
> > >>
> > >> precipitation_cnt:coordinates = "lat lon" ;
> > >>
> > >> precipitation_cnt:origname = "precipitation_cnt" ;
> > >>
> > >> precipitation_cnt:fullnamepath = "/precipitation_cnt" ;
> > >>
> > >> float uncal_precipitation(lon, lat) ;
> > >>
> > >> uncal_precipitation:units = "mm" ;
> > >>
> > >> uncal_precipitation:long_name = "Daily accumulated uncalibrated
> > >> precipitation" ;
> > >>
> > >> uncal_precipitation:coordinates = "lat lon" ;
> > >>
> > >> uncal_precipitation:_FillValue = -9999.9f ;
> > >>
> > >> uncal_precipitation:origname = "uncal_precipitation" ;
> > >>
> > >> uncal_precipitation:fullnamepath = "/uncal_precipitation" ;
> > >>
> > >> short uncal_precipitation_cnt(lon, lat) ;
> > >>
> > >> uncal_precipitation_cnt:units = "count" ;
> > >>
> > >> uncal_precipitation_cnt:long_name = "Count of valid 3-hr uncal
> > >> precipitation retrievals for the day" ;
> > >>
> > >> uncal_precipitation_cnt:coordinates = "lat lon" ;
> > >>
> > >> uncal_precipitation_cnt:origname = "uncal_precipitation_cnt" ;
> > >>
> > >> uncal_precipitation_cnt:fullnamepath =
"/uncal_precipitation_cnt" ;
> > >>
> > >> float precipitation(lon, lat) ;
> > >>
> > >> precipitation:units = "mm" ;
> > >>
> > >> precipitation:long_name = "Daily accumulated precipitation
(combined
> > >> microwave-IR) estimate" ;
> > >>
> > >> precipitation:coordinates = "lat lon" ;
> > >>
> > >> precipitation:_FillValue = -9999.9f ;
> > >>
> > >> precipitation:origname = "precipitation" ;
> > >>
> > >> precipitation:fullnamepath = "/precipitation" ;
> > >>
> > >> short randomError_cnt(lon, lat) ;
> > >>
> > >> randomError_cnt:units = "count" ;
> > >>
> > >> randomError_cnt:long_name = "Count of randomError for the day"
;
> > >>
> > >> randomError_cnt:coordinates = "lat lon" ;
> > >>
> > >> randomError_cnt:origname = "randomError_cnt" ;
> > >>
> > >> randomError_cnt:fullnamepath = "/randomError_cnt" ;
> > >>
> > >> float randomError(lon, lat) ;
> > >>
> > >> randomError:units = "mm" ;
> > >>
> > >> randomError:long_name = "Daily total error of combined
microwave-IR
> > >> precipitation estimate" ;
> > >>
> > >> randomError:_FillValue = -9999.9f ;
> > >>
> > >> randomError:origname = "randomError" ;
> > >>
> > >> randomError:fullnamepath = "/randomError" ;
> > >>
> > >> float lat(lat) ;
> > >>
> > >> lat:units = "degrees_north" ;
> > >>
> > >> lat:long_name = "Latitude" ;
> > >>
> > >> lat:origname = "lat" ;
> > >>
> > >> lat:fullnamepath = "/lat" ;
> > >>
> > >> float lon(lon) ;
> > >>
> > >> lon:units = "degrees_east" ;
> > >>
> > >> lon:long_name = "Longitude" ;
> > >>
> > >> lon:origname = "lon" ;
> > >>
> > >> lon:fullnamepath = "/lon" ;
> > >>
> > >>
> > >>
> > >>
> > >> Thank you.
> > >>
> > >> Regards,
> > >>
> > >>
> > >> Jinwoong
> > >>
> > >> On Thu, Jun 29, 2017 at 3:11 PM, met_help at ucar.edu via RT <
> > >> met_help at ucar.edu> wrote:
> > >>
> > >>> NOTE: THE MET TEAM HAS LIMITED AVAILABILITY BETWEEN 5/23/17
AND
> > >>> 5/30/17. RESPONSES MAY BE DELAYED.
> > >>>
> > >>> Greetings,
> > >>>
> > >>> This message has been automatically generated in response to
the
> > >>> creation of a trouble ticket regarding:
> > >>> "regrid_data_plane: not a valid data file",
> > >>> a summary of which appears below.
> > >>>
> > >>> There is no need to reply to this message right now. Your
ticket has
> > >>> been
> > >>> assigned an ID of [rt.rap.ucar.edu #81063].
> > >>>
> > >>> Please include the string:
> > >>>
> > >>> [rt.rap.ucar.edu #81063]
> > >>>
> > >>> in the subject line of all future correspondence about this
issue. To
> > do
> > >>> so,
> > >>> you may reply to this message.
> > >>>
> > >>> Thank you,
> > >>> met_help at ucar.edu
> > >>>
> > >>> ------------------------------------------------------------
> > >>> -------------
> > >>> Hi,
> > >>>
> > >>> I am trying to regrid one of my observation files in lat lon
> coordinate
> > >>> grid to WRF curvilinear grid.
> > >>>
> > >>> I ran bin/regrid_data_plane using a sample lat lon grid file
and a
> file
> > >>> in
> > >>> the WRF grid. But I got error as shown below:
> > >>>
> > >>> yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/ND_grided_obs* $
> > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
> > >>> /scratch/halstead/y/yoo108/ND_grided_obs/sample_tmax.nc
> > >>> /scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> maxminmean_1976.nc
> > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/NDtoWRFgrid_sample_tmax.nc
> > >>> -field
> > >>> 'name="tmax";'
> > >>>
> > >>> DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/ND_
> grided_obs/
> > >>> sample_tmax.nc
> > >>>
> > >>> ERROR : process_data_file() -> "/scratch/halstead/y/yoo108/ND
> > >>> _grided_obs/
> > >>> sample_tmax.nc" not a valid data file
> > >>>
> > >>> I wonder which part of the input file does not satisfy the
MET's
> "valid
> > >>> file" criteria.
> > >>> ncdump output of the input file looks as below:
> > >>> Input file was originally generated by VIC model and converted
into
> cf
> > >>> netcdf format.
> > >>>
> > >>>
> > >>> Thank you in advance.
> > >>> Regards,
> > >>>
> > >>> Jinwoong
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/ND_grided_obs* $
> > >>> ncdump -h
> > >>> sample_tmax.nc
> > >>>
> > >>> netcdf sample_tmax {
> > >>>
> > >>> dimensions:
> > >>>
> > >>> T = 1 ;
> > >>>
> > >>> X = 55 ;
> > >>>
> > >>> Y = 65 ;
> > >>>
> > >>>
> > >>> variables:
> > >>>
> > >>> double T(T) ;
> > >>>
> > >>> T:units = "days since 1915-01-01" ;
> > >>>
> > >>> T:long_name = "Time" ;
> > >>>
> > >>>
> > >>> double X(X) ;
> > >>>
> > >>> X:units = "degrees_east" ;
> > >>>
> > >>> X:long_name = "Longitude" ;
> > >>>
> > >>>
> > >>> double Y(Y) ;
> > >>>
> > >>> Y:units = "degrees_north" ;
> > >>>
> > >>> Y:long_name = "Latitude" ;
> > >>>
> > >>>
> > >>> double tmax(T, Y, X) ;
> > >>>
> > >>> tmax:units = "degC" ;
> > >>>
> > >>> tmax:long_name = "tmax calculated by VIC" ;
> > >>>
> > >>> tmax:missing_value = -9999.f ;
> > >>>
> > >>> // global attributes:
> > >>>
> > >>> :production = "VIC output" ;
> > >>>
> > >>>
> > >>
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: John Halley Gotway
Time: Thu Jul 06 08:41:44 2017
Jinwoong,
I'm out of the office today but will take a closer look tomorrow.
Thanks
John
On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>
> Hi John,
>
> Thank you for your reply.
> I uploaded my data as in Yoo_data4.tar on the ftp site.
> I included several files for the message of ID of [rt.rap.ucar.edu
#81074]
> as well.
> Thank you.
> Regards,
>
> Jinwoong
>
> On Mon, Jul 3, 2017 at 12:46 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Jinwoong,
> >
> > I see that you're having trouble reading a TRMM NetCDF file into
MET.
> Can
> > you please post the problematic file to our anonymous ftp site so
I can
> > take a look?
> >
> > http://www.dtcenter.org/met/users/support/met_help.php#ftp
> >
> > Thanks,
> > John Halley Gotway
> >
> > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > >
> > > Hi,
> > >
> > > TRMM data comes in as netCDF-4 classic model.
> > > I changed it to netCDF classic and run the same command for a
test.
> > > But I got the same error as below.
> > >
> > > yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
> > > ~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/TRMM/
> > > trmm_daily_nc3.20051231.7.nc
> > >
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_maxminmean_1976.nc
> > > /scratch/halstead/y/yoo108/TRMM/regrid_trmm_sample.nc -field
> > > 'name="precipitation";'
> > >
> > > DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
> > > trmm_daily_nc3.20051231.7.nc
> > >
> > > ERROR :
> > >
> > > ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TRMM/
> > > trmm_daily_nc3.20051231.7.nc" not a valid data file
> > >
> > > Thank you.
> > >
> > > Regards,
> > >
> > >
> > > Jinwoong
> > >
> > > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I noticed that TRMM data dimension was (lon, lat).
> > > > So I switched their order to (lat, lon) and ran the command
again.
> > > > However, I got the same error message as below.
> > > >
> > > > yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
> > > > ~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/
> > TRMM/
> > > > trmm_daily.20051231.7.nc /scratch/halstead/y/yoo108/ND_
> > > > grided_obs/daily_T2m_maxminmean_1976.nc
/scratch/halstead/y/yoo108/
> > TRMM/
> > > > regrid_trmm_sample.nc -field 'name="precipitation";'
> > > >
> > > > DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
> > > > trmm_daily.20051231.7.nc
> > > >
> > > > ERROR :
> > > >
> > > > ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TRMM/
> > > > trmm_daily.20051231.7.nc" not a valid data file
> > > >
> > > >
> > > > Thank you.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Jinwoong
> > > >
> > > >
> > > >
> > > > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong Yoo <
> jinwoong.yoo at gmail.com>
> > > > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> I got a similar result with a TRMM data.
> > > >> Please see below:
> > > >>
> > > >> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $
> > > >> ~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/
> > TRMM/
> > > >> 3B42RT_Daily.20051231.7.nc /scratch/halstead/y/yoo108/ND_
> > > >> grided_obs/daily_T2m_maxminmean_1976.nc
/scratch/halstead/y/yoo108/
> > > TRMM/
> > > >> regrid_trmm_sample.nc -field 'name="precipitation";'
> > > >>
> > > >> DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
> > > >> 3B42RT_Daily.20051231.7.nc
> > > >>
> > > >> ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TRMM/
> > > >> 3B42RT_Daily.20051231.7.nc" not a valid data file
> > > >>
> > > >>
> > > >> A part of ncdump output for the TRMM data is pasted below:
> > > >>
> > > >>
> > > >> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $
ncdump -h
> > > >> subset_200003-200512/3B42RT_Daily.20051231.7.nc4.nc4
> > > >>
> > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
> > > >>
> > > >> dimensions:
> > > >>
> > > >> lon = 59 ;
> > > >>
> > > >> lat = 58 ;
> > > >>
> > > >> variables:
> > > >>
> > > >> short precipitation_cnt(lon, lat) ;
> > > >>
> > > >> precipitation_cnt:units = "count" ;
> > > >>
> > > >> precipitation_cnt:long_name = "Count of valid 3-hr
precipitation
> > > >> retrievals for the day" ;
> > > >>
> > > >> precipitation_cnt:coordinates = "lat lon" ;
> > > >>
> > > >> precipitation_cnt:origname = "precipitation_cnt" ;
> > > >>
> > > >> precipitation_cnt:fullnamepath = "/precipitation_cnt" ;
> > > >>
> > > >> float uncal_precipitation(lon, lat) ;
> > > >>
> > > >> uncal_precipitation:units = "mm" ;
> > > >>
> > > >> uncal_precipitation:long_name = "Daily accumulated
uncalibrated
> > > >> precipitation" ;
> > > >>
> > > >> uncal_precipitation:coordinates = "lat lon" ;
> > > >>
> > > >> uncal_precipitation:_FillValue = -9999.9f ;
> > > >>
> > > >> uncal_precipitation:origname = "uncal_precipitation" ;
> > > >>
> > > >> uncal_precipitation:fullnamepath = "/uncal_precipitation" ;
> > > >>
> > > >> short uncal_precipitation_cnt(lon, lat) ;
> > > >>
> > > >> uncal_precipitation_cnt:units = "count" ;
> > > >>
> > > >> uncal_precipitation_cnt:long_name = "Count of valid 3-hr
uncal
> > > >> precipitation retrievals for the day" ;
> > > >>
> > > >> uncal_precipitation_cnt:coordinates = "lat lon" ;
> > > >>
> > > >> uncal_precipitation_cnt:origname = "uncal_precipitation_cnt"
;
> > > >>
> > > >> uncal_precipitation_cnt:fullnamepath =
"/uncal_precipitation_cnt" ;
> > > >>
> > > >> float precipitation(lon, lat) ;
> > > >>
> > > >> precipitation:units = "mm" ;
> > > >>
> > > >> precipitation:long_name = "Daily accumulated precipitation
(combined
> > > >> microwave-IR) estimate" ;
> > > >>
> > > >> precipitation:coordinates = "lat lon" ;
> > > >>
> > > >> precipitation:_FillValue = -9999.9f ;
> > > >>
> > > >> precipitation:origname = "precipitation" ;
> > > >>
> > > >> precipitation:fullnamepath = "/precipitation" ;
> > > >>
> > > >> short randomError_cnt(lon, lat) ;
> > > >>
> > > >> randomError_cnt:units = "count" ;
> > > >>
> > > >> randomError_cnt:long_name = "Count of randomError for the
day" ;
> > > >>
> > > >> randomError_cnt:coordinates = "lat lon" ;
> > > >>
> > > >> randomError_cnt:origname = "randomError_cnt" ;
> > > >>
> > > >> randomError_cnt:fullnamepath = "/randomError_cnt" ;
> > > >>
> > > >> float randomError(lon, lat) ;
> > > >>
> > > >> randomError:units = "mm" ;
> > > >>
> > > >> randomError:long_name = "Daily total error of combined
microwave-IR
> > > >> precipitation estimate" ;
> > > >>
> > > >> randomError:_FillValue = -9999.9f ;
> > > >>
> > > >> randomError:origname = "randomError" ;
> > > >>
> > > >> randomError:fullnamepath = "/randomError" ;
> > > >>
> > > >> float lat(lat) ;
> > > >>
> > > >> lat:units = "degrees_north" ;
> > > >>
> > > >> lat:long_name = "Latitude" ;
> > > >>
> > > >> lat:origname = "lat" ;
> > > >>
> > > >> lat:fullnamepath = "/lat" ;
> > > >>
> > > >> float lon(lon) ;
> > > >>
> > > >> lon:units = "degrees_east" ;
> > > >>
> > > >> lon:long_name = "Longitude" ;
> > > >>
> > > >> lon:origname = "lon" ;
> > > >>
> > > >> lon:fullnamepath = "/lon" ;
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> Thank you.
> > > >>
> > > >> Regards,
> > > >>
> > > >>
> > > >> Jinwoong
> > > >>
> > > >> On Thu, Jun 29, 2017 at 3:11 PM, met_help at ucar.edu via RT <
> > > >> met_help at ucar.edu> wrote:
> > > >>
> > > >>> NOTE: THE MET TEAM HAS LIMITED AVAILABILITY BETWEEN 5/23/17
AND
> > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
> > > >>>
> > > >>> Greetings,
> > > >>>
> > > >>> This message has been automatically generated in response to
the
> > > >>> creation of a trouble ticket regarding:
> > > >>> "regrid_data_plane: not a valid data file",
> > > >>> a summary of which appears below.
> > > >>>
> > > >>> There is no need to reply to this message right now. Your
ticket
> has
> > > >>> been
> > > >>> assigned an ID of [rt.rap.ucar.edu #81063].
> > > >>>
> > > >>> Please include the string:
> > > >>>
> > > >>> [rt.rap.ucar.edu #81063]
> > > >>>
> > > >>> in the subject line of all future correspondence about this
issue.
> To
> > > do
> > > >>> so,
> > > >>> you may reply to this message.
> > > >>>
> > > >>> Thank you,
> > > >>> met_help at ucar.edu
> > > >>>
> > > >>> ------------------------------------------------------------
> > > >>> -------------
> > > >>> Hi,
> > > >>>
> > > >>> I am trying to regrid one of my observation files in lat lon
> > coordinate
> > > >>> grid to WRF curvilinear grid.
> > > >>>
> > > >>> I ran bin/regrid_data_plane using a sample lat lon grid file
and a
> > file
> > > >>> in
> > > >>> the WRF grid. But I got error as shown below:
> > > >>>
> > > >>> yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/ND_grided_obs* $
> > > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
> > > >>> /scratch/halstead/y/yoo108/ND_grided_obs/sample_tmax.nc
> > > >>> /scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> > maxminmean_1976.nc
> > > >>> /scratch/halstead/y/yoo108/ND_grided_obs/NDtoWRFgrid_sample_
> tmax.nc
> > > >>> -field
> > > >>> 'name="tmax";'
> > > >>>
> > > >>> DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/ND_
> > grided_obs/
> > > >>> sample_tmax.nc
> > > >>>
> > > >>> ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/ND
> > > >>> _grided_obs/
> > > >>> sample_tmax.nc" not a valid data file
> > > >>>
> > > >>> I wonder which part of the input file does not satisfy the
MET's
> > "valid
> > > >>> file" criteria.
> > > >>> ncdump output of the input file looks as below:
> > > >>> Input file was originally generated by VIC model and
converted into
> > cf
> > > >>> netcdf format.
> > > >>>
> > > >>>
> > > >>> Thank you in advance.
> > > >>> Regards,
> > > >>>
> > > >>> Jinwoong
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/ND_grided_obs* $
> > > >>> ncdump -h
> > > >>> sample_tmax.nc
> > > >>>
> > > >>> netcdf sample_tmax {
> > > >>>
> > > >>> dimensions:
> > > >>>
> > > >>> T = 1 ;
> > > >>>
> > > >>> X = 55 ;
> > > >>>
> > > >>> Y = 65 ;
> > > >>>
> > > >>>
> > > >>> variables:
> > > >>>
> > > >>> double T(T) ;
> > > >>>
> > > >>> T:units = "days since 1915-01-01" ;
> > > >>>
> > > >>> T:long_name = "Time" ;
> > > >>>
> > > >>>
> > > >>> double X(X) ;
> > > >>>
> > > >>> X:units = "degrees_east" ;
> > > >>>
> > > >>> X:long_name = "Longitude" ;
> > > >>>
> > > >>>
> > > >>> double Y(Y) ;
> > > >>>
> > > >>> Y:units = "degrees_north" ;
> > > >>>
> > > >>> Y:long_name = "Latitude" ;
> > > >>>
> > > >>>
> > > >>> double tmax(T, Y, X) ;
> > > >>>
> > > >>> tmax:units = "degC" ;
> > > >>>
> > > >>> tmax:long_name = "tmax calculated by VIC" ;
> > > >>>
> > > >>> tmax:missing_value = -9999.f ;
> > > >>>
> > > >>> // global attributes:
> > > >>>
> > > >>> :production = "VIC output" ;
> > > >>>
> > > >>>
> > > >>
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Thu Jul 06 19:33:33 2017
Hi John,
Thank you very much.
Regards,
Jinwoong
On Thu, Jul 6, 2017 at 10:41 AM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Jinwoong,
>
> I'm out of the office today but will take a closer look tomorrow.
>
> Thanks
> John
>
> On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >
> > Hi John,
> >
> > Thank you for your reply.
> > I uploaded my data as in Yoo_data4.tar on the ftp site.
> > I included several files for the message of ID of [rt.rap.ucar.edu
> #81074]
> > as well.
> > Thank you.
> > Regards,
> >
> > Jinwoong
> >
> > On Mon, Jul 3, 2017 at 12:46 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Jinwoong,
> > >
> > > I see that you're having trouble reading a TRMM NetCDF file into
MET.
> > Can
> > > you please post the problematic file to our anonymous ftp site
so I can
> > > take a look?
> > >
> > > http://www.dtcenter.org/met/users/support/met_help.php#ftp
> > >
> > > Thanks,
> > > John Halley Gotway
> > >
> > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo via RT
<met_help at ucar.edu
> >
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
> > > >
> > > > Hi,
> > > >
> > > > TRMM data comes in as netCDF-4 classic model.
> > > > I changed it to netCDF classic and run the same command for a
test.
> > > > But I got the same error as below.
> > > >
> > > > yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
> > > > ~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/
> TRMM/
> > > > trmm_daily_nc3.20051231.7.nc
> > > > /scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> maxminmean_1976.nc
> > > > /scratch/halstead/y/yoo108/TRMM/regrid_trmm_sample.nc -field
> > > > 'name="precipitation";'
> > > >
> > > > DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
> > > > trmm_daily_nc3.20051231.7.nc
> > > >
> > > > ERROR :
> > > >
> > > > ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TRMM/
> > > > trmm_daily_nc3.20051231.7.nc" not a valid data file
> > > >
> > > > Thank you.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Jinwoong
> > > >
> > > > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong Yoo <
> jinwoong.yoo at gmail.com>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I noticed that TRMM data dimension was (lon, lat).
> > > > > So I switched their order to (lat, lon) and ran the command
again.
> > > > > However, I got the same error message as below.
> > > > >
> > > > > yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
> > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/
> > > TRMM/
> > > > > trmm_daily.20051231.7.nc /scratch/halstead/y/yoo108/ND_
> > > > > grided_obs/daily_T2m_maxminmean_1976.nc
> /scratch/halstead/y/yoo108/
> > > TRMM/
> > > > > regrid_trmm_sample.nc -field 'name="precipitation";'
> > > > >
> > > > > DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
> > > > > trmm_daily.20051231.7.nc
> > > > >
> > > > > ERROR :
> > > > >
> > > > > ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TRMM/
> > > > > trmm_daily.20051231.7.nc" not a valid data file
> > > > >
> > > > >
> > > > > Thank you.
> > > > >
> > > > > Regards,
> > > > >
> > > > >
> > > > > Jinwoong
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong Yoo <
> > jinwoong.yoo at gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> I got a similar result with a TRMM data.
> > > > >> Please see below:
> > > > >>
> > > > >> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $
> > > > >> ~/met-6.0_bugfix/bin/regrid_data_plane
> /scratch/halstead/y/yoo108/
> > > TRMM/
> > > > >> 3B42RT_Daily.20051231.7.nc /scratch/halstead/y/yoo108/ND_
> > > > >> grided_obs/daily_T2m_maxminmean_1976.nc
> /scratch/halstead/y/yoo108/
> > > > TRMM/
> > > > >> regrid_trmm_sample.nc -field 'name="precipitation";'
> > > > >>
> > > > >> DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/TRMM/
> > > > >> 3B42RT_Daily.20051231.7.nc
> > > > >>
> > > > >> ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TRMM/
> > > > >> 3B42RT_Daily.20051231.7.nc" not a valid data file
> > > > >>
> > > > >>
> > > > >> A part of ncdump output for the TRMM data is pasted below:
> > > > >>
> > > > >>
> > > > >> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $
ncdump
> -h
> > > > >> subset_200003-200512/3B42RT_Daily.20051231.7.nc4.nc4
> > > > >>
> > > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
> > > > >>
> > > > >> dimensions:
> > > > >>
> > > > >> lon = 59 ;
> > > > >>
> > > > >> lat = 58 ;
> > > > >>
> > > > >> variables:
> > > > >>
> > > > >> short precipitation_cnt(lon, lat) ;
> > > > >>
> > > > >> precipitation_cnt:units = "count" ;
> > > > >>
> > > > >> precipitation_cnt:long_name = "Count of valid 3-hr
precipitation
> > > > >> retrievals for the day" ;
> > > > >>
> > > > >> precipitation_cnt:coordinates = "lat lon" ;
> > > > >>
> > > > >> precipitation_cnt:origname = "precipitation_cnt" ;
> > > > >>
> > > > >> precipitation_cnt:fullnamepath = "/precipitation_cnt" ;
> > > > >>
> > > > >> float uncal_precipitation(lon, lat) ;
> > > > >>
> > > > >> uncal_precipitation:units = "mm" ;
> > > > >>
> > > > >> uncal_precipitation:long_name = "Daily accumulated
uncalibrated
> > > > >> precipitation" ;
> > > > >>
> > > > >> uncal_precipitation:coordinates = "lat lon" ;
> > > > >>
> > > > >> uncal_precipitation:_FillValue = -9999.9f ;
> > > > >>
> > > > >> uncal_precipitation:origname = "uncal_precipitation" ;
> > > > >>
> > > > >> uncal_precipitation:fullnamepath = "/uncal_precipitation" ;
> > > > >>
> > > > >> short uncal_precipitation_cnt(lon, lat) ;
> > > > >>
> > > > >> uncal_precipitation_cnt:units = "count" ;
> > > > >>
> > > > >> uncal_precipitation_cnt:long_name = "Count of valid 3-hr
uncal
> > > > >> precipitation retrievals for the day" ;
> > > > >>
> > > > >> uncal_precipitation_cnt:coordinates = "lat lon" ;
> > > > >>
> > > > >> uncal_precipitation_cnt:origname =
"uncal_precipitation_cnt" ;
> > > > >>
> > > > >> uncal_precipitation_cnt:fullnamepath =
> "/uncal_precipitation_cnt" ;
> > > > >>
> > > > >> float precipitation(lon, lat) ;
> > > > >>
> > > > >> precipitation:units = "mm" ;
> > > > >>
> > > > >> precipitation:long_name = "Daily accumulated precipitation
> (combined
> > > > >> microwave-IR) estimate" ;
> > > > >>
> > > > >> precipitation:coordinates = "lat lon" ;
> > > > >>
> > > > >> precipitation:_FillValue = -9999.9f ;
> > > > >>
> > > > >> precipitation:origname = "precipitation" ;
> > > > >>
> > > > >> precipitation:fullnamepath = "/precipitation" ;
> > > > >>
> > > > >> short randomError_cnt(lon, lat) ;
> > > > >>
> > > > >> randomError_cnt:units = "count" ;
> > > > >>
> > > > >> randomError_cnt:long_name = "Count of randomError for the
day" ;
> > > > >>
> > > > >> randomError_cnt:coordinates = "lat lon" ;
> > > > >>
> > > > >> randomError_cnt:origname = "randomError_cnt" ;
> > > > >>
> > > > >> randomError_cnt:fullnamepath = "/randomError_cnt" ;
> > > > >>
> > > > >> float randomError(lon, lat) ;
> > > > >>
> > > > >> randomError:units = "mm" ;
> > > > >>
> > > > >> randomError:long_name = "Daily total error of combined
> microwave-IR
> > > > >> precipitation estimate" ;
> > > > >>
> > > > >> randomError:_FillValue = -9999.9f ;
> > > > >>
> > > > >> randomError:origname = "randomError" ;
> > > > >>
> > > > >> randomError:fullnamepath = "/randomError" ;
> > > > >>
> > > > >> float lat(lat) ;
> > > > >>
> > > > >> lat:units = "degrees_north" ;
> > > > >>
> > > > >> lat:long_name = "Latitude" ;
> > > > >>
> > > > >> lat:origname = "lat" ;
> > > > >>
> > > > >> lat:fullnamepath = "/lat" ;
> > > > >>
> > > > >> float lon(lon) ;
> > > > >>
> > > > >> lon:units = "degrees_east" ;
> > > > >>
> > > > >> lon:long_name = "Longitude" ;
> > > > >>
> > > > >> lon:origname = "lon" ;
> > > > >>
> > > > >> lon:fullnamepath = "/lon" ;
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> Thank you.
> > > > >>
> > > > >> Regards,
> > > > >>
> > > > >>
> > > > >> Jinwoong
> > > > >>
> > > > >> On Thu, Jun 29, 2017 at 3:11 PM, met_help at ucar.edu via RT <
> > > > >> met_help at ucar.edu> wrote:
> > > > >>
> > > > >>> NOTE: THE MET TEAM HAS LIMITED AVAILABILITY BETWEEN
5/23/17 AND
> > > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
> > > > >>>
> > > > >>> Greetings,
> > > > >>>
> > > > >>> This message has been automatically generated in response
to the
> > > > >>> creation of a trouble ticket regarding:
> > > > >>> "regrid_data_plane: not a valid data file",
> > > > >>> a summary of which appears below.
> > > > >>>
> > > > >>> There is no need to reply to this message right now. Your
ticket
> > has
> > > > >>> been
> > > > >>> assigned an ID of [rt.rap.ucar.edu #81063].
> > > > >>>
> > > > >>> Please include the string:
> > > > >>>
> > > > >>> [rt.rap.ucar.edu #81063]
> > > > >>>
> > > > >>> in the subject line of all future correspondence about
this
> issue.
> > To
> > > > do
> > > > >>> so,
> > > > >>> you may reply to this message.
> > > > >>>
> > > > >>> Thank you,
> > > > >>> met_help at ucar.edu
> > > > >>>
> > > > >>>
------------------------------------------------------------
> > > > >>> -------------
> > > > >>> Hi,
> > > > >>>
> > > > >>> I am trying to regrid one of my observation files in lat
lon
> > > coordinate
> > > > >>> grid to WRF curvilinear grid.
> > > > >>>
> > > > >>> I ran bin/regrid_data_plane using a sample lat lon grid
file and
> a
> > > file
> > > > >>> in
> > > > >>> the WRF grid. But I got error as shown below:
> > > > >>>
> > > > >>> yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/ND_grided_obs*
> $
> > > > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
> > > > >>> /scratch/halstead/y/yoo108/ND_grided_obs/sample_tmax.nc
> > > > >>> /scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> > > maxminmean_1976.nc
> > > > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/NDtoWRFgrid_sample_
> > tmax.nc
> > > > >>> -field
> > > > >>> 'name="tmax";'
> > > > >>>
> > > > >>> DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/ND_
> > > grided_obs/
> > > > >>> sample_tmax.nc
> > > > >>>
> > > > >>> ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/ND
> > > > >>> _grided_obs/
> > > > >>> sample_tmax.nc" not a valid data file
> > > > >>>
> > > > >>> I wonder which part of the input file does not satisfy the
MET's
> > > "valid
> > > > >>> file" criteria.
> > > > >>> ncdump output of the input file looks as below:
> > > > >>> Input file was originally generated by VIC model and
converted
> into
> > > cf
> > > > >>> netcdf format.
> > > > >>>
> > > > >>>
> > > > >>> Thank you in advance.
> > > > >>> Regards,
> > > > >>>
> > > > >>> Jinwoong
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/ND_grided_obs*
> $
> > > > >>> ncdump -h
> > > > >>> sample_tmax.nc
> > > > >>>
> > > > >>> netcdf sample_tmax {
> > > > >>>
> > > > >>> dimensions:
> > > > >>>
> > > > >>> T = 1 ;
> > > > >>>
> > > > >>> X = 55 ;
> > > > >>>
> > > > >>> Y = 65 ;
> > > > >>>
> > > > >>>
> > > > >>> variables:
> > > > >>>
> > > > >>> double T(T) ;
> > > > >>>
> > > > >>> T:units = "days since 1915-01-01" ;
> > > > >>>
> > > > >>> T:long_name = "Time" ;
> > > > >>>
> > > > >>>
> > > > >>> double X(X) ;
> > > > >>>
> > > > >>> X:units = "degrees_east" ;
> > > > >>>
> > > > >>> X:long_name = "Longitude" ;
> > > > >>>
> > > > >>>
> > > > >>> double Y(Y) ;
> > > > >>>
> > > > >>> Y:units = "degrees_north" ;
> > > > >>>
> > > > >>> Y:long_name = "Latitude" ;
> > > > >>>
> > > > >>>
> > > > >>> double tmax(T, Y, X) ;
> > > > >>>
> > > > >>> tmax:units = "degC" ;
> > > > >>>
> > > > >>> tmax:long_name = "tmax calculated by VIC" ;
> > > > >>>
> > > > >>> tmax:missing_value = -9999.f ;
> > > > >>>
> > > > >>> // global attributes:
> > > > >>>
> > > > >>> :production = "VIC output" ;
> > > > >>>
> > > > >>>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: John Halley Gotway
Time: Fri Jul 07 11:16:37 2017
Jinwoong,
Thanks for sending your sample data and for your patience while I was
out
of town.
Using met-6.0, I'm able to process the TRMM NetCDF file you sent. The
trick is that I had to tell it which NetCDF file type should be used
to
interpret the data. Using "file_type = NETCDF_NCCF;" I'm telling MET
to
interpret it as if it were a CF-compliant NetCDF file:
met-6.0/bin/plot_data_plane \
trmm_daily.20051231.7.nc trmm_daily.20051231.7.ps \
'name="precipitation"; level="(*,*)"; file_type=NETCDF_NCCF;'
DEBUG 1: Opening data file: trmm_daily.20051231.7.nc
WARNING: NcCfFile::open() -> could not determine the valid time, using
0.
WARNING: NcCfFile::open() -> could not determine the valid time, using
0.
DEBUG 1: Creating postscript file: trmm_daily.20051231.7.ps
The plot_data_plane tool is able to read the data, and I've attached
the
resulting image. However, notice the warning messages about the valid
time.
Using ncdump to see that file attributes, I see this timing
information:
:HDF5_GLOBAL.BeginDate = "2005-12-31" ;
:HDF5_GLOBAL.BeginTime = "01:30:00.000Z" ;
:HDF5_GLOBAL.EndDate = "2006-01-01" ;
:HDF5_GLOBAL.EndTime = "01:29:59.999Z" ;
However that is not the CF-compliant way of specifying timing info.
So
while MET will be able to read the data, the timing info won't be
accurate
in the MET output files. Instead, you'll see "19700101" which is
unixtime
= 0.
Another option would be pulling the binary TRMM data and using this
Rscript
to convert the binary to NetCDF:
http://www.dtcenter.org/met/users/downloads/Rscripts/trmmbin2nc.R
However, I haven't done this in a while and am not sure if you'll run
into
any issues.
Hope that helps.
Thanks,
John
On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>
> Hi John,
>
> Thank you very much.
> Regards,
>
> Jinwoong
>
> On Thu, Jul 6, 2017 at 10:41 AM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Jinwoong,
> >
> > I'm out of the office today but will take a closer look tomorrow.
> >
> > Thanks
> > John
> >
> > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > >
> > > Hi John,
> > >
> > > Thank you for your reply.
> > > I uploaded my data as in Yoo_data4.tar on the ftp site.
> > > I included several files for the message of ID of
[rt.rap.ucar.edu
> > #81074]
> > > as well.
> > > Thank you.
> > > Regards,
> > >
> > > Jinwoong
> > >
> > > On Mon, Jul 3, 2017 at 12:46 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Jinwoong,
> > > >
> > > > I see that you're having trouble reading a TRMM NetCDF file
into MET.
> > > Can
> > > > you please post the problematic file to our anonymous ftp site
so I
> can
> > > > take a look?
> > > >
> > > > http://www.dtcenter.org/met/users/support/met_help.php#ftp
> > > >
> > > > Thanks,
> > > > John Halley Gotway
> > > >
> > > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo via RT <
> met_help at ucar.edu
> > >
> > > > wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > > > >
> > > > > Hi,
> > > > >
> > > > > TRMM data comes in as netCDF-4 classic model.
> > > > > I changed it to netCDF classic and run the same command for
a test.
> > > > > But I got the same error as below.
> > > > >
> > > > > yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
> > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
/scratch/halstead/y/yoo108/
> > TRMM/
> > > > > trmm_daily_nc3.20051231.7.nc
> > > > > /scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> > maxminmean_1976.nc
> > > > > /scratch/halstead/y/yoo108/TRMM/regrid_trmm_sample.nc -field
> > > > > 'name="precipitation";'
> > > > >
> > > > > DEBUG 1: Reading data file: /scratch/halstead/y/yoo108/TRMM/
> > > > > trmm_daily_nc3.20051231.7.nc
> > > > >
> > > > > ERROR :
> > > > >
> > > > > ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TRMM/
> > > > > trmm_daily_nc3.20051231.7.nc" not a valid data file
> > > > >
> > > > > Thank you.
> > > > >
> > > > > Regards,
> > > > >
> > > > >
> > > > > Jinwoong
> > > > >
> > > > > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong Yoo <
> > jinwoong.yoo at gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I noticed that TRMM data dimension was (lon, lat).
> > > > > > So I switched their order to (lat, lon) and ran the
command
> again.
> > > > > > However, I got the same error message as below.
> > > > > >
> > > > > > yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
> > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> /scratch/halstead/y/yoo108/
> > > > TRMM/
> > > > > > trmm_daily.20051231.7.nc /scratch/halstead/y/yoo108/ND_
> > > > > > grided_obs/daily_T2m_maxminmean_1976.nc
> > /scratch/halstead/y/yoo108/
> > > > TRMM/
> > > > > > regrid_trmm_sample.nc -field 'name="precipitation";'
> > > > > >
> > > > > > DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/TRMM/
> > > > > > trmm_daily.20051231.7.nc
> > > > > >
> > > > > > ERROR :
> > > > > >
> > > > > > ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TR
> MM/
> > > > > > trmm_daily.20051231.7.nc" not a valid data file
> > > > > >
> > > > > >
> > > > > > Thank you.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > >
> > > > > > Jinwoong
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong Yoo <
> > > jinwoong.yoo at gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >> Hi,
> > > > > >>
> > > > > >> I got a similar result with a TRMM data.
> > > > > >> Please see below:
> > > > > >>
> > > > > >> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $
> > > > > >> ~/met-6.0_bugfix/bin/regrid_data_plane
> > /scratch/halstead/y/yoo108/
> > > > TRMM/
> > > > > >> 3B42RT_Daily.20051231.7.nc /scratch/halstead/y/yoo108/ND_
> > > > > >> grided_obs/daily_T2m_maxminmean_1976.nc
> > /scratch/halstead/y/yoo108/
> > > > > TRMM/
> > > > > >> regrid_trmm_sample.nc -field 'name="precipitation";'
> > > > > >>
> > > > > >> DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/TRMM/
> > > > > >> 3B42RT_Daily.20051231.7.nc
> > > > > >>
> > > > > >> ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TR
> MM/
> > > > > >> 3B42RT_Daily.20051231.7.nc" not a valid data file
> > > > > >>
> > > > > >>
> > > > > >> A part of ncdump output for the TRMM data is pasted
below:
> > > > > >>
> > > > > >>
> > > > > >> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM* $
ncdump
> > -h
> > > > > >> subset_200003-200512/3B42RT_Daily.20051231.7.nc4.nc4
> > > > > >>
> > > > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
> > > > > >>
> > > > > >> dimensions:
> > > > > >>
> > > > > >> lon = 59 ;
> > > > > >>
> > > > > >> lat = 58 ;
> > > > > >>
> > > > > >> variables:
> > > > > >>
> > > > > >> short precipitation_cnt(lon, lat) ;
> > > > > >>
> > > > > >> precipitation_cnt:units = "count" ;
> > > > > >>
> > > > > >> precipitation_cnt:long_name = "Count of valid 3-hr
precipitation
> > > > > >> retrievals for the day" ;
> > > > > >>
> > > > > >> precipitation_cnt:coordinates = "lat lon" ;
> > > > > >>
> > > > > >> precipitation_cnt:origname = "precipitation_cnt" ;
> > > > > >>
> > > > > >> precipitation_cnt:fullnamepath = "/precipitation_cnt" ;
> > > > > >>
> > > > > >> float uncal_precipitation(lon, lat) ;
> > > > > >>
> > > > > >> uncal_precipitation:units = "mm" ;
> > > > > >>
> > > > > >> uncal_precipitation:long_name = "Daily accumulated
uncalibrated
> > > > > >> precipitation" ;
> > > > > >>
> > > > > >> uncal_precipitation:coordinates = "lat lon" ;
> > > > > >>
> > > > > >> uncal_precipitation:_FillValue = -9999.9f ;
> > > > > >>
> > > > > >> uncal_precipitation:origname = "uncal_precipitation" ;
> > > > > >>
> > > > > >> uncal_precipitation:fullnamepath = "/uncal_precipitation"
;
> > > > > >>
> > > > > >> short uncal_precipitation_cnt(lon, lat) ;
> > > > > >>
> > > > > >> uncal_precipitation_cnt:units = "count" ;
> > > > > >>
> > > > > >> uncal_precipitation_cnt:long_name = "Count of valid 3-hr
uncal
> > > > > >> precipitation retrievals for the day" ;
> > > > > >>
> > > > > >> uncal_precipitation_cnt:coordinates = "lat lon" ;
> > > > > >>
> > > > > >> uncal_precipitation_cnt:origname =
"uncal_precipitation_cnt" ;
> > > > > >>
> > > > > >> uncal_precipitation_cnt:fullnamepath =
> > "/uncal_precipitation_cnt" ;
> > > > > >>
> > > > > >> float precipitation(lon, lat) ;
> > > > > >>
> > > > > >> precipitation:units = "mm" ;
> > > > > >>
> > > > > >> precipitation:long_name = "Daily accumulated
precipitation
> > (combined
> > > > > >> microwave-IR) estimate" ;
> > > > > >>
> > > > > >> precipitation:coordinates = "lat lon" ;
> > > > > >>
> > > > > >> precipitation:_FillValue = -9999.9f ;
> > > > > >>
> > > > > >> precipitation:origname = "precipitation" ;
> > > > > >>
> > > > > >> precipitation:fullnamepath = "/precipitation" ;
> > > > > >>
> > > > > >> short randomError_cnt(lon, lat) ;
> > > > > >>
> > > > > >> randomError_cnt:units = "count" ;
> > > > > >>
> > > > > >> randomError_cnt:long_name = "Count of randomError for the
day" ;
> > > > > >>
> > > > > >> randomError_cnt:coordinates = "lat lon" ;
> > > > > >>
> > > > > >> randomError_cnt:origname = "randomError_cnt" ;
> > > > > >>
> > > > > >> randomError_cnt:fullnamepath = "/randomError_cnt" ;
> > > > > >>
> > > > > >> float randomError(lon, lat) ;
> > > > > >>
> > > > > >> randomError:units = "mm" ;
> > > > > >>
> > > > > >> randomError:long_name = "Daily total error of combined
> > microwave-IR
> > > > > >> precipitation estimate" ;
> > > > > >>
> > > > > >> randomError:_FillValue = -9999.9f ;
> > > > > >>
> > > > > >> randomError:origname = "randomError" ;
> > > > > >>
> > > > > >> randomError:fullnamepath = "/randomError" ;
> > > > > >>
> > > > > >> float lat(lat) ;
> > > > > >>
> > > > > >> lat:units = "degrees_north" ;
> > > > > >>
> > > > > >> lat:long_name = "Latitude" ;
> > > > > >>
> > > > > >> lat:origname = "lat" ;
> > > > > >>
> > > > > >> lat:fullnamepath = "/lat" ;
> > > > > >>
> > > > > >> float lon(lon) ;
> > > > > >>
> > > > > >> lon:units = "degrees_east" ;
> > > > > >>
> > > > > >> lon:long_name = "Longitude" ;
> > > > > >>
> > > > > >> lon:origname = "lon" ;
> > > > > >>
> > > > > >> lon:fullnamepath = "/lon" ;
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> Thank you.
> > > > > >>
> > > > > >> Regards,
> > > > > >>
> > > > > >>
> > > > > >> Jinwoong
> > > > > >>
> > > > > >> On Thu, Jun 29, 2017 at 3:11 PM, met_help at ucar.edu via RT
<
> > > > > >> met_help at ucar.edu> wrote:
> > > > > >>
> > > > > >>> NOTE: THE MET TEAM HAS LIMITED AVAILABILITY BETWEEN
5/23/17 AND
> > > > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
> > > > > >>>
> > > > > >>> Greetings,
> > > > > >>>
> > > > > >>> This message has been automatically generated in
response to
> the
> > > > > >>> creation of a trouble ticket regarding:
> > > > > >>> "regrid_data_plane: not a valid data file",
> > > > > >>> a summary of which appears below.
> > > > > >>>
> > > > > >>> There is no need to reply to this message right now.
Your
> ticket
> > > has
> > > > > >>> been
> > > > > >>> assigned an ID of [rt.rap.ucar.edu #81063].
> > > > > >>>
> > > > > >>> Please include the string:
> > > > > >>>
> > > > > >>> [rt.rap.ucar.edu #81063]
> > > > > >>>
> > > > > >>> in the subject line of all future correspondence about
this
> > issue.
> > > To
> > > > > do
> > > > > >>> so,
> > > > > >>> you may reply to this message.
> > > > > >>>
> > > > > >>> Thank you,
> > > > > >>> met_help at ucar.edu
> > > > > >>>
> > > > > >>>
------------------------------------------------------------
> > > > > >>> -------------
> > > > > >>> Hi,
> > > > > >>>
> > > > > >>> I am trying to regrid one of my observation files in lat
lon
> > > > coordinate
> > > > > >>> grid to WRF curvilinear grid.
> > > > > >>>
> > > > > >>> I ran bin/regrid_data_plane using a sample lat lon grid
file
> and
> > a
> > > > file
> > > > > >>> in
> > > > > >>> the WRF grid. But I got error as shown below:
> > > > > >>>
> > > > > >>> yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/ND_grided_
> obs*
> > $
> > > > > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
> > > > > >>> /scratch/halstead/y/yoo108/ND_grided_obs/sample_tmax.nc
> > > > > >>> /scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> > > > maxminmean_1976.nc
> > > > > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/NDtoWRFgrid_sample_
> > > tmax.nc
> > > > > >>> -field
> > > > > >>> 'name="tmax";'
> > > > > >>>
> > > > > >>> DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/ND_
> > > > grided_obs/
> > > > > >>> sample_tmax.nc
> > > > > >>>
> > > > > >>> ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/ND
> > > > > >>> _grided_obs/
> > > > > >>> sample_tmax.nc" not a valid data file
> > > > > >>>
> > > > > >>> I wonder which part of the input file does not satisfy
the
> MET's
> > > > "valid
> > > > > >>> file" criteria.
> > > > > >>> ncdump output of the input file looks as below:
> > > > > >>> Input file was originally generated by VIC model and
converted
> > into
> > > > cf
> > > > > >>> netcdf format.
> > > > > >>>
> > > > > >>>
> > > > > >>> Thank you in advance.
> > > > > >>> Regards,
> > > > > >>>
> > > > > >>> Jinwoong
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/ND_grided_
> obs*
> > $
> > > > > >>> ncdump -h
> > > > > >>> sample_tmax.nc
> > > > > >>>
> > > > > >>> netcdf sample_tmax {
> > > > > >>>
> > > > > >>> dimensions:
> > > > > >>>
> > > > > >>> T = 1 ;
> > > > > >>>
> > > > > >>> X = 55 ;
> > > > > >>>
> > > > > >>> Y = 65 ;
> > > > > >>>
> > > > > >>>
> > > > > >>> variables:
> > > > > >>>
> > > > > >>> double T(T) ;
> > > > > >>>
> > > > > >>> T:units = "days since 1915-01-01" ;
> > > > > >>>
> > > > > >>> T:long_name = "Time" ;
> > > > > >>>
> > > > > >>>
> > > > > >>> double X(X) ;
> > > > > >>>
> > > > > >>> X:units = "degrees_east" ;
> > > > > >>>
> > > > > >>> X:long_name = "Longitude" ;
> > > > > >>>
> > > > > >>>
> > > > > >>> double Y(Y) ;
> > > > > >>>
> > > > > >>> Y:units = "degrees_north" ;
> > > > > >>>
> > > > > >>> Y:long_name = "Latitude" ;
> > > > > >>>
> > > > > >>>
> > > > > >>> double tmax(T, Y, X) ;
> > > > > >>>
> > > > > >>> tmax:units = "degC" ;
> > > > > >>>
> > > > > >>> tmax:long_name = "tmax calculated by VIC" ;
> > > > > >>>
> > > > > >>> tmax:missing_value = -9999.f ;
> > > > > >>>
> > > > > >>> // global attributes:
> > > > > >>>
> > > > > >>> :production = "VIC output" ;
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Fri Jul 07 12:10:19 2017
Hi John,
Thank you very much for your time investing the issue.
I am glad to hear that there is a trick to work around the issue to
read in
TRMM data in netcdf format.
I wonder if I can apply the same trick ( file_type=NETCDF_NCCF;) to
read in
any other observation files in netcdf format?
In fact, I would like to read in "home brew" netcdf dataset files into
MET.
One sample file of them was included in the uploaded data folder (
sample_tmax.nc).
The data in this sample file was originally generated by VIC model.
Then the file format was converted into a generic netcdf file format
although the dimension names are T, X, Y not time, lat, lon.
But their coordinates have units in "degrees_east" or "degrees_north"
as
well as their long_name as "Longitude" and "Latitude", respectively.
Of course, I will try to read those in for Grid-stat today.
But I would like to hear from you if the trick (
file_type=NETCDF_NCCF;)
can be applied generally, which I wish very much.
Thank you so much, John.
Regards,
Jinwoong Yoo
On Fri, Jul 7, 2017 at 1:16 PM, John Halley Gotway via RT
<met_help at ucar.edu
> wrote:
> Jinwoong,
>
> Thanks for sending your sample data and for your patience while I
was out
> of town.
>
> Using met-6.0, I'm able to process the TRMM NetCDF file you sent.
The
> trick is that I had to tell it which NetCDF file type should be used
to
> interpret the data. Using "file_type = NETCDF_NCCF;" I'm telling
MET to
> interpret it as if it were a CF-compliant NetCDF file:
>
> met-6.0/bin/plot_data_plane \
> trmm_daily.20051231.7.nc trmm_daily.20051231.7.ps \
> 'name="precipitation"; level="(*,*)"; file_type=NETCDF_NCCF;'
>
> DEBUG 1: Opening data file: trmm_daily.20051231.7.nc
> WARNING: NcCfFile::open() -> could not determine the valid time,
using 0.
> WARNING: NcCfFile::open() -> could not determine the valid time,
using 0.
> DEBUG 1: Creating postscript file: trmm_daily.20051231.7.ps
>
> The plot_data_plane tool is able to read the data, and I've attached
the
> resulting image. However, notice the warning messages about the
valid
> time.
>
> Using ncdump to see that file attributes, I see this timing
information:
> :HDF5_GLOBAL.BeginDate = "2005-12-31" ;
> :HDF5_GLOBAL.BeginTime = "01:30:00.000Z" ;
> :HDF5_GLOBAL.EndDate = "2006-01-01" ;
> :HDF5_GLOBAL.EndTime = "01:29:59.999Z" ;
>
> However that is not the CF-compliant way of specifying timing info.
So
> while MET will be able to read the data, the timing info won't be
accurate
> in the MET output files. Instead, you'll see "19700101" which is
unixtime
> = 0.
>
> Another option would be pulling the binary TRMM data and using this
Rscript
> to convert the binary to NetCDF:
> http://www.dtcenter.org/met/users/downloads/Rscripts/trmmbin2nc.R
>
> However, I haven't done this in a while and am not sure if you'll
run into
> any issues.
>
> Hope that helps.
>
> Thanks,
> John
>
>
>
>
> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >
> > Hi John,
> >
> > Thank you very much.
> > Regards,
> >
> > Jinwoong
> >
> > On Thu, Jul 6, 2017 at 10:41 AM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Jinwoong,
> > >
> > > I'm out of the office today but will take a closer look
tomorrow.
> > >
> > > Thanks
> > > John
> > >
> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo via RT
<met_help at ucar.edu
> >
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
> > > >
> > > > Hi John,
> > > >
> > > > Thank you for your reply.
> > > > I uploaded my data as in Yoo_data4.tar on the ftp site.
> > > > I included several files for the message of ID of
[rt.rap.ucar.edu
> > > #81074]
> > > > as well.
> > > > Thank you.
> > > > Regards,
> > > >
> > > > Jinwoong
> > > >
> > > > On Mon, Jul 3, 2017 at 12:46 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > > Jinwoong,
> > > > >
> > > > > I see that you're having trouble reading a TRMM NetCDF file
into
> MET.
> > > > Can
> > > > > you please post the problematic file to our anonymous ftp
site so I
> > can
> > > > > take a look?
> > > > >
> > > > > http://www.dtcenter.org/met/users/support/met_help.php#ftp
> > > > >
> > > > > Thanks,
> > > > > John Halley Gotway
> > > > >
> > > > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo via RT <
> > met_help at ucar.edu
> > > >
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > TRMM data comes in as netCDF-4 classic model.
> > > > > > I changed it to netCDF classic and run the same command
for a
> test.
> > > > > > But I got the same error as below.
> > > > > >
> > > > > > yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
> > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> /scratch/halstead/y/yoo108/
> > > TRMM/
> > > > > > trmm_daily_nc3.20051231.7.nc
> > > > > > /scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> > > maxminmean_1976.nc
> > > > > > /scratch/halstead/y/yoo108/TRMM/regrid_trmm_sample.nc
-field
> > > > > > 'name="precipitation";'
> > > > > >
> > > > > > DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/TRMM/
> > > > > > trmm_daily_nc3.20051231.7.nc
> > > > > >
> > > > > > ERROR :
> > > > > >
> > > > > > ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/
> TRMM/
> > > > > > trmm_daily_nc3.20051231.7.nc" not a valid data file
> > > > > >
> > > > > > Thank you.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > >
> > > > > > Jinwoong
> > > > > >
> > > > > > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong Yoo <
> > > jinwoong.yoo at gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I noticed that TRMM data dimension was (lon, lat).
> > > > > > > So I switched their order to (lat, lon) and ran the
command
> > again.
> > > > > > > However, I got the same error message as below.
> > > > > > >
> > > > > > > yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
> > > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> > /scratch/halstead/y/yoo108/
> > > > > TRMM/
> > > > > > > trmm_daily.20051231.7.nc /scratch/halstead/y/yoo108/ND_
> > > > > > > grided_obs/daily_T2m_maxminmean_1976.nc
> > > /scratch/halstead/y/yoo108/
> > > > > TRMM/
> > > > > > > regrid_trmm_sample.nc -field 'name="precipitation";'
> > > > > > >
> > > > > > > DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/TRMM/
> > > > > > > trmm_daily.20051231.7.nc
> > > > > > >
> > > > > > > ERROR :
> > > > > > >
> > > > > > > ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TR
> > MM/
> > > > > > > trmm_daily.20051231.7.nc" not a valid data file
> > > > > > >
> > > > > > >
> > > > > > > Thank you.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > >
> > > > > > > Jinwoong
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong Yoo <
> > > > jinwoong.yoo at gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Hi,
> > > > > > >>
> > > > > > >> I got a similar result with a TRMM data.
> > > > > > >> Please see below:
> > > > > > >>
> > > > > > >> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM*
$
> > > > > > >> ~/met-6.0_bugfix/bin/regrid_data_plane
> > > /scratch/halstead/y/yoo108/
> > > > > TRMM/
> > > > > > >> 3B42RT_Daily.20051231.7.nc
/scratch/halstead/y/yoo108/ND_
> > > > > > >> grided_obs/daily_T2m_maxminmean_1976.nc
> > > /scratch/halstead/y/yoo108/
> > > > > > TRMM/
> > > > > > >> regrid_trmm_sample.nc -field 'name="precipitation";'
> > > > > > >>
> > > > > > >> DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/TRMM/
> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > > > > > >>
> > > > > > >> ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TR
> > MM/
> > > > > > >> 3B42RT_Daily.20051231.7.nc" not a valid data file
> > > > > > >>
> > > > > > >>
> > > > > > >> A part of ncdump output for the TRMM data is pasted
below:
> > > > > > >>
> > > > > > >>
> > > > > > >> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM*
$
> ncdump
> > > -h
> > > > > > >> subset_200003-200512/3B42RT_Daily.20051231.7.nc4.nc4
> > > > > > >>
> > > > > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
> > > > > > >>
> > > > > > >> dimensions:
> > > > > > >>
> > > > > > >> lon = 59 ;
> > > > > > >>
> > > > > > >> lat = 58 ;
> > > > > > >>
> > > > > > >> variables:
> > > > > > >>
> > > > > > >> short precipitation_cnt(lon, lat) ;
> > > > > > >>
> > > > > > >> precipitation_cnt:units = "count" ;
> > > > > > >>
> > > > > > >> precipitation_cnt:long_name = "Count of valid 3-hr
> precipitation
> > > > > > >> retrievals for the day" ;
> > > > > > >>
> > > > > > >> precipitation_cnt:coordinates = "lat lon" ;
> > > > > > >>
> > > > > > >> precipitation_cnt:origname = "precipitation_cnt" ;
> > > > > > >>
> > > > > > >> precipitation_cnt:fullnamepath = "/precipitation_cnt" ;
> > > > > > >>
> > > > > > >> float uncal_precipitation(lon, lat) ;
> > > > > > >>
> > > > > > >> uncal_precipitation:units = "mm" ;
> > > > > > >>
> > > > > > >> uncal_precipitation:long_name = "Daily accumulated
> uncalibrated
> > > > > > >> precipitation" ;
> > > > > > >>
> > > > > > >> uncal_precipitation:coordinates = "lat lon" ;
> > > > > > >>
> > > > > > >> uncal_precipitation:_FillValue = -9999.9f ;
> > > > > > >>
> > > > > > >> uncal_precipitation:origname = "uncal_precipitation" ;
> > > > > > >>
> > > > > > >> uncal_precipitation:fullnamepath =
"/uncal_precipitation" ;
> > > > > > >>
> > > > > > >> short uncal_precipitation_cnt(lon, lat) ;
> > > > > > >>
> > > > > > >> uncal_precipitation_cnt:units = "count" ;
> > > > > > >>
> > > > > > >> uncal_precipitation_cnt:long_name = "Count of valid 3-
hr
> uncal
> > > > > > >> precipitation retrievals for the day" ;
> > > > > > >>
> > > > > > >> uncal_precipitation_cnt:coordinates = "lat lon" ;
> > > > > > >>
> > > > > > >> uncal_precipitation_cnt:origname =
"uncal_precipitation_cnt"
> ;
> > > > > > >>
> > > > > > >> uncal_precipitation_cnt:fullnamepath =
> > > "/uncal_precipitation_cnt" ;
> > > > > > >>
> > > > > > >> float precipitation(lon, lat) ;
> > > > > > >>
> > > > > > >> precipitation:units = "mm" ;
> > > > > > >>
> > > > > > >> precipitation:long_name = "Daily accumulated
precipitation
> > > (combined
> > > > > > >> microwave-IR) estimate" ;
> > > > > > >>
> > > > > > >> precipitation:coordinates = "lat lon" ;
> > > > > > >>
> > > > > > >> precipitation:_FillValue = -9999.9f ;
> > > > > > >>
> > > > > > >> precipitation:origname = "precipitation" ;
> > > > > > >>
> > > > > > >> precipitation:fullnamepath = "/precipitation" ;
> > > > > > >>
> > > > > > >> short randomError_cnt(lon, lat) ;
> > > > > > >>
> > > > > > >> randomError_cnt:units = "count" ;
> > > > > > >>
> > > > > > >> randomError_cnt:long_name = "Count of randomError for
the
> day" ;
> > > > > > >>
> > > > > > >> randomError_cnt:coordinates = "lat lon" ;
> > > > > > >>
> > > > > > >> randomError_cnt:origname = "randomError_cnt" ;
> > > > > > >>
> > > > > > >> randomError_cnt:fullnamepath = "/randomError_cnt" ;
> > > > > > >>
> > > > > > >> float randomError(lon, lat) ;
> > > > > > >>
> > > > > > >> randomError:units = "mm" ;
> > > > > > >>
> > > > > > >> randomError:long_name = "Daily total error of combined
> > > microwave-IR
> > > > > > >> precipitation estimate" ;
> > > > > > >>
> > > > > > >> randomError:_FillValue = -9999.9f ;
> > > > > > >>
> > > > > > >> randomError:origname = "randomError" ;
> > > > > > >>
> > > > > > >> randomError:fullnamepath = "/randomError" ;
> > > > > > >>
> > > > > > >> float lat(lat) ;
> > > > > > >>
> > > > > > >> lat:units = "degrees_north" ;
> > > > > > >>
> > > > > > >> lat:long_name = "Latitude" ;
> > > > > > >>
> > > > > > >> lat:origname = "lat" ;
> > > > > > >>
> > > > > > >> lat:fullnamepath = "/lat" ;
> > > > > > >>
> > > > > > >> float lon(lon) ;
> > > > > > >>
> > > > > > >> lon:units = "degrees_east" ;
> > > > > > >>
> > > > > > >> lon:long_name = "Longitude" ;
> > > > > > >>
> > > > > > >> lon:origname = "lon" ;
> > > > > > >>
> > > > > > >> lon:fullnamepath = "/lon" ;
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> Thank you.
> > > > > > >>
> > > > > > >> Regards,
> > > > > > >>
> > > > > > >>
> > > > > > >> Jinwoong
> > > > > > >>
> > > > > > >> On Thu, Jun 29, 2017 at 3:11 PM, met_help at ucar.edu via
RT <
> > > > > > >> met_help at ucar.edu> wrote:
> > > > > > >>
> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED AVAILABILITY BETWEEN
5/23/17
> AND
> > > > > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
> > > > > > >>>
> > > > > > >>> Greetings,
> > > > > > >>>
> > > > > > >>> This message has been automatically generated in
response to
> > the
> > > > > > >>> creation of a trouble ticket regarding:
> > > > > > >>> "regrid_data_plane: not a valid data file",
> > > > > > >>> a summary of which appears below.
> > > > > > >>>
> > > > > > >>> There is no need to reply to this message right now.
Your
> > ticket
> > > > has
> > > > > > >>> been
> > > > > > >>> assigned an ID of [rt.rap.ucar.edu #81063].
> > > > > > >>>
> > > > > > >>> Please include the string:
> > > > > > >>>
> > > > > > >>> [rt.rap.ucar.edu #81063]
> > > > > > >>>
> > > > > > >>> in the subject line of all future correspondence about
this
> > > issue.
> > > > To
> > > > > > do
> > > > > > >>> so,
> > > > > > >>> you may reply to this message.
> > > > > > >>>
> > > > > > >>> Thank you,
> > > > > > >>> met_help at ucar.edu
> > > > > > >>>
> > > > > > >>>
------------------------------------------------------------
> > > > > > >>> -------------
> > > > > > >>> Hi,
> > > > > > >>>
> > > > > > >>> I am trying to regrid one of my observation files in
lat lon
> > > > > coordinate
> > > > > > >>> grid to WRF curvilinear grid.
> > > > > > >>>
> > > > > > >>> I ran bin/regrid_data_plane using a sample lat lon
grid file
> > and
> > > a
> > > > > file
> > > > > > >>> in
> > > > > > >>> the WRF grid. But I got error as shown below:
> > > > > > >>>
> > > > > > >>> yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/ND_grided_
> > obs*
> > > $
> > > > > > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
> > > > > > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/sample_tmax.nc
> > > > > > >>> /scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> > > > > maxminmean_1976.nc
> > > > > > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/NDtoWRFgrid_sample_
> > > > tmax.nc
> > > > > > >>> -field
> > > > > > >>> 'name="tmax";'
> > > > > > >>>
> > > > > > >>> DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/ND_
> > > > > grided_obs/
> > > > > > >>> sample_tmax.nc
> > > > > > >>>
> > > > > > >>> ERROR : process_data_file() ->
> "/scratch/halstead/y/yoo108/ND
> > > > > > >>> _grided_obs/
> > > > > > >>> sample_tmax.nc" not a valid data file
> > > > > > >>>
> > > > > > >>> I wonder which part of the input file does not satisfy
the
> > MET's
> > > > > "valid
> > > > > > >>> file" criteria.
> > > > > > >>> ncdump output of the input file looks as below:
> > > > > > >>> Input file was originally generated by VIC model and
> converted
> > > into
> > > > > cf
> > > > > > >>> netcdf format.
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> Thank you in advance.
> > > > > > >>> Regards,
> > > > > > >>>
> > > > > > >>> Jinwoong
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/ND_grided_
> > obs*
> > > $
> > > > > > >>> ncdump -h
> > > > > > >>> sample_tmax.nc
> > > > > > >>>
> > > > > > >>> netcdf sample_tmax {
> > > > > > >>>
> > > > > > >>> dimensions:
> > > > > > >>>
> > > > > > >>> T = 1 ;
> > > > > > >>>
> > > > > > >>> X = 55 ;
> > > > > > >>>
> > > > > > >>> Y = 65 ;
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> variables:
> > > > > > >>>
> > > > > > >>> double T(T) ;
> > > > > > >>>
> > > > > > >>> T:units = "days since 1915-01-01" ;
> > > > > > >>>
> > > > > > >>> T:long_name = "Time" ;
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> double X(X) ;
> > > > > > >>>
> > > > > > >>> X:units = "degrees_east" ;
> > > > > > >>>
> > > > > > >>> X:long_name = "Longitude" ;
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> double Y(Y) ;
> > > > > > >>>
> > > > > > >>> Y:units = "degrees_north" ;
> > > > > > >>>
> > > > > > >>> Y:long_name = "Latitude" ;
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> double tmax(T, Y, X) ;
> > > > > > >>>
> > > > > > >>> tmax:units = "degC" ;
> > > > > > >>>
> > > > > > >>> tmax:long_name = "tmax calculated by VIC" ;
> > > > > > >>>
> > > > > > >>> tmax:missing_value = -9999.f ;
> > > > > > >>>
> > > > > > >>> // global attributes:
> > > > > > >>>
> > > > > > >>> :production = "VIC output" ;
> > > > > > >>>
> > > > > > >>>
> > > > > > >>
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Fri Jul 07 12:11:23 2017
investigating not investing :)
Thanks!
Regards,
Jinwoong
On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo <jinwoong.yoo at gmail.com>
wrote:
> Hi John,
>
> Thank you very much for your time investing the issue.
> I am glad to hear that there is a trick to work around the issue to
read
> in TRMM data in netcdf format.
> I wonder if I can apply the same trick ( file_type=NETCDF_NCCF;) to
read
> in any other observation files in netcdf format?
> In fact, I would like to read in "home brew" netcdf dataset files
into
> MET.
> One sample file of them was included in the uploaded data folder (
> sample_tmax.nc).
> The data in this sample file was originally generated by VIC model.
> Then the file format was converted into a generic netcdf file format
> although the dimension names are T, X, Y not time, lat, lon.
> But their coordinates have units in "degrees_east" or
"degrees_north" as
> well as their long_name as "Longitude" and "Latitude", respectively.
>
> Of course, I will try to read those in for Grid-stat today.
> But I would like to hear from you if the trick (
file_type=NETCDF_NCCF;)
> can be applied generally, which I wish very much.
>
> Thank you so much, John.
>
> Regards,
>
> Jinwoong Yoo
>
>
> On Fri, Jul 7, 2017 at 1:16 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Jinwoong,
>>
>> Thanks for sending your sample data and for your patience while I
was out
>> of town.
>>
>> Using met-6.0, I'm able to process the TRMM NetCDF file you sent.
The
>> trick is that I had to tell it which NetCDF file type should be
used to
>> interpret the data. Using "file_type = NETCDF_NCCF;" I'm telling
MET to
>> interpret it as if it were a CF-compliant NetCDF file:
>>
>> met-6.0/bin/plot_data_plane \
>> trmm_daily.20051231.7.nc trmm_daily.20051231.7.ps \
>> 'name="precipitation"; level="(*,*)"; file_type=NETCDF_NCCF;'
>>
>> DEBUG 1: Opening data file: trmm_daily.20051231.7.nc
>> WARNING: NcCfFile::open() -> could not determine the valid time,
using 0.
>> WARNING: NcCfFile::open() -> could not determine the valid time,
using 0.
>> DEBUG 1: Creating postscript file: trmm_daily.20051231.7.ps
>>
>> The plot_data_plane tool is able to read the data, and I've
attached the
>> resulting image. However, notice the warning messages about the
valid
>> time.
>>
>> Using ncdump to see that file attributes, I see this timing
information:
>> :HDF5_GLOBAL.BeginDate = "2005-12-31" ;
>> :HDF5_GLOBAL.BeginTime = "01:30:00.000Z" ;
>> :HDF5_GLOBAL.EndDate = "2006-01-01" ;
>> :HDF5_GLOBAL.EndTime = "01:29:59.999Z" ;
>>
>> However that is not the CF-compliant way of specifying timing info.
So
>> while MET will be able to read the data, the timing info won't be
accurate
>> in the MET output files. Instead, you'll see "19700101" which is
unixtime
>> = 0.
>>
>> Another option would be pulling the binary TRMM data and using this
>> Rscript
>> to convert the binary to NetCDF:
>>
http://www.dtcenter.org/met/users/downloads/Rscripts/trmmbin2nc.R
>>
>> However, I haven't done this in a while and am not sure if you'll
run into
>> any issues.
>>
>> Hope that helps.
>>
>> Thanks,
>> John
>>
>>
>>
>>
>> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
>> wrote:
>>
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>> >
>> > Hi John,
>> >
>> > Thank you very much.
>> > Regards,
>> >
>> > Jinwoong
>> >
>> > On Thu, Jul 6, 2017 at 10:41 AM, John Halley Gotway via RT <
>> > met_help at ucar.edu> wrote:
>> >
>> > > Jinwoong,
>> > >
>> > > I'm out of the office today but will take a closer look
tomorrow.
>> > >
>> > > Thanks
>> > > John
>> > >
>> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo via RT <
>> met_help at ucar.edu>
>> > > wrote:
>> > >
>> > > >
>> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
>> > > >
>> > > > Hi John,
>> > > >
>> > > > Thank you for your reply.
>> > > > I uploaded my data as in Yoo_data4.tar on the ftp site.
>> > > > I included several files for the message of ID of
[rt.rap.ucar.edu
>> > > #81074]
>> > > > as well.
>> > > > Thank you.
>> > > > Regards,
>> > > >
>> > > > Jinwoong
>> > > >
>> > > > On Mon, Jul 3, 2017 at 12:46 PM, John Halley Gotway via RT <
>> > > > met_help at ucar.edu> wrote:
>> > > >
>> > > > > Jinwoong,
>> > > > >
>> > > > > I see that you're having trouble reading a TRMM NetCDF file
into
>> MET.
>> > > > Can
>> > > > > you please post the problematic file to our anonymous ftp
site so
>> I
>> > can
>> > > > > take a look?
>> > > > >
>> > > > > http://www.dtcenter.org/met/users/support/met_help.php#ftp
>> > > > >
>> > > > > Thanks,
>> > > > > John Halley Gotway
>> > > > >
>> > > > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo via RT <
>> > met_help at ucar.edu
>> > > >
>> > > > > wrote:
>> > > > >
>> > > > > >
>> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>> > > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > > TRMM data comes in as netCDF-4 classic model.
>> > > > > > I changed it to netCDF classic and run the same command
for a
>> test.
>> > > > > > But I got the same error as below.
>> > > > > >
>> > > > > > yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM* $
>> > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
>> /scratch/halstead/y/yoo108/
>> > > TRMM/
>> > > > > > trmm_daily_nc3.20051231.7.nc
>> > > > > > /scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
>> > > maxminmean_1976.nc
>> > > > > > /scratch/halstead/y/yoo108/TRMM/regrid_trmm_sample.nc
-field
>> > > > > > 'name="precipitation";'
>> > > > > >
>> > > > > > DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/TRMM/
>> > > > > > trmm_daily_nc3.20051231.7.nc
>> > > > > >
>> > > > > > ERROR :
>> > > > > >
>> > > > > > ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TR
>> MM/
>> > > > > > trmm_daily_nc3.20051231.7.nc" not a valid data file
>> > > > > >
>> > > > > > Thank you.
>> > > > > >
>> > > > > > Regards,
>> > > > > >
>> > > > > >
>> > > > > > Jinwoong
>> > > > > >
>> > > > > > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong Yoo <
>> > > jinwoong.yoo at gmail.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > I noticed that TRMM data dimension was (lon, lat).
>> > > > > > > So I switched their order to (lat, lon) and ran the
command
>> > again.
>> > > > > > > However, I got the same error message as below.
>> > > > > > >
>> > > > > > > yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM*
$
>> > > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
>> > /scratch/halstead/y/yoo108/
>> > > > > TRMM/
>> > > > > > > trmm_daily.20051231.7.nc /scratch/halstead/y/yoo108/ND_
>> > > > > > > grided_obs/daily_T2m_maxminmean_1976.nc
>> > > /scratch/halstead/y/yoo108/
>> > > > > TRMM/
>> > > > > > > regrid_trmm_sample.nc -field 'name="precipitation";'
>> > > > > > >
>> > > > > > > DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/TRMM/
>> > > > > > > trmm_daily.20051231.7.nc
>> > > > > > >
>> > > > > > > ERROR :
>> > > > > > >
>> > > > > > > ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TR
>> > MM/
>> > > > > > > trmm_daily.20051231.7.nc" not a valid data file
>> > > > > > >
>> > > > > > >
>> > > > > > > Thank you.
>> > > > > > >
>> > > > > > > Regards,
>> > > > > > >
>> > > > > > >
>> > > > > > > Jinwoong
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong Yoo <
>> > > > jinwoong.yoo at gmail.com>
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > >> Hi,
>> > > > > > >>
>> > > > > > >> I got a similar result with a TRMM data.
>> > > > > > >> Please see below:
>> > > > > > >>
>> > > > > > >> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM*
$
>> > > > > > >> ~/met-6.0_bugfix/bin/regrid_data_plane
>> > > /scratch/halstead/y/yoo108/
>> > > > > TRMM/
>> > > > > > >> 3B42RT_Daily.20051231.7.nc
/scratch/halstead/y/yoo108/ND_
>> > > > > > >> grided_obs/daily_T2m_maxminmean_1976.nc
>> > > /scratch/halstead/y/yoo108/
>> > > > > > TRMM/
>> > > > > > >> regrid_trmm_sample.nc -field 'name="precipitation";'
>> > > > > > >>
>> > > > > > >> DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/TRMM/
>> > > > > > >> 3B42RT_Daily.20051231.7.nc
>> > > > > > >>
>> > > > > > >> ERROR : process_data_file() ->
>> "/scratch/halstead/y/yoo108/TR
>> > MM/
>> > > > > > >> 3B42RT_Daily.20051231.7.nc" not a valid data file
>> > > > > > >>
>> > > > > > >>
>> > > > > > >> A part of ncdump output for the TRMM data is pasted
below:
>> > > > > > >>
>> > > > > > >>
>> > > > > > >> yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/TRMM*
$
>> ncdump
>> > > -h
>> > > > > > >> subset_200003-200512/3B42RT_Daily.20051231.7.nc4.nc4
>> > > > > > >>
>> > > > > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
>> > > > > > >>
>> > > > > > >> dimensions:
>> > > > > > >>
>> > > > > > >> lon = 59 ;
>> > > > > > >>
>> > > > > > >> lat = 58 ;
>> > > > > > >>
>> > > > > > >> variables:
>> > > > > > >>
>> > > > > > >> short precipitation_cnt(lon, lat) ;
>> > > > > > >>
>> > > > > > >> precipitation_cnt:units = "count" ;
>> > > > > > >>
>> > > > > > >> precipitation_cnt:long_name = "Count of valid 3-hr
>> precipitation
>> > > > > > >> retrievals for the day" ;
>> > > > > > >>
>> > > > > > >> precipitation_cnt:coordinates = "lat lon" ;
>> > > > > > >>
>> > > > > > >> precipitation_cnt:origname = "precipitation_cnt" ;
>> > > > > > >>
>> > > > > > >> precipitation_cnt:fullnamepath = "/precipitation_cnt"
;
>> > > > > > >>
>> > > > > > >> float uncal_precipitation(lon, lat) ;
>> > > > > > >>
>> > > > > > >> uncal_precipitation:units = "mm" ;
>> > > > > > >>
>> > > > > > >> uncal_precipitation:long_name = "Daily accumulated
>> uncalibrated
>> > > > > > >> precipitation" ;
>> > > > > > >>
>> > > > > > >> uncal_precipitation:coordinates = "lat lon" ;
>> > > > > > >>
>> > > > > > >> uncal_precipitation:_FillValue = -9999.9f ;
>> > > > > > >>
>> > > > > > >> uncal_precipitation:origname = "uncal_precipitation" ;
>> > > > > > >>
>> > > > > > >> uncal_precipitation:fullnamepath =
"/uncal_precipitation" ;
>> > > > > > >>
>> > > > > > >> short uncal_precipitation_cnt(lon, lat) ;
>> > > > > > >>
>> > > > > > >> uncal_precipitation_cnt:units = "count" ;
>> > > > > > >>
>> > > > > > >> uncal_precipitation_cnt:long_name = "Count of valid 3-
hr
>> uncal
>> > > > > > >> precipitation retrievals for the day" ;
>> > > > > > >>
>> > > > > > >> uncal_precipitation_cnt:coordinates = "lat lon" ;
>> > > > > > >>
>> > > > > > >> uncal_precipitation_cnt:origname =
>> "uncal_precipitation_cnt" ;
>> > > > > > >>
>> > > > > > >> uncal_precipitation_cnt:fullnamepath =
>> > > "/uncal_precipitation_cnt" ;
>> > > > > > >>
>> > > > > > >> float precipitation(lon, lat) ;
>> > > > > > >>
>> > > > > > >> precipitation:units = "mm" ;
>> > > > > > >>
>> > > > > > >> precipitation:long_name = "Daily accumulated
precipitation
>> > > (combined
>> > > > > > >> microwave-IR) estimate" ;
>> > > > > > >>
>> > > > > > >> precipitation:coordinates = "lat lon" ;
>> > > > > > >>
>> > > > > > >> precipitation:_FillValue = -9999.9f ;
>> > > > > > >>
>> > > > > > >> precipitation:origname = "precipitation" ;
>> > > > > > >>
>> > > > > > >> precipitation:fullnamepath = "/precipitation" ;
>> > > > > > >>
>> > > > > > >> short randomError_cnt(lon, lat) ;
>> > > > > > >>
>> > > > > > >> randomError_cnt:units = "count" ;
>> > > > > > >>
>> > > > > > >> randomError_cnt:long_name = "Count of randomError for
the
>> day" ;
>> > > > > > >>
>> > > > > > >> randomError_cnt:coordinates = "lat lon" ;
>> > > > > > >>
>> > > > > > >> randomError_cnt:origname = "randomError_cnt" ;
>> > > > > > >>
>> > > > > > >> randomError_cnt:fullnamepath = "/randomError_cnt" ;
>> > > > > > >>
>> > > > > > >> float randomError(lon, lat) ;
>> > > > > > >>
>> > > > > > >> randomError:units = "mm" ;
>> > > > > > >>
>> > > > > > >> randomError:long_name = "Daily total error of combined
>> > > microwave-IR
>> > > > > > >> precipitation estimate" ;
>> > > > > > >>
>> > > > > > >> randomError:_FillValue = -9999.9f ;
>> > > > > > >>
>> > > > > > >> randomError:origname = "randomError" ;
>> > > > > > >>
>> > > > > > >> randomError:fullnamepath = "/randomError" ;
>> > > > > > >>
>> > > > > > >> float lat(lat) ;
>> > > > > > >>
>> > > > > > >> lat:units = "degrees_north" ;
>> > > > > > >>
>> > > > > > >> lat:long_name = "Latitude" ;
>> > > > > > >>
>> > > > > > >> lat:origname = "lat" ;
>> > > > > > >>
>> > > > > > >> lat:fullnamepath = "/lat" ;
>> > > > > > >>
>> > > > > > >> float lon(lon) ;
>> > > > > > >>
>> > > > > > >> lon:units = "degrees_east" ;
>> > > > > > >>
>> > > > > > >> lon:long_name = "Longitude" ;
>> > > > > > >>
>> > > > > > >> lon:origname = "lon" ;
>> > > > > > >>
>> > > > > > >> lon:fullnamepath = "/lon" ;
>> > > > > > >>
>> > > > > > >>
>> > > > > > >>
>> > > > > > >>
>> > > > > > >> Thank you.
>> > > > > > >>
>> > > > > > >> Regards,
>> > > > > > >>
>> > > > > > >>
>> > > > > > >> Jinwoong
>> > > > > > >>
>> > > > > > >> On Thu, Jun 29, 2017 at 3:11 PM, met_help at ucar.edu via
RT <
>> > > > > > >> met_help at ucar.edu> wrote:
>> > > > > > >>
>> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED AVAILABILITY BETWEEN
5/23/17
>> AND
>> > > > > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
>> > > > > > >>>
>> > > > > > >>> Greetings,
>> > > > > > >>>
>> > > > > > >>> This message has been automatically generated in
response to
>> > the
>> > > > > > >>> creation of a trouble ticket regarding:
>> > > > > > >>> "regrid_data_plane: not a valid data file",
>> > > > > > >>> a summary of which appears below.
>> > > > > > >>>
>> > > > > > >>> There is no need to reply to this message right now.
Your
>> > ticket
>> > > > has
>> > > > > > >>> been
>> > > > > > >>> assigned an ID of [rt.rap.ucar.edu #81063].
>> > > > > > >>>
>> > > > > > >>> Please include the string:
>> > > > > > >>>
>> > > > > > >>> [rt.rap.ucar.edu #81063]
>> > > > > > >>>
>> > > > > > >>> in the subject line of all future correspondence
about this
>> > > issue.
>> > > > To
>> > > > > > do
>> > > > > > >>> so,
>> > > > > > >>> you may reply to this message.
>> > > > > > >>>
>> > > > > > >>> Thank you,
>> > > > > > >>> met_help at ucar.edu
>> > > > > > >>>
>> > > > > > >>> ------------------------------
>> ------------------------------
>> > > > > > >>> -------------
>> > > > > > >>> Hi,
>> > > > > > >>>
>> > > > > > >>> I am trying to regrid one of my observation files in
lat lon
>> > > > > coordinate
>> > > > > > >>> grid to WRF curvilinear grid.
>> > > > > > >>>
>> > > > > > >>> I ran bin/regrid_data_plane using a sample lat lon
grid file
>> > and
>> > > a
>> > > > > file
>> > > > > > >>> in
>> > > > > > >>> the WRF grid. But I got error as shown below:
>> > > > > > >>>
>> > > > > > >>> yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/ND_grided_
>> > obs*
>> > > $
>> > > > > > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
>> > > > > > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/sample_tmax.nc
>> > > > > > >>> /scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
>> > > > > maxminmean_1976.nc
>> > > > > > >>> /scratch/halstead/y/yoo108/ND_
>> grided_obs/NDtoWRFgrid_sample_
>> > > > tmax.nc
>> > > > > > >>> -field
>> > > > > > >>> 'name="tmax";'
>> > > > > > >>>
>> > > > > > >>> DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/ND_
>> > > > > grided_obs/
>> > > > > > >>> sample_tmax.nc
>> > > > > > >>>
>> > > > > > >>> ERROR : process_data_file() ->
>> "/scratch/halstead/y/yoo108/ND
>> > > > > > >>> _grided_obs/
>> > > > > > >>> sample_tmax.nc" not a valid data file
>> > > > > > >>>
>> > > > > > >>> I wonder which part of the input file does not
satisfy the
>> > MET's
>> > > > > "valid
>> > > > > > >>> file" criteria.
>> > > > > > >>> ncdump output of the input file looks as below:
>> > > > > > >>> Input file was originally generated by VIC model and
>> converted
>> > > into
>> > > > > cf
>> > > > > > >>> netcdf format.
>> > > > > > >>>
>> > > > > > >>>
>> > > > > > >>> Thank you in advance.
>> > > > > > >>> Regards,
>> > > > > > >>>
>> > > > > > >>> Jinwoong
>> > > > > > >>>
>> > > > > > >>>
>> > > > > > >>>
>> > > > > > >>>
>> > > > > > >>> yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/ND_grided_
>> > obs*
>> > > $
>> > > > > > >>> ncdump -h
>> > > > > > >>> sample_tmax.nc
>> > > > > > >>>
>> > > > > > >>> netcdf sample_tmax {
>> > > > > > >>>
>> > > > > > >>> dimensions:
>> > > > > > >>>
>> > > > > > >>> T = 1 ;
>> > > > > > >>>
>> > > > > > >>> X = 55 ;
>> > > > > > >>>
>> > > > > > >>> Y = 65 ;
>> > > > > > >>>
>> > > > > > >>>
>> > > > > > >>> variables:
>> > > > > > >>>
>> > > > > > >>> double T(T) ;
>> > > > > > >>>
>> > > > > > >>> T:units = "days since 1915-01-01" ;
>> > > > > > >>>
>> > > > > > >>> T:long_name = "Time" ;
>> > > > > > >>>
>> > > > > > >>>
>> > > > > > >>> double X(X) ;
>> > > > > > >>>
>> > > > > > >>> X:units = "degrees_east" ;
>> > > > > > >>>
>> > > > > > >>> X:long_name = "Longitude" ;
>> > > > > > >>>
>> > > > > > >>>
>> > > > > > >>> double Y(Y) ;
>> > > > > > >>>
>> > > > > > >>> Y:units = "degrees_north" ;
>> > > > > > >>>
>> > > > > > >>> Y:long_name = "Latitude" ;
>> > > > > > >>>
>> > > > > > >>>
>> > > > > > >>> double tmax(T, Y, X) ;
>> > > > > > >>>
>> > > > > > >>> tmax:units = "degC" ;
>> > > > > > >>>
>> > > > > > >>> tmax:long_name = "tmax calculated by VIC" ;
>> > > > > > >>>
>> > > > > > >>> tmax:missing_value = -9999.f ;
>> > > > > > >>>
>> > > > > > >>> // global attributes:
>> > > > > > >>>
>> > > > > > >>> :production = "VIC output" ;
>> > > > > > >>>
>> > > > > > >>>
>> > > > > > >>
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: John Halley Gotway
Time: Fri Jul 07 12:59:11 2017
Jinwoong,
Yes, you can give it a try. The closer you can make the NetCDF files
to
the CF-convention, the more likely MET will be able to read it.
The reason that's its able to read the TRMM data are that the lat/lon
values are equally spaced. Non-equally spaced lat/lon values on a map
projection require that the map projection information be specified.
Unfortunately, specifying map projection information in CF-compliant
NetCDF
files is not as easy as I think it should be!
Hope it works out ok for you.
Thanks,
John
On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>
> investigating not investing :)
>
> Thanks!
> Regards,
>
> Jinwoong
>
> On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> wrote:
>
> > Hi John,
> >
> > Thank you very much for your time investing the issue.
> > I am glad to hear that there is a trick to work around the issue
to read
> > in TRMM data in netcdf format.
> > I wonder if I can apply the same trick ( file_type=NETCDF_NCCF;)
to read
> > in any other observation files in netcdf format?
> > In fact, I would like to read in "home brew" netcdf dataset files
into
> > MET.
> > One sample file of them was included in the uploaded data folder (
> > sample_tmax.nc).
> > The data in this sample file was originally generated by VIC
model.
> > Then the file format was converted into a generic netcdf file
format
> > although the dimension names are T, X, Y not time, lat, lon.
> > But their coordinates have units in "degrees_east" or
"degrees_north" as
> > well as their long_name as "Longitude" and "Latitude",
respectively.
> >
> > Of course, I will try to read those in for Grid-stat today.
> > But I would like to hear from you if the trick (
file_type=NETCDF_NCCF;)
> > can be applied generally, which I wish very much.
> >
> > Thank you so much, John.
> >
> > Regards,
> >
> > Jinwoong Yoo
> >
> >
> > On Fri, Jul 7, 2017 at 1:16 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Jinwoong,
> >>
> >> Thanks for sending your sample data and for your patience while I
was
> out
> >> of town.
> >>
> >> Using met-6.0, I'm able to process the TRMM NetCDF file you sent.
The
> >> trick is that I had to tell it which NetCDF file type should be
used to
> >> interpret the data. Using "file_type = NETCDF_NCCF;" I'm telling
MET to
> >> interpret it as if it were a CF-compliant NetCDF file:
> >>
> >> met-6.0/bin/plot_data_plane \
> >> trmm_daily.20051231.7.nc trmm_daily.20051231.7.ps \
> >> 'name="precipitation"; level="(*,*)"; file_type=NETCDF_NCCF;'
> >>
> >> DEBUG 1: Opening data file: trmm_daily.20051231.7.nc
> >> WARNING: NcCfFile::open() -> could not determine the valid time,
using
> 0.
> >> WARNING: NcCfFile::open() -> could not determine the valid time,
using
> 0.
> >> DEBUG 1: Creating postscript file: trmm_daily.20051231.7.ps
> >>
> >> The plot_data_plane tool is able to read the data, and I've
attached the
> >> resulting image. However, notice the warning messages about the
valid
> >> time.
> >>
> >> Using ncdump to see that file attributes, I see this timing
information:
> >> :HDF5_GLOBAL.BeginDate = "2005-12-31" ;
> >> :HDF5_GLOBAL.BeginTime = "01:30:00.000Z" ;
> >> :HDF5_GLOBAL.EndDate = "2006-01-01" ;
> >> :HDF5_GLOBAL.EndTime = "01:29:59.999Z" ;
> >>
> >> However that is not the CF-compliant way of specifying timing
info. So
> >> while MET will be able to read the data, the timing info won't be
> accurate
> >> in the MET output files. Instead, you'll see "19700101" which is
> unixtime
> >> = 0.
> >>
> >> Another option would be pulling the binary TRMM data and using
this
> >> Rscript
> >> to convert the binary to NetCDF:
> >>
http://www.dtcenter.org/met/users/downloads/Rscripts/trmmbin2nc.R
> >>
> >> However, I haven't done this in a while and am not sure if you'll
run
> into
> >> any issues.
> >>
> >> Hope that helps.
> >>
> >> Thanks,
> >> John
> >>
> >>
> >>
> >>
> >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> >> wrote:
> >>
> >> >
> >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >> >
> >> > Hi John,
> >> >
> >> > Thank you very much.
> >> > Regards,
> >> >
> >> > Jinwoong
> >> >
> >> > On Thu, Jul 6, 2017 at 10:41 AM, John Halley Gotway via RT <
> >> > met_help at ucar.edu> wrote:
> >> >
> >> > > Jinwoong,
> >> > >
> >> > > I'm out of the office today but will take a closer look
tomorrow.
> >> > >
> >> > > Thanks
> >> > > John
> >> > >
> >> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo via RT <
> >> met_help at ucar.edu>
> >> > > wrote:
> >> > >
> >> > > >
> >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >> > > >
> >> > > > Hi John,
> >> > > >
> >> > > > Thank you for your reply.
> >> > > > I uploaded my data as in Yoo_data4.tar on the ftp site.
> >> > > > I included several files for the message of ID of [
> rt.rap.ucar.edu
> >> > > #81074]
> >> > > > as well.
> >> > > > Thank you.
> >> > > > Regards,
> >> > > >
> >> > > > Jinwoong
> >> > > >
> >> > > > On Mon, Jul 3, 2017 at 12:46 PM, John Halley Gotway via RT
<
> >> > > > met_help at ucar.edu> wrote:
> >> > > >
> >> > > > > Jinwoong,
> >> > > > >
> >> > > > > I see that you're having trouble reading a TRMM NetCDF
file into
> >> MET.
> >> > > > Can
> >> > > > > you please post the problematic file to our anonymous ftp
site
> so
> >> I
> >> > can
> >> > > > > take a look?
> >> > > > >
> >> > > > >
http://www.dtcenter.org/met/users/support/met_help.php#ftp
> >> > > > >
> >> > > > > Thanks,
> >> > > > > John Halley Gotway
> >> > > > >
> >> > > > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo via RT <
> >> > met_help at ucar.edu
> >> > > >
> >> > > > > wrote:
> >> > > > >
> >> > > > > >
> >> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
> >
> >> > > > > >
> >> > > > > > Hi,
> >> > > > > >
> >> > > > > > TRMM data comes in as netCDF-4 classic model.
> >> > > > > > I changed it to netCDF classic and run the same command
for a
> >> test.
> >> > > > > > But I got the same error as below.
> >> > > > > >
> >> > > > > > yoo108 at halstead-fe00:*/scratch/halstead/y/yoo108/TRMM*
$
> >> > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> >> /scratch/halstead/y/yoo108/
> >> > > TRMM/
> >> > > > > > trmm_daily_nc3.20051231.7.nc
> >> > > > > > /scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> >> > > maxminmean_1976.nc
> >> > > > > > /scratch/halstead/y/yoo108/TRMM/regrid_trmm_sample.nc
-field
> >> > > > > > 'name="precipitation";'
> >> > > > > >
> >> > > > > > DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/TRMM/
> >> > > > > > trmm_daily_nc3.20051231.7.nc
> >> > > > > >
> >> > > > > > ERROR :
> >> > > > > >
> >> > > > > > ERROR : process_data_file() ->
"/scratch/halstead/y/yoo108/TR
> >> MM/
> >> > > > > > trmm_daily_nc3.20051231.7.nc" not a valid data file
> >> > > > > >
> >> > > > > > Thank you.
> >> > > > > >
> >> > > > > > Regards,
> >> > > > > >
> >> > > > > >
> >> > > > > > Jinwoong
> >> > > > > >
> >> > > > > > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong Yoo <
> >> > > jinwoong.yoo at gmail.com>
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > > Hi,
> >> > > > > > >
> >> > > > > > > I noticed that TRMM data dimension was (lon, lat).
> >> > > > > > > So I switched their order to (lat, lon) and ran the
command
> >> > again.
> >> > > > > > > However, I got the same error message as below.
> >> > > > > > >
> >> > > > > > > yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/TRMM* $
> >> > > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> >> > /scratch/halstead/y/yoo108/
> >> > > > > TRMM/
> >> > > > > > > trmm_daily.20051231.7.nc
/scratch/halstead/y/yoo108/ND_
> >> > > > > > > grided_obs/daily_T2m_maxminmean_1976.nc
> >> > > /scratch/halstead/y/yoo108/
> >> > > > > TRMM/
> >> > > > > > > regrid_trmm_sample.nc -field 'name="precipitation";'
> >> > > > > > >
> >> > > > > > > DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/TRM
> M/
> >> > > > > > > trmm_daily.20051231.7.nc
> >> > > > > > >
> >> > > > > > > ERROR :
> >> > > > > > >
> >> > > > > > > ERROR : process_data_file() ->
> "/scratch/halstead/y/yoo108/TR
> >> > MM/
> >> > > > > > > trmm_daily.20051231.7.nc" not a valid data file
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > Thank you.
> >> > > > > > >
> >> > > > > > > Regards,
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > Jinwoong
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong Yoo <
> >> > > > jinwoong.yoo at gmail.com>
> >> > > > > > > wrote:
> >> > > > > > >
> >> > > > > > >> Hi,
> >> > > > > > >>
> >> > > > > > >> I got a similar result with a TRMM data.
> >> > > > > > >> Please see below:
> >> > > > > > >>
> >> > > > > > >> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/TRMM* $
> >> > > > > > >> ~/met-6.0_bugfix/bin/regrid_data_plane
> >> > > /scratch/halstead/y/yoo108/
> >> > > > > TRMM/
> >> > > > > > >> 3B42RT_Daily.20051231.7.nc
/scratch/halstead/y/yoo108/ND_
> >> > > > > > >> grided_obs/daily_T2m_maxminmean_1976.nc
> >> > > /scratch/halstead/y/yoo108/
> >> > > > > > TRMM/
> >> > > > > > >> regrid_trmm_sample.nc -field 'name="precipitation";'
> >> > > > > > >>
> >> > > > > > >> DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/TRM
> M/
> >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> >> > > > > > >>
> >> > > > > > >> ERROR : process_data_file() ->
> >> "/scratch/halstead/y/yoo108/TR
> >> > MM/
> >> > > > > > >> 3B42RT_Daily.20051231.7.nc" not a valid data file
> >> > > > > > >>
> >> > > > > > >>
> >> > > > > > >> A part of ncdump output for the TRMM data is pasted
below:
> >> > > > > > >>
> >> > > > > > >>
> >> > > > > > >> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/TRMM* $
> >> ncdump
> >> > > -h
> >> > > > > > >> subset_200003-200512/3B42RT_Daily.20051231.7.nc4.nc4
> >> > > > > > >>
> >> > > > > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
> >> > > > > > >>
> >> > > > > > >> dimensions:
> >> > > > > > >>
> >> > > > > > >> lon = 59 ;
> >> > > > > > >>
> >> > > > > > >> lat = 58 ;
> >> > > > > > >>
> >> > > > > > >> variables:
> >> > > > > > >>
> >> > > > > > >> short precipitation_cnt(lon, lat) ;
> >> > > > > > >>
> >> > > > > > >> precipitation_cnt:units = "count" ;
> >> > > > > > >>
> >> > > > > > >> precipitation_cnt:long_name = "Count of valid 3-hr
> >> precipitation
> >> > > > > > >> retrievals for the day" ;
> >> > > > > > >>
> >> > > > > > >> precipitation_cnt:coordinates = "lat lon" ;
> >> > > > > > >>
> >> > > > > > >> precipitation_cnt:origname = "precipitation_cnt" ;
> >> > > > > > >>
> >> > > > > > >> precipitation_cnt:fullnamepath =
"/precipitation_cnt" ;
> >> > > > > > >>
> >> > > > > > >> float uncal_precipitation(lon, lat) ;
> >> > > > > > >>
> >> > > > > > >> uncal_precipitation:units = "mm" ;
> >> > > > > > >>
> >> > > > > > >> uncal_precipitation:long_name = "Daily accumulated
> >> uncalibrated
> >> > > > > > >> precipitation" ;
> >> > > > > > >>
> >> > > > > > >> uncal_precipitation:coordinates = "lat lon" ;
> >> > > > > > >>
> >> > > > > > >> uncal_precipitation:_FillValue = -9999.9f ;
> >> > > > > > >>
> >> > > > > > >> uncal_precipitation:origname = "uncal_precipitation"
;
> >> > > > > > >>
> >> > > > > > >> uncal_precipitation:fullnamepath =
"/uncal_precipitation"
> ;
> >> > > > > > >>
> >> > > > > > >> short uncal_precipitation_cnt(lon, lat) ;
> >> > > > > > >>
> >> > > > > > >> uncal_precipitation_cnt:units = "count" ;
> >> > > > > > >>
> >> > > > > > >> uncal_precipitation_cnt:long_name = "Count of valid
3-hr
> >> uncal
> >> > > > > > >> precipitation retrievals for the day" ;
> >> > > > > > >>
> >> > > > > > >> uncal_precipitation_cnt:coordinates = "lat lon" ;
> >> > > > > > >>
> >> > > > > > >> uncal_precipitation_cnt:origname =
> >> "uncal_precipitation_cnt" ;
> >> > > > > > >>
> >> > > > > > >> uncal_precipitation_cnt:fullnamepath =
> >> > > "/uncal_precipitation_cnt" ;
> >> > > > > > >>
> >> > > > > > >> float precipitation(lon, lat) ;
> >> > > > > > >>
> >> > > > > > >> precipitation:units = "mm" ;
> >> > > > > > >>
> >> > > > > > >> precipitation:long_name = "Daily accumulated
precipitation
> >> > > (combined
> >> > > > > > >> microwave-IR) estimate" ;
> >> > > > > > >>
> >> > > > > > >> precipitation:coordinates = "lat lon" ;
> >> > > > > > >>
> >> > > > > > >> precipitation:_FillValue = -9999.9f ;
> >> > > > > > >>
> >> > > > > > >> precipitation:origname = "precipitation" ;
> >> > > > > > >>
> >> > > > > > >> precipitation:fullnamepath = "/precipitation" ;
> >> > > > > > >>
> >> > > > > > >> short randomError_cnt(lon, lat) ;
> >> > > > > > >>
> >> > > > > > >> randomError_cnt:units = "count" ;
> >> > > > > > >>
> >> > > > > > >> randomError_cnt:long_name = "Count of randomError
for the
> >> day" ;
> >> > > > > > >>
> >> > > > > > >> randomError_cnt:coordinates = "lat lon" ;
> >> > > > > > >>
> >> > > > > > >> randomError_cnt:origname = "randomError_cnt" ;
> >> > > > > > >>
> >> > > > > > >> randomError_cnt:fullnamepath = "/randomError_cnt" ;
> >> > > > > > >>
> >> > > > > > >> float randomError(lon, lat) ;
> >> > > > > > >>
> >> > > > > > >> randomError:units = "mm" ;
> >> > > > > > >>
> >> > > > > > >> randomError:long_name = "Daily total error of
combined
> >> > > microwave-IR
> >> > > > > > >> precipitation estimate" ;
> >> > > > > > >>
> >> > > > > > >> randomError:_FillValue = -9999.9f ;
> >> > > > > > >>
> >> > > > > > >> randomError:origname = "randomError" ;
> >> > > > > > >>
> >> > > > > > >> randomError:fullnamepath = "/randomError" ;
> >> > > > > > >>
> >> > > > > > >> float lat(lat) ;
> >> > > > > > >>
> >> > > > > > >> lat:units = "degrees_north" ;
> >> > > > > > >>
> >> > > > > > >> lat:long_name = "Latitude" ;
> >> > > > > > >>
> >> > > > > > >> lat:origname = "lat" ;
> >> > > > > > >>
> >> > > > > > >> lat:fullnamepath = "/lat" ;
> >> > > > > > >>
> >> > > > > > >> float lon(lon) ;
> >> > > > > > >>
> >> > > > > > >> lon:units = "degrees_east" ;
> >> > > > > > >>
> >> > > > > > >> lon:long_name = "Longitude" ;
> >> > > > > > >>
> >> > > > > > >> lon:origname = "lon" ;
> >> > > > > > >>
> >> > > > > > >> lon:fullnamepath = "/lon" ;
> >> > > > > > >>
> >> > > > > > >>
> >> > > > > > >>
> >> > > > > > >>
> >> > > > > > >> Thank you.
> >> > > > > > >>
> >> > > > > > >> Regards,
> >> > > > > > >>
> >> > > > > > >>
> >> > > > > > >> Jinwoong
> >> > > > > > >>
> >> > > > > > >> On Thu, Jun 29, 2017 at 3:11 PM, met_help at ucar.edu
via RT
> <
> >> > > > > > >> met_help at ucar.edu> wrote:
> >> > > > > > >>
> >> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED AVAILABILITY BETWEEN
> 5/23/17
> >> AND
> >> > > > > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
> >> > > > > > >>>
> >> > > > > > >>> Greetings,
> >> > > > > > >>>
> >> > > > > > >>> This message has been automatically generated in
response
> to
> >> > the
> >> > > > > > >>> creation of a trouble ticket regarding:
> >> > > > > > >>> "regrid_data_plane: not a valid data file",
> >> > > > > > >>> a summary of which appears below.
> >> > > > > > >>>
> >> > > > > > >>> There is no need to reply to this message right
now. Your
> >> > ticket
> >> > > > has
> >> > > > > > >>> been
> >> > > > > > >>> assigned an ID of [rt.rap.ucar.edu #81063].
> >> > > > > > >>>
> >> > > > > > >>> Please include the string:
> >> > > > > > >>>
> >> > > > > > >>> [rt.rap.ucar.edu #81063]
> >> > > > > > >>>
> >> > > > > > >>> in the subject line of all future correspondence
about
> this
> >> > > issue.
> >> > > > To
> >> > > > > > do
> >> > > > > > >>> so,
> >> > > > > > >>> you may reply to this message.
> >> > > > > > >>>
> >> > > > > > >>> Thank you,
> >> > > > > > >>> met_help at ucar.edu
> >> > > > > > >>>
> >> > > > > > >>> ------------------------------
> >> ------------------------------
> >> > > > > > >>> -------------
> >> > > > > > >>> Hi,
> >> > > > > > >>>
> >> > > > > > >>> I am trying to regrid one of my observation files
in lat
> lon
> >> > > > > coordinate
> >> > > > > > >>> grid to WRF curvilinear grid.
> >> > > > > > >>>
> >> > > > > > >>> I ran bin/regrid_data_plane using a sample lat lon
grid
> file
> >> > and
> >> > > a
> >> > > > > file
> >> > > > > > >>> in
> >> > > > > > >>> the WRF grid. But I got error as shown below:
> >> > > > > > >>>
> >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> /halstead/y/yoo108/ND_grided_
> >> > obs*
> >> > > $
> >> > > > > > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
> >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/sample_tmax.nc
> >> > > > > > >>> /scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> >> > > > > maxminmean_1976.nc
> >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> >> grided_obs/NDtoWRFgrid_sample_
> >> > > > tmax.nc
> >> > > > > > >>> -field
> >> > > > > > >>> 'name="tmax";'
> >> > > > > > >>>
> >> > > > > > >>> DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/ND_
> >> > > > > grided_obs/
> >> > > > > > >>> sample_tmax.nc
> >> > > > > > >>>
> >> > > > > > >>> ERROR : process_data_file() ->
> >> "/scratch/halstead/y/yoo108/ND
> >> > > > > > >>> _grided_obs/
> >> > > > > > >>> sample_tmax.nc" not a valid data file
> >> > > > > > >>>
> >> > > > > > >>> I wonder which part of the input file does not
satisfy the
> >> > MET's
> >> > > > > "valid
> >> > > > > > >>> file" criteria.
> >> > > > > > >>> ncdump output of the input file looks as below:
> >> > > > > > >>> Input file was originally generated by VIC model
and
> >> converted
> >> > > into
> >> > > > > cf
> >> > > > > > >>> netcdf format.
> >> > > > > > >>>
> >> > > > > > >>>
> >> > > > > > >>> Thank you in advance.
> >> > > > > > >>> Regards,
> >> > > > > > >>>
> >> > > > > > >>> Jinwoong
> >> > > > > > >>>
> >> > > > > > >>>
> >> > > > > > >>>
> >> > > > > > >>>
> >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> /halstead/y/yoo108/ND_grided_
> >> > obs*
> >> > > $
> >> > > > > > >>> ncdump -h
> >> > > > > > >>> sample_tmax.nc
> >> > > > > > >>>
> >> > > > > > >>> netcdf sample_tmax {
> >> > > > > > >>>
> >> > > > > > >>> dimensions:
> >> > > > > > >>>
> >> > > > > > >>> T = 1 ;
> >> > > > > > >>>
> >> > > > > > >>> X = 55 ;
> >> > > > > > >>>
> >> > > > > > >>> Y = 65 ;
> >> > > > > > >>>
> >> > > > > > >>>
> >> > > > > > >>> variables:
> >> > > > > > >>>
> >> > > > > > >>> double T(T) ;
> >> > > > > > >>>
> >> > > > > > >>> T:units = "days since 1915-01-01" ;
> >> > > > > > >>>
> >> > > > > > >>> T:long_name = "Time" ;
> >> > > > > > >>>
> >> > > > > > >>>
> >> > > > > > >>> double X(X) ;
> >> > > > > > >>>
> >> > > > > > >>> X:units = "degrees_east" ;
> >> > > > > > >>>
> >> > > > > > >>> X:long_name = "Longitude" ;
> >> > > > > > >>>
> >> > > > > > >>>
> >> > > > > > >>> double Y(Y) ;
> >> > > > > > >>>
> >> > > > > > >>> Y:units = "degrees_north" ;
> >> > > > > > >>>
> >> > > > > > >>> Y:long_name = "Latitude" ;
> >> > > > > > >>>
> >> > > > > > >>>
> >> > > > > > >>> double tmax(T, Y, X) ;
> >> > > > > > >>>
> >> > > > > > >>> tmax:units = "degC" ;
> >> > > > > > >>>
> >> > > > > > >>> tmax:long_name = "tmax calculated by VIC" ;
> >> > > > > > >>>
> >> > > > > > >>> tmax:missing_value = -9999.f ;
> >> > > > > > >>>
> >> > > > > > >>> // global attributes:
> >> > > > > > >>>
> >> > > > > > >>> :production = "VIC output" ;
> >> > > > > > >>>
> >> > > > > > >>>
> >> > > > > > >>
> >> > > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Fri Jul 07 13:01:09 2017
Hi John,
Thank you very much.
Let me try and let you know how it goes.
Thank you.
Regards,
Jinwoong
On Fri, Jul 7, 2017 at 2:59 PM, John Halley Gotway via RT
<met_help at ucar.edu
> wrote:
> Jinwoong,
>
> Yes, you can give it a try. The closer you can make the NetCDF
files to
> the CF-convention, the more likely MET will be able to read it.
>
> The reason that's its able to read the TRMM data are that the
lat/lon
> values are equally spaced. Non-equally spaced lat/lon values on a
map
> projection require that the map projection information be specified.
> Unfortunately, specifying map projection information in CF-compliant
NetCDF
> files is not as easy as I think it should be!
>
> Hope it works out ok for you.
>
> Thanks,
> John
>
> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >
> > investigating not investing :)
> >
> > Thanks!
> > Regards,
> >
> > Jinwoong
> >
> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > wrote:
> >
> > > Hi John,
> > >
> > > Thank you very much for your time investing the issue.
> > > I am glad to hear that there is a trick to work around the issue
to
> read
> > > in TRMM data in netcdf format.
> > > I wonder if I can apply the same trick ( file_type=NETCDF_NCCF;)
to
> read
> > > in any other observation files in netcdf format?
> > > In fact, I would like to read in "home brew" netcdf dataset
files into
> > > MET.
> > > One sample file of them was included in the uploaded data folder
(
> > > sample_tmax.nc).
> > > The data in this sample file was originally generated by VIC
model.
> > > Then the file format was converted into a generic netcdf file
format
> > > although the dimension names are T, X, Y not time, lat, lon.
> > > But their coordinates have units in "degrees_east" or
"degrees_north"
> as
> > > well as their long_name as "Longitude" and "Latitude",
respectively.
> > >
> > > Of course, I will try to read those in for Grid-stat today.
> > > But I would like to hear from you if the trick (
> file_type=NETCDF_NCCF;)
> > > can be applied generally, which I wish very much.
> > >
> > > Thank you so much, John.
> > >
> > > Regards,
> > >
> > > Jinwoong Yoo
> > >
> > >
> > > On Fri, Jul 7, 2017 at 1:16 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >> Jinwoong,
> > >>
> > >> Thanks for sending your sample data and for your patience while
I was
> > out
> > >> of town.
> > >>
> > >> Using met-6.0, I'm able to process the TRMM NetCDF file you
sent. The
> > >> trick is that I had to tell it which NetCDF file type should be
used
> to
> > >> interpret the data. Using "file_type = NETCDF_NCCF;" I'm
telling MET
> to
> > >> interpret it as if it were a CF-compliant NetCDF file:
> > >>
> > >> met-6.0/bin/plot_data_plane \
> > >> trmm_daily.20051231.7.nc trmm_daily.20051231.7.ps \
> > >> 'name="precipitation"; level="(*,*)"; file_type=NETCDF_NCCF;'
> > >>
> > >> DEBUG 1: Opening data file: trmm_daily.20051231.7.nc
> > >> WARNING: NcCfFile::open() -> could not determine the valid
time, using
> > 0.
> > >> WARNING: NcCfFile::open() -> could not determine the valid
time, using
> > 0.
> > >> DEBUG 1: Creating postscript file: trmm_daily.20051231.7.ps
> > >>
> > >> The plot_data_plane tool is able to read the data, and I've
attached
> the
> > >> resulting image. However, notice the warning messages about
the valid
> > >> time.
> > >>
> > >> Using ncdump to see that file attributes, I see this timing
> information:
> > >> :HDF5_GLOBAL.BeginDate = "2005-12-31" ;
> > >> :HDF5_GLOBAL.BeginTime = "01:30:00.000Z" ;
> > >> :HDF5_GLOBAL.EndDate = "2006-01-01" ;
> > >> :HDF5_GLOBAL.EndTime = "01:29:59.999Z" ;
> > >>
> > >> However that is not the CF-compliant way of specifying timing
info.
> So
> > >> while MET will be able to read the data, the timing info won't
be
> > accurate
> > >> in the MET output files. Instead, you'll see "19700101" which
is
> > unixtime
> > >> = 0.
> > >>
> > >> Another option would be pulling the binary TRMM data and using
this
> > >> Rscript
> > >> to convert the binary to NetCDF:
> > >>
http://www.dtcenter.org/met/users/downloads/Rscripts/trmmbin2nc.R
> > >>
> > >> However, I haven't done this in a while and am not sure if
you'll run
> > into
> > >> any issues.
> > >>
> > >> Hope that helps.
> > >>
> > >> Thanks,
> > >> John
> > >>
> > >>
> > >>
> > >>
> > >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo via RT <
> met_help at ucar.edu>
> > >> wrote:
> > >>
> > >> >
> > >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
> > >> >
> > >> > Hi John,
> > >> >
> > >> > Thank you very much.
> > >> > Regards,
> > >> >
> > >> > Jinwoong
> > >> >
> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John Halley Gotway via RT <
> > >> > met_help at ucar.edu> wrote:
> > >> >
> > >> > > Jinwoong,
> > >> > >
> > >> > > I'm out of the office today but will take a closer look
tomorrow.
> > >> > >
> > >> > > Thanks
> > >> > > John
> > >> > >
> > >> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo via RT <
> > >> met_help at ucar.edu>
> > >> > > wrote:
> > >> > >
> > >> > > >
> > >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > >> > > >
> > >> > > > Hi John,
> > >> > > >
> > >> > > > Thank you for your reply.
> > >> > > > I uploaded my data as in Yoo_data4.tar on the ftp site.
> > >> > > > I included several files for the message of ID of [
> > rt.rap.ucar.edu
> > >> > > #81074]
> > >> > > > as well.
> > >> > > > Thank you.
> > >> > > > Regards,
> > >> > > >
> > >> > > > Jinwoong
> > >> > > >
> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM, John Halley Gotway via
RT <
> > >> > > > met_help at ucar.edu> wrote:
> > >> > > >
> > >> > > > > Jinwoong,
> > >> > > > >
> > >> > > > > I see that you're having trouble reading a TRMM NetCDF
file
> into
> > >> MET.
> > >> > > > Can
> > >> > > > > you please post the problematic file to our anonymous
ftp site
> > so
> > >> I
> > >> > can
> > >> > > > > take a look?
> > >> > > > >
> > >> > > > >
http://www.dtcenter.org/met/users/support/met_help.php#ftp
> > >> > > > >
> > >> > > > > Thanks,
> > >> > > > > John Halley Gotway
> > >> > > > >
> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo via RT <
> > >> > met_help at ucar.edu
> > >> > > >
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > > >
> > >> > > > > > <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=81063
> > >
> > >> > > > > >
> > >> > > > > > Hi,
> > >> > > > > >
> > >> > > > > > TRMM data comes in as netCDF-4 classic model.
> > >> > > > > > I changed it to netCDF classic and run the same
command for
> a
> > >> test.
> > >> > > > > > But I got the same error as below.
> > >> > > > > >
> > >> > > > > > yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/TRMM* $
> > >> > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> > >> /scratch/halstead/y/yoo108/
> > >> > > TRMM/
> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > >> > > > > > /scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> > >> > > maxminmean_1976.nc
> > >> > > > > > /scratch/halstead/y/yoo108/TRMM/regrid_trmm_sample.nc
> -field
> > >> > > > > > 'name="precipitation";'
> > >> > > > > >
> > >> > > > > > DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/
> TRMM/
> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > >> > > > > >
> > >> > > > > > ERROR :
> > >> > > > > >
> > >> > > > > > ERROR : process_data_file() ->
> "/scratch/halstead/y/yoo108/TR
> > >> MM/
> > >> > > > > > trmm_daily_nc3.20051231.7.nc" not a valid data file
> > >> > > > > >
> > >> > > > > > Thank you.
> > >> > > > > >
> > >> > > > > > Regards,
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > Jinwoong
> > >> > > > > >
> > >> > > > > > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong Yoo <
> > >> > > jinwoong.yoo at gmail.com>
> > >> > > > > > wrote:
> > >> > > > > >
> > >> > > > > > > Hi,
> > >> > > > > > >
> > >> > > > > > > I noticed that TRMM data dimension was (lon, lat).
> > >> > > > > > > So I switched their order to (lat, lon) and ran the
> command
> > >> > again.
> > >> > > > > > > However, I got the same error message as below.
> > >> > > > > > >
> > >> > > > > > > yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/TRMM* $
> > >> > > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> > >> > /scratch/halstead/y/yoo108/
> > >> > > > > TRMM/
> > >> > > > > > > trmm_daily.20051231.7.nc
/scratch/halstead/y/yoo108/ND_
> > >> > > > > > > grided_obs/daily_T2m_maxminmean_1976.nc
> > >> > > /scratch/halstead/y/yoo108/
> > >> > > > > TRMM/
> > >> > > > > > > regrid_trmm_sample.nc -field
'name="precipitation";'
> > >> > > > > > >
> > >> > > > > > > DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/TRM
> > M/
> > >> > > > > > > trmm_daily.20051231.7.nc
> > >> > > > > > >
> > >> > > > > > > ERROR :
> > >> > > > > > >
> > >> > > > > > > ERROR : process_data_file() ->
> > "/scratch/halstead/y/yoo108/TR
> > >> > MM/
> > >> > > > > > > trmm_daily.20051231.7.nc" not a valid data file
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > Thank you.
> > >> > > > > > >
> > >> > > > > > > Regards,
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > Jinwoong
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong Yoo <
> > >> > > > jinwoong.yoo at gmail.com>
> > >> > > > > > > wrote:
> > >> > > > > > >
> > >> > > > > > >> Hi,
> > >> > > > > > >>
> > >> > > > > > >> I got a similar result with a TRMM data.
> > >> > > > > > >> Please see below:
> > >> > > > > > >>
> > >> > > > > > >> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/TRMM* $
> > >> > > > > > >> ~/met-6.0_bugfix/bin/regrid_data_plane
> > >> > > /scratch/halstead/y/yoo108/
> > >> > > > > TRMM/
> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> /scratch/halstead/y/yoo108/ND_
> > >> > > > > > >> grided_obs/daily_T2m_maxminmean_1976.nc
> > >> > > /scratch/halstead/y/yoo108/
> > >> > > > > > TRMM/
> > >> > > > > > >> regrid_trmm_sample.nc -field
'name="precipitation";'
> > >> > > > > > >>
> > >> > > > > > >> DEBUG 1: Reading data file:
> /scratch/halstead/y/yoo108/TRM
> > M/
> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > >> > > > > > >>
> > >> > > > > > >> ERROR : process_data_file() ->
> > >> "/scratch/halstead/y/yoo108/TR
> > >> > MM/
> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc" not a valid data file
> > >> > > > > > >>
> > >> > > > > > >>
> > >> > > > > > >> A part of ncdump output for the TRMM data is
pasted
> below:
> > >> > > > > > >>
> > >> > > > > > >>
> > >> > > > > > >> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/TRMM* $
> > >> ncdump
> > >> > > -h
> > >> > > > > > >> subset_200003-
200512/3B42RT_Daily.20051231.7.nc4.nc4
> > >> > > > > > >>
> > >> > > > > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
> > >> > > > > > >>
> > >> > > > > > >> dimensions:
> > >> > > > > > >>
> > >> > > > > > >> lon = 59 ;
> > >> > > > > > >>
> > >> > > > > > >> lat = 58 ;
> > >> > > > > > >>
> > >> > > > > > >> variables:
> > >> > > > > > >>
> > >> > > > > > >> short precipitation_cnt(lon, lat) ;
> > >> > > > > > >>
> > >> > > > > > >> precipitation_cnt:units = "count" ;
> > >> > > > > > >>
> > >> > > > > > >> precipitation_cnt:long_name = "Count of valid 3-hr
> > >> precipitation
> > >> > > > > > >> retrievals for the day" ;
> > >> > > > > > >>
> > >> > > > > > >> precipitation_cnt:coordinates = "lat lon" ;
> > >> > > > > > >>
> > >> > > > > > >> precipitation_cnt:origname = "precipitation_cnt" ;
> > >> > > > > > >>
> > >> > > > > > >> precipitation_cnt:fullnamepath =
"/precipitation_cnt" ;
> > >> > > > > > >>
> > >> > > > > > >> float uncal_precipitation(lon, lat) ;
> > >> > > > > > >>
> > >> > > > > > >> uncal_precipitation:units = "mm" ;
> > >> > > > > > >>
> > >> > > > > > >> uncal_precipitation:long_name = "Daily accumulated
> > >> uncalibrated
> > >> > > > > > >> precipitation" ;
> > >> > > > > > >>
> > >> > > > > > >> uncal_precipitation:coordinates = "lat lon" ;
> > >> > > > > > >>
> > >> > > > > > >> uncal_precipitation:_FillValue = -9999.9f ;
> > >> > > > > > >>
> > >> > > > > > >> uncal_precipitation:origname =
"uncal_precipitation" ;
> > >> > > > > > >>
> > >> > > > > > >> uncal_precipitation:fullnamepath =
> "/uncal_precipitation"
> > ;
> > >> > > > > > >>
> > >> > > > > > >> short uncal_precipitation_cnt(lon, lat) ;
> > >> > > > > > >>
> > >> > > > > > >> uncal_precipitation_cnt:units = "count" ;
> > >> > > > > > >>
> > >> > > > > > >> uncal_precipitation_cnt:long_name = "Count of
valid 3-hr
> > >> uncal
> > >> > > > > > >> precipitation retrievals for the day" ;
> > >> > > > > > >>
> > >> > > > > > >> uncal_precipitation_cnt:coordinates = "lat lon" ;
> > >> > > > > > >>
> > >> > > > > > >> uncal_precipitation_cnt:origname =
> > >> "uncal_precipitation_cnt" ;
> > >> > > > > > >>
> > >> > > > > > >> uncal_precipitation_cnt:fullnamepath =
> > >> > > "/uncal_precipitation_cnt" ;
> > >> > > > > > >>
> > >> > > > > > >> float precipitation(lon, lat) ;
> > >> > > > > > >>
> > >> > > > > > >> precipitation:units = "mm" ;
> > >> > > > > > >>
> > >> > > > > > >> precipitation:long_name = "Daily accumulated
> precipitation
> > >> > > (combined
> > >> > > > > > >> microwave-IR) estimate" ;
> > >> > > > > > >>
> > >> > > > > > >> precipitation:coordinates = "lat lon" ;
> > >> > > > > > >>
> > >> > > > > > >> precipitation:_FillValue = -9999.9f ;
> > >> > > > > > >>
> > >> > > > > > >> precipitation:origname = "precipitation" ;
> > >> > > > > > >>
> > >> > > > > > >> precipitation:fullnamepath = "/precipitation" ;
> > >> > > > > > >>
> > >> > > > > > >> short randomError_cnt(lon, lat) ;
> > >> > > > > > >>
> > >> > > > > > >> randomError_cnt:units = "count" ;
> > >> > > > > > >>
> > >> > > > > > >> randomError_cnt:long_name = "Count of randomError
for the
> > >> day" ;
> > >> > > > > > >>
> > >> > > > > > >> randomError_cnt:coordinates = "lat lon" ;
> > >> > > > > > >>
> > >> > > > > > >> randomError_cnt:origname = "randomError_cnt" ;
> > >> > > > > > >>
> > >> > > > > > >> randomError_cnt:fullnamepath = "/randomError_cnt"
;
> > >> > > > > > >>
> > >> > > > > > >> float randomError(lon, lat) ;
> > >> > > > > > >>
> > >> > > > > > >> randomError:units = "mm" ;
> > >> > > > > > >>
> > >> > > > > > >> randomError:long_name = "Daily total error of
combined
> > >> > > microwave-IR
> > >> > > > > > >> precipitation estimate" ;
> > >> > > > > > >>
> > >> > > > > > >> randomError:_FillValue = -9999.9f ;
> > >> > > > > > >>
> > >> > > > > > >> randomError:origname = "randomError" ;
> > >> > > > > > >>
> > >> > > > > > >> randomError:fullnamepath = "/randomError" ;
> > >> > > > > > >>
> > >> > > > > > >> float lat(lat) ;
> > >> > > > > > >>
> > >> > > > > > >> lat:units = "degrees_north" ;
> > >> > > > > > >>
> > >> > > > > > >> lat:long_name = "Latitude" ;
> > >> > > > > > >>
> > >> > > > > > >> lat:origname = "lat" ;
> > >> > > > > > >>
> > >> > > > > > >> lat:fullnamepath = "/lat" ;
> > >> > > > > > >>
> > >> > > > > > >> float lon(lon) ;
> > >> > > > > > >>
> > >> > > > > > >> lon:units = "degrees_east" ;
> > >> > > > > > >>
> > >> > > > > > >> lon:long_name = "Longitude" ;
> > >> > > > > > >>
> > >> > > > > > >> lon:origname = "lon" ;
> > >> > > > > > >>
> > >> > > > > > >> lon:fullnamepath = "/lon" ;
> > >> > > > > > >>
> > >> > > > > > >>
> > >> > > > > > >>
> > >> > > > > > >>
> > >> > > > > > >> Thank you.
> > >> > > > > > >>
> > >> > > > > > >> Regards,
> > >> > > > > > >>
> > >> > > > > > >>
> > >> > > > > > >> Jinwoong
> > >> > > > > > >>
> > >> > > > > > >> On Thu, Jun 29, 2017 at 3:11 PM, met_help at ucar.edu
via
> RT
> > <
> > >> > > > > > >> met_help at ucar.edu> wrote:
> > >> > > > > > >>
> > >> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED AVAILABILITY
BETWEEN
> > 5/23/17
> > >> AND
> > >> > > > > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
> > >> > > > > > >>>
> > >> > > > > > >>> Greetings,
> > >> > > > > > >>>
> > >> > > > > > >>> This message has been automatically generated in
> response
> > to
> > >> > the
> > >> > > > > > >>> creation of a trouble ticket regarding:
> > >> > > > > > >>> "regrid_data_plane: not a valid data
file",
> > >> > > > > > >>> a summary of which appears below.
> > >> > > > > > >>>
> > >> > > > > > >>> There is no need to reply to this message right
now.
> Your
> > >> > ticket
> > >> > > > has
> > >> > > > > > >>> been
> > >> > > > > > >>> assigned an ID of [rt.rap.ucar.edu #81063].
> > >> > > > > > >>>
> > >> > > > > > >>> Please include the string:
> > >> > > > > > >>>
> > >> > > > > > >>> [rt.rap.ucar.edu #81063]
> > >> > > > > > >>>
> > >> > > > > > >>> in the subject line of all future correspondence
about
> > this
> > >> > > issue.
> > >> > > > To
> > >> > > > > > do
> > >> > > > > > >>> so,
> > >> > > > > > >>> you may reply to this message.
> > >> > > > > > >>>
> > >> > > > > > >>> Thank you,
> > >> > > > > > >>> met_help at ucar.edu
> > >> > > > > > >>>
> > >> > > > > > >>> ------------------------------
> > >> ------------------------------
> > >> > > > > > >>> -------------
> > >> > > > > > >>> Hi,
> > >> > > > > > >>>
> > >> > > > > > >>> I am trying to regrid one of my observation files
in lat
> > lon
> > >> > > > > coordinate
> > >> > > > > > >>> grid to WRF curvilinear grid.
> > >> > > > > > >>>
> > >> > > > > > >>> I ran bin/regrid_data_plane using a sample lat
lon grid
> > file
> > >> > and
> > >> > > a
> > >> > > > > file
> > >> > > > > > >>> in
> > >> > > > > > >>> the WRF grid. But I got error as shown below:
> > >> > > > > > >>>
> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > /halstead/y/yoo108/ND_grided_
> > >> > obs*
> > >> > > $
> > >> > > > > > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/sample_tmax.nc
> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> > >> > > > > maxminmean_1976.nc
> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > >> grided_obs/NDtoWRFgrid_sample_
> > >> > > > tmax.nc
> > >> > > > > > >>> -field
> > >> > > > > > >>> 'name="tmax";'
> > >> > > > > > >>>
> > >> > > > > > >>> DEBUG 1: Reading data file:
> /scratch/halstead/y/yoo108/ND_
> > >> > > > > grided_obs/
> > >> > > > > > >>> sample_tmax.nc
> > >> > > > > > >>>
> > >> > > > > > >>> ERROR : process_data_file() ->
> > >> "/scratch/halstead/y/yoo108/ND
> > >> > > > > > >>> _grided_obs/
> > >> > > > > > >>> sample_tmax.nc" not a valid data file
> > >> > > > > > >>>
> > >> > > > > > >>> I wonder which part of the input file does not
satisfy
> the
> > >> > MET's
> > >> > > > > "valid
> > >> > > > > > >>> file" criteria.
> > >> > > > > > >>> ncdump output of the input file looks as below:
> > >> > > > > > >>> Input file was originally generated by VIC model
and
> > >> converted
> > >> > > into
> > >> > > > > cf
> > >> > > > > > >>> netcdf format.
> > >> > > > > > >>>
> > >> > > > > > >>>
> > >> > > > > > >>> Thank you in advance.
> > >> > > > > > >>> Regards,
> > >> > > > > > >>>
> > >> > > > > > >>> Jinwoong
> > >> > > > > > >>>
> > >> > > > > > >>>
> > >> > > > > > >>>
> > >> > > > > > >>>
> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > /halstead/y/yoo108/ND_grided_
> > >> > obs*
> > >> > > $
> > >> > > > > > >>> ncdump -h
> > >> > > > > > >>> sample_tmax.nc
> > >> > > > > > >>>
> > >> > > > > > >>> netcdf sample_tmax {
> > >> > > > > > >>>
> > >> > > > > > >>> dimensions:
> > >> > > > > > >>>
> > >> > > > > > >>> T = 1 ;
> > >> > > > > > >>>
> > >> > > > > > >>> X = 55 ;
> > >> > > > > > >>>
> > >> > > > > > >>> Y = 65 ;
> > >> > > > > > >>>
> > >> > > > > > >>>
> > >> > > > > > >>> variables:
> > >> > > > > > >>>
> > >> > > > > > >>> double T(T) ;
> > >> > > > > > >>>
> > >> > > > > > >>> T:units = "days since 1915-01-01" ;
> > >> > > > > > >>>
> > >> > > > > > >>> T:long_name = "Time" ;
> > >> > > > > > >>>
> > >> > > > > > >>>
> > >> > > > > > >>> double X(X) ;
> > >> > > > > > >>>
> > >> > > > > > >>> X:units = "degrees_east" ;
> > >> > > > > > >>>
> > >> > > > > > >>> X:long_name = "Longitude" ;
> > >> > > > > > >>>
> > >> > > > > > >>>
> > >> > > > > > >>> double Y(Y) ;
> > >> > > > > > >>>
> > >> > > > > > >>> Y:units = "degrees_north" ;
> > >> > > > > > >>>
> > >> > > > > > >>> Y:long_name = "Latitude" ;
> > >> > > > > > >>>
> > >> > > > > > >>>
> > >> > > > > > >>> double tmax(T, Y, X) ;
> > >> > > > > > >>>
> > >> > > > > > >>> tmax:units = "degC" ;
> > >> > > > > > >>>
> > >> > > > > > >>> tmax:long_name = "tmax calculated by VIC" ;
> > >> > > > > > >>>
> > >> > > > > > >>> tmax:missing_value = -9999.f ;
> > >> > > > > > >>>
> > >> > > > > > >>> // global attributes:
> > >> > > > > > >>>
> > >> > > > > > >>> :production = "VIC output" ;
> > >> > > > > > >>>
> > >> > > > > > >>>
> > >> > > > > > >>
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >>
> > >>
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Fri Jul 07 15:36:53 2017
Hi John,
I was able to read in a "home brew" netcdf data file using
plot_data_plane.
Then, I went ahead and tried another netcdf file in curvilinear
coordinate
which is in the same coordinate grid as my WRF output. But it failed.
I have many netcdf climatology files from the WRF simulation such as
daily,
monthly, and annual, etc. Therefore, they are all in curvilinear
coordinate
(Lambert).
I wonder if there is any work around so that I can feed these files
into
MET?
Or should I regrid them all into lat lon coordinate files first?
Thank you, John.
Regards,
Jinwoong Yoo
On Fri, Jul 7, 2017 at 3:01 PM, Jinwoong Yoo <jinwoong.yoo at gmail.com>
wrote:
> Hi John,
>
> Thank you very much.
> Let me try and let you know how it goes.
> Thank you.
> Regards,
>
> Jinwoong
>
> On Fri, Jul 7, 2017 at 2:59 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Jinwoong,
>>
>> Yes, you can give it a try. The closer you can make the NetCDF
files to
>> the CF-convention, the more likely MET will be able to read it.
>>
>> The reason that's its able to read the TRMM data are that the
lat/lon
>> values are equally spaced. Non-equally spaced lat/lon values on a
map
>> projection require that the map projection information be
specified.
>> Unfortunately, specifying map projection information in CF-
compliant
>> NetCDF
>> files is not as easy as I think it should be!
>>
>> Hope it works out ok for you.
>>
>> Thanks,
>> John
>>
>> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
>> wrote:
>>
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>> >
>> > investigating not investing :)
>> >
>> > Thanks!
>> > Regards,
>> >
>> > Jinwoong
>> >
>> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
>> > wrote:
>> >
>> > > Hi John,
>> > >
>> > > Thank you very much for your time investing the issue.
>> > > I am glad to hear that there is a trick to work around the
issue to
>> read
>> > > in TRMM data in netcdf format.
>> > > I wonder if I can apply the same trick (
file_type=NETCDF_NCCF;) to
>> read
>> > > in any other observation files in netcdf format?
>> > > In fact, I would like to read in "home brew" netcdf dataset
files into
>> > > MET.
>> > > One sample file of them was included in the uploaded data
folder (
>> > > sample_tmax.nc).
>> > > The data in this sample file was originally generated by VIC
model.
>> > > Then the file format was converted into a generic netcdf file
format
>> > > although the dimension names are T, X, Y not time, lat, lon.
>> > > But their coordinates have units in "degrees_east" or
"degrees_north"
>> as
>> > > well as their long_name as "Longitude" and "Latitude",
respectively.
>> > >
>> > > Of course, I will try to read those in for Grid-stat today.
>> > > But I would like to hear from you if the trick (
>> file_type=NETCDF_NCCF;)
>> > > can be applied generally, which I wish very much.
>> > >
>> > > Thank you so much, John.
>> > >
>> > > Regards,
>> > >
>> > > Jinwoong Yoo
>> > >
>> > >
>> > > On Fri, Jul 7, 2017 at 1:16 PM, John Halley Gotway via RT <
>> > > met_help at ucar.edu> wrote:
>> > >
>> > >> Jinwoong,
>> > >>
>> > >> Thanks for sending your sample data and for your patience
while I was
>> > out
>> > >> of town.
>> > >>
>> > >> Using met-6.0, I'm able to process the TRMM NetCDF file you
sent.
>> The
>> > >> trick is that I had to tell it which NetCDF file type should
be used
>> to
>> > >> interpret the data. Using "file_type = NETCDF_NCCF;" I'm
telling
>> MET to
>> > >> interpret it as if it were a CF-compliant NetCDF file:
>> > >>
>> > >> met-6.0/bin/plot_data_plane \
>> > >> trmm_daily.20051231.7.nc trmm_daily.20051231.7.ps \
>> > >> 'name="precipitation"; level="(*,*)"; file_type=NETCDF_NCCF;'
>> > >>
>> > >> DEBUG 1: Opening data file: trmm_daily.20051231.7.nc
>> > >> WARNING: NcCfFile::open() -> could not determine the valid
time,
>> using
>> > 0.
>> > >> WARNING: NcCfFile::open() -> could not determine the valid
time,
>> using
>> > 0.
>> > >> DEBUG 1: Creating postscript file: trmm_daily.20051231.7.ps
>> > >>
>> > >> The plot_data_plane tool is able to read the data, and I've
attached
>> the
>> > >> resulting image. However, notice the warning messages about
the
>> valid
>> > >> time.
>> > >>
>> > >> Using ncdump to see that file attributes, I see this timing
>> information:
>> > >> :HDF5_GLOBAL.BeginDate = "2005-12-31" ;
>> > >> :HDF5_GLOBAL.BeginTime = "01:30:00.000Z" ;
>> > >> :HDF5_GLOBAL.EndDate = "2006-01-01" ;
>> > >> :HDF5_GLOBAL.EndTime = "01:29:59.999Z" ;
>> > >>
>> > >> However that is not the CF-compliant way of specifying timing
info.
>> So
>> > >> while MET will be able to read the data, the timing info won't
be
>> > accurate
>> > >> in the MET output files. Instead, you'll see "19700101" which
is
>> > unixtime
>> > >> = 0.
>> > >>
>> > >> Another option would be pulling the binary TRMM data and using
this
>> > >> Rscript
>> > >> to convert the binary to NetCDF:
>> > >>
http://www.dtcenter.org/met/users/downloads/Rscripts/trmmbin2nc.R
>> > >>
>> > >> However, I haven't done this in a while and am not sure if
you'll run
>> > into
>> > >> any issues.
>> > >>
>> > >> Hope that helps.
>> > >>
>> > >> Thanks,
>> > >> John
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo via RT <
>> met_help at ucar.edu>
>> > >> wrote:
>> > >>
>> > >> >
>> > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>> > >> >
>> > >> > Hi John,
>> > >> >
>> > >> > Thank you very much.
>> > >> > Regards,
>> > >> >
>> > >> > Jinwoong
>> > >> >
>> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John Halley Gotway via RT <
>> > >> > met_help at ucar.edu> wrote:
>> > >> >
>> > >> > > Jinwoong,
>> > >> > >
>> > >> > > I'm out of the office today but will take a closer look
tomorrow.
>> > >> > >
>> > >> > > Thanks
>> > >> > > John
>> > >> > >
>> > >> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo via RT <
>> > >> met_help at ucar.edu>
>> > >> > > wrote:
>> > >> > >
>> > >> > > >
>> > >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>> >
>> > >> > > >
>> > >> > > > Hi John,
>> > >> > > >
>> > >> > > > Thank you for your reply.
>> > >> > > > I uploaded my data as in Yoo_data4.tar on the ftp site.
>> > >> > > > I included several files for the message of ID of [
>> > rt.rap.ucar.edu
>> > >> > > #81074]
>> > >> > > > as well.
>> > >> > > > Thank you.
>> > >> > > > Regards,
>> > >> > > >
>> > >> > > > Jinwoong
>> > >> > > >
>> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM, John Halley Gotway via
RT <
>> > >> > > > met_help at ucar.edu> wrote:
>> > >> > > >
>> > >> > > > > Jinwoong,
>> > >> > > > >
>> > >> > > > > I see that you're having trouble reading a TRMM NetCDF
file
>> into
>> > >> MET.
>> > >> > > > Can
>> > >> > > > > you please post the problematic file to our anonymous
ftp
>> site
>> > so
>> > >> I
>> > >> > can
>> > >> > > > > take a look?
>> > >> > > > >
>> > >> > > > >
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>> > >> > > > >
>> > >> > > > > Thanks,
>> > >> > > > > John Halley Gotway
>> > >> > > > >
>> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo via RT <
>> > >> > met_help at ucar.edu
>> > >> > > >
>> > >> > > > > wrote:
>> > >> > > > >
>> > >> > > > > >
>> > >> > > > > > <URL: https://rt.rap.ucar.edu/rt/Tic
>> ket/Display.html?id=81063
>> > >
>> > >> > > > > >
>> > >> > > > > > Hi,
>> > >> > > > > >
>> > >> > > > > > TRMM data comes in as netCDF-4 classic model.
>> > >> > > > > > I changed it to netCDF classic and run the same
command
>> for a
>> > >> test.
>> > >> > > > > > But I got the same error as below.
>> > >> > > > > >
>> > >> > > > > > yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/TRMM* $
>> > >> > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
>> > >> /scratch/halstead/y/yoo108/
>> > >> > > TRMM/
>> > >> > > > > > trmm_daily_nc3.20051231.7.nc
>> > >> > > > > > /scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
>> > >> > > maxminmean_1976.nc
>> > >> > > > > >
/scratch/halstead/y/yoo108/TRMM/regrid_trmm_sample.nc
>> -field
>> > >> > > > > > 'name="precipitation";'
>> > >> > > > > >
>> > >> > > > > > DEBUG 1: Reading data file:
/scratch/halstead/y/yoo108/TRM
>> M/
>> > >> > > > > > trmm_daily_nc3.20051231.7.nc
>> > >> > > > > >
>> > >> > > > > > ERROR :
>> > >> > > > > >
>> > >> > > > > > ERROR : process_data_file() ->
>> "/scratch/halstead/y/yoo108/TR
>> > >> MM/
>> > >> > > > > > trmm_daily_nc3.20051231.7.nc" not a valid data file
>> > >> > > > > >
>> > >> > > > > > Thank you.
>> > >> > > > > >
>> > >> > > > > > Regards,
>> > >> > > > > >
>> > >> > > > > >
>> > >> > > > > > Jinwoong
>> > >> > > > > >
>> > >> > > > > > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong Yoo <
>> > >> > > jinwoong.yoo at gmail.com>
>> > >> > > > > > wrote:
>> > >> > > > > >
>> > >> > > > > > > Hi,
>> > >> > > > > > >
>> > >> > > > > > > I noticed that TRMM data dimension was (lon, lat).
>> > >> > > > > > > So I switched their order to (lat, lon) and ran
the
>> command
>> > >> > again.
>> > >> > > > > > > However, I got the same error message as below.
>> > >> > > > > > >
>> > >> > > > > > > yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/TRMM* $
>> > >> > > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
>> > >> > /scratch/halstead/y/yoo108/
>> > >> > > > > TRMM/
>> > >> > > > > > > trmm_daily.20051231.7.nc
/scratch/halstead/y/yoo108/ND_
>> > >> > > > > > > grided_obs/daily_T2m_maxminmean_1976.nc
>> > >> > > /scratch/halstead/y/yoo108/
>> > >> > > > > TRMM/
>> > >> > > > > > > regrid_trmm_sample.nc -field
'name="precipitation";'
>> > >> > > > > > >
>> > >> > > > > > > DEBUG 1: Reading data file:
>> /scratch/halstead/y/yoo108/TRM
>> > M/
>> > >> > > > > > > trmm_daily.20051231.7.nc
>> > >> > > > > > >
>> > >> > > > > > > ERROR :
>> > >> > > > > > >
>> > >> > > > > > > ERROR : process_data_file() ->
>> > "/scratch/halstead/y/yoo108/TR
>> > >> > MM/
>> > >> > > > > > > trmm_daily.20051231.7.nc" not a valid data file
>> > >> > > > > > >
>> > >> > > > > > >
>> > >> > > > > > > Thank you.
>> > >> > > > > > >
>> > >> > > > > > > Regards,
>> > >> > > > > > >
>> > >> > > > > > >
>> > >> > > > > > > Jinwoong
>> > >> > > > > > >
>> > >> > > > > > >
>> > >> > > > > > >
>> > >> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong Yoo <
>> > >> > > > jinwoong.yoo at gmail.com>
>> > >> > > > > > > wrote:
>> > >> > > > > > >
>> > >> > > > > > >> Hi,
>> > >> > > > > > >>
>> > >> > > > > > >> I got a similar result with a TRMM data.
>> > >> > > > > > >> Please see below:
>> > >> > > > > > >>
>> > >> > > > > > >> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/TRMM*
>> $
>> > >> > > > > > >> ~/met-6.0_bugfix/bin/regrid_data_plane
>> > >> > > /scratch/halstead/y/yoo108/
>> > >> > > > > TRMM/
>> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
>> /scratch/halstead/y/yoo108/ND_
>> > >> > > > > > >> grided_obs/daily_T2m_maxminmean_1976.nc
>> > >> > > /scratch/halstead/y/yoo108/
>> > >> > > > > > TRMM/
>> > >> > > > > > >> regrid_trmm_sample.nc -field
'name="precipitation";'
>> > >> > > > > > >>
>> > >> > > > > > >> DEBUG 1: Reading data file:
>> /scratch/halstead/y/yoo108/TRM
>> > M/
>> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
>> > >> > > > > > >>
>> > >> > > > > > >> ERROR : process_data_file() ->
>> > >> "/scratch/halstead/y/yoo108/TR
>> > >> > MM/
>> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc" not a valid data file
>> > >> > > > > > >>
>> > >> > > > > > >>
>> > >> > > > > > >> A part of ncdump output for the TRMM data is
pasted
>> below:
>> > >> > > > > > >>
>> > >> > > > > > >>
>> > >> > > > > > >> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/TRMM*
>> $
>> > >> ncdump
>> > >> > > -h
>> > >> > > > > > >> subset_200003-
200512/3B42RT_Daily.20051231.7.nc4.nc4
>> > >> > > > > > >>
>> > >> > > > > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
>> > >> > > > > > >>
>> > >> > > > > > >> dimensions:
>> > >> > > > > > >>
>> > >> > > > > > >> lon = 59 ;
>> > >> > > > > > >>
>> > >> > > > > > >> lat = 58 ;
>> > >> > > > > > >>
>> > >> > > > > > >> variables:
>> > >> > > > > > >>
>> > >> > > > > > >> short precipitation_cnt(lon, lat) ;
>> > >> > > > > > >>
>> > >> > > > > > >> precipitation_cnt:units = "count" ;
>> > >> > > > > > >>
>> > >> > > > > > >> precipitation_cnt:long_name = "Count of valid 3-
hr
>> > >> precipitation
>> > >> > > > > > >> retrievals for the day" ;
>> > >> > > > > > >>
>> > >> > > > > > >> precipitation_cnt:coordinates = "lat lon" ;
>> > >> > > > > > >>
>> > >> > > > > > >> precipitation_cnt:origname = "precipitation_cnt"
;
>> > >> > > > > > >>
>> > >> > > > > > >> precipitation_cnt:fullnamepath =
"/precipitation_cnt" ;
>> > >> > > > > > >>
>> > >> > > > > > >> float uncal_precipitation(lon, lat) ;
>> > >> > > > > > >>
>> > >> > > > > > >> uncal_precipitation:units = "mm" ;
>> > >> > > > > > >>
>> > >> > > > > > >> uncal_precipitation:long_name = "Daily
accumulated
>> > >> uncalibrated
>> > >> > > > > > >> precipitation" ;
>> > >> > > > > > >>
>> > >> > > > > > >> uncal_precipitation:coordinates = "lat lon" ;
>> > >> > > > > > >>
>> > >> > > > > > >> uncal_precipitation:_FillValue = -9999.9f ;
>> > >> > > > > > >>
>> > >> > > > > > >> uncal_precipitation:origname =
"uncal_precipitation" ;
>> > >> > > > > > >>
>> > >> > > > > > >> uncal_precipitation:fullnamepath =
>> "/uncal_precipitation"
>> > ;
>> > >> > > > > > >>
>> > >> > > > > > >> short uncal_precipitation_cnt(lon, lat) ;
>> > >> > > > > > >>
>> > >> > > > > > >> uncal_precipitation_cnt:units = "count" ;
>> > >> > > > > > >>
>> > >> > > > > > >> uncal_precipitation_cnt:long_name = "Count of
valid
>> 3-hr
>> > >> uncal
>> > >> > > > > > >> precipitation retrievals for the day" ;
>> > >> > > > > > >>
>> > >> > > > > > >> uncal_precipitation_cnt:coordinates = "lat lon" ;
>> > >> > > > > > >>
>> > >> > > > > > >> uncal_precipitation_cnt:origname =
>> > >> "uncal_precipitation_cnt" ;
>> > >> > > > > > >>
>> > >> > > > > > >> uncal_precipitation_cnt:fullnamepath =
>> > >> > > "/uncal_precipitation_cnt" ;
>> > >> > > > > > >>
>> > >> > > > > > >> float precipitation(lon, lat) ;
>> > >> > > > > > >>
>> > >> > > > > > >> precipitation:units = "mm" ;
>> > >> > > > > > >>
>> > >> > > > > > >> precipitation:long_name = "Daily accumulated
>> precipitation
>> > >> > > (combined
>> > >> > > > > > >> microwave-IR) estimate" ;
>> > >> > > > > > >>
>> > >> > > > > > >> precipitation:coordinates = "lat lon" ;
>> > >> > > > > > >>
>> > >> > > > > > >> precipitation:_FillValue = -9999.9f ;
>> > >> > > > > > >>
>> > >> > > > > > >> precipitation:origname = "precipitation" ;
>> > >> > > > > > >>
>> > >> > > > > > >> precipitation:fullnamepath = "/precipitation" ;
>> > >> > > > > > >>
>> > >> > > > > > >> short randomError_cnt(lon, lat) ;
>> > >> > > > > > >>
>> > >> > > > > > >> randomError_cnt:units = "count" ;
>> > >> > > > > > >>
>> > >> > > > > > >> randomError_cnt:long_name = "Count of randomError
for
>> the
>> > >> day" ;
>> > >> > > > > > >>
>> > >> > > > > > >> randomError_cnt:coordinates = "lat lon" ;
>> > >> > > > > > >>
>> > >> > > > > > >> randomError_cnt:origname = "randomError_cnt" ;
>> > >> > > > > > >>
>> > >> > > > > > >> randomError_cnt:fullnamepath = "/randomError_cnt"
;
>> > >> > > > > > >>
>> > >> > > > > > >> float randomError(lon, lat) ;
>> > >> > > > > > >>
>> > >> > > > > > >> randomError:units = "mm" ;
>> > >> > > > > > >>
>> > >> > > > > > >> randomError:long_name = "Daily total error of
combined
>> > >> > > microwave-IR
>> > >> > > > > > >> precipitation estimate" ;
>> > >> > > > > > >>
>> > >> > > > > > >> randomError:_FillValue = -9999.9f ;
>> > >> > > > > > >>
>> > >> > > > > > >> randomError:origname = "randomError" ;
>> > >> > > > > > >>
>> > >> > > > > > >> randomError:fullnamepath = "/randomError" ;
>> > >> > > > > > >>
>> > >> > > > > > >> float lat(lat) ;
>> > >> > > > > > >>
>> > >> > > > > > >> lat:units = "degrees_north" ;
>> > >> > > > > > >>
>> > >> > > > > > >> lat:long_name = "Latitude" ;
>> > >> > > > > > >>
>> > >> > > > > > >> lat:origname = "lat" ;
>> > >> > > > > > >>
>> > >> > > > > > >> lat:fullnamepath = "/lat" ;
>> > >> > > > > > >>
>> > >> > > > > > >> float lon(lon) ;
>> > >> > > > > > >>
>> > >> > > > > > >> lon:units = "degrees_east" ;
>> > >> > > > > > >>
>> > >> > > > > > >> lon:long_name = "Longitude" ;
>> > >> > > > > > >>
>> > >> > > > > > >> lon:origname = "lon" ;
>> > >> > > > > > >>
>> > >> > > > > > >> lon:fullnamepath = "/lon" ;
>> > >> > > > > > >>
>> > >> > > > > > >>
>> > >> > > > > > >>
>> > >> > > > > > >>
>> > >> > > > > > >> Thank you.
>> > >> > > > > > >>
>> > >> > > > > > >> Regards,
>> > >> > > > > > >>
>> > >> > > > > > >>
>> > >> > > > > > >> Jinwoong
>> > >> > > > > > >>
>> > >> > > > > > >> On Thu, Jun 29, 2017 at 3:11 PM,
met_help at ucar.edu via
>> RT
>> > <
>> > >> > > > > > >> met_help at ucar.edu> wrote:
>> > >> > > > > > >>
>> > >> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED AVAILABILITY
BETWEEN
>> > 5/23/17
>> > >> AND
>> > >> > > > > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
>> > >> > > > > > >>>
>> > >> > > > > > >>> Greetings,
>> > >> > > > > > >>>
>> > >> > > > > > >>> This message has been automatically generated in
>> response
>> > to
>> > >> > the
>> > >> > > > > > >>> creation of a trouble ticket regarding:
>> > >> > > > > > >>> "regrid_data_plane: not a valid data
file",
>> > >> > > > > > >>> a summary of which appears below.
>> > >> > > > > > >>>
>> > >> > > > > > >>> There is no need to reply to this message right
now.
>> Your
>> > >> > ticket
>> > >> > > > has
>> > >> > > > > > >>> been
>> > >> > > > > > >>> assigned an ID of [rt.rap.ucar.edu #81063].
>> > >> > > > > > >>>
>> > >> > > > > > >>> Please include the string:
>> > >> > > > > > >>>
>> > >> > > > > > >>> [rt.rap.ucar.edu #81063]
>> > >> > > > > > >>>
>> > >> > > > > > >>> in the subject line of all future correspondence
about
>> > this
>> > >> > > issue.
>> > >> > > > To
>> > >> > > > > > do
>> > >> > > > > > >>> so,
>> > >> > > > > > >>> you may reply to this message.
>> > >> > > > > > >>>
>> > >> > > > > > >>> Thank you,
>> > >> > > > > > >>> met_help at ucar.edu
>> > >> > > > > > >>>
>> > >> > > > > > >>> ------------------------------
>> > >> ------------------------------
>> > >> > > > > > >>> -------------
>> > >> > > > > > >>> Hi,
>> > >> > > > > > >>>
>> > >> > > > > > >>> I am trying to regrid one of my observation
files in
>> lat
>> > lon
>> > >> > > > > coordinate
>> > >> > > > > > >>> grid to WRF curvilinear grid.
>> > >> > > > > > >>>
>> > >> > > > > > >>> I ran bin/regrid_data_plane using a sample lat
lon grid
>> > file
>> > >> > and
>> > >> > > a
>> > >> > > > > file
>> > >> > > > > > >>> in
>> > >> > > > > > >>> the WRF grid. But I got error as shown below:
>> > >> > > > > > >>>
>> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
>> > /halstead/y/yoo108/ND_grided_
>> > >> > obs*
>> > >> > > $
>> > >> > > > > > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
>> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_grided_obs/
>> sample_tmax.nc
>> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
>> > >> > > > > maxminmean_1976.nc
>> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
>> > >> grided_obs/NDtoWRFgrid_sample_
>> > >> > > > tmax.nc
>> > >> > > > > > >>> -field
>> > >> > > > > > >>> 'name="tmax";'
>> > >> > > > > > >>>
>> > >> > > > > > >>> DEBUG 1: Reading data file:
>> /scratch/halstead/y/yoo108/ND_
>> > >> > > > > grided_obs/
>> > >> > > > > > >>> sample_tmax.nc
>> > >> > > > > > >>>
>> > >> > > > > > >>> ERROR : process_data_file() ->
>> > >> "/scratch/halstead/y/yoo108/ND
>> > >> > > > > > >>> _grided_obs/
>> > >> > > > > > >>> sample_tmax.nc" not a valid data file
>> > >> > > > > > >>>
>> > >> > > > > > >>> I wonder which part of the input file does not
satisfy
>> the
>> > >> > MET's
>> > >> > > > > "valid
>> > >> > > > > > >>> file" criteria.
>> > >> > > > > > >>> ncdump output of the input file looks as below:
>> > >> > > > > > >>> Input file was originally generated by VIC model
and
>> > >> converted
>> > >> > > into
>> > >> > > > > cf
>> > >> > > > > > >>> netcdf format.
>> > >> > > > > > >>>
>> > >> > > > > > >>>
>> > >> > > > > > >>> Thank you in advance.
>> > >> > > > > > >>> Regards,
>> > >> > > > > > >>>
>> > >> > > > > > >>> Jinwoong
>> > >> > > > > > >>>
>> > >> > > > > > >>>
>> > >> > > > > > >>>
>> > >> > > > > > >>>
>> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
>> > /halstead/y/yoo108/ND_grided_
>> > >> > obs*
>> > >> > > $
>> > >> > > > > > >>> ncdump -h
>> > >> > > > > > >>> sample_tmax.nc
>> > >> > > > > > >>>
>> > >> > > > > > >>> netcdf sample_tmax {
>> > >> > > > > > >>>
>> > >> > > > > > >>> dimensions:
>> > >> > > > > > >>>
>> > >> > > > > > >>> T = 1 ;
>> > >> > > > > > >>>
>> > >> > > > > > >>> X = 55 ;
>> > >> > > > > > >>>
>> > >> > > > > > >>> Y = 65 ;
>> > >> > > > > > >>>
>> > >> > > > > > >>>
>> > >> > > > > > >>> variables:
>> > >> > > > > > >>>
>> > >> > > > > > >>> double T(T) ;
>> > >> > > > > > >>>
>> > >> > > > > > >>> T:units = "days since 1915-01-01" ;
>> > >> > > > > > >>>
>> > >> > > > > > >>> T:long_name = "Time" ;
>> > >> > > > > > >>>
>> > >> > > > > > >>>
>> > >> > > > > > >>> double X(X) ;
>> > >> > > > > > >>>
>> > >> > > > > > >>> X:units = "degrees_east" ;
>> > >> > > > > > >>>
>> > >> > > > > > >>> X:long_name = "Longitude" ;
>> > >> > > > > > >>>
>> > >> > > > > > >>>
>> > >> > > > > > >>> double Y(Y) ;
>> > >> > > > > > >>>
>> > >> > > > > > >>> Y:units = "degrees_north" ;
>> > >> > > > > > >>>
>> > >> > > > > > >>> Y:long_name = "Latitude" ;
>> > >> > > > > > >>>
>> > >> > > > > > >>>
>> > >> > > > > > >>> double tmax(T, Y, X) ;
>> > >> > > > > > >>>
>> > >> > > > > > >>> tmax:units = "degC" ;
>> > >> > > > > > >>>
>> > >> > > > > > >>> tmax:long_name = "tmax calculated by VIC" ;
>> > >> > > > > > >>>
>> > >> > > > > > >>> tmax:missing_value = -9999.f ;
>> > >> > > > > > >>>
>> > >> > > > > > >>> // global attributes:
>> > >> > > > > > >>>
>> > >> > > > > > >>> :production = "VIC output" ;
>> > >> > > > > > >>>
>> > >> > > > > > >>>
>> > >> > > > > > >>
>> > >> > > > > > >
>> > >> > > > > >
>> > >> > > > > >
>> > >> > > > >
>> > >> > > > >
>> > >> > > >
>> > >> > > >
>> > >> > >
>> > >> > >
>> > >> >
>> > >> >
>> > >>
>> > >>
>> > >
>> >
>> >
>>
>>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: John Halley Gotway
Time: Fri Jul 07 16:04:28 2017
Jinwoong,
If they really are output from WRF, one simple thing to try is telling
MET
to interpret them as the NetCDF output of the wrf_interp utility
:
file_type = NETCDF_PINT;
"PINT" stands for "pressure interpolated"... pinterp was the precursor
to
the current wrf_interp tool.
If that doesn't work, I'll need to see a sample file before making any
other suggestions.
Thanks,
John
On Fri, Jul 7, 2017 at 3:36 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>
> Hi John,
>
> I was able to read in a "home brew" netcdf data file using
plot_data_plane.
>
> Then, I went ahead and tried another netcdf file in curvilinear
coordinate
> which is in the same coordinate grid as my WRF output. But it
failed.
>
> I have many netcdf climatology files from the WRF simulation such as
daily,
> monthly, and annual, etc. Therefore, they are all in curvilinear
coordinate
> (Lambert).
>
> I wonder if there is any work around so that I can feed these files
into
> MET?
> Or should I regrid them all into lat lon coordinate files first?
>
> Thank you, John.
>
> Regards,
>
> Jinwoong Yoo
>
>
> On Fri, Jul 7, 2017 at 3:01 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> wrote:
>
> > Hi John,
> >
> > Thank you very much.
> > Let me try and let you know how it goes.
> > Thank you.
> > Regards,
> >
> > Jinwoong
> >
> > On Fri, Jul 7, 2017 at 2:59 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Jinwoong,
> >>
> >> Yes, you can give it a try. The closer you can make the NetCDF
files to
> >> the CF-convention, the more likely MET will be able to read it.
> >>
> >> The reason that's its able to read the TRMM data are that the
lat/lon
> >> values are equally spaced. Non-equally spaced lat/lon values on
a map
> >> projection require that the map projection information be
specified.
> >> Unfortunately, specifying map projection information in CF-
compliant
> >> NetCDF
> >> files is not as easy as I think it should be!
> >>
> >> Hope it works out ok for you.
> >>
> >> Thanks,
> >> John
> >>
> >> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo via RT
<met_help at ucar.edu
> >
> >> wrote:
> >>
> >> >
> >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >> >
> >> > investigating not investing :)
> >> >
> >> > Thanks!
> >> > Regards,
> >> >
> >> > Jinwoong
> >> >
> >> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> >> > wrote:
> >> >
> >> > > Hi John,
> >> > >
> >> > > Thank you very much for your time investing the issue.
> >> > > I am glad to hear that there is a trick to work around the
issue to
> >> read
> >> > > in TRMM data in netcdf format.
> >> > > I wonder if I can apply the same trick (
file_type=NETCDF_NCCF;) to
> >> read
> >> > > in any other observation files in netcdf format?
> >> > > In fact, I would like to read in "home brew" netcdf dataset
files
> into
> >> > > MET.
> >> > > One sample file of them was included in the uploaded data
folder (
> >> > > sample_tmax.nc).
> >> > > The data in this sample file was originally generated by VIC
model.
> >> > > Then the file format was converted into a generic netcdf file
format
> >> > > although the dimension names are T, X, Y not time, lat, lon.
> >> > > But their coordinates have units in "degrees_east" or
> "degrees_north"
> >> as
> >> > > well as their long_name as "Longitude" and "Latitude",
respectively.
> >> > >
> >> > > Of course, I will try to read those in for Grid-stat today.
> >> > > But I would like to hear from you if the trick (
> >> file_type=NETCDF_NCCF;)
> >> > > can be applied generally, which I wish very much.
> >> > >
> >> > > Thank you so much, John.
> >> > >
> >> > > Regards,
> >> > >
> >> > > Jinwoong Yoo
> >> > >
> >> > >
> >> > > On Fri, Jul 7, 2017 at 1:16 PM, John Halley Gotway via RT <
> >> > > met_help at ucar.edu> wrote:
> >> > >
> >> > >> Jinwoong,
> >> > >>
> >> > >> Thanks for sending your sample data and for your patience
while I
> was
> >> > out
> >> > >> of town.
> >> > >>
> >> > >> Using met-6.0, I'm able to process the TRMM NetCDF file you
sent.
> >> The
> >> > >> trick is that I had to tell it which NetCDF file type should
be
> used
> >> to
> >> > >> interpret the data. Using "file_type = NETCDF_NCCF;" I'm
telling
> >> MET to
> >> > >> interpret it as if it were a CF-compliant NetCDF file:
> >> > >>
> >> > >> met-6.0/bin/plot_data_plane \
> >> > >> trmm_daily.20051231.7.nc trmm_daily.20051231.7.ps \
> >> > >> 'name="precipitation"; level="(*,*)";
file_type=NETCDF_NCCF;'
> >> > >>
> >> > >> DEBUG 1: Opening data file: trmm_daily.20051231.7.nc
> >> > >> WARNING: NcCfFile::open() -> could not determine the valid
time,
> >> using
> >> > 0.
> >> > >> WARNING: NcCfFile::open() -> could not determine the valid
time,
> >> using
> >> > 0.
> >> > >> DEBUG 1: Creating postscript file: trmm_daily.20051231.7.ps
> >> > >>
> >> > >> The plot_data_plane tool is able to read the data, and I've
> attached
> >> the
> >> > >> resulting image. However, notice the warning messages about
the
> >> valid
> >> > >> time.
> >> > >>
> >> > >> Using ncdump to see that file attributes, I see this timing
> >> information:
> >> > >> :HDF5_GLOBAL.BeginDate = "2005-12-31" ;
> >> > >> :HDF5_GLOBAL.BeginTime = "01:30:00.000Z" ;
> >> > >> :HDF5_GLOBAL.EndDate = "2006-01-01" ;
> >> > >> :HDF5_GLOBAL.EndTime = "01:29:59.999Z" ;
> >> > >>
> >> > >> However that is not the CF-compliant way of specifying
timing info.
> >> So
> >> > >> while MET will be able to read the data, the timing info
won't be
> >> > accurate
> >> > >> in the MET output files. Instead, you'll see "19700101"
which is
> >> > unixtime
> >> > >> = 0.
> >> > >>
> >> > >> Another option would be pulling the binary TRMM data and
using this
> >> > >> Rscript
> >> > >> to convert the binary to NetCDF:
> >> > >> http://www.dtcenter.org/met/users/downloads/Rscripts/
> trmmbin2nc.R
> >> > >>
> >> > >> However, I haven't done this in a while and am not sure if
you'll
> run
> >> > into
> >> > >> any issues.
> >> > >>
> >> > >> Hope that helps.
> >> > >>
> >> > >> Thanks,
> >> > >> John
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo via RT <
> >> met_help at ucar.edu>
> >> > >> wrote:
> >> > >>
> >> > >> >
> >> > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >> > >> >
> >> > >> > Hi John,
> >> > >> >
> >> > >> > Thank you very much.
> >> > >> > Regards,
> >> > >> >
> >> > >> > Jinwoong
> >> > >> >
> >> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John Halley Gotway via RT
<
> >> > >> > met_help at ucar.edu> wrote:
> >> > >> >
> >> > >> > > Jinwoong,
> >> > >> > >
> >> > >> > > I'm out of the office today but will take a closer look
> tomorrow.
> >> > >> > >
> >> > >> > > Thanks
> >> > >> > > John
> >> > >> > >
> >> > >> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo via RT <
> >> > >> met_help at ucar.edu>
> >> > >> > > wrote:
> >> > >> > >
> >> > >> > > >
> >> > >> > > > <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=81063
> >> >
> >> > >> > > >
> >> > >> > > > Hi John,
> >> > >> > > >
> >> > >> > > > Thank you for your reply.
> >> > >> > > > I uploaded my data as in Yoo_data4.tar on the ftp
site.
> >> > >> > > > I included several files for the message of ID of [
> >> > rt.rap.ucar.edu
> >> > >> > > #81074]
> >> > >> > > > as well.
> >> > >> > > > Thank you.
> >> > >> > > > Regards,
> >> > >> > > >
> >> > >> > > > Jinwoong
> >> > >> > > >
> >> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM, John Halley Gotway
via RT <
> >> > >> > > > met_help at ucar.edu> wrote:
> >> > >> > > >
> >> > >> > > > > Jinwoong,
> >> > >> > > > >
> >> > >> > > > > I see that you're having trouble reading a TRMM
NetCDF file
> >> into
> >> > >> MET.
> >> > >> > > > Can
> >> > >> > > > > you please post the problematic file to our
anonymous ftp
> >> site
> >> > so
> >> > >> I
> >> > >> > can
> >> > >> > > > > take a look?
> >> > >> > > > >
> >> > >> > > > >
http://www.dtcenter.org/met/users/support/met_help.php#ftp
> >> > >> > > > >
> >> > >> > > > > Thanks,
> >> > >> > > > > John Halley Gotway
> >> > >> > > > >
> >> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo via RT
<
> >> > >> > met_help at ucar.edu
> >> > >> > > >
> >> > >> > > > > wrote:
> >> > >> > > > >
> >> > >> > > > > >
> >> > >> > > > > > <URL: https://rt.rap.ucar.edu/rt/Tic
> >> ket/Display.html?id=81063
> >> > >
> >> > >> > > > > >
> >> > >> > > > > > Hi,
> >> > >> > > > > >
> >> > >> > > > > > TRMM data comes in as netCDF-4 classic model.
> >> > >> > > > > > I changed it to netCDF classic and run the same
command
> >> for a
> >> > >> test.
> >> > >> > > > > > But I got the same error as below.
> >> > >> > > > > >
> >> > >> > > > > > yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/TRMM* $
> >> > >> > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> >> > >> /scratch/halstead/y/yoo108/
> >> > >> > > TRMM/
> >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> >> > >> > > > > >
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> >> > >> > > maxminmean_1976.nc
> >> > >> > > > > >
/scratch/halstead/y/yoo108/TRMM/regrid_trmm_sample.nc
> >> -field
> >> > >> > > > > > 'name="precipitation";'
> >> > >> > > > > >
> >> > >> > > > > > DEBUG 1: Reading data file:
> /scratch/halstead/y/yoo108/TRM
> >> M/
> >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> >> > >> > > > > >
> >> > >> > > > > > ERROR :
> >> > >> > > > > >
> >> > >> > > > > > ERROR : process_data_file() ->
> >> "/scratch/halstead/y/yoo108/TR
> >> > >> MM/
> >> > >> > > > > > trmm_daily_nc3.20051231.7.nc" not a valid data
file
> >> > >> > > > > >
> >> > >> > > > > > Thank you.
> >> > >> > > > > >
> >> > >> > > > > > Regards,
> >> > >> > > > > >
> >> > >> > > > > >
> >> > >> > > > > > Jinwoong
> >> > >> > > > > >
> >> > >> > > > > > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong Yoo <
> >> > >> > > jinwoong.yoo at gmail.com>
> >> > >> > > > > > wrote:
> >> > >> > > > > >
> >> > >> > > > > > > Hi,
> >> > >> > > > > > >
> >> > >> > > > > > > I noticed that TRMM data dimension was (lon,
lat).
> >> > >> > > > > > > So I switched their order to (lat, lon) and ran
the
> >> command
> >> > >> > again.
> >> > >> > > > > > > However, I got the same error message as below.
> >> > >> > > > > > >
> >> > >> > > > > > > yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/TRMM*
> $
> >> > >> > > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> >> > >> > /scratch/halstead/y/yoo108/
> >> > >> > > > > TRMM/
> >> > >> > > > > > > trmm_daily.20051231.7.nc
> /scratch/halstead/y/yoo108/ND_
> >> > >> > > > > > > grided_obs/daily_T2m_maxminmean_1976.nc
> >> > >> > > /scratch/halstead/y/yoo108/
> >> > >> > > > > TRMM/
> >> > >> > > > > > > regrid_trmm_sample.nc -field
'name="precipitation";'
> >> > >> > > > > > >
> >> > >> > > > > > > DEBUG 1: Reading data file:
> >> /scratch/halstead/y/yoo108/TRM
> >> > M/
> >> > >> > > > > > > trmm_daily.20051231.7.nc
> >> > >> > > > > > >
> >> > >> > > > > > > ERROR :
> >> > >> > > > > > >
> >> > >> > > > > > > ERROR : process_data_file() ->
> >> > "/scratch/halstead/y/yoo108/TR
> >> > >> > MM/
> >> > >> > > > > > > trmm_daily.20051231.7.nc" not a valid data file
> >> > >> > > > > > >
> >> > >> > > > > > >
> >> > >> > > > > > > Thank you.
> >> > >> > > > > > >
> >> > >> > > > > > > Regards,
> >> > >> > > > > > >
> >> > >> > > > > > >
> >> > >> > > > > > > Jinwoong
> >> > >> > > > > > >
> >> > >> > > > > > >
> >> > >> > > > > > >
> >> > >> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong Yoo <
> >> > >> > > > jinwoong.yoo at gmail.com>
> >> > >> > > > > > > wrote:
> >> > >> > > > > > >
> >> > >> > > > > > >> Hi,
> >> > >> > > > > > >>
> >> > >> > > > > > >> I got a similar result with a TRMM data.
> >> > >> > > > > > >> Please see below:
> >> > >> > > > > > >>
> >> > >> > > > > > >> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/
> TRMM*
> >> $
> >> > >> > > > > > >> ~/met-6.0_bugfix/bin/regrid_data_plane
> >> > >> > > /scratch/halstead/y/yoo108/
> >> > >> > > > > TRMM/
> >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> >> /scratch/halstead/y/yoo108/ND_
> >> > >> > > > > > >> grided_obs/daily_T2m_maxminmean_1976.nc
> >> > >> > > /scratch/halstead/y/yoo108/
> >> > >> > > > > > TRMM/
> >> > >> > > > > > >> regrid_trmm_sample.nc -field
'name="precipitation";'
> >> > >> > > > > > >>
> >> > >> > > > > > >> DEBUG 1: Reading data file:
> >> /scratch/halstead/y/yoo108/TRM
> >> > M/
> >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> >> > >> > > > > > >>
> >> > >> > > > > > >> ERROR : process_data_file() ->
> >> > >> "/scratch/halstead/y/yoo108/TR
> >> > >> > MM/
> >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc" not a valid data
file
> >> > >> > > > > > >>
> >> > >> > > > > > >>
> >> > >> > > > > > >> A part of ncdump output for the TRMM data is
pasted
> >> below:
> >> > >> > > > > > >>
> >> > >> > > > > > >>
> >> > >> > > > > > >> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/
> TRMM*
> >> $
> >> > >> ncdump
> >> > >> > > -h
> >> > >> > > > > > >> subset_200003-
200512/3B42RT_Daily.20051231.7.nc4.nc4
> >> > >> > > > > > >>
> >> > >> > > > > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
> >> > >> > > > > > >>
> >> > >> > > > > > >> dimensions:
> >> > >> > > > > > >>
> >> > >> > > > > > >> lon = 59 ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> lat = 58 ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> variables:
> >> > >> > > > > > >>
> >> > >> > > > > > >> short precipitation_cnt(lon, lat) ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> precipitation_cnt:units = "count" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> precipitation_cnt:long_name = "Count of valid
3-hr
> >> > >> precipitation
> >> > >> > > > > > >> retrievals for the day" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> precipitation_cnt:coordinates = "lat lon" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> precipitation_cnt:origname =
"precipitation_cnt" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> precipitation_cnt:fullnamepath =
"/precipitation_cnt"
> ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> float uncal_precipitation(lon, lat) ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> uncal_precipitation:units = "mm" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> uncal_precipitation:long_name = "Daily
accumulated
> >> > >> uncalibrated
> >> > >> > > > > > >> precipitation" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> uncal_precipitation:coordinates = "lat lon" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> uncal_precipitation:_FillValue = -9999.9f ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> uncal_precipitation:origname =
"uncal_precipitation" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> uncal_precipitation:fullnamepath =
> >> "/uncal_precipitation"
> >> > ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> short uncal_precipitation_cnt(lon, lat) ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> uncal_precipitation_cnt:units = "count" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> uncal_precipitation_cnt:long_name = "Count of
valid
> >> 3-hr
> >> > >> uncal
> >> > >> > > > > > >> precipitation retrievals for the day" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> uncal_precipitation_cnt:coordinates = "lat lon"
;
> >> > >> > > > > > >>
> >> > >> > > > > > >> uncal_precipitation_cnt:origname =
> >> > >> "uncal_precipitation_cnt" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> uncal_precipitation_cnt:fullnamepath =
> >> > >> > > "/uncal_precipitation_cnt" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> float precipitation(lon, lat) ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> precipitation:units = "mm" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> precipitation:long_name = "Daily accumulated
> >> precipitation
> >> > >> > > (combined
> >> > >> > > > > > >> microwave-IR) estimate" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> precipitation:coordinates = "lat lon" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> precipitation:_FillValue = -9999.9f ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> precipitation:origname = "precipitation" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> precipitation:fullnamepath = "/precipitation" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> short randomError_cnt(lon, lat) ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> randomError_cnt:units = "count" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> randomError_cnt:long_name = "Count of
randomError for
> >> the
> >> > >> day" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> randomError_cnt:coordinates = "lat lon" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> randomError_cnt:origname = "randomError_cnt" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> randomError_cnt:fullnamepath =
"/randomError_cnt" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> float randomError(lon, lat) ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> randomError:units = "mm" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> randomError:long_name = "Daily total error of
combined
> >> > >> > > microwave-IR
> >> > >> > > > > > >> precipitation estimate" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> randomError:_FillValue = -9999.9f ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> randomError:origname = "randomError" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> randomError:fullnamepath = "/randomError" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> float lat(lat) ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> lat:units = "degrees_north" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> lat:long_name = "Latitude" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> lat:origname = "lat" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> lat:fullnamepath = "/lat" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> float lon(lon) ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> lon:units = "degrees_east" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> lon:long_name = "Longitude" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> lon:origname = "lon" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >> lon:fullnamepath = "/lon" ;
> >> > >> > > > > > >>
> >> > >> > > > > > >>
> >> > >> > > > > > >>
> >> > >> > > > > > >>
> >> > >> > > > > > >> Thank you.
> >> > >> > > > > > >>
> >> > >> > > > > > >> Regards,
> >> > >> > > > > > >>
> >> > >> > > > > > >>
> >> > >> > > > > > >> Jinwoong
> >> > >> > > > > > >>
> >> > >> > > > > > >> On Thu, Jun 29, 2017 at 3:11 PM,
met_help at ucar.edu
> via
> >> RT
> >> > <
> >> > >> > > > > > >> met_help at ucar.edu> wrote:
> >> > >> > > > > > >>
> >> > >> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED AVAILABILITY
BETWEEN
> >> > 5/23/17
> >> > >> AND
> >> > >> > > > > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> Greetings,
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> This message has been automatically generated
in
> >> response
> >> > to
> >> > >> > the
> >> > >> > > > > > >>> creation of a trouble ticket regarding:
> >> > >> > > > > > >>> "regrid_data_plane: not a valid data
file",
> >> > >> > > > > > >>> a summary of which appears below.
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> There is no need to reply to this message
right now.
> >> Your
> >> > >> > ticket
> >> > >> > > > has
> >> > >> > > > > > >>> been
> >> > >> > > > > > >>> assigned an ID of [rt.rap.ucar.edu #81063].
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> Please include the string:
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> [rt.rap.ucar.edu #81063]
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> in the subject line of all future
correspondence
> about
> >> > this
> >> > >> > > issue.
> >> > >> > > > To
> >> > >> > > > > > do
> >> > >> > > > > > >>> so,
> >> > >> > > > > > >>> you may reply to this message.
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> Thank you,
> >> > >> > > > > > >>> met_help at ucar.edu
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> ------------------------------
> >> > >> ------------------------------
> >> > >> > > > > > >>> -------------
> >> > >> > > > > > >>> Hi,
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> I am trying to regrid one of my observation
files in
> >> lat
> >> > lon
> >> > >> > > > > coordinate
> >> > >> > > > > > >>> grid to WRF curvilinear grid.
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> I ran bin/regrid_data_plane using a sample lat
lon
> grid
> >> > file
> >> > >> > and
> >> > >> > > a
> >> > >> > > > > file
> >> > >> > > > > > >>> in
> >> > >> > > > > > >>> the WRF grid. But I got error as shown below:
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> >> > /halstead/y/yoo108/ND_grided_
> >> > >> > obs*
> >> > >> > > $
> >> > >> > > > > > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
> >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_grided_obs/
> >> sample_tmax.nc
> >> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> >> > >> > > > > maxminmean_1976.nc
> >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> >> > >> grided_obs/NDtoWRFgrid_sample_
> >> > >> > > > tmax.nc
> >> > >> > > > > > >>> -field
> >> > >> > > > > > >>> 'name="tmax";'
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> DEBUG 1: Reading data file:
> >> /scratch/halstead/y/yoo108/ND_
> >> > >> > > > > grided_obs/
> >> > >> > > > > > >>> sample_tmax.nc
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> ERROR : process_data_file() ->
> >> > >> "/scratch/halstead/y/yoo108/ND
> >> > >> > > > > > >>> _grided_obs/
> >> > >> > > > > > >>> sample_tmax.nc" not a valid data file
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> I wonder which part of the input file does not
> satisfy
> >> the
> >> > >> > MET's
> >> > >> > > > > "valid
> >> > >> > > > > > >>> file" criteria.
> >> > >> > > > > > >>> ncdump output of the input file looks as
below:
> >> > >> > > > > > >>> Input file was originally generated by VIC
model and
> >> > >> converted
> >> > >> > > into
> >> > >> > > > > cf
> >> > >> > > > > > >>> netcdf format.
> >> > >> > > > > > >>>
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> Thank you in advance.
> >> > >> > > > > > >>> Regards,
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> Jinwoong
> >> > >> > > > > > >>>
> >> > >> > > > > > >>>
> >> > >> > > > > > >>>
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> >> > /halstead/y/yoo108/ND_grided_
> >> > >> > obs*
> >> > >> > > $
> >> > >> > > > > > >>> ncdump -h
> >> > >> > > > > > >>> sample_tmax.nc
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> netcdf sample_tmax {
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> dimensions:
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> T = 1 ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> X = 55 ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> Y = 65 ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> variables:
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> double T(T) ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> T:units = "days since 1915-01-01" ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> T:long_name = "Time" ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> double X(X) ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> X:units = "degrees_east" ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> X:long_name = "Longitude" ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> double Y(Y) ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> Y:units = "degrees_north" ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> Y:long_name = "Latitude" ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> double tmax(T, Y, X) ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> tmax:units = "degC" ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> tmax:long_name = "tmax calculated by VIC" ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> tmax:missing_value = -9999.f ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> // global attributes:
> >> > >> > > > > > >>>
> >> > >> > > > > > >>> :production = "VIC output" ;
> >> > >> > > > > > >>>
> >> > >> > > > > > >>>
> >> > >> > > > > > >>
> >> > >> > > > > > >
> >> > >> > > > > >
> >> > >> > > > > >
> >> > >> > > > >
> >> > >> > > > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > >
> >> > >> > >
> >> > >> >
> >> > >> >
> >> > >>
> >> > >>
> >> > >
> >> >
> >> >
> >>
> >>
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Fri Jul 07 17:06:28 2017
Hi John,
Thank you for your comment.
I tried it but it failed.
Please see below.
yoo108 at halstead-fe03:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal*
$
~/met-6.0_bugfix/bin/plot_data_plane
/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_maxminmean_20051231.nc
wrfDaily_T2m_maxminmean_20051231.ps
'name="T2m_max";level="(0,*,*)";file_type = NETCDF_PINT;'
DEBUG 1: Opening data file:
/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_maxminmean_20051231.nc
ERROR : MetNcPinterpDataFile::open(const char *) -> unable to open
NetCDF
file
"/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_maxminmean_20051231.nc"
ERROR : Met2dDataFileFactory::new_met_2d_data_file() -> error opening
file
"/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_maxminmean_20051231.nc"
One sample file (wrfDaily_T2m_maxminmean_19810101.nc) is also included
in
the Yoo_data4.tar file that I uploaded previously.
Thank you.
Haver a nice weekend.
Regards,
Jinwoong
On Fri, Jul 7, 2017 at 6:04 PM, John Halley Gotway via RT
<met_help at ucar.edu
> wrote:
> Jinwoong,
>
> If they really are output from WRF, one simple thing to try is
telling MET
> to interpret them as the NetCDF output of the wrf_interp utility
> :
> file_type = NETCDF_PINT;
>
> "PINT" stands for "pressure interpolated"... pinterp was the
precursor to
> the current wrf_interp tool.
>
> If that doesn't work, I'll need to see a sample file before making
any
> other suggestions.
>
> Thanks,
> John
>
>
>
> On Fri, Jul 7, 2017 at 3:36 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >
> > Hi John,
> >
> > I was able to read in a "home brew" netcdf data file using
> plot_data_plane.
> >
> > Then, I went ahead and tried another netcdf file in curvilinear
> coordinate
> > which is in the same coordinate grid as my WRF output. But it
failed.
> >
> > I have many netcdf climatology files from the WRF simulation such
as
> daily,
> > monthly, and annual, etc. Therefore, they are all in curvilinear
> coordinate
> > (Lambert).
> >
> > I wonder if there is any work around so that I can feed these
files into
> > MET?
> > Or should I regrid them all into lat lon coordinate files first?
> >
> > Thank you, John.
> >
> > Regards,
> >
> > Jinwoong Yoo
> >
> >
> > On Fri, Jul 7, 2017 at 3:01 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > wrote:
> >
> > > Hi John,
> > >
> > > Thank you very much.
> > > Let me try and let you know how it goes.
> > > Thank you.
> > > Regards,
> > >
> > > Jinwoong
> > >
> > > On Fri, Jul 7, 2017 at 2:59 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >> Jinwoong,
> > >>
> > >> Yes, you can give it a try. The closer you can make the NetCDF
files
> to
> > >> the CF-convention, the more likely MET will be able to read it.
> > >>
> > >> The reason that's its able to read the TRMM data are that the
lat/lon
> > >> values are equally spaced. Non-equally spaced lat/lon values
on a map
> > >> projection require that the map projection information be
specified.
> > >> Unfortunately, specifying map projection information in CF-
compliant
> > >> NetCDF
> > >> files is not as easy as I think it should be!
> > >>
> > >> Hope it works out ok for you.
> > >>
> > >> Thanks,
> > >> John
> > >>
> > >> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo via RT <
> met_help at ucar.edu
> > >
> > >> wrote:
> > >>
> > >> >
> > >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
> > >> >
> > >> > investigating not investing :)
> > >> >
> > >> > Thanks!
> > >> > Regards,
> > >> >
> > >> > Jinwoong
> > >> >
> > >> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo <
> jinwoong.yoo at gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Hi John,
> > >> > >
> > >> > > Thank you very much for your time investing the issue.
> > >> > > I am glad to hear that there is a trick to work around the
issue
> to
> > >> read
> > >> > > in TRMM data in netcdf format.
> > >> > > I wonder if I can apply the same trick (
file_type=NETCDF_NCCF;)
> to
> > >> read
> > >> > > in any other observation files in netcdf format?
> > >> > > In fact, I would like to read in "home brew" netcdf dataset
files
> > into
> > >> > > MET.
> > >> > > One sample file of them was included in the uploaded data
folder (
> > >> > > sample_tmax.nc).
> > >> > > The data in this sample file was originally generated by
VIC
> model.
> > >> > > Then the file format was converted into a generic netcdf
file
> format
> > >> > > although the dimension names are T, X, Y not time, lat,
lon.
> > >> > > But their coordinates have units in "degrees_east" or
> > "degrees_north"
> > >> as
> > >> > > well as their long_name as "Longitude" and "Latitude",
> respectively.
> > >> > >
> > >> > > Of course, I will try to read those in for Grid-stat today.
> > >> > > But I would like to hear from you if the trick (
> > >> file_type=NETCDF_NCCF;)
> > >> > > can be applied generally, which I wish very much.
> > >> > >
> > >> > > Thank you so much, John.
> > >> > >
> > >> > > Regards,
> > >> > >
> > >> > > Jinwoong Yoo
> > >> > >
> > >> > >
> > >> > > On Fri, Jul 7, 2017 at 1:16 PM, John Halley Gotway via RT <
> > >> > > met_help at ucar.edu> wrote:
> > >> > >
> > >> > >> Jinwoong,
> > >> > >>
> > >> > >> Thanks for sending your sample data and for your patience
while I
> > was
> > >> > out
> > >> > >> of town.
> > >> > >>
> > >> > >> Using met-6.0, I'm able to process the TRMM NetCDF file
you sent.
> > >> The
> > >> > >> trick is that I had to tell it which NetCDF file type
should be
> > used
> > >> to
> > >> > >> interpret the data. Using "file_type = NETCDF_NCCF;" I'm
telling
> > >> MET to
> > >> > >> interpret it as if it were a CF-compliant NetCDF file:
> > >> > >>
> > >> > >> met-6.0/bin/plot_data_plane \
> > >> > >> trmm_daily.20051231.7.nc trmm_daily.20051231.7.ps \
> > >> > >> 'name="precipitation"; level="(*,*)";
file_type=NETCDF_NCCF;'
> > >> > >>
> > >> > >> DEBUG 1: Opening data file: trmm_daily.20051231.7.nc
> > >> > >> WARNING: NcCfFile::open() -> could not determine the valid
time,
> > >> using
> > >> > 0.
> > >> > >> WARNING: NcCfFile::open() -> could not determine the valid
time,
> > >> using
> > >> > 0.
> > >> > >> DEBUG 1: Creating postscript file:
trmm_daily.20051231.7.ps
> > >> > >>
> > >> > >> The plot_data_plane tool is able to read the data, and
I've
> > attached
> > >> the
> > >> > >> resulting image. However, notice the warning messages
about the
> > >> valid
> > >> > >> time.
> > >> > >>
> > >> > >> Using ncdump to see that file attributes, I see this
timing
> > >> information:
> > >> > >> :HDF5_GLOBAL.BeginDate = "2005-12-31" ;
> > >> > >> :HDF5_GLOBAL.BeginTime = "01:30:00.000Z" ;
> > >> > >> :HDF5_GLOBAL.EndDate = "2006-01-01" ;
> > >> > >> :HDF5_GLOBAL.EndTime = "01:29:59.999Z" ;
> > >> > >>
> > >> > >> However that is not the CF-compliant way of specifying
timing
> info.
> > >> So
> > >> > >> while MET will be able to read the data, the timing info
won't be
> > >> > accurate
> > >> > >> in the MET output files. Instead, you'll see "19700101"
which is
> > >> > unixtime
> > >> > >> = 0.
> > >> > >>
> > >> > >> Another option would be pulling the binary TRMM data and
using
> this
> > >> > >> Rscript
> > >> > >> to convert the binary to NetCDF:
> > >> > >> http://www.dtcenter.org/met/users/downloads/Rscripts/
> > trmmbin2nc.R
> > >> > >>
> > >> > >> However, I haven't done this in a while and am not sure if
you'll
> > run
> > >> > into
> > >> > >> any issues.
> > >> > >>
> > >> > >> Hope that helps.
> > >> > >>
> > >> > >> Thanks,
> > >> > >> John
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo via RT <
> > >> met_help at ucar.edu>
> > >> > >> wrote:
> > >> > >>
> > >> > >> >
> > >> > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
> >
> > >> > >> >
> > >> > >> > Hi John,
> > >> > >> >
> > >> > >> > Thank you very much.
> > >> > >> > Regards,
> > >> > >> >
> > >> > >> > Jinwoong
> > >> > >> >
> > >> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John Halley Gotway via
RT <
> > >> > >> > met_help at ucar.edu> wrote:
> > >> > >> >
> > >> > >> > > Jinwoong,
> > >> > >> > >
> > >> > >> > > I'm out of the office today but will take a closer
look
> > tomorrow.
> > >> > >> > >
> > >> > >> > > Thanks
> > >> > >> > > John
> > >> > >> > >
> > >> > >> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo via RT <
> > >> > >> met_help at ucar.edu>
> > >> > >> > > wrote:
> > >> > >> > >
> > >> > >> > > >
> > >> > >> > > > <URL: https://rt.rap.ucar.edu/rt/
> > Ticket/Display.html?id=81063
> > >> >
> > >> > >> > > >
> > >> > >> > > > Hi John,
> > >> > >> > > >
> > >> > >> > > > Thank you for your reply.
> > >> > >> > > > I uploaded my data as in Yoo_data4.tar on the ftp
site.
> > >> > >> > > > I included several files for the message of ID of [
> > >> > rt.rap.ucar.edu
> > >> > >> > > #81074]
> > >> > >> > > > as well.
> > >> > >> > > > Thank you.
> > >> > >> > > > Regards,
> > >> > >> > > >
> > >> > >> > > > Jinwoong
> > >> > >> > > >
> > >> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM, John Halley Gotway
via RT
> <
> > >> > >> > > > met_help at ucar.edu> wrote:
> > >> > >> > > >
> > >> > >> > > > > Jinwoong,
> > >> > >> > > > >
> > >> > >> > > > > I see that you're having trouble reading a TRMM
NetCDF
> file
> > >> into
> > >> > >> MET.
> > >> > >> > > > Can
> > >> > >> > > > > you please post the problematic file to our
anonymous ftp
> > >> site
> > >> > so
> > >> > >> I
> > >> > >> > can
> > >> > >> > > > > take a look?
> > >> > >> > > > >
> > >> > >> > > > > http://www.dtcenter.org/met/
> users/support/met_help.php#ftp
> > >> > >> > > > >
> > >> > >> > > > > Thanks,
> > >> > >> > > > > John Halley Gotway
> > >> > >> > > > >
> > >> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo via
RT <
> > >> > >> > met_help at ucar.edu
> > >> > >> > > >
> > >> > >> > > > > wrote:
> > >> > >> > > > >
> > >> > >> > > > > >
> > >> > >> > > > > > <URL: https://rt.rap.ucar.edu/rt/Tic
> > >> ket/Display.html?id=81063
> > >> > >
> > >> > >> > > > > >
> > >> > >> > > > > > Hi,
> > >> > >> > > > > >
> > >> > >> > > > > > TRMM data comes in as netCDF-4 classic model.
> > >> > >> > > > > > I changed it to netCDF classic and run the same
command
> > >> for a
> > >> > >> test.
> > >> > >> > > > > > But I got the same error as below.
> > >> > >> > > > > >
> > >> > >> > > > > > yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/TRMM*
> $
> > >> > >> > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> > >> > >> /scratch/halstead/y/yoo108/
> > >> > >> > > TRMM/
> > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > >> > >> > > > > >
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> > >> > >> > > maxminmean_1976.nc
> > >> > >> > > > > >
/scratch/halstead/y/yoo108/TRMM/regrid_trmm_sample.nc
> > >> -field
> > >> > >> > > > > > 'name="precipitation";'
> > >> > >> > > > > >
> > >> > >> > > > > > DEBUG 1: Reading data file:
> > /scratch/halstead/y/yoo108/TRM
> > >> M/
> > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > >> > >> > > > > >
> > >> > >> > > > > > ERROR :
> > >> > >> > > > > >
> > >> > >> > > > > > ERROR : process_data_file() ->
> > >> "/scratch/halstead/y/yoo108/TR
> > >> > >> MM/
> > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc" not a valid data
file
> > >> > >> > > > > >
> > >> > >> > > > > > Thank you.
> > >> > >> > > > > >
> > >> > >> > > > > > Regards,
> > >> > >> > > > > >
> > >> > >> > > > > >
> > >> > >> > > > > > Jinwoong
> > >> > >> > > > > >
> > >> > >> > > > > > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong Yoo <
> > >> > >> > > jinwoong.yoo at gmail.com>
> > >> > >> > > > > > wrote:
> > >> > >> > > > > >
> > >> > >> > > > > > > Hi,
> > >> > >> > > > > > >
> > >> > >> > > > > > > I noticed that TRMM data dimension was (lon,
lat).
> > >> > >> > > > > > > So I switched their order to (lat, lon) and
ran the
> > >> command
> > >> > >> > again.
> > >> > >> > > > > > > However, I got the same error message as
below.
> > >> > >> > > > > > >
> > >> > >> > > > > > > yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/
> TRMM*
> > $
> > >> > >> > > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> > >> > >> > /scratch/halstead/y/yoo108/
> > >> > >> > > > > TRMM/
> > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > /scratch/halstead/y/yoo108/ND_
> > >> > >> > > > > > > grided_obs/daily_T2m_maxminmean_1976.nc
> > >> > >> > > /scratch/halstead/y/yoo108/
> > >> > >> > > > > TRMM/
> > >> > >> > > > > > > regrid_trmm_sample.nc -field
'name="precipitation";'
> > >> > >> > > > > > >
> > >> > >> > > > > > > DEBUG 1: Reading data file:
> > >> /scratch/halstead/y/yoo108/TRM
> > >> > M/
> > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > >> > >> > > > > > >
> > >> > >> > > > > > > ERROR :
> > >> > >> > > > > > >
> > >> > >> > > > > > > ERROR : process_data_file() ->
> > >> > "/scratch/halstead/y/yoo108/TR
> > >> > >> > MM/
> > >> > >> > > > > > > trmm_daily.20051231.7.nc" not a valid data
file
> > >> > >> > > > > > >
> > >> > >> > > > > > >
> > >> > >> > > > > > > Thank you.
> > >> > >> > > > > > >
> > >> > >> > > > > > > Regards,
> > >> > >> > > > > > >
> > >> > >> > > > > > >
> > >> > >> > > > > > > Jinwoong
> > >> > >> > > > > > >
> > >> > >> > > > > > >
> > >> > >> > > > > > >
> > >> > >> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong Yoo
<
> > >> > >> > > > jinwoong.yoo at gmail.com>
> > >> > >> > > > > > > wrote:
> > >> > >> > > > > > >
> > >> > >> > > > > > >> Hi,
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> I got a similar result with a TRMM data.
> > >> > >> > > > > > >> Please see below:
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/
> > TRMM*
> > >> $
> > >> > >> > > > > > >> ~/met-6.0_bugfix/bin/regrid_data_plane
> > >> > >> > > /scratch/halstead/y/yoo108/
> > >> > >> > > > > TRMM/
> > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > >> /scratch/halstead/y/yoo108/ND_
> > >> > >> > > > > > >> grided_obs/daily_T2m_maxminmean_1976.nc
> > >> > >> > > /scratch/halstead/y/yoo108/
> > >> > >> > > > > > TRMM/
> > >> > >> > > > > > >> regrid_trmm_sample.nc -field
> 'name="precipitation";'
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> DEBUG 1: Reading data file:
> > >> /scratch/halstead/y/yoo108/TRM
> > >> > M/
> > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> ERROR : process_data_file() ->
> > >> > >> "/scratch/halstead/y/yoo108/TR
> > >> > >> > MM/
> > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc" not a valid data
file
> > >> > >> > > > > > >>
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> A part of ncdump output for the TRMM data is
pasted
> > >> below:
> > >> > >> > > > > > >>
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/
> > TRMM*
> > >> $
> > >> > >> ncdump
> > >> > >> > > -h
> > >> > >> > > > > > >> subset_200003-200512/3B42RT_
> Daily.20051231.7.nc4.nc4
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> dimensions:
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> lon = 59 ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> lat = 58 ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> variables:
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> short precipitation_cnt(lon, lat) ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> precipitation_cnt:units = "count" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> precipitation_cnt:long_name = "Count of valid
3-hr
> > >> > >> precipitation
> > >> > >> > > > > > >> retrievals for the day" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> precipitation_cnt:coordinates = "lat lon" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> precipitation_cnt:origname =
"precipitation_cnt" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> precipitation_cnt:fullnamepath =
> "/precipitation_cnt"
> > ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> float uncal_precipitation(lon, lat) ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> uncal_precipitation:units = "mm" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> uncal_precipitation:long_name = "Daily
accumulated
> > >> > >> uncalibrated
> > >> > >> > > > > > >> precipitation" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> uncal_precipitation:coordinates = "lat lon" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> uncal_precipitation:_FillValue = -9999.9f ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> uncal_precipitation:origname =
> "uncal_precipitation" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> uncal_precipitation:fullnamepath =
> > >> "/uncal_precipitation"
> > >> > ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> short uncal_precipitation_cnt(lon, lat) ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> uncal_precipitation_cnt:units = "count" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> uncal_precipitation_cnt:long_name = "Count of
valid
> > >> 3-hr
> > >> > >> uncal
> > >> > >> > > > > > >> precipitation retrievals for the day" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> uncal_precipitation_cnt:coordinates = "lat
lon" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> uncal_precipitation_cnt:origname =
> > >> > >> "uncal_precipitation_cnt" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> uncal_precipitation_cnt:fullnamepath =
> > >> > >> > > "/uncal_precipitation_cnt" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> float precipitation(lon, lat) ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> precipitation:units = "mm" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> precipitation:long_name = "Daily accumulated
> > >> precipitation
> > >> > >> > > (combined
> > >> > >> > > > > > >> microwave-IR) estimate" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> precipitation:coordinates = "lat lon" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> precipitation:_FillValue = -9999.9f ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> precipitation:origname = "precipitation" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> precipitation:fullnamepath = "/precipitation"
;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> short randomError_cnt(lon, lat) ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> randomError_cnt:units = "count" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> randomError_cnt:long_name = "Count of
randomError
> for
> > >> the
> > >> > >> day" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> randomError_cnt:coordinates = "lat lon" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> randomError_cnt:origname = "randomError_cnt"
;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> randomError_cnt:fullnamepath =
"/randomError_cnt" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> float randomError(lon, lat) ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> randomError:units = "mm" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> randomError:long_name = "Daily total error of
> combined
> > >> > >> > > microwave-IR
> > >> > >> > > > > > >> precipitation estimate" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> randomError:_FillValue = -9999.9f ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> randomError:origname = "randomError" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> randomError:fullnamepath = "/randomError" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> float lat(lat) ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> lat:units = "degrees_north" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> lat:long_name = "Latitude" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> lat:origname = "lat" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> lat:fullnamepath = "/lat" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> float lon(lon) ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> lon:units = "degrees_east" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> lon:long_name = "Longitude" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> lon:origname = "lon" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> lon:fullnamepath = "/lon" ;
> > >> > >> > > > > > >>
> > >> > >> > > > > > >>
> > >> > >> > > > > > >>
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> Thank you.
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> Regards,
> > >> > >> > > > > > >>
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> Jinwoong
> > >> > >> > > > > > >>
> > >> > >> > > > > > >> On Thu, Jun 29, 2017 at 3:11 PM,
met_help at ucar.edu
> > via
> > >> RT
> > >> > <
> > >> > >> > > > > > >> met_help at ucar.edu> wrote:
> > >> > >> > > > > > >>
> > >> > >> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED AVAILABILITY
BETWEEN
> > >> > 5/23/17
> > >> > >> AND
> > >> > >> > > > > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> Greetings,
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> This message has been automatically
generated in
> > >> response
> > >> > to
> > >> > >> > the
> > >> > >> > > > > > >>> creation of a trouble ticket regarding:
> > >> > >> > > > > > >>> "regrid_data_plane: not a valid data
file",
> > >> > >> > > > > > >>> a summary of which appears below.
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> There is no need to reply to this message
right
> now.
> > >> Your
> > >> > >> > ticket
> > >> > >> > > > has
> > >> > >> > > > > > >>> been
> > >> > >> > > > > > >>> assigned an ID of [rt.rap.ucar.edu #81063].
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> Please include the string:
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> [rt.rap.ucar.edu #81063]
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> in the subject line of all future
correspondence
> > about
> > >> > this
> > >> > >> > > issue.
> > >> > >> > > > To
> > >> > >> > > > > > do
> > >> > >> > > > > > >>> so,
> > >> > >> > > > > > >>> you may reply to this message.
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> Thank you,
> > >> > >> > > > > > >>> met_help at ucar.edu
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> ------------------------------
> > >> > >> ------------------------------
> > >> > >> > > > > > >>> -------------
> > >> > >> > > > > > >>> Hi,
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> I am trying to regrid one of my observation
files
> in
> > >> lat
> > >> > lon
> > >> > >> > > > > coordinate
> > >> > >> > > > > > >>> grid to WRF curvilinear grid.
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> I ran bin/regrid_data_plane using a sample
lat lon
> > grid
> > >> > file
> > >> > >> > and
> > >> > >> > > a
> > >> > >> > > > > file
> > >> > >> > > > > > >>> in
> > >> > >> > > > > > >>> the WRF grid. But I got error as shown
below:
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > >> > /halstead/y/yoo108/ND_grided_
> > >> > >> > obs*
> > >> > >> > > $
> > >> > >> > > > > > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
> > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_grided_obs/
> > >> sample_tmax.nc
> > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> grided_obs/daily_T2m_
> > >> > >> > > > > maxminmean_1976.nc
> > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > >> > >> grided_obs/NDtoWRFgrid_sample_
> > >> > >> > > > tmax.nc
> > >> > >> > > > > > >>> -field
> > >> > >> > > > > > >>> 'name="tmax";'
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> DEBUG 1: Reading data file:
> > >> /scratch/halstead/y/yoo108/ND_
> > >> > >> > > > > grided_obs/
> > >> > >> > > > > > >>> sample_tmax.nc
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> ERROR : process_data_file() ->
> > >> > >> "/scratch/halstead/y/yoo108/ND
> > >> > >> > > > > > >>> _grided_obs/
> > >> > >> > > > > > >>> sample_tmax.nc" not a valid data file
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> I wonder which part of the input file does
not
> > satisfy
> > >> the
> > >> > >> > MET's
> > >> > >> > > > > "valid
> > >> > >> > > > > > >>> file" criteria.
> > >> > >> > > > > > >>> ncdump output of the input file looks as
below:
> > >> > >> > > > > > >>> Input file was originally generated by VIC
model
> and
> > >> > >> converted
> > >> > >> > > into
> > >> > >> > > > > cf
> > >> > >> > > > > > >>> netcdf format.
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> Thank you in advance.
> > >> > >> > > > > > >>> Regards,
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> Jinwoong
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > >> > /halstead/y/yoo108/ND_grided_
> > >> > >> > obs*
> > >> > >> > > $
> > >> > >> > > > > > >>> ncdump -h
> > >> > >> > > > > > >>> sample_tmax.nc
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> netcdf sample_tmax {
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> dimensions:
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> T = 1 ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> X = 55 ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> Y = 65 ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> variables:
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> double T(T) ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> T:units = "days since 1915-01-01" ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> T:long_name = "Time" ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> double X(X) ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> X:units = "degrees_east" ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> X:long_name = "Longitude" ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> double Y(Y) ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> Y:units = "degrees_north" ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> Y:long_name = "Latitude" ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> double tmax(T, Y, X) ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> tmax:units = "degC" ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> tmax:long_name = "tmax calculated by VIC" ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> tmax:missing_value = -9999.f ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> // global attributes:
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>> :production = "VIC output" ;
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>>
> > >> > >> > > > > > >>
> > >> > >> > > > > > >
> > >> > >> > > > > >
> > >> > >> > > > > >
> > >> > >> > > > >
> > >> > >> > > > >
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > >
> > >> > >> > >
> > >> > >> >
> > >> > >> >
> > >> > >>
> > >> > >>
> > >> > >
> > >> >
> > >> >
> > >>
> > >>
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: John Halley Gotway
Time: Mon Jul 10 13:04:04 2017
Jinwoong,
I tried running the sample file (daily_T2m_maxminmean_1981.nc) through
plot_data_plane and saw the same behavior you did. Looking closely at
that
file I see that is not the NetCDF output generated by WRF. The
history
attribute indicates that it was created by the "ncks" utility:
:history = "Sun Jul 2 15:47:18 2017: ncks -d days,0,0
/scratch/halstead/k/khoogewi/CCRC_wrf/analysis/T2m/daily_T2m_maxminmean_1981.nc
/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_maxminmean_19810101.nc"
This is not a CF-compliant NetCDF file and it does not look like the
output
from WRF. Another alternative is making it look like the NetCDF file
format used by the MET tools themselves.
I ran the following command to add global attributes to define the
grid
spec for MET:
ncatted \
-a MET_version,global,o,c,"V6.0" \
-a Projection,global,o,c,"Lambert Conformal" \
-a scale_lat_1,global,o,c,"48" \
-a scale_lat_2,global,o,c,"32" \
-a lat_pin,global,o,c,"48" \
-a lon_pin,global,o,c,"-97" \
-a x_pin,global,o,c,"0" \
-a y_pin,global,o,c,"0" \
-a lon_orient,global,o,c,"-97" \
-a d_km,global,o,c,"3" \
-a r_km,global,o,c,"6371.2" \
-a nx,global,o,c,"189" \
-a ny,global,o,c,"270" \
daily_T2m_maxminmean_1976.nc -o daily_T2m_maxminmean_1976_MET.nc
However, I don't think these are all correct. Specifically, I don't
know
how the "lon_orient" should be set. So I set it to the longitude of
the
lower-left corner. Also, I don't know how the d_km should be set.
That's
the grid spacing in km. So I just guess with a value of 3.
This enables MET to plot the result, but you should work on making the
grid
info correct:
met-6.0/bin/plot_data_plane \
daily_T2m_maxminmean_1976_MET.nc \
daily_T2m_maxminmean_1976_MET.ps \
'name="T2m_max"; level="(10,*,*)";' -v 4
Thanks,
John
On Fri, Jul 7, 2017 at 5:06 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>
> Hi John,
>
> Thank you for your comment.
> I tried it but it failed.
> Please see below.
>
> yoo108 at halstead-
fe03:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal* $
> ~/met-6.0_bugfix/bin/plot_data_plane
> /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> maxminmean_20051231.nc
> wrfDaily_T2m_maxminmean_20051231.ps
> 'name="T2m_max";level="(0,*,*)";file_type = NETCDF_PINT;'
>
> DEBUG 1: Opening data file:
> /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> maxminmean_20051231.nc
>
> ERROR : MetNcPinterpDataFile::open(const char *) -> unable to open
NetCDF
> file
> "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> maxminmean_20051231.nc"
>
> ERROR : Met2dDataFileFactory::new_met_2d_data_file() -> error
opening
> file
> "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> maxminmean_20051231.nc"
>
>
>
> One sample file (wrfDaily_T2m_maxminmean_19810101.nc) is also
included in
> the Yoo_data4.tar file that I uploaded previously.
> Thank you.
> Haver a nice weekend.
>
> Regards,
>
> Jinwoong
>
>
>
> On Fri, Jul 7, 2017 at 6:04 PM, John Halley Gotway via RT <
> met_help at ucar.edu
> > wrote:
>
> > Jinwoong,
> >
> > If they really are output from WRF, one simple thing to try is
telling
> MET
> > to interpret them as the NetCDF output of the wrf_interp utility
> > :
> > file_type = NETCDF_PINT;
> >
> > "PINT" stands for "pressure interpolated"... pinterp was the
precursor to
> > the current wrf_interp tool.
> >
> > If that doesn't work, I'll need to see a sample file before making
any
> > other suggestions.
> >
> > Thanks,
> > John
> >
> >
> >
> > On Fri, Jul 7, 2017 at 3:36 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > >
> > > Hi John,
> > >
> > > I was able to read in a "home brew" netcdf data file using
> > plot_data_plane.
> > >
> > > Then, I went ahead and tried another netcdf file in curvilinear
> > coordinate
> > > which is in the same coordinate grid as my WRF output. But it
failed.
> > >
> > > I have many netcdf climatology files from the WRF simulation
such as
> > daily,
> > > monthly, and annual, etc. Therefore, they are all in curvilinear
> > coordinate
> > > (Lambert).
> > >
> > > I wonder if there is any work around so that I can feed these
files
> into
> > > MET?
> > > Or should I regrid them all into lat lon coordinate files first?
> > >
> > > Thank you, John.
> > >
> > > Regards,
> > >
> > > Jinwoong Yoo
> > >
> > >
> > > On Fri, Jul 7, 2017 at 3:01 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > > wrote:
> > >
> > > > Hi John,
> > > >
> > > > Thank you very much.
> > > > Let me try and let you know how it goes.
> > > > Thank you.
> > > > Regards,
> > > >
> > > > Jinwoong
> > > >
> > > > On Fri, Jul 7, 2017 at 2:59 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > >> Jinwoong,
> > > >>
> > > >> Yes, you can give it a try. The closer you can make the
NetCDF
> files
> > to
> > > >> the CF-convention, the more likely MET will be able to read
it.
> > > >>
> > > >> The reason that's its able to read the TRMM data are that the
> lat/lon
> > > >> values are equally spaced. Non-equally spaced lat/lon values
on a
> map
> > > >> projection require that the map projection information be
specified.
> > > >> Unfortunately, specifying map projection information in CF-
compliant
> > > >> NetCDF
> > > >> files is not as easy as I think it should be!
> > > >>
> > > >> Hope it works out ok for you.
> > > >>
> > > >> Thanks,
> > > >> John
> > > >>
> > > >> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo via RT <
> > met_help at ucar.edu
> > > >
> > > >> wrote:
> > > >>
> > > >> >
> > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > > >> >
> > > >> > investigating not investing :)
> > > >> >
> > > >> > Thanks!
> > > >> > Regards,
> > > >> >
> > > >> > Jinwoong
> > > >> >
> > > >> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo <
> > jinwoong.yoo at gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> > > Hi John,
> > > >> > >
> > > >> > > Thank you very much for your time investing the issue.
> > > >> > > I am glad to hear that there is a trick to work around
the issue
> > to
> > > >> read
> > > >> > > in TRMM data in netcdf format.
> > > >> > > I wonder if I can apply the same trick (
file_type=NETCDF_NCCF;)
> > to
> > > >> read
> > > >> > > in any other observation files in netcdf format?
> > > >> > > In fact, I would like to read in "home brew" netcdf
dataset
> files
> > > into
> > > >> > > MET.
> > > >> > > One sample file of them was included in the uploaded data
> folder (
> > > >> > > sample_tmax.nc).
> > > >> > > The data in this sample file was originally generated by
VIC
> > model.
> > > >> > > Then the file format was converted into a generic netcdf
file
> > format
> > > >> > > although the dimension names are T, X, Y not time, lat,
lon.
> > > >> > > But their coordinates have units in "degrees_east" or
> > > "degrees_north"
> > > >> as
> > > >> > > well as their long_name as "Longitude" and "Latitude",
> > respectively.
> > > >> > >
> > > >> > > Of course, I will try to read those in for Grid-stat
today.
> > > >> > > But I would like to hear from you if the trick (
> > > >> file_type=NETCDF_NCCF;)
> > > >> > > can be applied generally, which I wish very much.
> > > >> > >
> > > >> > > Thank you so much, John.
> > > >> > >
> > > >> > > Regards,
> > > >> > >
> > > >> > > Jinwoong Yoo
> > > >> > >
> > > >> > >
> > > >> > > On Fri, Jul 7, 2017 at 1:16 PM, John Halley Gotway via RT
<
> > > >> > > met_help at ucar.edu> wrote:
> > > >> > >
> > > >> > >> Jinwoong,
> > > >> > >>
> > > >> > >> Thanks for sending your sample data and for your
patience
> while I
> > > was
> > > >> > out
> > > >> > >> of town.
> > > >> > >>
> > > >> > >> Using met-6.0, I'm able to process the TRMM NetCDF file
you
> sent.
> > > >> The
> > > >> > >> trick is that I had to tell it which NetCDF file type
should be
> > > used
> > > >> to
> > > >> > >> interpret the data. Using "file_type = NETCDF_NCCF;"
I'm
> telling
> > > >> MET to
> > > >> > >> interpret it as if it were a CF-compliant NetCDF file:
> > > >> > >>
> > > >> > >> met-6.0/bin/plot_data_plane \
> > > >> > >> trmm_daily.20051231.7.nc trmm_daily.20051231.7.ps \
> > > >> > >> 'name="precipitation"; level="(*,*)";
file_type=NETCDF_NCCF;'
> > > >> > >>
> > > >> > >> DEBUG 1: Opening data file: trmm_daily.20051231.7.nc
> > > >> > >> WARNING: NcCfFile::open() -> could not determine the
valid
> time,
> > > >> using
> > > >> > 0.
> > > >> > >> WARNING: NcCfFile::open() -> could not determine the
valid
> time,
> > > >> using
> > > >> > 0.
> > > >> > >> DEBUG 1: Creating postscript file:
trmm_daily.20051231.7.ps
> > > >> > >>
> > > >> > >> The plot_data_plane tool is able to read the data, and
I've
> > > attached
> > > >> the
> > > >> > >> resulting image. However, notice the warning messages
about
> the
> > > >> valid
> > > >> > >> time.
> > > >> > >>
> > > >> > >> Using ncdump to see that file attributes, I see this
timing
> > > >> information:
> > > >> > >> :HDF5_GLOBAL.BeginDate = "2005-12-31" ;
> > > >> > >> :HDF5_GLOBAL.BeginTime = "01:30:00.000Z"
;
> > > >> > >> :HDF5_GLOBAL.EndDate = "2006-01-01" ;
> > > >> > >> :HDF5_GLOBAL.EndTime = "01:29:59.999Z" ;
> > > >> > >>
> > > >> > >> However that is not the CF-compliant way of specifying
timing
> > info.
> > > >> So
> > > >> > >> while MET will be able to read the data, the timing info
won't
> be
> > > >> > accurate
> > > >> > >> in the MET output files. Instead, you'll see "19700101"
which
> is
> > > >> > unixtime
> > > >> > >> = 0.
> > > >> > >>
> > > >> > >> Another option would be pulling the binary TRMM data and
using
> > this
> > > >> > >> Rscript
> > > >> > >> to convert the binary to NetCDF:
> > > >> > >> http://www.dtcenter.org/met/users/downloads/Rscripts/
> > > trmmbin2nc.R
> > > >> > >>
> > > >> > >> However, I haven't done this in a while and am not sure
if
> you'll
> > > run
> > > >> > into
> > > >> > >> any issues.
> > > >> > >>
> > > >> > >> Hope that helps.
> > > >> > >>
> > > >> > >> Thanks,
> > > >> > >> John
> > > >> > >>
> > > >> > >>
> > > >> > >>
> > > >> > >>
> > > >> > >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo via RT <
> > > >> met_help at ucar.edu>
> > > >> > >> wrote:
> > > >> > >>
> > > >> > >> >
> > > >> > >> > <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=81063
> > >
> > > >> > >> >
> > > >> > >> > Hi John,
> > > >> > >> >
> > > >> > >> > Thank you very much.
> > > >> > >> > Regards,
> > > >> > >> >
> > > >> > >> > Jinwoong
> > > >> > >> >
> > > >> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John Halley Gotway
via RT <
> > > >> > >> > met_help at ucar.edu> wrote:
> > > >> > >> >
> > > >> > >> > > Jinwoong,
> > > >> > >> > >
> > > >> > >> > > I'm out of the office today but will take a closer
look
> > > tomorrow.
> > > >> > >> > >
> > > >> > >> > > Thanks
> > > >> > >> > > John
> > > >> > >> > >
> > > >> > >> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo via RT
<
> > > >> > >> met_help at ucar.edu>
> > > >> > >> > > wrote:
> > > >> > >> > >
> > > >> > >> > > >
> > > >> > >> > > > <URL: https://rt.rap.ucar.edu/rt/
> > > Ticket/Display.html?id=81063
> > > >> >
> > > >> > >> > > >
> > > >> > >> > > > Hi John,
> > > >> > >> > > >
> > > >> > >> > > > Thank you for your reply.
> > > >> > >> > > > I uploaded my data as in Yoo_data4.tar on the ftp
site.
> > > >> > >> > > > I included several files for the message of ID of
[
> > > >> > rt.rap.ucar.edu
> > > >> > >> > > #81074]
> > > >> > >> > > > as well.
> > > >> > >> > > > Thank you.
> > > >> > >> > > > Regards,
> > > >> > >> > > >
> > > >> > >> > > > Jinwoong
> > > >> > >> > > >
> > > >> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM, John Halley
Gotway via
> RT
> > <
> > > >> > >> > > > met_help at ucar.edu> wrote:
> > > >> > >> > > >
> > > >> > >> > > > > Jinwoong,
> > > >> > >> > > > >
> > > >> > >> > > > > I see that you're having trouble reading a TRMM
NetCDF
> > file
> > > >> into
> > > >> > >> MET.
> > > >> > >> > > > Can
> > > >> > >> > > > > you please post the problematic file to our
anonymous
> ftp
> > > >> site
> > > >> > so
> > > >> > >> I
> > > >> > >> > can
> > > >> > >> > > > > take a look?
> > > >> > >> > > > >
> > > >> > >> > > > > http://www.dtcenter.org/met/
> > users/support/met_help.php#ftp
> > > >> > >> > > > >
> > > >> > >> > > > > Thanks,
> > > >> > >> > > > > John Halley Gotway
> > > >> > >> > > > >
> > > >> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo via
RT <
> > > >> > >> > met_help at ucar.edu
> > > >> > >> > > >
> > > >> > >> > > > > wrote:
> > > >> > >> > > > >
> > > >> > >> > > > > >
> > > >> > >> > > > > > <URL: https://rt.rap.ucar.edu/rt/Tic
> > > >> ket/Display.html?id=81063
> > > >> > >
> > > >> > >> > > > > >
> > > >> > >> > > > > > Hi,
> > > >> > >> > > > > >
> > > >> > >> > > > > > TRMM data comes in as netCDF-4 classic model.
> > > >> > >> > > > > > I changed it to netCDF classic and run the
same
> command
> > > >> for a
> > > >> > >> test.
> > > >> > >> > > > > > But I got the same error as below.
> > > >> > >> > > > > >
> > > >> > >> > > > > > yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/
> TRMM*
> > $
> > > >> > >> > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> > > >> > >> /scratch/halstead/y/yoo108/
> > > >> > >> > > TRMM/
> > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > > >> > >> > > > > >
/scratch/halstead/y/yoo108/ND_grided_obs/daily_T2m_
> > > >> > >> > > maxminmean_1976.nc
> > > >> > >> > > > > > /scratch/halstead/y/yoo108/TRMM/
> regrid_trmm_sample.nc
> > > >> -field
> > > >> > >> > > > > > 'name="precipitation";'
> > > >> > >> > > > > >
> > > >> > >> > > > > > DEBUG 1: Reading data file:
> > > /scratch/halstead/y/yoo108/TRM
> > > >> M/
> > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > > >> > >> > > > > >
> > > >> > >> > > > > > ERROR :
> > > >> > >> > > > > >
> > > >> > >> > > > > > ERROR : process_data_file() ->
> > > >> "/scratch/halstead/y/yoo108/TR
> > > >> > >> MM/
> > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc" not a valid data
file
> > > >> > >> > > > > >
> > > >> > >> > > > > > Thank you.
> > > >> > >> > > > > >
> > > >> > >> > > > > > Regards,
> > > >> > >> > > > > >
> > > >> > >> > > > > >
> > > >> > >> > > > > > Jinwoong
> > > >> > >> > > > > >
> > > >> > >> > > > > > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong Yoo
<
> > > >> > >> > > jinwoong.yoo at gmail.com>
> > > >> > >> > > > > > wrote:
> > > >> > >> > > > > >
> > > >> > >> > > > > > > Hi,
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > I noticed that TRMM data dimension was (lon,
lat).
> > > >> > >> > > > > > > So I switched their order to (lat, lon) and
ran the
> > > >> command
> > > >> > >> > again.
> > > >> > >> > > > > > > However, I got the same error message as
below.
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/
> > TRMM*
> > > $
> > > >> > >> > > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> > > >> > >> > /scratch/halstead/y/yoo108/
> > > >> > >> > > > > TRMM/
> > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > > /scratch/halstead/y/yoo108/ND_
> > > >> > >> > > > > > > grided_obs/daily_T2m_maxminmean_1976.nc
> > > >> > >> > > /scratch/halstead/y/yoo108/
> > > >> > >> > > > > TRMM/
> > > >> > >> > > > > > > regrid_trmm_sample.nc -field
> 'name="precipitation";'
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > DEBUG 1: Reading data file:
> > > >> /scratch/halstead/y/yoo108/TRM
> > > >> > M/
> > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > ERROR :
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > ERROR : process_data_file() ->
> > > >> > "/scratch/halstead/y/yoo108/TR
> > > >> > >> > MM/
> > > >> > >> > > > > > > trmm_daily.20051231.7.nc" not a valid data
file
> > > >> > >> > > > > > >
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > Thank you.
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > Regards,
> > > >> > >> > > > > > >
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > Jinwoong
> > > >> > >> > > > > > >
> > > >> > >> > > > > > >
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong
Yoo <
> > > >> > >> > > > jinwoong.yoo at gmail.com>
> > > >> > >> > > > > > > wrote:
> > > >> > >> > > > > > >
> > > >> > >> > > > > > >> Hi,
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> I got a similar result with a TRMM data.
> > > >> > >> > > > > > >> Please see below:
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/
> > > TRMM*
> > > >> $
> > > >> > >> > > > > > >> ~/met-6.0_bugfix/bin/regrid_data_plane
> > > >> > >> > > /scratch/halstead/y/yoo108/
> > > >> > >> > > > > TRMM/
> > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > > >> /scratch/halstead/y/yoo108/ND_
> > > >> > >> > > > > > >> grided_obs/daily_T2m_maxminmean_1976.nc
> > > >> > >> > > /scratch/halstead/y/yoo108/
> > > >> > >> > > > > > TRMM/
> > > >> > >> > > > > > >> regrid_trmm_sample.nc -field
> > 'name="precipitation";'
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> DEBUG 1: Reading data file:
> > > >> /scratch/halstead/y/yoo108/TRM
> > > >> > M/
> > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> ERROR : process_data_file() ->
> > > >> > >> "/scratch/halstead/y/yoo108/TR
> > > >> > >> > MM/
> > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc" not a valid
data file
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> A part of ncdump output for the TRMM data
is
> pasted
> > > >> below:
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/
> > > TRMM*
> > > >> $
> > > >> > >> ncdump
> > > >> > >> > > -h
> > > >> > >> > > > > > >> subset_200003-200512/3B42RT_
> > Daily.20051231.7.nc4.nc4
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> dimensions:
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> lon = 59 ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> lat = 58 ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> variables:
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> short precipitation_cnt(lon, lat) ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> precipitation_cnt:units = "count" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> precipitation_cnt:long_name = "Count of
valid 3-hr
> > > >> > >> precipitation
> > > >> > >> > > > > > >> retrievals for the day" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> precipitation_cnt:coordinates = "lat lon" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> precipitation_cnt:origname =
"precipitation_cnt" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> precipitation_cnt:fullnamepath =
> > "/precipitation_cnt"
> > > ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> float uncal_precipitation(lon, lat) ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> uncal_precipitation:units = "mm" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> uncal_precipitation:long_name = "Daily
accumulated
> > > >> > >> uncalibrated
> > > >> > >> > > > > > >> precipitation" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> uncal_precipitation:coordinates = "lat lon"
;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> uncal_precipitation:_FillValue = -9999.9f ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> uncal_precipitation:origname =
> > "uncal_precipitation" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> uncal_precipitation:fullnamepath =
> > > >> "/uncal_precipitation"
> > > >> > ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> short uncal_precipitation_cnt(lon, lat) ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> uncal_precipitation_cnt:units = "count" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> uncal_precipitation_cnt:long_name = "Count
of
> valid
> > > >> 3-hr
> > > >> > >> uncal
> > > >> > >> > > > > > >> precipitation retrievals for the day" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> uncal_precipitation_cnt:coordinates = "lat
lon" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> uncal_precipitation_cnt:origname =
> > > >> > >> "uncal_precipitation_cnt" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> uncal_precipitation_cnt:fullnamepath =
> > > >> > >> > > "/uncal_precipitation_cnt" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> float precipitation(lon, lat) ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> precipitation:units = "mm" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> precipitation:long_name = "Daily
accumulated
> > > >> precipitation
> > > >> > >> > > (combined
> > > >> > >> > > > > > >> microwave-IR) estimate" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> precipitation:coordinates = "lat lon" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> precipitation:_FillValue = -9999.9f ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> precipitation:origname = "precipitation" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> precipitation:fullnamepath =
"/precipitation" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> short randomError_cnt(lon, lat) ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> randomError_cnt:units = "count" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> randomError_cnt:long_name = "Count of
randomError
> > for
> > > >> the
> > > >> > >> day" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> randomError_cnt:coordinates = "lat lon" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> randomError_cnt:origname =
"randomError_cnt" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> randomError_cnt:fullnamepath =
"/randomError_cnt"
> ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> float randomError(lon, lat) ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> randomError:units = "mm" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> randomError:long_name = "Daily total error
of
> > combined
> > > >> > >> > > microwave-IR
> > > >> > >> > > > > > >> precipitation estimate" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> randomError:_FillValue = -9999.9f ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> randomError:origname = "randomError" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> randomError:fullnamepath = "/randomError" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> float lat(lat) ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> lat:units = "degrees_north" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> lat:long_name = "Latitude" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> lat:origname = "lat" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> lat:fullnamepath = "/lat" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> float lon(lon) ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> lon:units = "degrees_east" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> lon:long_name = "Longitude" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> lon:origname = "lon" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> lon:fullnamepath = "/lon" ;
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> Thank you.
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> Regards,
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> Jinwoong
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >> On Thu, Jun 29, 2017 at 3:11 PM,
> met_help at ucar.edu
> > > via
> > > >> RT
> > > >> > <
> > > >> > >> > > > > > >> met_help at ucar.edu> wrote:
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED
AVAILABILITY
> BETWEEN
> > > >> > 5/23/17
> > > >> > >> AND
> > > >> > >> > > > > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> Greetings,
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> This message has been automatically
generated in
> > > >> response
> > > >> > to
> > > >> > >> > the
> > > >> > >> > > > > > >>> creation of a trouble ticket regarding:
> > > >> > >> > > > > > >>> "regrid_data_plane: not a valid
data
> file",
> > > >> > >> > > > > > >>> a summary of which appears below.
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> There is no need to reply to this message
right
> > now.
> > > >> Your
> > > >> > >> > ticket
> > > >> > >> > > > has
> > > >> > >> > > > > > >>> been
> > > >> > >> > > > > > >>> assigned an ID of [rt.rap.ucar.edu
#81063].
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> Please include the string:
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> [rt.rap.ucar.edu #81063]
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> in the subject line of all future
correspondence
> > > about
> > > >> > this
> > > >> > >> > > issue.
> > > >> > >> > > > To
> > > >> > >> > > > > > do
> > > >> > >> > > > > > >>> so,
> > > >> > >> > > > > > >>> you may reply to this message.
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> Thank you,
> > > >> > >> > > > > > >>> met_help at ucar.edu
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> ------------------------------
> > > >> > >> ------------------------------
> > > >> > >> > > > > > >>> -------------
> > > >> > >> > > > > > >>> Hi,
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> I am trying to regrid one of my
observation files
> > in
> > > >> lat
> > > >> > lon
> > > >> > >> > > > > coordinate
> > > >> > >> > > > > > >>> grid to WRF curvilinear grid.
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> I ran bin/regrid_data_plane using a sample
lat
> lon
> > > grid
> > > >> > file
> > > >> > >> > and
> > > >> > >> > > a
> > > >> > >> > > > > file
> > > >> > >> > > > > > >>> in
> > > >> > >> > > > > > >>> the WRF grid. But I got error as shown
below:
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > > >> > /halstead/y/yoo108/ND_grided_
> > > >> > >> > obs*
> > > >> > >> > > $
> > > >> > >> > > > > > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
> > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_grided_obs/
> > > >> sample_tmax.nc
> > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > grided_obs/daily_T2m_
> > > >> > >> > > > > maxminmean_1976.nc
> > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > > >> > >> grided_obs/NDtoWRFgrid_sample_
> > > >> > >> > > > tmax.nc
> > > >> > >> > > > > > >>> -field
> > > >> > >> > > > > > >>> 'name="tmax";'
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> DEBUG 1: Reading data file:
> > > >> /scratch/halstead/y/yoo108/ND_
> > > >> > >> > > > > grided_obs/
> > > >> > >> > > > > > >>> sample_tmax.nc
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> ERROR : process_data_file() ->
> > > >> > >> "/scratch/halstead/y/yoo108/ND
> > > >> > >> > > > > > >>> _grided_obs/
> > > >> > >> > > > > > >>> sample_tmax.nc" not a valid data file
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> I wonder which part of the input file does
not
> > > satisfy
> > > >> the
> > > >> > >> > MET's
> > > >> > >> > > > > "valid
> > > >> > >> > > > > > >>> file" criteria.
> > > >> > >> > > > > > >>> ncdump output of the input file looks as
below:
> > > >> > >> > > > > > >>> Input file was originally generated by VIC
model
> > and
> > > >> > >> converted
> > > >> > >> > > into
> > > >> > >> > > > > cf
> > > >> > >> > > > > > >>> netcdf format.
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> Thank you in advance.
> > > >> > >> > > > > > >>> Regards,
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> Jinwoong
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > > >> > /halstead/y/yoo108/ND_grided_
> > > >> > >> > obs*
> > > >> > >> > > $
> > > >> > >> > > > > > >>> ncdump -h
> > > >> > >> > > > > > >>> sample_tmax.nc
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> netcdf sample_tmax {
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> dimensions:
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> T = 1 ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> X = 55 ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> Y = 65 ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> variables:
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> double T(T) ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> T:units = "days since 1915-01-01" ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> T:long_name = "Time" ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> double X(X) ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> X:units = "degrees_east" ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> X:long_name = "Longitude" ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> double Y(Y) ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> Y:units = "degrees_north" ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> Y:long_name = "Latitude" ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> double tmax(T, Y, X) ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> tmax:units = "degC" ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> tmax:long_name = "tmax calculated by VIC"
;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> tmax:missing_value = -9999.f ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> // global attributes:
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>> :production = "VIC output" ;
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>>
> > > >> > >> > > > > > >>
> > > >> > >> > > > > > >
> > > >> > >> > > > > >
> > > >> > >> > > > > >
> > > >> > >> > > > >
> > > >> > >> > > > >
> > > >> > >> > > >
> > > >> > >> > > >
> > > >> > >> > >
> > > >> > >> > >
> > > >> > >> >
> > > >> > >> >
> > > >> > >>
> > > >> > >>
> > > >> > >
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Mon Jul 10 13:43:39 2017
Hi John,
Thank you for your note.
Let me try and will let you know if I need your help.
Thank you.
Regards,
Jinwoong
On Mon, Jul 10, 2017 at 3:04 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Jinwoong,
>
> I tried running the sample file (daily_T2m_maxminmean_1981.nc)
through
> plot_data_plane and saw the same behavior you did. Looking closely
at that
> file I see that is not the NetCDF output generated by WRF. The
history
> attribute indicates that it was created by the "ncks" utility:
>
> :history = "Sun Jul 2 15:47:18 2017: ncks -d days,0,0
> /scratch/halstead/k/khoogewi/CCRC_wrf/analysis/T2m/daily_
> T2m_maxminmean_1981.nc
> /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> maxminmean_19810101.nc"
>
>
> This is not a CF-compliant NetCDF file and it does not look like the
output
> from WRF. Another alternative is making it look like the NetCDF
file
> format used by the MET tools themselves.
>
> I ran the following command to add global attributes to define the
grid
> spec for MET:
>
> ncatted \
> -a MET_version,global,o,c,"V6.0" \
> -a Projection,global,o,c,"Lambert Conformal" \
> -a scale_lat_1,global,o,c,"48" \
> -a scale_lat_2,global,o,c,"32" \
> -a lat_pin,global,o,c,"48" \
> -a lon_pin,global,o,c,"-97" \
> -a x_pin,global,o,c,"0" \
> -a y_pin,global,o,c,"0" \
> -a lon_orient,global,o,c,"-97" \
> -a d_km,global,o,c,"3" \
> -a r_km,global,o,c,"6371.2" \
> -a nx,global,o,c,"189" \
> -a ny,global,o,c,"270" \
> daily_T2m_maxminmean_1976.nc -o daily_T2m_maxminmean_1976_MET.nc
>
> However, I don't think these are all correct. Specifically, I don't
know
> how the "lon_orient" should be set. So I set it to the longitude of
the
> lower-left corner. Also, I don't know how the d_km should be set.
That's
> the grid spacing in km. So I just guess with a value of 3.
>
> This enables MET to plot the result, but you should work on making
the grid
> info correct:
> met-6.0/bin/plot_data_plane \
> daily_T2m_maxminmean_1976_MET.nc \
> daily_T2m_maxminmean_1976_MET.ps \
> 'name="T2m_max"; level="(10,*,*)";' -v 4
>
> Thanks,
> John
>
>
>
> On Fri, Jul 7, 2017 at 5:06 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >
> > Hi John,
> >
> > Thank you for your comment.
> > I tried it but it failed.
> > Please see below.
> >
> > yoo108 at halstead-
fe03:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal* $
> > ~/met-6.0_bugfix/bin/plot_data_plane
> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > maxminmean_20051231.nc
> > wrfDaily_T2m_maxminmean_20051231.ps
> > 'name="T2m_max";level="(0,*,*)";file_type = NETCDF_PINT;'
> >
> > DEBUG 1: Opening data file:
> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > maxminmean_20051231.nc
> >
> > ERROR : MetNcPinterpDataFile::open(const char *) -> unable to
open
> NetCDF
> > file
> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > maxminmean_20051231.nc"
> >
> > ERROR : Met2dDataFileFactory::new_met_2d_data_file() -> error
opening
> > file
> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > maxminmean_20051231.nc"
> >
> >
> >
> > One sample file (wrfDaily_T2m_maxminmean_19810101.nc) is also
included
> in
> > the Yoo_data4.tar file that I uploaded previously.
> > Thank you.
> > Haver a nice weekend.
> >
> > Regards,
> >
> > Jinwoong
> >
> >
> >
> > On Fri, Jul 7, 2017 at 6:04 PM, John Halley Gotway via RT <
> > met_help at ucar.edu
> > > wrote:
> >
> > > Jinwoong,
> > >
> > > If they really are output from WRF, one simple thing to try is
telling
> > MET
> > > to interpret them as the NetCDF output of the wrf_interp utility
> > > :
> > > file_type = NETCDF_PINT;
> > >
> > > "PINT" stands for "pressure interpolated"... pinterp was the
precursor
> to
> > > the current wrf_interp tool.
> > >
> > > If that doesn't work, I'll need to see a sample file before
making any
> > > other suggestions.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > >
> > > On Fri, Jul 7, 2017 at 3:36 PM, Jinwoong Yoo via RT
<met_help at ucar.edu
> >
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
> > > >
> > > > Hi John,
> > > >
> > > > I was able to read in a "home brew" netcdf data file using
> > > plot_data_plane.
> > > >
> > > > Then, I went ahead and tried another netcdf file in
curvilinear
> > > coordinate
> > > > which is in the same coordinate grid as my WRF output. But it
failed.
> > > >
> > > > I have many netcdf climatology files from the WRF simulation
such as
> > > daily,
> > > > monthly, and annual, etc. Therefore, they are all in
curvilinear
> > > coordinate
> > > > (Lambert).
> > > >
> > > > I wonder if there is any work around so that I can feed these
files
> > into
> > > > MET?
> > > > Or should I regrid them all into lat lon coordinate files
first?
> > > >
> > > > Thank you, John.
> > > >
> > > > Regards,
> > > >
> > > > Jinwoong Yoo
> > > >
> > > >
> > > > On Fri, Jul 7, 2017 at 3:01 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com
> >
> > > > wrote:
> > > >
> > > > > Hi John,
> > > > >
> > > > > Thank you very much.
> > > > > Let me try and let you know how it goes.
> > > > > Thank you.
> > > > > Regards,
> > > > >
> > > > > Jinwoong
> > > > >
> > > > > On Fri, Jul 7, 2017 at 2:59 PM, John Halley Gotway via RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > >> Jinwoong,
> > > > >>
> > > > >> Yes, you can give it a try. The closer you can make the
NetCDF
> > files
> > > to
> > > > >> the CF-convention, the more likely MET will be able to read
it.
> > > > >>
> > > > >> The reason that's its able to read the TRMM data are that
the
> > lat/lon
> > > > >> values are equally spaced. Non-equally spaced lat/lon
values on a
> > map
> > > > >> projection require that the map projection information be
> specified.
> > > > >> Unfortunately, specifying map projection information in
> CF-compliant
> > > > >> NetCDF
> > > > >> files is not as easy as I think it should be!
> > > > >>
> > > > >> Hope it works out ok for you.
> > > > >>
> > > > >> Thanks,
> > > > >> John
> > > > >>
> > > > >> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo via RT <
> > > met_help at ucar.edu
> > > > >
> > > > >> wrote:
> > > > >>
> > > > >> >
> > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > > > >> >
> > > > >> > investigating not investing :)
> > > > >> >
> > > > >> > Thanks!
> > > > >> > Regards,
> > > > >> >
> > > > >> > Jinwoong
> > > > >> >
> > > > >> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo <
> > > jinwoong.yoo at gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Hi John,
> > > > >> > >
> > > > >> > > Thank you very much for your time investing the issue.
> > > > >> > > I am glad to hear that there is a trick to work around
the
> issue
> > > to
> > > > >> read
> > > > >> > > in TRMM data in netcdf format.
> > > > >> > > I wonder if I can apply the same trick (
> file_type=NETCDF_NCCF;)
> > > to
> > > > >> read
> > > > >> > > in any other observation files in netcdf format?
> > > > >> > > In fact, I would like to read in "home brew" netcdf
dataset
> > files
> > > > into
> > > > >> > > MET.
> > > > >> > > One sample file of them was included in the uploaded
data
> > folder (
> > > > >> > > sample_tmax.nc).
> > > > >> > > The data in this sample file was originally generated
by VIC
> > > model.
> > > > >> > > Then the file format was converted into a generic
netcdf file
> > > format
> > > > >> > > although the dimension names are T, X, Y not time, lat,
lon.
> > > > >> > > But their coordinates have units in "degrees_east" or
> > > > "degrees_north"
> > > > >> as
> > > > >> > > well as their long_name as "Longitude" and "Latitude",
> > > respectively.
> > > > >> > >
> > > > >> > > Of course, I will try to read those in for Grid-stat
today.
> > > > >> > > But I would like to hear from you if the trick (
> > > > >> file_type=NETCDF_NCCF;)
> > > > >> > > can be applied generally, which I wish very much.
> > > > >> > >
> > > > >> > > Thank you so much, John.
> > > > >> > >
> > > > >> > > Regards,
> > > > >> > >
> > > > >> > > Jinwoong Yoo
> > > > >> > >
> > > > >> > >
> > > > >> > > On Fri, Jul 7, 2017 at 1:16 PM, John Halley Gotway via
RT <
> > > > >> > > met_help at ucar.edu> wrote:
> > > > >> > >
> > > > >> > >> Jinwoong,
> > > > >> > >>
> > > > >> > >> Thanks for sending your sample data and for your
patience
> > while I
> > > > was
> > > > >> > out
> > > > >> > >> of town.
> > > > >> > >>
> > > > >> > >> Using met-6.0, I'm able to process the TRMM NetCDF
file you
> > sent.
> > > > >> The
> > > > >> > >> trick is that I had to tell it which NetCDF file type
should
> be
> > > > used
> > > > >> to
> > > > >> > >> interpret the data. Using "file_type = NETCDF_NCCF;"
I'm
> > telling
> > > > >> MET to
> > > > >> > >> interpret it as if it were a CF-compliant NetCDF file:
> > > > >> > >>
> > > > >> > >> met-6.0/bin/plot_data_plane \
> > > > >> > >> trmm_daily.20051231.7.nc trmm_daily.20051231.7.ps \
> > > > >> > >> 'name="precipitation"; level="(*,*)";
file_type=NETCDF_NCCF;'
> > > > >> > >>
> > > > >> > >> DEBUG 1: Opening data file: trmm_daily.20051231.7.nc
> > > > >> > >> WARNING: NcCfFile::open() -> could not determine the
valid
> > time,
> > > > >> using
> > > > >> > 0.
> > > > >> > >> WARNING: NcCfFile::open() -> could not determine the
valid
> > time,
> > > > >> using
> > > > >> > 0.
> > > > >> > >> DEBUG 1: Creating postscript file:
trmm_daily.20051231.7.ps
> > > > >> > >>
> > > > >> > >> The plot_data_plane tool is able to read the data, and
I've
> > > > attached
> > > > >> the
> > > > >> > >> resulting image. However, notice the warning messages
about
> > the
> > > > >> valid
> > > > >> > >> time.
> > > > >> > >>
> > > > >> > >> Using ncdump to see that file attributes, I see this
timing
> > > > >> information:
> > > > >> > >> :HDF5_GLOBAL.BeginDate = "2005-12-31"
;
> > > > >> > >> :HDF5_GLOBAL.BeginTime =
"01:30:00.000Z" ;
> > > > >> > >> :HDF5_GLOBAL.EndDate = "2006-01-01" ;
> > > > >> > >> :HDF5_GLOBAL.EndTime = "01:29:59.999Z"
;
> > > > >> > >>
> > > > >> > >> However that is not the CF-compliant way of specifying
timing
> > > info.
> > > > >> So
> > > > >> > >> while MET will be able to read the data, the timing
info
> won't
> > be
> > > > >> > accurate
> > > > >> > >> in the MET output files. Instead, you'll see
"19700101"
> which
> > is
> > > > >> > unixtime
> > > > >> > >> = 0.
> > > > >> > >>
> > > > >> > >> Another option would be pulling the binary TRMM data
and
> using
> > > this
> > > > >> > >> Rscript
> > > > >> > >> to convert the binary to NetCDF:
> > > > >> > >>
http://www.dtcenter.org/met/users/downloads/Rscripts/
> > > > trmmbin2nc.R
> > > > >> > >>
> > > > >> > >> However, I haven't done this in a while and am not
sure if
> > you'll
> > > > run
> > > > >> > into
> > > > >> > >> any issues.
> > > > >> > >>
> > > > >> > >> Hope that helps.
> > > > >> > >>
> > > > >> > >> Thanks,
> > > > >> > >> John
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo via RT <
> > > > >> met_help at ucar.edu>
> > > > >> > >> wrote:
> > > > >> > >>
> > > > >> > >> >
> > > > >> > >> > <URL: https://rt.rap.ucar.edu/rt/
> > Ticket/Display.html?id=81063
> > > >
> > > > >> > >> >
> > > > >> > >> > Hi John,
> > > > >> > >> >
> > > > >> > >> > Thank you very much.
> > > > >> > >> > Regards,
> > > > >> > >> >
> > > > >> > >> > Jinwoong
> > > > >> > >> >
> > > > >> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John Halley Gotway
via RT
> <
> > > > >> > >> > met_help at ucar.edu> wrote:
> > > > >> > >> >
> > > > >> > >> > > Jinwoong,
> > > > >> > >> > >
> > > > >> > >> > > I'm out of the office today but will take a closer
look
> > > > tomorrow.
> > > > >> > >> > >
> > > > >> > >> > > Thanks
> > > > >> > >> > > John
> > > > >> > >> > >
> > > > >> > >> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo via
RT <
> > > > >> > >> met_help at ucar.edu>
> > > > >> > >> > > wrote:
> > > > >> > >> > >
> > > > >> > >> > > >
> > > > >> > >> > > > <URL: https://rt.rap.ucar.edu/rt/
> > > > Ticket/Display.html?id=81063
> > > > >> >
> > > > >> > >> > > >
> > > > >> > >> > > > Hi John,
> > > > >> > >> > > >
> > > > >> > >> > > > Thank you for your reply.
> > > > >> > >> > > > I uploaded my data as in Yoo_data4.tar on the
ftp site.
> > > > >> > >> > > > I included several files for the message of ID
of [
> > > > >> > rt.rap.ucar.edu
> > > > >> > >> > > #81074]
> > > > >> > >> > > > as well.
> > > > >> > >> > > > Thank you.
> > > > >> > >> > > > Regards,
> > > > >> > >> > > >
> > > > >> > >> > > > Jinwoong
> > > > >> > >> > > >
> > > > >> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM, John Halley
Gotway via
> > RT
> > > <
> > > > >> > >> > > > met_help at ucar.edu> wrote:
> > > > >> > >> > > >
> > > > >> > >> > > > > Jinwoong,
> > > > >> > >> > > > >
> > > > >> > >> > > > > I see that you're having trouble reading a
TRMM
> NetCDF
> > > file
> > > > >> into
> > > > >> > >> MET.
> > > > >> > >> > > > Can
> > > > >> > >> > > > > you please post the problematic file to our
anonymous
> > ftp
> > > > >> site
> > > > >> > so
> > > > >> > >> I
> > > > >> > >> > can
> > > > >> > >> > > > > take a look?
> > > > >> > >> > > > >
> > > > >> > >> > > > > http://www.dtcenter.org/met/
> > > users/support/met_help.php#ftp
> > > > >> > >> > > > >
> > > > >> > >> > > > > Thanks,
> > > > >> > >> > > > > John Halley Gotway
> > > > >> > >> > > > >
> > > > >> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo
via RT <
> > > > >> > >> > met_help at ucar.edu
> > > > >> > >> > > >
> > > > >> > >> > > > > wrote:
> > > > >> > >> > > > >
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > <URL: https://rt.rap.ucar.edu/rt/Tic
> > > > >> ket/Display.html?id=81063
> > > > >> > >
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > Hi,
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > TRMM data comes in as netCDF-4 classic
model.
> > > > >> > >> > > > > > I changed it to netCDF classic and run the
same
> > command
> > > > >> for a
> > > > >> > >> test.
> > > > >> > >> > > > > > But I got the same error as below.
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/
> > TRMM*
> > > $
> > > > >> > >> > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> > > > >> > >> /scratch/halstead/y/yoo108/
> > > > >> > >> > > TRMM/
> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/ND_
> grided_obs/daily_T2m_
> > > > >> > >> > > maxminmean_1976.nc
> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/TRMM/
> > regrid_trmm_sample.nc
> > > > >> -field
> > > > >> > >> > > > > > 'name="precipitation";'
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > DEBUG 1: Reading data file:
> > > > /scratch/halstead/y/yoo108/TRM
> > > > >> M/
> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > ERROR :
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > ERROR : process_data_file() ->
> > > > >> "/scratch/halstead/y/yoo108/TR
> > > > >> > >> MM/
> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc" not a valid
data
> file
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > Thank you.
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > Regards,
> > > > >> > >> > > > > >
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > Jinwoong
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong
Yoo <
> > > > >> > >> > > jinwoong.yoo at gmail.com>
> > > > >> > >> > > > > > wrote:
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > > Hi,
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > I noticed that TRMM data dimension was
(lon,
> lat).
> > > > >> > >> > > > > > > So I switched their order to (lat, lon)
and ran
> the
> > > > >> command
> > > > >> > >> > again.
> > > > >> > >> > > > > > > However, I got the same error message as
below.
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > yoo108 at halstead-fe00:*/
> scratch/halstead/y/yoo108/
> > > TRMM*
> > > > $
> > > > >> > >> > > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> > > > >> > >> > /scratch/halstead/y/yoo108/
> > > > >> > >> > > > > TRMM/
> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > > > /scratch/halstead/y/yoo108/ND_
> > > > >> > >> > > > > > > grided_obs/daily_T2m_maxminmean_1976.nc
> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > > > >> > >> > > > > TRMM/
> > > > >> > >> > > > > > > regrid_trmm_sample.nc -field
> > 'name="precipitation";'
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > DEBUG 1: Reading data file:
> > > > >> /scratch/halstead/y/yoo108/TRM
> > > > >> > M/
> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > ERROR :
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > ERROR : process_data_file() ->
> > > > >> > "/scratch/halstead/y/yoo108/TR
> > > > >> > >> > MM/
> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc" not a valid data
file
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > Thank you.
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > Regards,
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > Jinwoong
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong
Yoo <
> > > > >> > >> > > > jinwoong.yoo at gmail.com>
> > > > >> > >> > > > > > > wrote:
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > >> Hi,
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> I got a similar result with a TRMM data.
> > > > >> > >> > > > > > >> Please see below:
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/
> scratch/halstead/y/yoo108/
> > > > TRMM*
> > > > >> $
> > > > >> > >> > > > > > >> ~/met-6.0_bugfix/bin/regrid_data_plane
> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > > > >> > >> > > > > TRMM/
> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > > > >> /scratch/halstead/y/yoo108/ND_
> > > > >> > >> > > > > > >> grided_obs/daily_T2m_maxminmean_1976.nc
> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > > > >> > >> > > > > > TRMM/
> > > > >> > >> > > > > > >> regrid_trmm_sample.nc -field
> > > 'name="precipitation";'
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> DEBUG 1: Reading data file:
> > > > >> /scratch/halstead/y/yoo108/TRM
> > > > >> > M/
> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> ERROR : process_data_file() ->
> > > > >> > >> "/scratch/halstead/y/yoo108/TR
> > > > >> > >> > MM/
> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc" not a valid
data
> file
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> A part of ncdump output for the TRMM data
is
> > pasted
> > > > >> below:
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/
> scratch/halstead/y/yoo108/
> > > > TRMM*
> > > > >> $
> > > > >> > >> ncdump
> > > > >> > >> > > -h
> > > > >> > >> > > > > > >> subset_200003-200512/3B42RT_
> > > Daily.20051231.7.nc4.nc4
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> dimensions:
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lon = 59 ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lat = 58 ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> variables:
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> short precipitation_cnt(lon, lat) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation_cnt:units = "count" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation_cnt:long_name = "Count of
valid
> 3-hr
> > > > >> > >> precipitation
> > > > >> > >> > > > > > >> retrievals for the day" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation_cnt:coordinates = "lat lon"
;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation_cnt:origname =
> "precipitation_cnt" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation_cnt:fullnamepath =
> > > "/precipitation_cnt"
> > > > ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> float uncal_precipitation(lon, lat) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation:units = "mm" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation:long_name = "Daily
> accumulated
> > > > >> > >> uncalibrated
> > > > >> > >> > > > > > >> precipitation" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation:coordinates = "lat
lon" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation:_FillValue = -9999.9f
;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation:origname =
> > > "uncal_precipitation" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation:fullnamepath =
> > > > >> "/uncal_precipitation"
> > > > >> > ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> short uncal_precipitation_cnt(lon, lat) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation_cnt:units = "count" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation_cnt:long_name =
"Count of
> > valid
> > > > >> 3-hr
> > > > >> > >> uncal
> > > > >> > >> > > > > > >> precipitation retrievals for the day" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation_cnt:coordinates =
"lat
> lon" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation_cnt:origname =
> > > > >> > >> "uncal_precipitation_cnt" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation_cnt:fullnamepath =
> > > > >> > >> > > "/uncal_precipitation_cnt" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> float precipitation(lon, lat) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation:units = "mm" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation:long_name = "Daily
accumulated
> > > > >> precipitation
> > > > >> > >> > > (combined
> > > > >> > >> > > > > > >> microwave-IR) estimate" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation:coordinates = "lat lon" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation:_FillValue = -9999.9f ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation:origname = "precipitation"
;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation:fullnamepath =
"/precipitation" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> short randomError_cnt(lon, lat) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError_cnt:units = "count" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError_cnt:long_name = "Count of
> randomError
> > > for
> > > > >> the
> > > > >> > >> day" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError_cnt:coordinates = "lat lon" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError_cnt:origname =
"randomError_cnt" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError_cnt:fullnamepath =
> "/randomError_cnt"
> > ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> float randomError(lon, lat) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError:units = "mm" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError:long_name = "Daily total
error of
> > > combined
> > > > >> > >> > > microwave-IR
> > > > >> > >> > > > > > >> precipitation estimate" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError:_FillValue = -9999.9f ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError:origname = "randomError" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError:fullnamepath = "/randomError"
;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> float lat(lat) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lat:units = "degrees_north" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lat:long_name = "Latitude" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lat:origname = "lat" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lat:fullnamepath = "/lat" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> float lon(lon) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lon:units = "degrees_east" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lon:long_name = "Longitude" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lon:origname = "lon" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lon:fullnamepath = "/lon" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> Thank you.
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> Regards,
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> Jinwoong
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> On Thu, Jun 29, 2017 at 3:11 PM,
> > met_help at ucar.edu
> > > > via
> > > > >> RT
> > > > >> > <
> > > > >> > >> > > > > > >> met_help at ucar.edu> wrote:
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED
AVAILABILITY
> > BETWEEN
> > > > >> > 5/23/17
> > > > >> > >> AND
> > > > >> > >> > > > > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Greetings,
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> This message has been automatically
generated
> in
> > > > >> response
> > > > >> > to
> > > > >> > >> > the
> > > > >> > >> > > > > > >>> creation of a trouble ticket regarding:
> > > > >> > >> > > > > > >>> "regrid_data_plane: not a valid
data
> > file",
> > > > >> > >> > > > > > >>> a summary of which appears below.
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> There is no need to reply to this
message right
> > > now.
> > > > >> Your
> > > > >> > >> > ticket
> > > > >> > >> > > > has
> > > > >> > >> > > > > > >>> been
> > > > >> > >> > > > > > >>> assigned an ID of [rt.rap.ucar.edu
#81063].
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Please include the string:
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> [rt.rap.ucar.edu #81063]
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> in the subject line of all future
> correspondence
> > > > about
> > > > >> > this
> > > > >> > >> > > issue.
> > > > >> > >> > > > To
> > > > >> > >> > > > > > do
> > > > >> > >> > > > > > >>> so,
> > > > >> > >> > > > > > >>> you may reply to this message.
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Thank you,
> > > > >> > >> > > > > > >>>
met_help at ucar.edu
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> ------------------------------
> > > > >> > >> ------------------------------
> > > > >> > >> > > > > > >>> -------------
> > > > >> > >> > > > > > >>> Hi,
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> I am trying to regrid one of my
observation
> files
> > > in
> > > > >> lat
> > > > >> > lon
> > > > >> > >> > > > > coordinate
> > > > >> > >> > > > > > >>> grid to WRF curvilinear grid.
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> I ran bin/regrid_data_plane using a
sample lat
> > lon
> > > > grid
> > > > >> > file
> > > > >> > >> > and
> > > > >> > >> > > a
> > > > >> > >> > > > > file
> > > > >> > >> > > > > > >>> in
> > > > >> > >> > > > > > >>> the WRF grid. But I got error as shown
below:
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > > > >> > /halstead/y/yoo108/ND_grided_
> > > > >> > >> > obs*
> > > > >> > >> > > $
> > > > >> > >> > > > > > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
> > > > >> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/
> > > > >> sample_tmax.nc
> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > > grided_obs/daily_T2m_
> > > > >> > >> > > > > maxminmean_1976.nc
> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > > > >> > >> grided_obs/NDtoWRFgrid_sample_
> > > > >> > >> > > > tmax.nc
> > > > >> > >> > > > > > >>> -field
> > > > >> > >> > > > > > >>> 'name="tmax";'
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> DEBUG 1: Reading data file:
> > > > >> /scratch/halstead/y/yoo108/ND_
> > > > >> > >> > > > > grided_obs/
> > > > >> > >> > > > > > >>> sample_tmax.nc
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> ERROR : process_data_file() ->
> > > > >> > >> "/scratch/halstead/y/yoo108/ND
> > > > >> > >> > > > > > >>> _grided_obs/
> > > > >> > >> > > > > > >>> sample_tmax.nc" not a valid data file
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> I wonder which part of the input file
does not
> > > > satisfy
> > > > >> the
> > > > >> > >> > MET's
> > > > >> > >> > > > > "valid
> > > > >> > >> > > > > > >>> file" criteria.
> > > > >> > >> > > > > > >>> ncdump output of the input file looks as
below:
> > > > >> > >> > > > > > >>> Input file was originally generated by
VIC
> model
> > > and
> > > > >> > >> converted
> > > > >> > >> > > into
> > > > >> > >> > > > > cf
> > > > >> > >> > > > > > >>> netcdf format.
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Thank you in advance.
> > > > >> > >> > > > > > >>> Regards,
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Jinwoong
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > > > >> > /halstead/y/yoo108/ND_grided_
> > > > >> > >> > obs*
> > > > >> > >> > > $
> > > > >> > >> > > > > > >>> ncdump -h
> > > > >> > >> > > > > > >>> sample_tmax.nc
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> netcdf sample_tmax {
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> dimensions:
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> T = 1 ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> X = 55 ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Y = 65 ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> variables:
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> double T(T) ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> T:units = "days since 1915-01-01" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> T:long_name = "Time" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> double X(X) ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> X:units = "degrees_east" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> X:long_name = "Longitude" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> double Y(Y) ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Y:units = "degrees_north" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Y:long_name = "Latitude" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> double tmax(T, Y, X) ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> tmax:units = "degC" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> tmax:long_name = "tmax calculated by
VIC" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> tmax:missing_value = -9999.f ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> // global attributes:
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> :production = "VIC output" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > >
> > > > >> > >> > > > > >
> > > > >> > >> > > > >
> > > > >> > >> > > > >
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > >
> > > > >> > >> > >
> > > > >> > >> >
> > > > >> > >> >
> > > > >> > >>
> > > > >> > >>
> > > > >> > >
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Mon Jul 10 14:53:56 2017
Hi John,
I was able to open netcdf files that share the same coordinates with
WRF
output by copying the global attribute of the WRF output to these
netcdf
files:
ncks -A -x wrfout.nc target.nc
This enabled me to open netcdf files in MET using
'name="TT";level="(0,0,*,*)";file_type
= NETCDF_PINT;' argument.
Thank you very much!
Regards,
Jinwoong
On Mon, Jul 10, 2017 at 3:04 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Jinwoong,
>
> I tried running the sample file (daily_T2m_maxminmean_1981.nc)
through
> plot_data_plane and saw the same behavior you did. Looking closely
at that
> file I see that is not the NetCDF output generated by WRF. The
history
> attribute indicates that it was created by the "ncks" utility:
>
> :history = "Sun Jul 2 15:47:18 2017: ncks -d days,0,0
> /scratch/halstead/k/khoogewi/CCRC_wrf/analysis/T2m/daily_
> T2m_maxminmean_1981.nc
> /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> maxminmean_19810101.nc"
>
>
> This is not a CF-compliant NetCDF file and it does not look like the
output
> from WRF. Another alternative is making it look like the NetCDF
file
> format used by the MET tools themselves.
>
> I ran the following command to add global attributes to define the
grid
> spec for MET:
>
> ncatted \
> -a MET_version,global,o,c,"V6.0" \
> -a Projection,global,o,c,"Lambert Conformal" \
> -a scale_lat_1,global,o,c,"48" \
> -a scale_lat_2,global,o,c,"32" \
> -a lat_pin,global,o,c,"48" \
> -a lon_pin,global,o,c,"-97" \
> -a x_pin,global,o,c,"0" \
> -a y_pin,global,o,c,"0" \
> -a lon_orient,global,o,c,"-97" \
> -a d_km,global,o,c,"3" \
> -a r_km,global,o,c,"6371.2" \
> -a nx,global,o,c,"189" \
> -a ny,global,o,c,"270" \
> daily_T2m_maxminmean_1976.nc -o daily_T2m_maxminmean_1976_MET.nc
>
> However, I don't think these are all correct. Specifically, I don't
know
> how the "lon_orient" should be set. So I set it to the longitude of
the
> lower-left corner. Also, I don't know how the d_km should be set.
That's
> the grid spacing in km. So I just guess with a value of 3.
>
> This enables MET to plot the result, but you should work on making
the grid
> info correct:
> met-6.0/bin/plot_data_plane \
> daily_T2m_maxminmean_1976_MET.nc \
> daily_T2m_maxminmean_1976_MET.ps \
> 'name="T2m_max"; level="(10,*,*)";' -v 4
>
> Thanks,
> John
>
>
>
> On Fri, Jul 7, 2017 at 5:06 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >
> > Hi John,
> >
> > Thank you for your comment.
> > I tried it but it failed.
> > Please see below.
> >
> > yoo108 at halstead-
fe03:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal* $
> > ~/met-6.0_bugfix/bin/plot_data_plane
> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > maxminmean_20051231.nc
> > wrfDaily_T2m_maxminmean_20051231.ps
> > 'name="T2m_max";level="(0,*,*)";file_type = NETCDF_PINT;'
> >
> > DEBUG 1: Opening data file:
> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > maxminmean_20051231.nc
> >
> > ERROR : MetNcPinterpDataFile::open(const char *) -> unable to
open
> NetCDF
> > file
> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > maxminmean_20051231.nc"
> >
> > ERROR : Met2dDataFileFactory::new_met_2d_data_file() -> error
opening
> > file
> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > maxminmean_20051231.nc"
> >
> >
> >
> > One sample file (wrfDaily_T2m_maxminmean_19810101.nc) is also
included
> in
> > the Yoo_data4.tar file that I uploaded previously.
> > Thank you.
> > Haver a nice weekend.
> >
> > Regards,
> >
> > Jinwoong
> >
> >
> >
> > On Fri, Jul 7, 2017 at 6:04 PM, John Halley Gotway via RT <
> > met_help at ucar.edu
> > > wrote:
> >
> > > Jinwoong,
> > >
> > > If they really are output from WRF, one simple thing to try is
telling
> > MET
> > > to interpret them as the NetCDF output of the wrf_interp utility
> > > :
> > > file_type = NETCDF_PINT;
> > >
> > > "PINT" stands for "pressure interpolated"... pinterp was the
precursor
> to
> > > the current wrf_interp tool.
> > >
> > > If that doesn't work, I'll need to see a sample file before
making any
> > > other suggestions.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > >
> > > On Fri, Jul 7, 2017 at 3:36 PM, Jinwoong Yoo via RT
<met_help at ucar.edu
> >
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
> > > >
> > > > Hi John,
> > > >
> > > > I was able to read in a "home brew" netcdf data file using
> > > plot_data_plane.
> > > >
> > > > Then, I went ahead and tried another netcdf file in
curvilinear
> > > coordinate
> > > > which is in the same coordinate grid as my WRF output. But it
failed.
> > > >
> > > > I have many netcdf climatology files from the WRF simulation
such as
> > > daily,
> > > > monthly, and annual, etc. Therefore, they are all in
curvilinear
> > > coordinate
> > > > (Lambert).
> > > >
> > > > I wonder if there is any work around so that I can feed these
files
> > into
> > > > MET?
> > > > Or should I regrid them all into lat lon coordinate files
first?
> > > >
> > > > Thank you, John.
> > > >
> > > > Regards,
> > > >
> > > > Jinwoong Yoo
> > > >
> > > >
> > > > On Fri, Jul 7, 2017 at 3:01 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com
> >
> > > > wrote:
> > > >
> > > > > Hi John,
> > > > >
> > > > > Thank you very much.
> > > > > Let me try and let you know how it goes.
> > > > > Thank you.
> > > > > Regards,
> > > > >
> > > > > Jinwoong
> > > > >
> > > > > On Fri, Jul 7, 2017 at 2:59 PM, John Halley Gotway via RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > >> Jinwoong,
> > > > >>
> > > > >> Yes, you can give it a try. The closer you can make the
NetCDF
> > files
> > > to
> > > > >> the CF-convention, the more likely MET will be able to read
it.
> > > > >>
> > > > >> The reason that's its able to read the TRMM data are that
the
> > lat/lon
> > > > >> values are equally spaced. Non-equally spaced lat/lon
values on a
> > map
> > > > >> projection require that the map projection information be
> specified.
> > > > >> Unfortunately, specifying map projection information in
> CF-compliant
> > > > >> NetCDF
> > > > >> files is not as easy as I think it should be!
> > > > >>
> > > > >> Hope it works out ok for you.
> > > > >>
> > > > >> Thanks,
> > > > >> John
> > > > >>
> > > > >> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo via RT <
> > > met_help at ucar.edu
> > > > >
> > > > >> wrote:
> > > > >>
> > > > >> >
> > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > > > >> >
> > > > >> > investigating not investing :)
> > > > >> >
> > > > >> > Thanks!
> > > > >> > Regards,
> > > > >> >
> > > > >> > Jinwoong
> > > > >> >
> > > > >> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo <
> > > jinwoong.yoo at gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Hi John,
> > > > >> > >
> > > > >> > > Thank you very much for your time investing the issue.
> > > > >> > > I am glad to hear that there is a trick to work around
the
> issue
> > > to
> > > > >> read
> > > > >> > > in TRMM data in netcdf format.
> > > > >> > > I wonder if I can apply the same trick (
> file_type=NETCDF_NCCF;)
> > > to
> > > > >> read
> > > > >> > > in any other observation files in netcdf format?
> > > > >> > > In fact, I would like to read in "home brew" netcdf
dataset
> > files
> > > > into
> > > > >> > > MET.
> > > > >> > > One sample file of them was included in the uploaded
data
> > folder (
> > > > >> > > sample_tmax.nc).
> > > > >> > > The data in this sample file was originally generated
by VIC
> > > model.
> > > > >> > > Then the file format was converted into a generic
netcdf file
> > > format
> > > > >> > > although the dimension names are T, X, Y not time, lat,
lon.
> > > > >> > > But their coordinates have units in "degrees_east" or
> > > > "degrees_north"
> > > > >> as
> > > > >> > > well as their long_name as "Longitude" and "Latitude",
> > > respectively.
> > > > >> > >
> > > > >> > > Of course, I will try to read those in for Grid-stat
today.
> > > > >> > > But I would like to hear from you if the trick (
> > > > >> file_type=NETCDF_NCCF;)
> > > > >> > > can be applied generally, which I wish very much.
> > > > >> > >
> > > > >> > > Thank you so much, John.
> > > > >> > >
> > > > >> > > Regards,
> > > > >> > >
> > > > >> > > Jinwoong Yoo
> > > > >> > >
> > > > >> > >
> > > > >> > > On Fri, Jul 7, 2017 at 1:16 PM, John Halley Gotway via
RT <
> > > > >> > > met_help at ucar.edu> wrote:
> > > > >> > >
> > > > >> > >> Jinwoong,
> > > > >> > >>
> > > > >> > >> Thanks for sending your sample data and for your
patience
> > while I
> > > > was
> > > > >> > out
> > > > >> > >> of town.
> > > > >> > >>
> > > > >> > >> Using met-6.0, I'm able to process the TRMM NetCDF
file you
> > sent.
> > > > >> The
> > > > >> > >> trick is that I had to tell it which NetCDF file type
should
> be
> > > > used
> > > > >> to
> > > > >> > >> interpret the data. Using "file_type = NETCDF_NCCF;"
I'm
> > telling
> > > > >> MET to
> > > > >> > >> interpret it as if it were a CF-compliant NetCDF file:
> > > > >> > >>
> > > > >> > >> met-6.0/bin/plot_data_plane \
> > > > >> > >> trmm_daily.20051231.7.nc trmm_daily.20051231.7.ps \
> > > > >> > >> 'name="precipitation"; level="(*,*)";
file_type=NETCDF_NCCF;'
> > > > >> > >>
> > > > >> > >> DEBUG 1: Opening data file: trmm_daily.20051231.7.nc
> > > > >> > >> WARNING: NcCfFile::open() -> could not determine the
valid
> > time,
> > > > >> using
> > > > >> > 0.
> > > > >> > >> WARNING: NcCfFile::open() -> could not determine the
valid
> > time,
> > > > >> using
> > > > >> > 0.
> > > > >> > >> DEBUG 1: Creating postscript file:
trmm_daily.20051231.7.ps
> > > > >> > >>
> > > > >> > >> The plot_data_plane tool is able to read the data, and
I've
> > > > attached
> > > > >> the
> > > > >> > >> resulting image. However, notice the warning messages
about
> > the
> > > > >> valid
> > > > >> > >> time.
> > > > >> > >>
> > > > >> > >> Using ncdump to see that file attributes, I see this
timing
> > > > >> information:
> > > > >> > >> :HDF5_GLOBAL.BeginDate = "2005-12-31"
;
> > > > >> > >> :HDF5_GLOBAL.BeginTime =
"01:30:00.000Z" ;
> > > > >> > >> :HDF5_GLOBAL.EndDate = "2006-01-01" ;
> > > > >> > >> :HDF5_GLOBAL.EndTime = "01:29:59.999Z"
;
> > > > >> > >>
> > > > >> > >> However that is not the CF-compliant way of specifying
timing
> > > info.
> > > > >> So
> > > > >> > >> while MET will be able to read the data, the timing
info
> won't
> > be
> > > > >> > accurate
> > > > >> > >> in the MET output files. Instead, you'll see
"19700101"
> which
> > is
> > > > >> > unixtime
> > > > >> > >> = 0.
> > > > >> > >>
> > > > >> > >> Another option would be pulling the binary TRMM data
and
> using
> > > this
> > > > >> > >> Rscript
> > > > >> > >> to convert the binary to NetCDF:
> > > > >> > >>
http://www.dtcenter.org/met/users/downloads/Rscripts/
> > > > trmmbin2nc.R
> > > > >> > >>
> > > > >> > >> However, I haven't done this in a while and am not
sure if
> > you'll
> > > > run
> > > > >> > into
> > > > >> > >> any issues.
> > > > >> > >>
> > > > >> > >> Hope that helps.
> > > > >> > >>
> > > > >> > >> Thanks,
> > > > >> > >> John
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo via RT <
> > > > >> met_help at ucar.edu>
> > > > >> > >> wrote:
> > > > >> > >>
> > > > >> > >> >
> > > > >> > >> > <URL: https://rt.rap.ucar.edu/rt/
> > Ticket/Display.html?id=81063
> > > >
> > > > >> > >> >
> > > > >> > >> > Hi John,
> > > > >> > >> >
> > > > >> > >> > Thank you very much.
> > > > >> > >> > Regards,
> > > > >> > >> >
> > > > >> > >> > Jinwoong
> > > > >> > >> >
> > > > >> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John Halley Gotway
via RT
> <
> > > > >> > >> > met_help at ucar.edu> wrote:
> > > > >> > >> >
> > > > >> > >> > > Jinwoong,
> > > > >> > >> > >
> > > > >> > >> > > I'm out of the office today but will take a closer
look
> > > > tomorrow.
> > > > >> > >> > >
> > > > >> > >> > > Thanks
> > > > >> > >> > > John
> > > > >> > >> > >
> > > > >> > >> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo via
RT <
> > > > >> > >> met_help at ucar.edu>
> > > > >> > >> > > wrote:
> > > > >> > >> > >
> > > > >> > >> > > >
> > > > >> > >> > > > <URL: https://rt.rap.ucar.edu/rt/
> > > > Ticket/Display.html?id=81063
> > > > >> >
> > > > >> > >> > > >
> > > > >> > >> > > > Hi John,
> > > > >> > >> > > >
> > > > >> > >> > > > Thank you for your reply.
> > > > >> > >> > > > I uploaded my data as in Yoo_data4.tar on the
ftp site.
> > > > >> > >> > > > I included several files for the message of ID
of [
> > > > >> > rt.rap.ucar.edu
> > > > >> > >> > > #81074]
> > > > >> > >> > > > as well.
> > > > >> > >> > > > Thank you.
> > > > >> > >> > > > Regards,
> > > > >> > >> > > >
> > > > >> > >> > > > Jinwoong
> > > > >> > >> > > >
> > > > >> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM, John Halley
Gotway via
> > RT
> > > <
> > > > >> > >> > > > met_help at ucar.edu> wrote:
> > > > >> > >> > > >
> > > > >> > >> > > > > Jinwoong,
> > > > >> > >> > > > >
> > > > >> > >> > > > > I see that you're having trouble reading a
TRMM
> NetCDF
> > > file
> > > > >> into
> > > > >> > >> MET.
> > > > >> > >> > > > Can
> > > > >> > >> > > > > you please post the problematic file to our
anonymous
> > ftp
> > > > >> site
> > > > >> > so
> > > > >> > >> I
> > > > >> > >> > can
> > > > >> > >> > > > > take a look?
> > > > >> > >> > > > >
> > > > >> > >> > > > > http://www.dtcenter.org/met/
> > > users/support/met_help.php#ftp
> > > > >> > >> > > > >
> > > > >> > >> > > > > Thanks,
> > > > >> > >> > > > > John Halley Gotway
> > > > >> > >> > > > >
> > > > >> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo
via RT <
> > > > >> > >> > met_help at ucar.edu
> > > > >> > >> > > >
> > > > >> > >> > > > > wrote:
> > > > >> > >> > > > >
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > <URL: https://rt.rap.ucar.edu/rt/Tic
> > > > >> ket/Display.html?id=81063
> > > > >> > >
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > Hi,
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > TRMM data comes in as netCDF-4 classic
model.
> > > > >> > >> > > > > > I changed it to netCDF classic and run the
same
> > command
> > > > >> for a
> > > > >> > >> test.
> > > > >> > >> > > > > > But I got the same error as below.
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/
> > TRMM*
> > > $
> > > > >> > >> > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> > > > >> > >> /scratch/halstead/y/yoo108/
> > > > >> > >> > > TRMM/
> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/ND_
> grided_obs/daily_T2m_
> > > > >> > >> > > maxminmean_1976.nc
> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/TRMM/
> > regrid_trmm_sample.nc
> > > > >> -field
> > > > >> > >> > > > > > 'name="precipitation";'
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > DEBUG 1: Reading data file:
> > > > /scratch/halstead/y/yoo108/TRM
> > > > >> M/
> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > ERROR :
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > ERROR : process_data_file() ->
> > > > >> "/scratch/halstead/y/yoo108/TR
> > > > >> > >> MM/
> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc" not a valid
data
> file
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > Thank you.
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > Regards,
> > > > >> > >> > > > > >
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > Jinwoong
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong
Yoo <
> > > > >> > >> > > jinwoong.yoo at gmail.com>
> > > > >> > >> > > > > > wrote:
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > > Hi,
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > I noticed that TRMM data dimension was
(lon,
> lat).
> > > > >> > >> > > > > > > So I switched their order to (lat, lon)
and ran
> the
> > > > >> command
> > > > >> > >> > again.
> > > > >> > >> > > > > > > However, I got the same error message as
below.
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > yoo108 at halstead-fe00:*/
> scratch/halstead/y/yoo108/
> > > TRMM*
> > > > $
> > > > >> > >> > > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> > > > >> > >> > /scratch/halstead/y/yoo108/
> > > > >> > >> > > > > TRMM/
> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > > > /scratch/halstead/y/yoo108/ND_
> > > > >> > >> > > > > > > grided_obs/daily_T2m_maxminmean_1976.nc
> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > > > >> > >> > > > > TRMM/
> > > > >> > >> > > > > > > regrid_trmm_sample.nc -field
> > 'name="precipitation";'
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > DEBUG 1: Reading data file:
> > > > >> /scratch/halstead/y/yoo108/TRM
> > > > >> > M/
> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > ERROR :
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > ERROR : process_data_file() ->
> > > > >> > "/scratch/halstead/y/yoo108/TR
> > > > >> > >> > MM/
> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc" not a valid data
file
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > Thank you.
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > Regards,
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > Jinwoong
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong
Yoo <
> > > > >> > >> > > > jinwoong.yoo at gmail.com>
> > > > >> > >> > > > > > > wrote:
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > >> Hi,
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> I got a similar result with a TRMM data.
> > > > >> > >> > > > > > >> Please see below:
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/
> scratch/halstead/y/yoo108/
> > > > TRMM*
> > > > >> $
> > > > >> > >> > > > > > >> ~/met-6.0_bugfix/bin/regrid_data_plane
> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > > > >> > >> > > > > TRMM/
> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > > > >> /scratch/halstead/y/yoo108/ND_
> > > > >> > >> > > > > > >> grided_obs/daily_T2m_maxminmean_1976.nc
> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > > > >> > >> > > > > > TRMM/
> > > > >> > >> > > > > > >> regrid_trmm_sample.nc -field
> > > 'name="precipitation";'
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> DEBUG 1: Reading data file:
> > > > >> /scratch/halstead/y/yoo108/TRM
> > > > >> > M/
> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> ERROR : process_data_file() ->
> > > > >> > >> "/scratch/halstead/y/yoo108/TR
> > > > >> > >> > MM/
> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc" not a valid
data
> file
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> A part of ncdump output for the TRMM data
is
> > pasted
> > > > >> below:
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/
> scratch/halstead/y/yoo108/
> > > > TRMM*
> > > > >> $
> > > > >> > >> ncdump
> > > > >> > >> > > -h
> > > > >> > >> > > > > > >> subset_200003-200512/3B42RT_
> > > Daily.20051231.7.nc4.nc4
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> dimensions:
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lon = 59 ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lat = 58 ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> variables:
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> short precipitation_cnt(lon, lat) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation_cnt:units = "count" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation_cnt:long_name = "Count of
valid
> 3-hr
> > > > >> > >> precipitation
> > > > >> > >> > > > > > >> retrievals for the day" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation_cnt:coordinates = "lat lon"
;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation_cnt:origname =
> "precipitation_cnt" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation_cnt:fullnamepath =
> > > "/precipitation_cnt"
> > > > ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> float uncal_precipitation(lon, lat) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation:units = "mm" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation:long_name = "Daily
> accumulated
> > > > >> > >> uncalibrated
> > > > >> > >> > > > > > >> precipitation" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation:coordinates = "lat
lon" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation:_FillValue = -9999.9f
;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation:origname =
> > > "uncal_precipitation" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation:fullnamepath =
> > > > >> "/uncal_precipitation"
> > > > >> > ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> short uncal_precipitation_cnt(lon, lat) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation_cnt:units = "count" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation_cnt:long_name =
"Count of
> > valid
> > > > >> 3-hr
> > > > >> > >> uncal
> > > > >> > >> > > > > > >> precipitation retrievals for the day" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation_cnt:coordinates =
"lat
> lon" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation_cnt:origname =
> > > > >> > >> "uncal_precipitation_cnt" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> uncal_precipitation_cnt:fullnamepath =
> > > > >> > >> > > "/uncal_precipitation_cnt" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> float precipitation(lon, lat) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation:units = "mm" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation:long_name = "Daily
accumulated
> > > > >> precipitation
> > > > >> > >> > > (combined
> > > > >> > >> > > > > > >> microwave-IR) estimate" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation:coordinates = "lat lon" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation:_FillValue = -9999.9f ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation:origname = "precipitation"
;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> precipitation:fullnamepath =
"/precipitation" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> short randomError_cnt(lon, lat) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError_cnt:units = "count" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError_cnt:long_name = "Count of
> randomError
> > > for
> > > > >> the
> > > > >> > >> day" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError_cnt:coordinates = "lat lon" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError_cnt:origname =
"randomError_cnt" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError_cnt:fullnamepath =
> "/randomError_cnt"
> > ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> float randomError(lon, lat) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError:units = "mm" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError:long_name = "Daily total
error of
> > > combined
> > > > >> > >> > > microwave-IR
> > > > >> > >> > > > > > >> precipitation estimate" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError:_FillValue = -9999.9f ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError:origname = "randomError" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> randomError:fullnamepath = "/randomError"
;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> float lat(lat) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lat:units = "degrees_north" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lat:long_name = "Latitude" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lat:origname = "lat" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lat:fullnamepath = "/lat" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> float lon(lon) ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lon:units = "degrees_east" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lon:long_name = "Longitude" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lon:origname = "lon" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> lon:fullnamepath = "/lon" ;
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> Thank you.
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> Regards,
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> Jinwoong
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >> On Thu, Jun 29, 2017 at 3:11 PM,
> > met_help at ucar.edu
> > > > via
> > > > >> RT
> > > > >> > <
> > > > >> > >> > > > > > >> met_help at ucar.edu> wrote:
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED
AVAILABILITY
> > BETWEEN
> > > > >> > 5/23/17
> > > > >> > >> AND
> > > > >> > >> > > > > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Greetings,
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> This message has been automatically
generated
> in
> > > > >> response
> > > > >> > to
> > > > >> > >> > the
> > > > >> > >> > > > > > >>> creation of a trouble ticket regarding:
> > > > >> > >> > > > > > >>> "regrid_data_plane: not a valid
data
> > file",
> > > > >> > >> > > > > > >>> a summary of which appears below.
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> There is no need to reply to this
message right
> > > now.
> > > > >> Your
> > > > >> > >> > ticket
> > > > >> > >> > > > has
> > > > >> > >> > > > > > >>> been
> > > > >> > >> > > > > > >>> assigned an ID of [rt.rap.ucar.edu
#81063].
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Please include the string:
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> [rt.rap.ucar.edu #81063]
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> in the subject line of all future
> correspondence
> > > > about
> > > > >> > this
> > > > >> > >> > > issue.
> > > > >> > >> > > > To
> > > > >> > >> > > > > > do
> > > > >> > >> > > > > > >>> so,
> > > > >> > >> > > > > > >>> you may reply to this message.
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Thank you,
> > > > >> > >> > > > > > >>>
met_help at ucar.edu
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> ------------------------------
> > > > >> > >> ------------------------------
> > > > >> > >> > > > > > >>> -------------
> > > > >> > >> > > > > > >>> Hi,
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> I am trying to regrid one of my
observation
> files
> > > in
> > > > >> lat
> > > > >> > lon
> > > > >> > >> > > > > coordinate
> > > > >> > >> > > > > > >>> grid to WRF curvilinear grid.
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> I ran bin/regrid_data_plane using a
sample lat
> > lon
> > > > grid
> > > > >> > file
> > > > >> > >> > and
> > > > >> > >> > > a
> > > > >> > >> > > > > file
> > > > >> > >> > > > > > >>> in
> > > > >> > >> > > > > > >>> the WRF grid. But I got error as shown
below:
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > > > >> > /halstead/y/yoo108/ND_grided_
> > > > >> > >> > obs*
> > > > >> > >> > > $
> > > > >> > >> > > > > > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
> > > > >> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/
> > > > >> sample_tmax.nc
> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > > grided_obs/daily_T2m_
> > > > >> > >> > > > > maxminmean_1976.nc
> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > > > >> > >> grided_obs/NDtoWRFgrid_sample_
> > > > >> > >> > > > tmax.nc
> > > > >> > >> > > > > > >>> -field
> > > > >> > >> > > > > > >>> 'name="tmax";'
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> DEBUG 1: Reading data file:
> > > > >> /scratch/halstead/y/yoo108/ND_
> > > > >> > >> > > > > grided_obs/
> > > > >> > >> > > > > > >>> sample_tmax.nc
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> ERROR : process_data_file() ->
> > > > >> > >> "/scratch/halstead/y/yoo108/ND
> > > > >> > >> > > > > > >>> _grided_obs/
> > > > >> > >> > > > > > >>> sample_tmax.nc" not a valid data file
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> I wonder which part of the input file
does not
> > > > satisfy
> > > > >> the
> > > > >> > >> > MET's
> > > > >> > >> > > > > "valid
> > > > >> > >> > > > > > >>> file" criteria.
> > > > >> > >> > > > > > >>> ncdump output of the input file looks as
below:
> > > > >> > >> > > > > > >>> Input file was originally generated by
VIC
> model
> > > and
> > > > >> > >> converted
> > > > >> > >> > > into
> > > > >> > >> > > > > cf
> > > > >> > >> > > > > > >>> netcdf format.
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Thank you in advance.
> > > > >> > >> > > > > > >>> Regards,
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Jinwoong
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > > > >> > /halstead/y/yoo108/ND_grided_
> > > > >> > >> > obs*
> > > > >> > >> > > $
> > > > >> > >> > > > > > >>> ncdump -h
> > > > >> > >> > > > > > >>> sample_tmax.nc
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> netcdf sample_tmax {
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> dimensions:
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> T = 1 ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> X = 55 ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Y = 65 ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> variables:
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> double T(T) ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> T:units = "days since 1915-01-01" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> T:long_name = "Time" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> double X(X) ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> X:units = "degrees_east" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> X:long_name = "Longitude" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> double Y(Y) ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Y:units = "degrees_north" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> Y:long_name = "Latitude" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> double tmax(T, Y, X) ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> tmax:units = "degC" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> tmax:long_name = "tmax calculated by
VIC" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> tmax:missing_value = -9999.f ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> // global attributes:
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>> :production = "VIC output" ;
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>>
> > > > >> > >> > > > > > >>
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > >
> > > > >> > >> > > > > >
> > > > >> > >> > > > >
> > > > >> > >> > > > >
> > > > >> > >> > > >
> > > > >> > >> > > >
> > > > >> > >> > >
> > > > >> > >> > >
> > > > >> > >> >
> > > > >> > >> >
> > > > >> > >>
> > > > >> > >>
> > > > >> > >
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Tue Jul 11 09:12:38 2017
Hi John,
Now I am trying to execute grid_stat against these netcdf files that
have
been patted with the WRF global attributes.
I tried to include 'file_type = NETCDF_PINT;' argument both in its
configuration file and in the command line.
However, both failed to run (Please see below).
Could you please guide me how to specify the netcdf file type in the
grid_stat application?
Thank you.
Regards,
Jinwoong
1.
.......
obs = {
field = [
{
name = "TT";
level = [ "(0,0,*,*)" ];
file_type = NETCDF_PINT;
cat_thresh = [];
}
.......
DEBUG 1: Default Config File:
/home/yoo108/met-6.0_bugfix/share/met/config/GridStatConfig_default
DEBUG 1: User Config File:
/scratch/halstead/y/yoo108/wrfAnalysis/METanal/GridStatConfig_met_em
DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() -> created new
Met2dDataFile object of type "FileType_Gb2".
DEBUG 4: Switching the GRIB2 radius of the earth value of 6371.23 km
to
6371.2 km for internal consistency.
DEBUG 4:
DEBUG 4: Lambert Conformal Grid Data:
DEBUG 4: scale_lat_1: 48
DEBUG 4: scale_lat_2: 32
DEBUG 4: lat_pin: 36.9132
DEBUG 4: lon_pin: 92.0748
DEBUG 4: x_pin: 0
DEBUG 4: y_pin: 0
DEBUG 4: lon_orient: 97
DEBUG 4: d_km: 4
DEBUG 4: r_km: 6371.2
DEBUG 4: nx: 189
DEBUG 4: ny: 270
DEBUG 4:
DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() -> created new
Met2dDataFile object of type "FileType_None".
ERROR :
ERROR : Trouble reading observation file
"/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.1980-01-
01_00:00:00.nc
"
2.
/home/yoo108/met-6.0_bugfix/bin/grid_stat
$dir_data/$yyyy/$yyyy$nummon/
$grib_date1 $dir_data2/$met_em_date1 $analDir/$GridStatConfig
'file_type =
NETCDF_PINT;' -outdir $workDir -v 4
*** Model Evaluation Tools (METV6.0) ***
Usage: grid_stat
fcst_file
obs_file
config_file
[-outdir path]
[-log file]
[-v level]
[-compress level]
where "fcst_file" is a gridded forecast file containing the field(s)
to be
verified (required).
"obs_file" is a gridded observation file containing the verifying
field(s)
(required).
"config_file" is a GridStatConfig file containing the desired
configuration
settings (required).
"-outdir path" overrides the default output directory
(/scratch/halstead/y/yoo108/wrfAnalysis/METanal/wrf2met_em)
(optional).
"-log file" outputs log messages to the specified file (optional).
"-v level" overrides the default level of logging (4) (optional).
"-compress level" overrides the compression level of NetCDF variable
(0)
(optional).
On Mon, Jul 10, 2017 at 4:53 PM, Jinwoong Yoo <jinwoong.yoo at gmail.com>
wrote:
> Hi John,
>
> I was able to open netcdf files that share the same coordinates with
WRF
> output by copying the global attribute of the WRF output to these
netcdf
> files:
>
> ncks -A -x wrfout.nc target.nc
>
> This enabled me to open netcdf files in MET using
> 'name="TT";level="(0,0,*,*)";file_type = NETCDF_PINT;' argument.
>
> Thank you very much!
> Regards,
>
> Jinwoong
>
> On Mon, Jul 10, 2017 at 3:04 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Jinwoong,
>>
>> I tried running the sample file (daily_T2m_maxminmean_1981.nc)
through
>> plot_data_plane and saw the same behavior you did. Looking closely
at
>> that
>> file I see that is not the NetCDF output generated by WRF. The
history
>> attribute indicates that it was created by the "ncks" utility:
>>
>> :history = "Sun Jul 2 15:47:18 2017: ncks -d days,0,0
>> /scratch/halstead/k/khoogewi/CCRC_wrf/analysis/T2m/daily_T2m_
>> maxminmean_1981.nc
>> /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_maxminm
>> ean_19810101.nc"
>>
>>
>> This is not a CF-compliant NetCDF file and it does not look like
the
>> output
>> from WRF. Another alternative is making it look like the NetCDF
file
>> format used by the MET tools themselves.
>>
>> I ran the following command to add global attributes to define the
grid
>> spec for MET:
>>
>> ncatted \
>> -a MET_version,global,o,c,"V6.0" \
>> -a Projection,global,o,c,"Lambert Conformal" \
>> -a scale_lat_1,global,o,c,"48" \
>> -a scale_lat_2,global,o,c,"32" \
>> -a lat_pin,global,o,c,"48" \
>> -a lon_pin,global,o,c,"-97" \
>> -a x_pin,global,o,c,"0" \
>> -a y_pin,global,o,c,"0" \
>> -a lon_orient,global,o,c,"-97" \
>> -a d_km,global,o,c,"3" \
>> -a r_km,global,o,c,"6371.2" \
>> -a nx,global,o,c,"189" \
>> -a ny,global,o,c,"270" \
>> daily_T2m_maxminmean_1976.nc -o daily_T2m_maxminmean_1976_MET.nc
>>
>> However, I don't think these are all correct. Specifically, I
don't know
>> how the "lon_orient" should be set. So I set it to the longitude
of the
>> lower-left corner. Also, I don't know how the d_km should be set.
That's
>> the grid spacing in km. So I just guess with a value of 3.
>>
>> This enables MET to plot the result, but you should work on making
the
>> grid
>> info correct:
>> met-6.0/bin/plot_data_plane \
>> daily_T2m_maxminmean_1976_MET.nc \
>> daily_T2m_maxminmean_1976_MET.ps \
>> 'name="T2m_max"; level="(10,*,*)";' -v 4
>>
>> Thanks,
>> John
>>
>>
>>
>> On Fri, Jul 7, 2017 at 5:06 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
>> wrote:
>>
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>> >
>> > Hi John,
>> >
>> > Thank you for your comment.
>> > I tried it but it failed.
>> > Please see below.
>> >
>> > yoo108 at halstead-
fe03:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal* $
>> > ~/met-6.0_bugfix/bin/plot_data_plane
>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
>> > maxminmean_20051231.nc
>> > wrfDaily_T2m_maxminmean_20051231.ps
>> > 'name="T2m_max";level="(0,*,*)";file_type = NETCDF_PINT;'
>> >
>> > DEBUG 1: Opening data file:
>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
>> > maxminmean_20051231.nc
>> >
>> > ERROR : MetNcPinterpDataFile::open(const char *) -> unable to
open
>> NetCDF
>> > file
>> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
>> > maxminmean_20051231.nc"
>> >
>> > ERROR : Met2dDataFileFactory::new_met_2d_data_file() -> error
opening
>> > file
>> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
>> > maxminmean_20051231.nc"
>> >
>> >
>> >
>> > One sample file (wrfDaily_T2m_maxminmean_19810101.nc) is also
included
>> in
>> > the Yoo_data4.tar file that I uploaded previously.
>> > Thank you.
>> > Haver a nice weekend.
>> >
>> > Regards,
>> >
>> > Jinwoong
>> >
>> >
>> >
>> > On Fri, Jul 7, 2017 at 6:04 PM, John Halley Gotway via RT <
>> > met_help at ucar.edu
>> > > wrote:
>> >
>> > > Jinwoong,
>> > >
>> > > If they really are output from WRF, one simple thing to try is
telling
>> > MET
>> > > to interpret them as the NetCDF output of the wrf_interp
utility
>> > > :
>> > > file_type = NETCDF_PINT;
>> > >
>> > > "PINT" stands for "pressure interpolated"... pinterp was the
>> precursor to
>> > > the current wrf_interp tool.
>> > >
>> > > If that doesn't work, I'll need to see a sample file before
making any
>> > > other suggestions.
>> > >
>> > > Thanks,
>> > > John
>> > >
>> > >
>> > >
>> > > On Fri, Jul 7, 2017 at 3:36 PM, Jinwoong Yoo via RT <
>> met_help at ucar.edu>
>> > > wrote:
>> > >
>> > > >
>> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
>> > > >
>> > > > Hi John,
>> > > >
>> > > > I was able to read in a "home brew" netcdf data file using
>> > > plot_data_plane.
>> > > >
>> > > > Then, I went ahead and tried another netcdf file in
curvilinear
>> > > coordinate
>> > > > which is in the same coordinate grid as my WRF output. But it
>> failed.
>> > > >
>> > > > I have many netcdf climatology files from the WRF simulation
such as
>> > > daily,
>> > > > monthly, and annual, etc. Therefore, they are all in
curvilinear
>> > > coordinate
>> > > > (Lambert).
>> > > >
>> > > > I wonder if there is any work around so that I can feed these
files
>> > into
>> > > > MET?
>> > > > Or should I regrid them all into lat lon coordinate files
first?
>> > > >
>> > > > Thank you, John.
>> > > >
>> > > > Regards,
>> > > >
>> > > > Jinwoong Yoo
>> > > >
>> > > >
>> > > > On Fri, Jul 7, 2017 at 3:01 PM, Jinwoong Yoo <
>> jinwoong.yoo at gmail.com>
>> > > > wrote:
>> > > >
>> > > > > Hi John,
>> > > > >
>> > > > > Thank you very much.
>> > > > > Let me try and let you know how it goes.
>> > > > > Thank you.
>> > > > > Regards,
>> > > > >
>> > > > > Jinwoong
>> > > > >
>> > > > > On Fri, Jul 7, 2017 at 2:59 PM, John Halley Gotway via RT <
>> > > > > met_help at ucar.edu> wrote:
>> > > > >
>> > > > >> Jinwoong,
>> > > > >>
>> > > > >> Yes, you can give it a try. The closer you can make the
NetCDF
>> > files
>> > > to
>> > > > >> the CF-convention, the more likely MET will be able to
read it.
>> > > > >>
>> > > > >> The reason that's its able to read the TRMM data are that
the
>> > lat/lon
>> > > > >> values are equally spaced. Non-equally spaced lat/lon
values on
>> a
>> > map
>> > > > >> projection require that the map projection information be
>> specified.
>> > > > >> Unfortunately, specifying map projection information in
>> CF-compliant
>> > > > >> NetCDF
>> > > > >> files is not as easy as I think it should be!
>> > > > >>
>> > > > >> Hope it works out ok for you.
>> > > > >>
>> > > > >> Thanks,
>> > > > >> John
>> > > > >>
>> > > > >> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo via RT <
>> > > met_help at ucar.edu
>> > > > >
>> > > > >> wrote:
>> > > > >>
>> > > > >> >
>> > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>> >
>> > > > >> >
>> > > > >> > investigating not investing :)
>> > > > >> >
>> > > > >> > Thanks!
>> > > > >> > Regards,
>> > > > >> >
>> > > > >> > Jinwoong
>> > > > >> >
>> > > > >> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo <
>> > > jinwoong.yoo at gmail.com>
>> > > > >> > wrote:
>> > > > >> >
>> > > > >> > > Hi John,
>> > > > >> > >
>> > > > >> > > Thank you very much for your time investing the issue.
>> > > > >> > > I am glad to hear that there is a trick to work around
the
>> issue
>> > > to
>> > > > >> read
>> > > > >> > > in TRMM data in netcdf format.
>> > > > >> > > I wonder if I can apply the same trick (
>> file_type=NETCDF_NCCF;)
>> > > to
>> > > > >> read
>> > > > >> > > in any other observation files in netcdf format?
>> > > > >> > > In fact, I would like to read in "home brew" netcdf
dataset
>> > files
>> > > > into
>> > > > >> > > MET.
>> > > > >> > > One sample file of them was included in the uploaded
data
>> > folder (
>> > > > >> > > sample_tmax.nc).
>> > > > >> > > The data in this sample file was originally generated
by VIC
>> > > model.
>> > > > >> > > Then the file format was converted into a generic
netcdf file
>> > > format
>> > > > >> > > although the dimension names are T, X, Y not time,
lat, lon.
>> > > > >> > > But their coordinates have units in "degrees_east" or
>> > > > "degrees_north"
>> > > > >> as
>> > > > >> > > well as their long_name as "Longitude" and "Latitude",
>> > > respectively.
>> > > > >> > >
>> > > > >> > > Of course, I will try to read those in for Grid-stat
today.
>> > > > >> > > But I would like to hear from you if the trick (
>> > > > >> file_type=NETCDF_NCCF;)
>> > > > >> > > can be applied generally, which I wish very much.
>> > > > >> > >
>> > > > >> > > Thank you so much, John.
>> > > > >> > >
>> > > > >> > > Regards,
>> > > > >> > >
>> > > > >> > > Jinwoong Yoo
>> > > > >> > >
>> > > > >> > >
>> > > > >> > > On Fri, Jul 7, 2017 at 1:16 PM, John Halley Gotway via
RT <
>> > > > >> > > met_help at ucar.edu> wrote:
>> > > > >> > >
>> > > > >> > >> Jinwoong,
>> > > > >> > >>
>> > > > >> > >> Thanks for sending your sample data and for your
patience
>> > while I
>> > > > was
>> > > > >> > out
>> > > > >> > >> of town.
>> > > > >> > >>
>> > > > >> > >> Using met-6.0, I'm able to process the TRMM NetCDF
file you
>> > sent.
>> > > > >> The
>> > > > >> > >> trick is that I had to tell it which NetCDF file type
>> should be
>> > > > used
>> > > > >> to
>> > > > >> > >> interpret the data. Using "file_type = NETCDF_NCCF;"
I'm
>> > telling
>> > > > >> MET to
>> > > > >> > >> interpret it as if it were a CF-compliant NetCDF
file:
>> > > > >> > >>
>> > > > >> > >> met-6.0/bin/plot_data_plane \
>> > > > >> > >> trmm_daily.20051231.7.nc trmm_daily.20051231.7.ps \
>> > > > >> > >> 'name="precipitation"; level="(*,*)";
>> file_type=NETCDF_NCCF;'
>> > > > >> > >>
>> > > > >> > >> DEBUG 1: Opening data file: trmm_daily.20051231.7.nc
>> > > > >> > >> WARNING: NcCfFile::open() -> could not determine the
valid
>> > time,
>> > > > >> using
>> > > > >> > 0.
>> > > > >> > >> WARNING: NcCfFile::open() -> could not determine the
valid
>> > time,
>> > > > >> using
>> > > > >> > 0.
>> > > > >> > >> DEBUG 1: Creating postscript file:
trmm_daily.20051231.7.ps
>> > > > >> > >>
>> > > > >> > >> The plot_data_plane tool is able to read the data,
and I've
>> > > > attached
>> > > > >> the
>> > > > >> > >> resulting image. However, notice the warning
messages about
>> > the
>> > > > >> valid
>> > > > >> > >> time.
>> > > > >> > >>
>> > > > >> > >> Using ncdump to see that file attributes, I see this
timing
>> > > > >> information:
>> > > > >> > >> :HDF5_GLOBAL.BeginDate = "2005-12-31"
;
>> > > > >> > >> :HDF5_GLOBAL.BeginTime =
"01:30:00.000Z" ;
>> > > > >> > >> :HDF5_GLOBAL.EndDate = "2006-01-01" ;
>> > > > >> > >> :HDF5_GLOBAL.EndTime =
"01:29:59.999Z" ;
>> > > > >> > >>
>> > > > >> > >> However that is not the CF-compliant way of
specifying
>> timing
>> > > info.
>> > > > >> So
>> > > > >> > >> while MET will be able to read the data, the timing
info
>> won't
>> > be
>> > > > >> > accurate
>> > > > >> > >> in the MET output files. Instead, you'll see
"19700101"
>> which
>> > is
>> > > > >> > unixtime
>> > > > >> > >> = 0.
>> > > > >> > >>
>> > > > >> > >> Another option would be pulling the binary TRMM data
and
>> using
>> > > this
>> > > > >> > >> Rscript
>> > > > >> > >> to convert the binary to NetCDF:
>> > > > >> > >>
http://www.dtcenter.org/met/users/downloads/Rscripts/
>> > > > trmmbin2nc.R
>> > > > >> > >>
>> > > > >> > >> However, I haven't done this in a while and am not
sure if
>> > you'll
>> > > > run
>> > > > >> > into
>> > > > >> > >> any issues.
>> > > > >> > >>
>> > > > >> > >> Hope that helps.
>> > > > >> > >>
>> > > > >> > >> Thanks,
>> > > > >> > >> John
>> > > > >> > >>
>> > > > >> > >>
>> > > > >> > >>
>> > > > >> > >>
>> > > > >> > >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo via RT <
>> > > > >> met_help at ucar.edu>
>> > > > >> > >> wrote:
>> > > > >> > >>
>> > > > >> > >> >
>> > > > >> > >> > <URL: https://rt.rap.ucar.edu/rt/
>> > Ticket/Display.html?id=81063
>> > > >
>> > > > >> > >> >
>> > > > >> > >> > Hi John,
>> > > > >> > >> >
>> > > > >> > >> > Thank you very much.
>> > > > >> > >> > Regards,
>> > > > >> > >> >
>> > > > >> > >> > Jinwoong
>> > > > >> > >> >
>> > > > >> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John Halley Gotway
via
>> RT <
>> > > > >> > >> > met_help at ucar.edu> wrote:
>> > > > >> > >> >
>> > > > >> > >> > > Jinwoong,
>> > > > >> > >> > >
>> > > > >> > >> > > I'm out of the office today but will take a
closer look
>> > > > tomorrow.
>> > > > >> > >> > >
>> > > > >> > >> > > Thanks
>> > > > >> > >> > > John
>> > > > >> > >> > >
>> > > > >> > >> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo via
RT <
>> > > > >> > >> met_help at ucar.edu>
>> > > > >> > >> > > wrote:
>> > > > >> > >> > >
>> > > > >> > >> > > >
>> > > > >> > >> > > > <URL: https://rt.rap.ucar.edu/rt/
>> > > > Ticket/Display.html?id=81063
>> > > > >> >
>> > > > >> > >> > > >
>> > > > >> > >> > > > Hi John,
>> > > > >> > >> > > >
>> > > > >> > >> > > > Thank you for your reply.
>> > > > >> > >> > > > I uploaded my data as in Yoo_data4.tar on the
ftp
>> site.
>> > > > >> > >> > > > I included several files for the message of ID
of [
>> > > > >> > rt.rap.ucar.edu
>> > > > >> > >> > > #81074]
>> > > > >> > >> > > > as well.
>> > > > >> > >> > > > Thank you.
>> > > > >> > >> > > > Regards,
>> > > > >> > >> > > >
>> > > > >> > >> > > > Jinwoong
>> > > > >> > >> > > >
>> > > > >> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM, John Halley
Gotway
>> via
>> > RT
>> > > <
>> > > > >> > >> > > > met_help at ucar.edu> wrote:
>> > > > >> > >> > > >
>> > > > >> > >> > > > > Jinwoong,
>> > > > >> > >> > > > >
>> > > > >> > >> > > > > I see that you're having trouble reading a
TRMM
>> NetCDF
>> > > file
>> > > > >> into
>> > > > >> > >> MET.
>> > > > >> > >> > > > Can
>> > > > >> > >> > > > > you please post the problematic file to our
>> anonymous
>> > ftp
>> > > > >> site
>> > > > >> > so
>> > > > >> > >> I
>> > > > >> > >> > can
>> > > > >> > >> > > > > take a look?
>> > > > >> > >> > > > >
>> > > > >> > >> > > > > http://www.dtcenter.org/met/
>> > > users/support/met_help.php#ftp
>> > > > >> > >> > > > >
>> > > > >> > >> > > > > Thanks,
>> > > > >> > >> > > > > John Halley Gotway
>> > > > >> > >> > > > >
>> > > > >> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo
via RT
>> <
>> > > > >> > >> > met_help at ucar.edu
>> > > > >> > >> > > >
>> > > > >> > >> > > > > wrote:
>> > > > >> > >> > > > >
>> > > > >> > >> > > > > >
>> > > > >> > >> > > > > > <URL: https://rt.rap.ucar.edu/rt/Tic
>> > > > >> ket/Display.html?id=81063
>> > > > >> > >
>> > > > >> > >> > > > > >
>> > > > >> > >> > > > > > Hi,
>> > > > >> > >> > > > > >
>> > > > >> > >> > > > > > TRMM data comes in as netCDF-4 classic
model.
>> > > > >> > >> > > > > > I changed it to netCDF classic and run the
same
>> > command
>> > > > >> for a
>> > > > >> > >> test.
>> > > > >> > >> > > > > > But I got the same error as below.
>> > > > >> > >> > > > > >
>> > > > >> > >> > > > > > yoo108 at halstead-
fe00:*/scratch/halstead/y/yoo108/
>> > TRMM*
>> > > $
>> > > > >> > >> > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
>> > > > >> > >> /scratch/halstead/y/yoo108/
>> > > > >> > >> > > TRMM/
>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
>> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/ND_
>> grided_obs/daily_T2m_
>> > > > >> > >> > > maxminmean_1976.nc
>> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/TRMM/
>> > regrid_trmm_sample.nc
>> > > > >> -field
>> > > > >> > >> > > > > > 'name="precipitation";'
>> > > > >> > >> > > > > >
>> > > > >> > >> > > > > > DEBUG 1: Reading data file:
>> > > > /scratch/halstead/y/yoo108/TRM
>> > > > >> M/
>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
>> > > > >> > >> > > > > >
>> > > > >> > >> > > > > > ERROR :
>> > > > >> > >> > > > > >
>> > > > >> > >> > > > > > ERROR : process_data_file() ->
>> > > > >> "/scratch/halstead/y/yoo108/TR
>> > > > >> > >> MM/
>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc" not a valid
data
>> file
>> > > > >> > >> > > > > >
>> > > > >> > >> > > > > > Thank you.
>> > > > >> > >> > > > > >
>> > > > >> > >> > > > > > Regards,
>> > > > >> > >> > > > > >
>> > > > >> > >> > > > > >
>> > > > >> > >> > > > > > Jinwoong
>> > > > >> > >> > > > > >
>> > > > >> > >> > > > > > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong
Yoo <
>> > > > >> > >> > > jinwoong.yoo at gmail.com>
>> > > > >> > >> > > > > > wrote:
>> > > > >> > >> > > > > >
>> > > > >> > >> > > > > > > Hi,
>> > > > >> > >> > > > > > >
>> > > > >> > >> > > > > > > I noticed that TRMM data dimension was
(lon,
>> lat).
>> > > > >> > >> > > > > > > So I switched their order to (lat, lon)
and ran
>> the
>> > > > >> command
>> > > > >> > >> > again.
>> > > > >> > >> > > > > > > However, I got the same error message as
below.
>> > > > >> > >> > > > > > >
>> > > > >> > >> > > > > > > yoo108 at halstead-fe00:*/scratch
>> /halstead/y/yoo108/
>> > > TRMM*
>> > > > $
>> > > > >> > >> > > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
>> > > > >> > >> > /scratch/halstead/y/yoo108/
>> > > > >> > >> > > > > TRMM/
>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
>> > > > /scratch/halstead/y/yoo108/ND_
>> > > > >> > >> > > > > > > grided_obs/daily_T2m_maxminmean_1976.nc
>> > > > >> > >> > > /scratch/halstead/y/yoo108/
>> > > > >> > >> > > > > TRMM/
>> > > > >> > >> > > > > > > regrid_trmm_sample.nc -field
>> > 'name="precipitation";'
>> > > > >> > >> > > > > > >
>> > > > >> > >> > > > > > > DEBUG 1: Reading data file:
>> > > > >> /scratch/halstead/y/yoo108/TRM
>> > > > >> > M/
>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
>> > > > >> > >> > > > > > >
>> > > > >> > >> > > > > > > ERROR :
>> > > > >> > >> > > > > > >
>> > > > >> > >> > > > > > > ERROR : process_data_file() ->
>> > > > >> > "/scratch/halstead/y/yoo108/TR
>> > > > >> > >> > MM/
>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc" not a valid
data file
>> > > > >> > >> > > > > > >
>> > > > >> > >> > > > > > >
>> > > > >> > >> > > > > > > Thank you.
>> > > > >> > >> > > > > > >
>> > > > >> > >> > > > > > > Regards,
>> > > > >> > >> > > > > > >
>> > > > >> > >> > > > > > >
>> > > > >> > >> > > > > > > Jinwoong
>> > > > >> > >> > > > > > >
>> > > > >> > >> > > > > > >
>> > > > >> > >> > > > > > >
>> > > > >> > >> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM, Jinwoong
Yoo <
>> > > > >> > >> > > > jinwoong.yoo at gmail.com>
>> > > > >> > >> > > > > > > wrote:
>> > > > >> > >> > > > > > >
>> > > > >> > >> > > > > > >> Hi,
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> I got a similar result with a TRMM data.
>> > > > >> > >> > > > > > >> Please see below:
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/scratch
>> /halstead/y/yoo108/
>> > > > TRMM*
>> > > > >> $
>> > > > >> > >> > > > > > >> ~/met-6.0_bugfix/bin/regrid_data_plane
>> > > > >> > >> > > /scratch/halstead/y/yoo108/
>> > > > >> > >> > > > > TRMM/
>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
>> > > > >> /scratch/halstead/y/yoo108/ND_
>> > > > >> > >> > > > > > >> grided_obs/daily_T2m_maxminmean_1976.nc
>> > > > >> > >> > > /scratch/halstead/y/yoo108/
>> > > > >> > >> > > > > > TRMM/
>> > > > >> > >> > > > > > >> regrid_trmm_sample.nc -field
>> > > 'name="precipitation";'
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> DEBUG 1: Reading data file:
>> > > > >> /scratch/halstead/y/yoo108/TRM
>> > > > >> > M/
>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> ERROR : process_data_file() ->
>> > > > >> > >> "/scratch/halstead/y/yoo108/TR
>> > > > >> > >> > MM/
>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc" not a valid
data
>> file
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> A part of ncdump output for the TRMM
data is
>> > pasted
>> > > > >> below:
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/scratch
>> /halstead/y/yoo108/
>> > > > TRMM*
>> > > > >> $
>> > > > >> > >> ncdump
>> > > > >> > >> > > -h
>> > > > >> > >> > > > > > >> subset_200003-200512/3B42RT_
>> > > Daily.20051231.7.nc4.nc4
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> dimensions:
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> lon = 59 ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> lat = 58 ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> variables:
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> short precipitation_cnt(lon, lat) ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> precipitation_cnt:units = "count" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> precipitation_cnt:long_name = "Count of
valid
>> 3-hr
>> > > > >> > >> precipitation
>> > > > >> > >> > > > > > >> retrievals for the day" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> precipitation_cnt:coordinates = "lat
lon" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> precipitation_cnt:origname =
>> "precipitation_cnt" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> precipitation_cnt:fullnamepath =
>> > > "/precipitation_cnt"
>> > > > ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> float uncal_precipitation(lon, lat) ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> uncal_precipitation:units = "mm" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> uncal_precipitation:long_name = "Daily
>> accumulated
>> > > > >> > >> uncalibrated
>> > > > >> > >> > > > > > >> precipitation" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> uncal_precipitation:coordinates = "lat
lon" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> uncal_precipitation:_FillValue =
-9999.9f ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> uncal_precipitation:origname =
>> > > "uncal_precipitation" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> uncal_precipitation:fullnamepath =
>> > > > >> "/uncal_precipitation"
>> > > > >> > ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> short uncal_precipitation_cnt(lon, lat)
;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:units = "count"
;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:long_name =
"Count of
>> > valid
>> > > > >> 3-hr
>> > > > >> > >> uncal
>> > > > >> > >> > > > > > >> precipitation retrievals for the day" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:coordinates =
"lat
>> lon" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:origname =
>> > > > >> > >> "uncal_precipitation_cnt" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:fullnamepath =
>> > > > >> > >> > > "/uncal_precipitation_cnt" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> float precipitation(lon, lat) ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> precipitation:units = "mm" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> precipitation:long_name = "Daily
accumulated
>> > > > >> precipitation
>> > > > >> > >> > > (combined
>> > > > >> > >> > > > > > >> microwave-IR) estimate" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> precipitation:coordinates = "lat lon" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> precipitation:_FillValue = -9999.9f ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> precipitation:origname = "precipitation"
;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> precipitation:fullnamepath =
"/precipitation" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> short randomError_cnt(lon, lat) ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> randomError_cnt:units = "count" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> randomError_cnt:long_name = "Count of
>> randomError
>> > > for
>> > > > >> the
>> > > > >> > >> day" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> randomError_cnt:coordinates = "lat lon"
;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> randomError_cnt:origname =
"randomError_cnt" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> randomError_cnt:fullnamepath =
>> "/randomError_cnt"
>> > ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> float randomError(lon, lat) ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> randomError:units = "mm" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> randomError:long_name = "Daily total
error of
>> > > combined
>> > > > >> > >> > > microwave-IR
>> > > > >> > >> > > > > > >> precipitation estimate" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> randomError:_FillValue = -9999.9f ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> randomError:origname = "randomError" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> randomError:fullnamepath =
"/randomError" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> float lat(lat) ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> lat:units = "degrees_north" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> lat:long_name = "Latitude" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> lat:origname = "lat" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> lat:fullnamepath = "/lat" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> float lon(lon) ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> lon:units = "degrees_east" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> lon:long_name = "Longitude" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> lon:origname = "lon" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> lon:fullnamepath = "/lon" ;
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> Thank you.
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> Regards,
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> Jinwoong
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >> On Thu, Jun 29, 2017 at 3:11 PM,
>> > met_help at ucar.edu
>> > > > via
>> > > > >> RT
>> > > > >> > <
>> > > > >> > >> > > > > > >> met_help at ucar.edu> wrote:
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED
AVAILABILITY
>> > BETWEEN
>> > > > >> > 5/23/17
>> > > > >> > >> AND
>> > > > >> > >> > > > > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> Greetings,
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> This message has been automatically
generated
>> in
>> > > > >> response
>> > > > >> > to
>> > > > >> > >> > the
>> > > > >> > >> > > > > > >>> creation of a trouble ticket regarding:
>> > > > >> > >> > > > > > >>> "regrid_data_plane: not a valid
data
>> > file",
>> > > > >> > >> > > > > > >>> a summary of which appears below.
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> There is no need to reply to this
message
>> right
>> > > now.
>> > > > >> Your
>> > > > >> > >> > ticket
>> > > > >> > >> > > > has
>> > > > >> > >> > > > > > >>> been
>> > > > >> > >> > > > > > >>> assigned an ID of [rt.rap.ucar.edu
#81063].
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> Please include the string:
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> [rt.rap.ucar.edu #81063]
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> in the subject line of all future
>> correspondence
>> > > > about
>> > > > >> > this
>> > > > >> > >> > > issue.
>> > > > >> > >> > > > To
>> > > > >> > >> > > > > > do
>> > > > >> > >> > > > > > >>> so,
>> > > > >> > >> > > > > > >>> you may reply to this message.
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> Thank you,
>> > > > >> > >> > > > > > >>>
met_help at ucar.edu
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> ------------------------------
>> > > > >> > >> ------------------------------
>> > > > >> > >> > > > > > >>> -------------
>> > > > >> > >> > > > > > >>> Hi,
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> I am trying to regrid one of my
observation
>> files
>> > > in
>> > > > >> lat
>> > > > >> > lon
>> > > > >> > >> > > > > coordinate
>> > > > >> > >> > > > > > >>> grid to WRF curvilinear grid.
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> I ran bin/regrid_data_plane using a
sample lat
>> > lon
>> > > > grid
>> > > > >> > file
>> > > > >> > >> > and
>> > > > >> > >> > > a
>> > > > >> > >> > > > > file
>> > > > >> > >> > > > > > >>> in
>> > > > >> > >> > > > > > >>> the WRF grid. But I got error as shown
below:
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
>> > > > >> > /halstead/y/yoo108/ND_grided_
>> > > > >> > >> > obs*
>> > > > >> > >> > > $
>> > > > >> > >> > > > > > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
>> > > > >> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/
>> > > > >> sample_tmax.nc
>> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
>> > > grided_obs/daily_T2m_
>> > > > >> > >> > > > > maxminmean_1976.nc
>> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
>> > > > >> > >> grided_obs/NDtoWRFgrid_sample_
>> > > > >> > >> > > > tmax.nc
>> > > > >> > >> > > > > > >>> -field
>> > > > >> > >> > > > > > >>> 'name="tmax";'
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> DEBUG 1: Reading data file:
>> > > > >> /scratch/halstead/y/yoo108/ND_
>> > > > >> > >> > > > > grided_obs/
>> > > > >> > >> > > > > > >>> sample_tmax.nc
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> ERROR : process_data_file() ->
>> > > > >> > >> "/scratch/halstead/y/yoo108/ND
>> > > > >> > >> > > > > > >>> _grided_obs/
>> > > > >> > >> > > > > > >>> sample_tmax.nc" not a valid data file
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> I wonder which part of the input file
does not
>> > > > satisfy
>> > > > >> the
>> > > > >> > >> > MET's
>> > > > >> > >> > > > > "valid
>> > > > >> > >> > > > > > >>> file" criteria.
>> > > > >> > >> > > > > > >>> ncdump output of the input file looks
as
>> below:
>> > > > >> > >> > > > > > >>> Input file was originally generated by
VIC
>> model
>> > > and
>> > > > >> > >> converted
>> > > > >> > >> > > into
>> > > > >> > >> > > > > cf
>> > > > >> > >> > > > > > >>> netcdf format.
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> Thank you in advance.
>> > > > >> > >> > > > > > >>> Regards,
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> Jinwoong
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
>> > > > >> > /halstead/y/yoo108/ND_grided_
>> > > > >> > >> > obs*
>> > > > >> > >> > > $
>> > > > >> > >> > > > > > >>> ncdump -h
>> > > > >> > >> > > > > > >>> sample_tmax.nc
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> netcdf sample_tmax {
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> dimensions:
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> T = 1 ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> X = 55 ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> Y = 65 ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> variables:
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> double T(T) ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> T:units = "days since 1915-01-01" ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> T:long_name = "Time" ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> double X(X) ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> X:units = "degrees_east" ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> X:long_name = "Longitude" ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> double Y(Y) ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> Y:units = "degrees_north" ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> Y:long_name = "Latitude" ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> double tmax(T, Y, X) ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> tmax:units = "degC" ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> tmax:long_name = "tmax calculated by
VIC" ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> tmax:missing_value = -9999.f ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> // global attributes:
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>> :production = "VIC output" ;
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>>
>> > > > >> > >> > > > > > >>
>> > > > >> > >> > > > > > >
>> > > > >> > >> > > > > >
>> > > > >> > >> > > > > >
>> > > > >> > >> > > > >
>> > > > >> > >> > > > >
>> > > > >> > >> > > >
>> > > > >> > >> > > >
>> > > > >> > >> > >
>> > > > >> > >> > >
>> > > > >> > >> >
>> > > > >> > >> >
>> > > > >> > >>
>> > > > >> > >>
>> > > > >> > >
>> > > > >> >
>> > > > >> >
>> > > > >>
>> > > > >>
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Tue Jul 11 09:44:39 2017
Hi John,
Even with the plot_data_plane command,
I noticed that "file_type = NETCDF_PINT;" argument should be provided
in
the command line.
Otherwise, it fails. Please see below.
yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal*
$
~/met-6.0_bugfix/bin/plot_data_plane
/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:00.nc
met_em.d03.2005-12-31_18:00:00.ps 'name="TT";level="(0,0,*,*)";'
DEBUG 1: Opening data file:
/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:00.nc
ERROR : plot_data_plane -> file
"/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:00.nc"
not a valid data file
yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal*
$
~/met-6.0_bugfix/bin/plot_data_plane
/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:00.nc
met_em.d03.2005-12-31_18:00:00.ps
'name="TT";level="(0,0,*,*)";file_type =
NETCDF_PINT;'
DEBUG 1: Opening data file:
/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:00.nc
DEBUG 1: Creating postscript file: met_em.d03.2005-12-31_18:00:00.ps
Thank you.
Regards,
Jinwoong
On Tue, Jul 11, 2017 at 11:12 AM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
wrote:
> Hi John,
>
> Now I am trying to execute grid_stat against these netcdf files that
have
> been patted with the WRF global attributes.
>
> I tried to include 'file_type = NETCDF_PINT;' argument both in its
> configuration file and in the command line.
> However, both failed to run (Please see below).
>
> Could you please guide me how to specify the netcdf file type in the
> grid_stat application?
> Thank you.
>
> Regards,
>
> Jinwoong
>
>
> 1.
>
> .......
>
> obs = {
>
>
> field = [
>
> {
>
> name = "TT";
>
> level = [ "(0,0,*,*)" ];
>
> file_type = NETCDF_PINT;
>
> cat_thresh = [];
>
> }
>
> .......
>
> DEBUG 1: Default Config File: /home/yoo108/met-6.0_bugfix/
> share/met/config/GridStatConfig_default
>
> DEBUG 1: User Config File:
/scratch/halstead/y/yoo108/wrfAnalysis/METanal/
> GridStatConfig_met_em
>
> DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() -> created new
> Met2dDataFile object of type "FileType_Gb2".
>
> DEBUG 4: Switching the GRIB2 radius of the earth value of 6371.23 km
to
> 6371.2 km for internal consistency.
>
> DEBUG 4:
>
> DEBUG 4: Lambert Conformal Grid Data:
>
> DEBUG 4: scale_lat_1: 48
>
> DEBUG 4: scale_lat_2: 32
>
> DEBUG 4: lat_pin: 36.9132
>
> DEBUG 4: lon_pin: 92.0748
>
> DEBUG 4: x_pin: 0
>
> DEBUG 4: y_pin: 0
>
> DEBUG 4: lon_orient: 97
>
> DEBUG 4: d_km: 4
>
> DEBUG 4: r_km: 6371.2
>
> DEBUG 4: nx: 189
>
> DEBUG 4: ny: 270
>
> DEBUG 4:
>
> DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() -> created new
> Met2dDataFile object of type "FileType_None".
>
> ERROR :
>
> ERROR : Trouble reading observation file
"/scratch/halstead/y/yoo108/
> NCAR_BC_met_em/met_em.d03.1980-01-01_00:00:00.nc"
>
>
>
> 2.
>
> /home/yoo108/met-6.0_bugfix/bin/grid_stat
$dir_data/$yyyy/$yyyy$nummon/$
> grib_date1 $dir_data2/$met_em_date1 $analDir/$GridStatConfig
'file_type =
> NETCDF_PINT;' -outdir $workDir -v 4
>
> *** Model Evaluation Tools (METV6.0) ***
>
>
> Usage: grid_stat
>
> fcst_file
>
> obs_file
>
> config_file
>
> [-outdir path]
>
> [-log file]
>
> [-v level]
>
> [-compress level]
>
>
> where "fcst_file" is a gridded forecast file containing the field(s)
to
> be verified (required).
>
> "obs_file" is a gridded observation file containing the verifying
field(s)
> (required).
>
> "config_file" is a GridStatConfig file containing the desired
> configuration settings (required).
>
> "-outdir path" overrides the default output directory
> (/scratch/halstead/y/yoo108/wrfAnalysis/METanal/wrf2met_em)
(optional).
>
> "-log file" outputs log messages to the specified file (optional).
>
> "-v level" overrides the default level of logging (4) (optional).
>
> "-compress level" overrides the compression level of NetCDF variable
(0)
> (optional).
>
>
>
>
>
> On Mon, Jul 10, 2017 at 4:53 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> wrote:
>
>> Hi John,
>>
>> I was able to open netcdf files that share the same coordinates
with WRF
>> output by copying the global attribute of the WRF output to these
netcdf
>> files:
>>
>> ncks -A -x wrfout.nc target.nc
>>
>> This enabled me to open netcdf files in MET using
>> 'name="TT";level="(0,0,*,*)";file_type = NETCDF_PINT;' argument.
>>
>> Thank you very much!
>> Regards,
>>
>> Jinwoong
>>
>> On Mon, Jul 10, 2017 at 3:04 PM, John Halley Gotway via RT <
>> met_help at ucar.edu> wrote:
>>
>>> Jinwoong,
>>>
>>> I tried running the sample file (daily_T2m_maxminmean_1981.nc)
through
>>> plot_data_plane and saw the same behavior you did. Looking
closely at
>>> that
>>> file I see that is not the NetCDF output generated by WRF. The
history
>>> attribute indicates that it was created by the "ncks" utility:
>>>
>>> :history = "Sun Jul 2 15:47:18 2017: ncks -d days,0,0
>>> /scratch/halstead/k/khoogewi/CCRC_wrf/analysis/T2m/daily_T2m_
>>> maxminmean_1981.nc
>>> /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_maxminm
>>> ean_19810101.nc"
>>>
>>>
>>> This is not a CF-compliant NetCDF file and it does not look like
the
>>> output
>>> from WRF. Another alternative is making it look like the NetCDF
file
>>> format used by the MET tools themselves.
>>>
>>> I ran the following command to add global attributes to define the
grid
>>> spec for MET:
>>>
>>> ncatted \
>>> -a MET_version,global,o,c,"V6.0" \
>>> -a Projection,global,o,c,"Lambert Conformal" \
>>> -a scale_lat_1,global,o,c,"48" \
>>> -a scale_lat_2,global,o,c,"32" \
>>> -a lat_pin,global,o,c,"48" \
>>> -a lon_pin,global,o,c,"-97" \
>>> -a x_pin,global,o,c,"0" \
>>> -a y_pin,global,o,c,"0" \
>>> -a lon_orient,global,o,c,"-97" \
>>> -a d_km,global,o,c,"3" \
>>> -a r_km,global,o,c,"6371.2" \
>>> -a nx,global,o,c,"189" \
>>> -a ny,global,o,c,"270" \
>>> daily_T2m_maxminmean_1976.nc -o daily_T2m_maxminmean_1976_MET.nc
>>>
>>> However, I don't think these are all correct. Specifically, I
don't know
>>> how the "lon_orient" should be set. So I set it to the longitude
of the
>>> lower-left corner. Also, I don't know how the d_km should be set.
>>> That's
>>> the grid spacing in km. So I just guess with a value of 3.
>>>
>>> This enables MET to plot the result, but you should work on making
the
>>> grid
>>> info correct:
>>> met-6.0/bin/plot_data_plane \
>>> daily_T2m_maxminmean_1976_MET.nc \
>>> daily_T2m_maxminmean_1976_MET.ps \
>>> 'name="T2m_max"; level="(10,*,*)";' -v 4
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>> On Fri, Jul 7, 2017 at 5:06 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
>>> wrote:
>>>
>>> >
>>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>>> >
>>> > Hi John,
>>> >
>>> > Thank you for your comment.
>>> > I tried it but it failed.
>>> > Please see below.
>>> >
>>> > yoo108 at halstead-
fe03:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal*
>>> $
>>> > ~/met-6.0_bugfix/bin/plot_data_plane
>>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
>>> > maxminmean_20051231.nc
>>> > wrfDaily_T2m_maxminmean_20051231.ps
>>> > 'name="T2m_max";level="(0,*,*)";file_type = NETCDF_PINT;'
>>> >
>>> > DEBUG 1: Opening data file:
>>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
>>> > maxminmean_20051231.nc
>>> >
>>> > ERROR : MetNcPinterpDataFile::open(const char *) -> unable to
open
>>> NetCDF
>>> > file
>>> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
>>> > maxminmean_20051231.nc"
>>> >
>>> > ERROR : Met2dDataFileFactory::new_met_2d_data_file() -> error
opening
>>> > file
>>> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
>>> > maxminmean_20051231.nc"
>>> >
>>> >
>>> >
>>> > One sample file (wrfDaily_T2m_maxminmean_19810101.nc) is also
>>> included in
>>> > the Yoo_data4.tar file that I uploaded previously.
>>> > Thank you.
>>> > Haver a nice weekend.
>>> >
>>> > Regards,
>>> >
>>> > Jinwoong
>>> >
>>> >
>>> >
>>> > On Fri, Jul 7, 2017 at 6:04 PM, John Halley Gotway via RT <
>>> > met_help at ucar.edu
>>> > > wrote:
>>> >
>>> > > Jinwoong,
>>> > >
>>> > > If they really are output from WRF, one simple thing to try is
>>> telling
>>> > MET
>>> > > to interpret them as the NetCDF output of the wrf_interp
utility
>>> > > :
>>> > > file_type = NETCDF_PINT;
>>> > >
>>> > > "PINT" stands for "pressure interpolated"... pinterp was the
>>> precursor to
>>> > > the current wrf_interp tool.
>>> > >
>>> > > If that doesn't work, I'll need to see a sample file before
making
>>> any
>>> > > other suggestions.
>>> > >
>>> > > Thanks,
>>> > > John
>>> > >
>>> > >
>>> > >
>>> > > On Fri, Jul 7, 2017 at 3:36 PM, Jinwoong Yoo via RT <
>>> met_help at ucar.edu>
>>> > > wrote:
>>> > >
>>> > > >
>>> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>>> > > >
>>> > > > Hi John,
>>> > > >
>>> > > > I was able to read in a "home brew" netcdf data file using
>>> > > plot_data_plane.
>>> > > >
>>> > > > Then, I went ahead and tried another netcdf file in
curvilinear
>>> > > coordinate
>>> > > > which is in the same coordinate grid as my WRF output. But
it
>>> failed.
>>> > > >
>>> > > > I have many netcdf climatology files from the WRF simulation
such
>>> as
>>> > > daily,
>>> > > > monthly, and annual, etc. Therefore, they are all in
curvilinear
>>> > > coordinate
>>> > > > (Lambert).
>>> > > >
>>> > > > I wonder if there is any work around so that I can feed
these files
>>> > into
>>> > > > MET?
>>> > > > Or should I regrid them all into lat lon coordinate files
first?
>>> > > >
>>> > > > Thank you, John.
>>> > > >
>>> > > > Regards,
>>> > > >
>>> > > > Jinwoong Yoo
>>> > > >
>>> > > >
>>> > > > On Fri, Jul 7, 2017 at 3:01 PM, Jinwoong Yoo <
>>> jinwoong.yoo at gmail.com>
>>> > > > wrote:
>>> > > >
>>> > > > > Hi John,
>>> > > > >
>>> > > > > Thank you very much.
>>> > > > > Let me try and let you know how it goes.
>>> > > > > Thank you.
>>> > > > > Regards,
>>> > > > >
>>> > > > > Jinwoong
>>> > > > >
>>> > > > > On Fri, Jul 7, 2017 at 2:59 PM, John Halley Gotway via RT
<
>>> > > > > met_help at ucar.edu> wrote:
>>> > > > >
>>> > > > >> Jinwoong,
>>> > > > >>
>>> > > > >> Yes, you can give it a try. The closer you can make the
NetCDF
>>> > files
>>> > > to
>>> > > > >> the CF-convention, the more likely MET will be able to
read it.
>>> > > > >>
>>> > > > >> The reason that's its able to read the TRMM data are that
the
>>> > lat/lon
>>> > > > >> values are equally spaced. Non-equally spaced lat/lon
values
>>> on a
>>> > map
>>> > > > >> projection require that the map projection information be
>>> specified.
>>> > > > >> Unfortunately, specifying map projection information in
>>> CF-compliant
>>> > > > >> NetCDF
>>> > > > >> files is not as easy as I think it should be!
>>> > > > >>
>>> > > > >> Hope it works out ok for you.
>>> > > > >>
>>> > > > >> Thanks,
>>> > > > >> John
>>> > > > >>
>>> > > > >> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo via RT <
>>> > > met_help at ucar.edu
>>> > > > >
>>> > > > >> wrote:
>>> > > > >>
>>> > > > >> >
>>> > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>>> >
>>> > > > >> >
>>> > > > >> > investigating not investing :)
>>> > > > >> >
>>> > > > >> > Thanks!
>>> > > > >> > Regards,
>>> > > > >> >
>>> > > > >> > Jinwoong
>>> > > > >> >
>>> > > > >> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo <
>>> > > jinwoong.yoo at gmail.com>
>>> > > > >> > wrote:
>>> > > > >> >
>>> > > > >> > > Hi John,
>>> > > > >> > >
>>> > > > >> > > Thank you very much for your time investing the
issue.
>>> > > > >> > > I am glad to hear that there is a trick to work
around the
>>> issue
>>> > > to
>>> > > > >> read
>>> > > > >> > > in TRMM data in netcdf format.
>>> > > > >> > > I wonder if I can apply the same trick (
>>> file_type=NETCDF_NCCF;)
>>> > > to
>>> > > > >> read
>>> > > > >> > > in any other observation files in netcdf format?
>>> > > > >> > > In fact, I would like to read in "home brew" netcdf
dataset
>>> > files
>>> > > > into
>>> > > > >> > > MET.
>>> > > > >> > > One sample file of them was included in the uploaded
data
>>> > folder (
>>> > > > >> > > sample_tmax.nc).
>>> > > > >> > > The data in this sample file was originally generated
by VIC
>>> > > model.
>>> > > > >> > > Then the file format was converted into a generic
netcdf
>>> file
>>> > > format
>>> > > > >> > > although the dimension names are T, X, Y not time,
lat, lon.
>>> > > > >> > > But their coordinates have units in "degrees_east" or
>>> > > > "degrees_north"
>>> > > > >> as
>>> > > > >> > > well as their long_name as "Longitude" and
"Latitude",
>>> > > respectively.
>>> > > > >> > >
>>> > > > >> > > Of course, I will try to read those in for Grid-stat
today.
>>> > > > >> > > But I would like to hear from you if the trick (
>>> > > > >> file_type=NETCDF_NCCF;)
>>> > > > >> > > can be applied generally, which I wish very much.
>>> > > > >> > >
>>> > > > >> > > Thank you so much, John.
>>> > > > >> > >
>>> > > > >> > > Regards,
>>> > > > >> > >
>>> > > > >> > > Jinwoong Yoo
>>> > > > >> > >
>>> > > > >> > >
>>> > > > >> > > On Fri, Jul 7, 2017 at 1:16 PM, John Halley Gotway
via RT <
>>> > > > >> > > met_help at ucar.edu> wrote:
>>> > > > >> > >
>>> > > > >> > >> Jinwoong,
>>> > > > >> > >>
>>> > > > >> > >> Thanks for sending your sample data and for your
patience
>>> > while I
>>> > > > was
>>> > > > >> > out
>>> > > > >> > >> of town.
>>> > > > >> > >>
>>> > > > >> > >> Using met-6.0, I'm able to process the TRMM NetCDF
file you
>>> > sent.
>>> > > > >> The
>>> > > > >> > >> trick is that I had to tell it which NetCDF file
type
>>> should be
>>> > > > used
>>> > > > >> to
>>> > > > >> > >> interpret the data. Using "file_type =
NETCDF_NCCF;" I'm
>>> > telling
>>> > > > >> MET to
>>> > > > >> > >> interpret it as if it were a CF-compliant NetCDF
file:
>>> > > > >> > >>
>>> > > > >> > >> met-6.0/bin/plot_data_plane \
>>> > > > >> > >> trmm_daily.20051231.7.nc trmm_daily.20051231.7.ps \
>>> > > > >> > >> 'name="precipitation"; level="(*,*)";
>>> file_type=NETCDF_NCCF;'
>>> > > > >> > >>
>>> > > > >> > >> DEBUG 1: Opening data file: trmm_daily.20051231.7.nc
>>> > > > >> > >> WARNING: NcCfFile::open() -> could not determine the
valid
>>> > time,
>>> > > > >> using
>>> > > > >> > 0.
>>> > > > >> > >> WARNING: NcCfFile::open() -> could not determine the
valid
>>> > time,
>>> > > > >> using
>>> > > > >> > 0.
>>> > > > >> > >> DEBUG 1: Creating postscript file:
>>> trmm_daily.20051231.7.ps
>>> > > > >> > >>
>>> > > > >> > >> The plot_data_plane tool is able to read the data,
and I've
>>> > > > attached
>>> > > > >> the
>>> > > > >> > >> resulting image. However, notice the warning
messages
>>> about
>>> > the
>>> > > > >> valid
>>> > > > >> > >> time.
>>> > > > >> > >>
>>> > > > >> > >> Using ncdump to see that file attributes, I see this
timing
>>> > > > >> information:
>>> > > > >> > >> :HDF5_GLOBAL.BeginDate = "2005-12-
31" ;
>>> > > > >> > >> :HDF5_GLOBAL.BeginTime =
"01:30:00.000Z" ;
>>> > > > >> > >> :HDF5_GLOBAL.EndDate = "2006-01-01"
;
>>> > > > >> > >> :HDF5_GLOBAL.EndTime =
"01:29:59.999Z" ;
>>> > > > >> > >>
>>> > > > >> > >> However that is not the CF-compliant way of
specifying
>>> timing
>>> > > info.
>>> > > > >> So
>>> > > > >> > >> while MET will be able to read the data, the timing
info
>>> won't
>>> > be
>>> > > > >> > accurate
>>> > > > >> > >> in the MET output files. Instead, you'll see
"19700101"
>>> which
>>> > is
>>> > > > >> > unixtime
>>> > > > >> > >> = 0.
>>> > > > >> > >>
>>> > > > >> > >> Another option would be pulling the binary TRMM data
and
>>> using
>>> > > this
>>> > > > >> > >> Rscript
>>> > > > >> > >> to convert the binary to NetCDF:
>>> > > > >> > >>
http://www.dtcenter.org/met/users/downloads/Rscripts/
>>> > > > trmmbin2nc.R
>>> > > > >> > >>
>>> > > > >> > >> However, I haven't done this in a while and am not
sure if
>>> > you'll
>>> > > > run
>>> > > > >> > into
>>> > > > >> > >> any issues.
>>> > > > >> > >>
>>> > > > >> > >> Hope that helps.
>>> > > > >> > >>
>>> > > > >> > >> Thanks,
>>> > > > >> > >> John
>>> > > > >> > >>
>>> > > > >> > >>
>>> > > > >> > >>
>>> > > > >> > >>
>>> > > > >> > >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo via RT
<
>>> > > > >> met_help at ucar.edu>
>>> > > > >> > >> wrote:
>>> > > > >> > >>
>>> > > > >> > >> >
>>> > > > >> > >> > <URL: https://rt.rap.ucar.edu/rt/
>>> > Ticket/Display.html?id=81063
>>> > > >
>>> > > > >> > >> >
>>> > > > >> > >> > Hi John,
>>> > > > >> > >> >
>>> > > > >> > >> > Thank you very much.
>>> > > > >> > >> > Regards,
>>> > > > >> > >> >
>>> > > > >> > >> > Jinwoong
>>> > > > >> > >> >
>>> > > > >> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John Halley
Gotway via
>>> RT <
>>> > > > >> > >> > met_help at ucar.edu> wrote:
>>> > > > >> > >> >
>>> > > > >> > >> > > Jinwoong,
>>> > > > >> > >> > >
>>> > > > >> > >> > > I'm out of the office today but will take a
closer look
>>> > > > tomorrow.
>>> > > > >> > >> > >
>>> > > > >> > >> > > Thanks
>>> > > > >> > >> > > John
>>> > > > >> > >> > >
>>> > > > >> > >> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo via
RT <
>>> > > > >> > >> met_help at ucar.edu>
>>> > > > >> > >> > > wrote:
>>> > > > >> > >> > >
>>> > > > >> > >> > > >
>>> > > > >> > >> > > > <URL: https://rt.rap.ucar.edu/rt/
>>> > > > Ticket/Display.html?id=81063
>>> > > > >> >
>>> > > > >> > >> > > >
>>> > > > >> > >> > > > Hi John,
>>> > > > >> > >> > > >
>>> > > > >> > >> > > > Thank you for your reply.
>>> > > > >> > >> > > > I uploaded my data as in Yoo_data4.tar on the
ftp
>>> site.
>>> > > > >> > >> > > > I included several files for the message of ID
of [
>>> > > > >> > rt.rap.ucar.edu
>>> > > > >> > >> > > #81074]
>>> > > > >> > >> > > > as well.
>>> > > > >> > >> > > > Thank you.
>>> > > > >> > >> > > > Regards,
>>> > > > >> > >> > > >
>>> > > > >> > >> > > > Jinwoong
>>> > > > >> > >> > > >
>>> > > > >> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM, John Halley
Gotway
>>> via
>>> > RT
>>> > > <
>>> > > > >> > >> > > > met_help at ucar.edu> wrote:
>>> > > > >> > >> > > >
>>> > > > >> > >> > > > > Jinwoong,
>>> > > > >> > >> > > > >
>>> > > > >> > >> > > > > I see that you're having trouble reading a
TRMM
>>> NetCDF
>>> > > file
>>> > > > >> into
>>> > > > >> > >> MET.
>>> > > > >> > >> > > > Can
>>> > > > >> > >> > > > > you please post the problematic file to our
>>> anonymous
>>> > ftp
>>> > > > >> site
>>> > > > >> > so
>>> > > > >> > >> I
>>> > > > >> > >> > can
>>> > > > >> > >> > > > > take a look?
>>> > > > >> > >> > > > >
>>> > > > >> > >> > > > > http://www.dtcenter.org/met/
>>> > > users/support/met_help.php#ftp
>>> > > > >> > >> > > > >
>>> > > > >> > >> > > > > Thanks,
>>> > > > >> > >> > > > > John Halley Gotway
>>> > > > >> > >> > > > >
>>> > > > >> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong Yoo
via
>>> RT <
>>> > > > >> > >> > met_help at ucar.edu
>>> > > > >> > >> > > >
>>> > > > >> > >> > > > > wrote:
>>> > > > >> > >> > > > >
>>> > > > >> > >> > > > > >
>>> > > > >> > >> > > > > > <URL: https://rt.rap.ucar.edu/rt/Tic
>>> > > > >> ket/Display.html?id=81063
>>> > > > >> > >
>>> > > > >> > >> > > > > >
>>> > > > >> > >> > > > > > Hi,
>>> > > > >> > >> > > > > >
>>> > > > >> > >> > > > > > TRMM data comes in as netCDF-4 classic
model.
>>> > > > >> > >> > > > > > I changed it to netCDF classic and run the
same
>>> > command
>>> > > > >> for a
>>> > > > >> > >> test.
>>> > > > >> > >> > > > > > But I got the same error as below.
>>> > > > >> > >> > > > > >
>>> > > > >> > >> > > > > > yoo108 at halstead-fe00:*/scratch
>>> /halstead/y/yoo108/
>>> > TRMM*
>>> > > $
>>> > > > >> > >> > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
>>> > > > >> > >> /scratch/halstead/y/yoo108/
>>> > > > >> > >> > > TRMM/
>>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
>>> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/ND_
>>> grided_obs/daily_T2m_
>>> > > > >> > >> > > maxminmean_1976.nc
>>> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/TRMM/
>>> > regrid_trmm_sample.nc
>>> > > > >> -field
>>> > > > >> > >> > > > > > 'name="precipitation";'
>>> > > > >> > >> > > > > >
>>> > > > >> > >> > > > > > DEBUG 1: Reading data file:
>>> > > > /scratch/halstead/y/yoo108/TRM
>>> > > > >> M/
>>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
>>> > > > >> > >> > > > > >
>>> > > > >> > >> > > > > > ERROR :
>>> > > > >> > >> > > > > >
>>> > > > >> > >> > > > > > ERROR : process_data_file() ->
>>> > > > >> "/scratch/halstead/y/yoo108/TR
>>> > > > >> > >> MM/
>>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc" not a valid
data
>>> file
>>> > > > >> > >> > > > > >
>>> > > > >> > >> > > > > > Thank you.
>>> > > > >> > >> > > > > >
>>> > > > >> > >> > > > > > Regards,
>>> > > > >> > >> > > > > >
>>> > > > >> > >> > > > > >
>>> > > > >> > >> > > > > > Jinwoong
>>> > > > >> > >> > > > > >
>>> > > > >> > >> > > > > > On Mon, Jul 3, 2017 at 11:41 AM, Jinwoong
Yoo <
>>> > > > >> > >> > > jinwoong.yoo at gmail.com>
>>> > > > >> > >> > > > > > wrote:
>>> > > > >> > >> > > > > >
>>> > > > >> > >> > > > > > > Hi,
>>> > > > >> > >> > > > > > >
>>> > > > >> > >> > > > > > > I noticed that TRMM data dimension was
(lon,
>>> lat).
>>> > > > >> > >> > > > > > > So I switched their order to (lat, lon)
and
>>> ran the
>>> > > > >> command
>>> > > > >> > >> > again.
>>> > > > >> > >> > > > > > > However, I got the same error message as
below.
>>> > > > >> > >> > > > > > >
>>> > > > >> > >> > > > > > > yoo108 at halstead-fe00:*/scratch
>>> /halstead/y/yoo108/
>>> > > TRMM*
>>> > > > $
>>> > > > >> > >> > > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
>>> > > > >> > >> > /scratch/halstead/y/yoo108/
>>> > > > >> > >> > > > > TRMM/
>>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
>>> > > > /scratch/halstead/y/yoo108/ND_
>>> > > > >> > >> > > > > > > grided_obs/daily_T2m_maxminmean_1976.nc
>>> > > > >> > >> > > /scratch/halstead/y/yoo108/
>>> > > > >> > >> > > > > TRMM/
>>> > > > >> > >> > > > > > > regrid_trmm_sample.nc -field
>>> > 'name="precipitation";'
>>> > > > >> > >> > > > > > >
>>> > > > >> > >> > > > > > > DEBUG 1: Reading data file:
>>> > > > >> /scratch/halstead/y/yoo108/TRM
>>> > > > >> > M/
>>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
>>> > > > >> > >> > > > > > >
>>> > > > >> > >> > > > > > > ERROR :
>>> > > > >> > >> > > > > > >
>>> > > > >> > >> > > > > > > ERROR : process_data_file() ->
>>> > > > >> > "/scratch/halstead/y/yoo108/TR
>>> > > > >> > >> > MM/
>>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc" not a valid
data
>>> file
>>> > > > >> > >> > > > > > >
>>> > > > >> > >> > > > > > >
>>> > > > >> > >> > > > > > > Thank you.
>>> > > > >> > >> > > > > > >
>>> > > > >> > >> > > > > > > Regards,
>>> > > > >> > >> > > > > > >
>>> > > > >> > >> > > > > > >
>>> > > > >> > >> > > > > > > Jinwoong
>>> > > > >> > >> > > > > > >
>>> > > > >> > >> > > > > > >
>>> > > > >> > >> > > > > > >
>>> > > > >> > >> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM,
Jinwoong Yoo <
>>> > > > >> > >> > > > jinwoong.yoo at gmail.com>
>>> > > > >> > >> > > > > > > wrote:
>>> > > > >> > >> > > > > > >
>>> > > > >> > >> > > > > > >> Hi,
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> I got a similar result with a TRMM
data.
>>> > > > >> > >> > > > > > >> Please see below:
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/scratch
>>> /halstead/y/yoo108/
>>> > > > TRMM*
>>> > > > >> $
>>> > > > >> > >> > > > > > >> ~/met-6.0_bugfix/bin/regrid_data_plane
>>> > > > >> > >> > > /scratch/halstead/y/yoo108/
>>> > > > >> > >> > > > > TRMM/
>>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
>>> > > > >> /scratch/halstead/y/yoo108/ND_
>>> > > > >> > >> > > > > > >> grided_obs/daily_T2m_maxminmean_1976.nc
>>> > > > >> > >> > > /scratch/halstead/y/yoo108/
>>> > > > >> > >> > > > > > TRMM/
>>> > > > >> > >> > > > > > >> regrid_trmm_sample.nc -field
>>> > > 'name="precipitation";'
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> DEBUG 1: Reading data file:
>>> > > > >> /scratch/halstead/y/yoo108/TRM
>>> > > > >> > M/
>>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> ERROR : process_data_file() ->
>>> > > > >> > >> "/scratch/halstead/y/yoo108/TR
>>> > > > >> > >> > MM/
>>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc" not a valid
data
>>> file
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> A part of ncdump output for the TRMM
data is
>>> > pasted
>>> > > > >> below:
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/scratch
>>> /halstead/y/yoo108/
>>> > > > TRMM*
>>> > > > >> $
>>> > > > >> > >> ncdump
>>> > > > >> > >> > > -h
>>> > > > >> > >> > > > > > >> subset_200003-200512/3B42RT_
>>> > > Daily.20051231.7.nc4.nc4
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> dimensions:
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> lon = 59 ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> lat = 58 ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> variables:
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> short precipitation_cnt(lon, lat) ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> precipitation_cnt:units = "count" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> precipitation_cnt:long_name = "Count of
valid
>>> 3-hr
>>> > > > >> > >> precipitation
>>> > > > >> > >> > > > > > >> retrievals for the day" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> precipitation_cnt:coordinates = "lat
lon" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> precipitation_cnt:origname =
>>> "precipitation_cnt" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> precipitation_cnt:fullnamepath =
>>> > > "/precipitation_cnt"
>>> > > > ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> float uncal_precipitation(lon, lat) ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> uncal_precipitation:units = "mm" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> uncal_precipitation:long_name = "Daily
>>> accumulated
>>> > > > >> > >> uncalibrated
>>> > > > >> > >> > > > > > >> precipitation" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> uncal_precipitation:coordinates = "lat
lon" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> uncal_precipitation:_FillValue =
-9999.9f ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> uncal_precipitation:origname =
>>> > > "uncal_precipitation" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> uncal_precipitation:fullnamepath =
>>> > > > >> "/uncal_precipitation"
>>> > > > >> > ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> short uncal_precipitation_cnt(lon, lat)
;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:units = "count"
;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:long_name =
"Count of
>>> > valid
>>> > > > >> 3-hr
>>> > > > >> > >> uncal
>>> > > > >> > >> > > > > > >> precipitation retrievals for the day" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:coordinates =
"lat
>>> lon" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:origname =
>>> > > > >> > >> "uncal_precipitation_cnt" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:fullnamepath =
>>> > > > >> > >> > > "/uncal_precipitation_cnt" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> float precipitation(lon, lat) ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> precipitation:units = "mm" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> precipitation:long_name = "Daily
accumulated
>>> > > > >> precipitation
>>> > > > >> > >> > > (combined
>>> > > > >> > >> > > > > > >> microwave-IR) estimate" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> precipitation:coordinates = "lat lon" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> precipitation:_FillValue = -9999.9f ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> precipitation:origname =
"precipitation" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> precipitation:fullnamepath =
"/precipitation"
>>> ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> short randomError_cnt(lon, lat) ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> randomError_cnt:units = "count" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> randomError_cnt:long_name = "Count of
>>> randomError
>>> > > for
>>> > > > >> the
>>> > > > >> > >> day" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> randomError_cnt:coordinates = "lat lon"
;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> randomError_cnt:origname =
"randomError_cnt" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> randomError_cnt:fullnamepath =
>>> "/randomError_cnt"
>>> > ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> float randomError(lon, lat) ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> randomError:units = "mm" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> randomError:long_name = "Daily total
error of
>>> > > combined
>>> > > > >> > >> > > microwave-IR
>>> > > > >> > >> > > > > > >> precipitation estimate" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> randomError:_FillValue = -9999.9f ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> randomError:origname = "randomError" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> randomError:fullnamepath =
"/randomError" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> float lat(lat) ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> lat:units = "degrees_north" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> lat:long_name = "Latitude" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> lat:origname = "lat" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> lat:fullnamepath = "/lat" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> float lon(lon) ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> lon:units = "degrees_east" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> lon:long_name = "Longitude" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> lon:origname = "lon" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> lon:fullnamepath = "/lon" ;
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> Thank you.
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> Regards,
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> Jinwoong
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >> On Thu, Jun 29, 2017 at 3:11 PM,
>>> > met_help at ucar.edu
>>> > > > via
>>> > > > >> RT
>>> > > > >> > <
>>> > > > >> > >> > > > > > >> met_help at ucar.edu> wrote:
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED
AVAILABILITY
>>> > BETWEEN
>>> > > > >> > 5/23/17
>>> > > > >> > >> AND
>>> > > > >> > >> > > > > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> Greetings,
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> This message has been automatically
>>> generated in
>>> > > > >> response
>>> > > > >> > to
>>> > > > >> > >> > the
>>> > > > >> > >> > > > > > >>> creation of a trouble ticket
regarding:
>>> > > > >> > >> > > > > > >>> "regrid_data_plane: not a
valid data
>>> > file",
>>> > > > >> > >> > > > > > >>> a summary of which appears below.
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> There is no need to reply to this
message
>>> right
>>> > > now.
>>> > > > >> Your
>>> > > > >> > >> > ticket
>>> > > > >> > >> > > > has
>>> > > > >> > >> > > > > > >>> been
>>> > > > >> > >> > > > > > >>> assigned an ID of [rt.rap.ucar.edu
#81063].
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> Please include the string:
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> [rt.rap.ucar.edu #81063]
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> in the subject line of all future
>>> correspondence
>>> > > > about
>>> > > > >> > this
>>> > > > >> > >> > > issue.
>>> > > > >> > >> > > > To
>>> > > > >> > >> > > > > > do
>>> > > > >> > >> > > > > > >>> so,
>>> > > > >> > >> > > > > > >>> you may reply to this message.
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> Thank you,
>>> > > > >> > >> > > > > > >>>
met_help at ucar.edu
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> ------------------------------
>>> > > > >> > >> ------------------------------
>>> > > > >> > >> > > > > > >>> -------------
>>> > > > >> > >> > > > > > >>> Hi,
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> I am trying to regrid one of my
observation
>>> files
>>> > > in
>>> > > > >> lat
>>> > > > >> > lon
>>> > > > >> > >> > > > > coordinate
>>> > > > >> > >> > > > > > >>> grid to WRF curvilinear grid.
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> I ran bin/regrid_data_plane using a
sample
>>> lat
>>> > lon
>>> > > > grid
>>> > > > >> > file
>>> > > > >> > >> > and
>>> > > > >> > >> > > a
>>> > > > >> > >> > > > > file
>>> > > > >> > >> > > > > > >>> in
>>> > > > >> > >> > > > > > >>> the WRF grid. But I got error as shown
below:
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
>>> > > > >> > /halstead/y/yoo108/ND_grided_
>>> > > > >> > >> > obs*
>>> > > > >> > >> > > $
>>> > > > >> > >> > > > > > >>> ~/met-6.0_bugfix/bin/regrid_data_plane
>>> > > > >> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/
>>> > > > >> sample_tmax.nc
>>> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
>>> > > grided_obs/daily_T2m_
>>> > > > >> > >> > > > > maxminmean_1976.nc
>>> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
>>> > > > >> > >> grided_obs/NDtoWRFgrid_sample_
>>> > > > >> > >> > > > tmax.nc
>>> > > > >> > >> > > > > > >>> -field
>>> > > > >> > >> > > > > > >>> 'name="tmax";'
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> DEBUG 1: Reading data file:
>>> > > > >> /scratch/halstead/y/yoo108/ND_
>>> > > > >> > >> > > > > grided_obs/
>>> > > > >> > >> > > > > > >>> sample_tmax.nc
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> ERROR : process_data_file() ->
>>> > > > >> > >> "/scratch/halstead/y/yoo108/ND
>>> > > > >> > >> > > > > > >>> _grided_obs/
>>> > > > >> > >> > > > > > >>> sample_tmax.nc" not a valid data file
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> I wonder which part of the input file
does
>>> not
>>> > > > satisfy
>>> > > > >> the
>>> > > > >> > >> > MET's
>>> > > > >> > >> > > > > "valid
>>> > > > >> > >> > > > > > >>> file" criteria.
>>> > > > >> > >> > > > > > >>> ncdump output of the input file looks
as
>>> below:
>>> > > > >> > >> > > > > > >>> Input file was originally generated by
VIC
>>> model
>>> > > and
>>> > > > >> > >> converted
>>> > > > >> > >> > > into
>>> > > > >> > >> > > > > cf
>>> > > > >> > >> > > > > > >>> netcdf format.
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> Thank you in advance.
>>> > > > >> > >> > > > > > >>> Regards,
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> Jinwoong
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
>>> > > > >> > /halstead/y/yoo108/ND_grided_
>>> > > > >> > >> > obs*
>>> > > > >> > >> > > $
>>> > > > >> > >> > > > > > >>> ncdump -h
>>> > > > >> > >> > > > > > >>> sample_tmax.nc
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> netcdf sample_tmax {
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> dimensions:
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> T = 1 ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> X = 55 ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> Y = 65 ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> variables:
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> double T(T) ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> T:units = "days since 1915-01-01" ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> T:long_name = "Time" ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> double X(X) ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> X:units = "degrees_east" ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> X:long_name = "Longitude" ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> double Y(Y) ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> Y:units = "degrees_north" ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> Y:long_name = "Latitude" ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> double tmax(T, Y, X) ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> tmax:units = "degC" ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> tmax:long_name = "tmax calculated by
VIC" ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> tmax:missing_value = -9999.f ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> // global attributes:
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>> :production = "VIC output" ;
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>>
>>> > > > >> > >> > > > > > >>
>>> > > > >> > >> > > > > > >
>>> > > > >> > >> > > > > >
>>> > > > >> > >> > > > > >
>>> > > > >> > >> > > > >
>>> > > > >> > >> > > > >
>>> > > > >> > >> > > >
>>> > > > >> > >> > > >
>>> > > > >> > >> > >
>>> > > > >> > >> > >
>>> > > > >> > >> >
>>> > > > >> > >> >
>>> > > > >> > >>
>>> > > > >> > >>
>>> > > > >> > >
>>> > > > >> >
>>> > > > >> >
>>> > > > >>
>>> > > > >>
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>>
>>>
>>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: John Halley Gotway
Time: Wed Jul 12 11:44:07 2017
Great, glad you were able to get it working.
Thanks,
John
On Tue, Jul 11, 2017 at 9:44 AM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>
> Hi John,
>
> Even with the plot_data_plane command,
> I noticed that "file_type = NETCDF_PINT;" argument should be
provided in
> the command line.
> Otherwise, it fails. Please see below.
>
> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal* $
> ~/met-6.0_bugfix/bin/plot_data_plane
> /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> 00.nc
> met_em.d03.2005-12-31_18:00:00.ps 'name="TT";level="(0,0,*,*)";'
>
> DEBUG 1: Opening data file:
> /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> 00.nc
>
> ERROR : plot_data_plane -> file
> "/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> 00.nc"
> not a valid data file
>
>
>
> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal* $
> ~/met-6.0_bugfix/bin/plot_data_plane
> /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> 00.nc
> met_em.d03.2005-12-31_18:00:00.ps
'name="TT";level="(0,0,*,*)";file_type =
> NETCDF_PINT;'
>
> DEBUG 1: Opening data file:
> /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> 00.nc
>
> DEBUG 1: Creating postscript file: met_em.d03.2005-12-31_18:00:00.ps
>
>
>
> Thank you.
>
> Regards,
>
>
> Jinwoong
>
>
> On Tue, Jul 11, 2017 at 11:12 AM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> wrote:
>
> > Hi John,
> >
> > Now I am trying to execute grid_stat against these netcdf files
that have
> > been patted with the WRF global attributes.
> >
> > I tried to include 'file_type = NETCDF_PINT;' argument both in its
> > configuration file and in the command line.
> > However, both failed to run (Please see below).
> >
> > Could you please guide me how to specify the netcdf file type in
the
> > grid_stat application?
> > Thank you.
> >
> > Regards,
> >
> > Jinwoong
> >
> >
> > 1.
> >
> > .......
> >
> > obs = {
> >
> >
> > field = [
> >
> > {
> >
> > name = "TT";
> >
> > level = [ "(0,0,*,*)" ];
> >
> > file_type = NETCDF_PINT;
> >
> > cat_thresh = [];
> >
> > }
> >
> > .......
> >
> > DEBUG 1: Default Config File: /home/yoo108/met-6.0_bugfix/
> > share/met/config/GridStatConfig_default
> >
> > DEBUG 1: User Config File: /scratch/halstead/y/yoo108/
> wrfAnalysis/METanal/
> > GridStatConfig_met_em
> >
> > DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() -> created
new
> > Met2dDataFile object of type "FileType_Gb2".
> >
> > DEBUG 4: Switching the GRIB2 radius of the earth value of 6371.23
km to
> > 6371.2 km for internal consistency.
> >
> > DEBUG 4:
> >
> > DEBUG 4: Lambert Conformal Grid Data:
> >
> > DEBUG 4: scale_lat_1: 48
> >
> > DEBUG 4: scale_lat_2: 32
> >
> > DEBUG 4: lat_pin: 36.9132
> >
> > DEBUG 4: lon_pin: 92.0748
> >
> > DEBUG 4: x_pin: 0
> >
> > DEBUG 4: y_pin: 0
> >
> > DEBUG 4: lon_orient: 97
> >
> > DEBUG 4: d_km: 4
> >
> > DEBUG 4: r_km: 6371.2
> >
> > DEBUG 4: nx: 189
> >
> > DEBUG 4: ny: 270
> >
> > DEBUG 4:
> >
> > DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() -> created
new
> > Met2dDataFile object of type "FileType_None".
> >
> > ERROR :
> >
> > ERROR : Trouble reading observation file
"/scratch/halstead/y/yoo108/
> > NCAR_BC_met_em/met_em.d03.1980-01-01_00:00:00.nc"
> >
> >
> >
> > 2.
> >
> > /home/yoo108/met-6.0_bugfix/bin/grid_stat
$dir_data/$yyyy/$yyyy$nummon/$
> > grib_date1 $dir_data2/$met_em_date1 $analDir/$GridStatConfig
'file_type =
> > NETCDF_PINT;' -outdir $workDir -v 4
> >
> > *** Model Evaluation Tools (METV6.0) ***
> >
> >
> > Usage: grid_stat
> >
> > fcst_file
> >
> > obs_file
> >
> > config_file
> >
> > [-outdir path]
> >
> > [-log file]
> >
> > [-v level]
> >
> > [-compress level]
> >
> >
> > where "fcst_file" is a gridded forecast file containing the
field(s) to
> > be verified (required).
> >
> > "obs_file" is a gridded observation file containing the verifying
> field(s)
> > (required).
> >
> > "config_file" is a GridStatConfig file containing the desired
> > configuration settings (required).
> >
> > "-outdir path" overrides the default output directory
> > (/scratch/halstead/y/yoo108/wrfAnalysis/METanal/wrf2met_em)
(optional).
> >
> > "-log file" outputs log messages to the specified file (optional).
> >
> > "-v level" overrides the default level of logging (4) (optional).
> >
> > "-compress level" overrides the compression level of NetCDF
variable (0)
> > (optional).
> >
> >
> >
> >
> >
> > On Mon, Jul 10, 2017 at 4:53 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > wrote:
> >
> >> Hi John,
> >>
> >> I was able to open netcdf files that share the same coordinates
with WRF
> >> output by copying the global attribute of the WRF output to these
netcdf
> >> files:
> >>
> >> ncks -A -x wrfout.nc target.nc
> >>
> >> This enabled me to open netcdf files in MET using
> >> 'name="TT";level="(0,0,*,*)";file_type = NETCDF_PINT;' argument.
> >>
> >> Thank you very much!
> >> Regards,
> >>
> >> Jinwoong
> >>
> >> On Mon, Jul 10, 2017 at 3:04 PM, John Halley Gotway via RT <
> >> met_help at ucar.edu> wrote:
> >>
> >>> Jinwoong,
> >>>
> >>> I tried running the sample file (daily_T2m_maxminmean_1981.nc)
through
> >>> plot_data_plane and saw the same behavior you did. Looking
closely at
> >>> that
> >>> file I see that is not the NetCDF output generated by WRF. The
history
> >>> attribute indicates that it was created by the "ncks" utility:
> >>>
> >>> :history = "Sun Jul 2 15:47:18 2017: ncks -d days,0,0
> >>> /scratch/halstead/k/khoogewi/CCRC_wrf/analysis/T2m/daily_T2m_
> >>> maxminmean_1981.nc
> >>> /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_maxminm
> >>> ean_19810101.nc"
> >>>
> >>>
> >>> This is not a CF-compliant NetCDF file and it does not look like
the
> >>> output
> >>> from WRF. Another alternative is making it look like the NetCDF
file
> >>> format used by the MET tools themselves.
> >>>
> >>> I ran the following command to add global attributes to define
the grid
> >>> spec for MET:
> >>>
> >>> ncatted \
> >>> -a MET_version,global,o,c,"V6.0" \
> >>> -a Projection,global,o,c,"Lambert Conformal" \
> >>> -a scale_lat_1,global,o,c,"48" \
> >>> -a scale_lat_2,global,o,c,"32" \
> >>> -a lat_pin,global,o,c,"48" \
> >>> -a lon_pin,global,o,c,"-97" \
> >>> -a x_pin,global,o,c,"0" \
> >>> -a y_pin,global,o,c,"0" \
> >>> -a lon_orient,global,o,c,"-97" \
> >>> -a d_km,global,o,c,"3" \
> >>> -a r_km,global,o,c,"6371.2" \
> >>> -a nx,global,o,c,"189" \
> >>> -a ny,global,o,c,"270" \
> >>> daily_T2m_maxminmean_1976.nc -o daily_T2m_maxminmean_1976_MET.nc
> >>>
> >>> However, I don't think these are all correct. Specifically, I
don't
> know
> >>> how the "lon_orient" should be set. So I set it to the
longitude of
> the
> >>> lower-left corner. Also, I don't know how the d_km should be
set.
> >>> That's
> >>> the grid spacing in km. So I just guess with a value of 3.
> >>>
> >>> This enables MET to plot the result, but you should work on
making the
> >>> grid
> >>> info correct:
> >>> met-6.0/bin/plot_data_plane \
> >>> daily_T2m_maxminmean_1976_MET.nc \
> >>> daily_T2m_maxminmean_1976_MET.ps \
> >>> 'name="T2m_max"; level="(10,*,*)";' -v 4
> >>>
> >>> Thanks,
> >>> John
> >>>
> >>>
> >>>
> >>> On Fri, Jul 7, 2017 at 5:06 PM, Jinwoong Yoo via RT
<met_help at ucar.edu
> >
> >>> wrote:
> >>>
> >>> >
> >>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
> >>> >
> >>> > Hi John,
> >>> >
> >>> > Thank you for your comment.
> >>> > I tried it but it failed.
> >>> > Please see below.
> >>> >
> >>> > yoo108 at halstead-fe03:*/scratch/halstead/y/yoo108/
> wrfAnalysis/METanal*
> >>> $
> >>> > ~/met-6.0_bugfix/bin/plot_data_plane
> >>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> >>> > maxminmean_20051231.nc
> >>> > wrfDaily_T2m_maxminmean_20051231.ps
> >>> > 'name="T2m_max";level="(0,*,*)";file_type = NETCDF_PINT;'
> >>> >
> >>> > DEBUG 1: Opening data file:
> >>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> >>> > maxminmean_20051231.nc
> >>> >
> >>> > ERROR : MetNcPinterpDataFile::open(const char *) -> unable to
open
> >>> NetCDF
> >>> > file
> >>> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> >>> > maxminmean_20051231.nc"
> >>> >
> >>> > ERROR : Met2dDataFileFactory::new_met_2d_data_file() -> error
> opening
> >>> > file
> >>> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> >>> > maxminmean_20051231.nc"
> >>> >
> >>> >
> >>> >
> >>> > One sample file (wrfDaily_T2m_maxminmean_19810101.nc) is also
> >>> included in
> >>> > the Yoo_data4.tar file that I uploaded previously.
> >>> > Thank you.
> >>> > Haver a nice weekend.
> >>> >
> >>> > Regards,
> >>> >
> >>> > Jinwoong
> >>> >
> >>> >
> >>> >
> >>> > On Fri, Jul 7, 2017 at 6:04 PM, John Halley Gotway via RT <
> >>> > met_help at ucar.edu
> >>> > > wrote:
> >>> >
> >>> > > Jinwoong,
> >>> > >
> >>> > > If they really are output from WRF, one simple thing to try
is
> >>> telling
> >>> > MET
> >>> > > to interpret them as the NetCDF output of the wrf_interp
utility
> >>> > > :
> >>> > > file_type = NETCDF_PINT;
> >>> > >
> >>> > > "PINT" stands for "pressure interpolated"... pinterp was the
> >>> precursor to
> >>> > > the current wrf_interp tool.
> >>> > >
> >>> > > If that doesn't work, I'll need to see a sample file before
making
> >>> any
> >>> > > other suggestions.
> >>> > >
> >>> > > Thanks,
> >>> > > John
> >>> > >
> >>> > >
> >>> > >
> >>> > > On Fri, Jul 7, 2017 at 3:36 PM, Jinwoong Yoo via RT <
> >>> met_help at ucar.edu>
> >>> > > wrote:
> >>> > >
> >>> > > >
> >>> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >>> > > >
> >>> > > > Hi John,
> >>> > > >
> >>> > > > I was able to read in a "home brew" netcdf data file using
> >>> > > plot_data_plane.
> >>> > > >
> >>> > > > Then, I went ahead and tried another netcdf file in
curvilinear
> >>> > > coordinate
> >>> > > > which is in the same coordinate grid as my WRF output. But
it
> >>> failed.
> >>> > > >
> >>> > > > I have many netcdf climatology files from the WRF
simulation such
> >>> as
> >>> > > daily,
> >>> > > > monthly, and annual, etc. Therefore, they are all in
curvilinear
> >>> > > coordinate
> >>> > > > (Lambert).
> >>> > > >
> >>> > > > I wonder if there is any work around so that I can feed
these
> files
> >>> > into
> >>> > > > MET?
> >>> > > > Or should I regrid them all into lat lon coordinate files
first?
> >>> > > >
> >>> > > > Thank you, John.
> >>> > > >
> >>> > > > Regards,
> >>> > > >
> >>> > > > Jinwoong Yoo
> >>> > > >
> >>> > > >
> >>> > > > On Fri, Jul 7, 2017 at 3:01 PM, Jinwoong Yoo <
> >>> jinwoong.yoo at gmail.com>
> >>> > > > wrote:
> >>> > > >
> >>> > > > > Hi John,
> >>> > > > >
> >>> > > > > Thank you very much.
> >>> > > > > Let me try and let you know how it goes.
> >>> > > > > Thank you.
> >>> > > > > Regards,
> >>> > > > >
> >>> > > > > Jinwoong
> >>> > > > >
> >>> > > > > On Fri, Jul 7, 2017 at 2:59 PM, John Halley Gotway via
RT <
> >>> > > > > met_help at ucar.edu> wrote:
> >>> > > > >
> >>> > > > >> Jinwoong,
> >>> > > > >>
> >>> > > > >> Yes, you can give it a try. The closer you can make
the
> NetCDF
> >>> > files
> >>> > > to
> >>> > > > >> the CF-convention, the more likely MET will be able to
read
> it.
> >>> > > > >>
> >>> > > > >> The reason that's its able to read the TRMM data are
that the
> >>> > lat/lon
> >>> > > > >> values are equally spaced. Non-equally spaced lat/lon
values
> >>> on a
> >>> > map
> >>> > > > >> projection require that the map projection information
be
> >>> specified.
> >>> > > > >> Unfortunately, specifying map projection information in
> >>> CF-compliant
> >>> > > > >> NetCDF
> >>> > > > >> files is not as easy as I think it should be!
> >>> > > > >>
> >>> > > > >> Hope it works out ok for you.
> >>> > > > >>
> >>> > > > >> Thanks,
> >>> > > > >> John
> >>> > > > >>
> >>> > > > >> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo via RT <
> >>> > > met_help at ucar.edu
> >>> > > > >
> >>> > > > >> wrote:
> >>> > > > >>
> >>> > > > >> >
> >>> > > > >> > <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=81063
> >>> >
> >>> > > > >> >
> >>> > > > >> > investigating not investing :)
> >>> > > > >> >
> >>> > > > >> > Thanks!
> >>> > > > >> > Regards,
> >>> > > > >> >
> >>> > > > >> > Jinwoong
> >>> > > > >> >
> >>> > > > >> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo <
> >>> > > jinwoong.yoo at gmail.com>
> >>> > > > >> > wrote:
> >>> > > > >> >
> >>> > > > >> > > Hi John,
> >>> > > > >> > >
> >>> > > > >> > > Thank you very much for your time investing the
issue.
> >>> > > > >> > > I am glad to hear that there is a trick to work
around the
> >>> issue
> >>> > > to
> >>> > > > >> read
> >>> > > > >> > > in TRMM data in netcdf format.
> >>> > > > >> > > I wonder if I can apply the same trick (
> >>> file_type=NETCDF_NCCF;)
> >>> > > to
> >>> > > > >> read
> >>> > > > >> > > in any other observation files in netcdf format?
> >>> > > > >> > > In fact, I would like to read in "home brew" netcdf
> dataset
> >>> > files
> >>> > > > into
> >>> > > > >> > > MET.
> >>> > > > >> > > One sample file of them was included in the
uploaded data
> >>> > folder (
> >>> > > > >> > > sample_tmax.nc).
> >>> > > > >> > > The data in this sample file was originally
generated by
> VIC
> >>> > > model.
> >>> > > > >> > > Then the file format was converted into a generic
netcdf
> >>> file
> >>> > > format
> >>> > > > >> > > although the dimension names are T, X, Y not time,
lat,
> lon.
> >>> > > > >> > > But their coordinates have units in "degrees_east"
or
> >>> > > > "degrees_north"
> >>> > > > >> as
> >>> > > > >> > > well as their long_name as "Longitude" and
"Latitude",
> >>> > > respectively.
> >>> > > > >> > >
> >>> > > > >> > > Of course, I will try to read those in for Grid-
stat
> today.
> >>> > > > >> > > But I would like to hear from you if the trick (
> >>> > > > >> file_type=NETCDF_NCCF;)
> >>> > > > >> > > can be applied generally, which I wish very much.
> >>> > > > >> > >
> >>> > > > >> > > Thank you so much, John.
> >>> > > > >> > >
> >>> > > > >> > > Regards,
> >>> > > > >> > >
> >>> > > > >> > > Jinwoong Yoo
> >>> > > > >> > >
> >>> > > > >> > >
> >>> > > > >> > > On Fri, Jul 7, 2017 at 1:16 PM, John Halley Gotway
via RT
> <
> >>> > > > >> > > met_help at ucar.edu> wrote:
> >>> > > > >> > >
> >>> > > > >> > >> Jinwoong,
> >>> > > > >> > >>
> >>> > > > >> > >> Thanks for sending your sample data and for your
patience
> >>> > while I
> >>> > > > was
> >>> > > > >> > out
> >>> > > > >> > >> of town.
> >>> > > > >> > >>
> >>> > > > >> > >> Using met-6.0, I'm able to process the TRMM NetCDF
file
> you
> >>> > sent.
> >>> > > > >> The
> >>> > > > >> > >> trick is that I had to tell it which NetCDF file
type
> >>> should be
> >>> > > > used
> >>> > > > >> to
> >>> > > > >> > >> interpret the data. Using "file_type =
NETCDF_NCCF;" I'm
> >>> > telling
> >>> > > > >> MET to
> >>> > > > >> > >> interpret it as if it were a CF-compliant NetCDF
file:
> >>> > > > >> > >>
> >>> > > > >> > >> met-6.0/bin/plot_data_plane \
> >>> > > > >> > >> trmm_daily.20051231.7.nc trmm_daily.20051231.7.ps
\
> >>> > > > >> > >> 'name="precipitation"; level="(*,*)";
> >>> file_type=NETCDF_NCCF;'
> >>> > > > >> > >>
> >>> > > > >> > >> DEBUG 1: Opening data file:
trmm_daily.20051231.7.nc
> >>> > > > >> > >> WARNING: NcCfFile::open() -> could not determine
the
> valid
> >>> > time,
> >>> > > > >> using
> >>> > > > >> > 0.
> >>> > > > >> > >> WARNING: NcCfFile::open() -> could not determine
the
> valid
> >>> > time,
> >>> > > > >> using
> >>> > > > >> > 0.
> >>> > > > >> > >> DEBUG 1: Creating postscript file:
> >>> trmm_daily.20051231.7.ps
> >>> > > > >> > >>
> >>> > > > >> > >> The plot_data_plane tool is able to read the data,
and
> I've
> >>> > > > attached
> >>> > > > >> the
> >>> > > > >> > >> resulting image. However, notice the warning
messages
> >>> about
> >>> > the
> >>> > > > >> valid
> >>> > > > >> > >> time.
> >>> > > > >> > >>
> >>> > > > >> > >> Using ncdump to see that file attributes, I see
this
> timing
> >>> > > > >> information:
> >>> > > > >> > >> :HDF5_GLOBAL.BeginDate = "2005-12-
31" ;
> >>> > > > >> > >> :HDF5_GLOBAL.BeginTime =
"01:30:00.000Z"
> ;
> >>> > > > >> > >> :HDF5_GLOBAL.EndDate = "2006-01-
01" ;
> >>> > > > >> > >> :HDF5_GLOBAL.EndTime =
"01:29:59.999Z" ;
> >>> > > > >> > >>
> >>> > > > >> > >> However that is not the CF-compliant way of
specifying
> >>> timing
> >>> > > info.
> >>> > > > >> So
> >>> > > > >> > >> while MET will be able to read the data, the
timing info
> >>> won't
> >>> > be
> >>> > > > >> > accurate
> >>> > > > >> > >> in the MET output files. Instead, you'll see
"19700101"
> >>> which
> >>> > is
> >>> > > > >> > unixtime
> >>> > > > >> > >> = 0.
> >>> > > > >> > >>
> >>> > > > >> > >> Another option would be pulling the binary TRMM
data and
> >>> using
> >>> > > this
> >>> > > > >> > >> Rscript
> >>> > > > >> > >> to convert the binary to NetCDF:
> >>> > > > >> > >>
http://www.dtcenter.org/met/users/downloads/Rscripts/
> >>> > > > trmmbin2nc.R
> >>> > > > >> > >>
> >>> > > > >> > >> However, I haven't done this in a while and am not
sure
> if
> >>> > you'll
> >>> > > > run
> >>> > > > >> > into
> >>> > > > >> > >> any issues.
> >>> > > > >> > >>
> >>> > > > >> > >> Hope that helps.
> >>> > > > >> > >>
> >>> > > > >> > >> Thanks,
> >>> > > > >> > >> John
> >>> > > > >> > >>
> >>> > > > >> > >>
> >>> > > > >> > >>
> >>> > > > >> > >>
> >>> > > > >> > >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo via
RT <
> >>> > > > >> met_help at ucar.edu>
> >>> > > > >> > >> wrote:
> >>> > > > >> > >>
> >>> > > > >> > >> >
> >>> > > > >> > >> > <URL: https://rt.rap.ucar.edu/rt/
> >>> > Ticket/Display.html?id=81063
> >>> > > >
> >>> > > > >> > >> >
> >>> > > > >> > >> > Hi John,
> >>> > > > >> > >> >
> >>> > > > >> > >> > Thank you very much.
> >>> > > > >> > >> > Regards,
> >>> > > > >> > >> >
> >>> > > > >> > >> > Jinwoong
> >>> > > > >> > >> >
> >>> > > > >> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John Halley
Gotway via
> >>> RT <
> >>> > > > >> > >> > met_help at ucar.edu> wrote:
> >>> > > > >> > >> >
> >>> > > > >> > >> > > Jinwoong,
> >>> > > > >> > >> > >
> >>> > > > >> > >> > > I'm out of the office today but will take a
closer
> look
> >>> > > > tomorrow.
> >>> > > > >> > >> > >
> >>> > > > >> > >> > > Thanks
> >>> > > > >> > >> > > John
> >>> > > > >> > >> > >
> >>> > > > >> > >> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo
via RT <
> >>> > > > >> > >> met_help at ucar.edu>
> >>> > > > >> > >> > > wrote:
> >>> > > > >> > >> > >
> >>> > > > >> > >> > > >
> >>> > > > >> > >> > > > <URL: https://rt.rap.ucar.edu/rt/
> >>> > > > Ticket/Display.html?id=81063
> >>> > > > >> >
> >>> > > > >> > >> > > >
> >>> > > > >> > >> > > > Hi John,
> >>> > > > >> > >> > > >
> >>> > > > >> > >> > > > Thank you for your reply.
> >>> > > > >> > >> > > > I uploaded my data as in Yoo_data4.tar on
the ftp
> >>> site.
> >>> > > > >> > >> > > > I included several files for the message of
ID of [
> >>> > > > >> > rt.rap.ucar.edu
> >>> > > > >> > >> > > #81074]
> >>> > > > >> > >> > > > as well.
> >>> > > > >> > >> > > > Thank you.
> >>> > > > >> > >> > > > Regards,
> >>> > > > >> > >> > > >
> >>> > > > >> > >> > > > Jinwoong
> >>> > > > >> > >> > > >
> >>> > > > >> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM, John Halley
Gotway
> >>> via
> >>> > RT
> >>> > > <
> >>> > > > >> > >> > > > met_help at ucar.edu> wrote:
> >>> > > > >> > >> > > >
> >>> > > > >> > >> > > > > Jinwoong,
> >>> > > > >> > >> > > > >
> >>> > > > >> > >> > > > > I see that you're having trouble reading a
TRMM
> >>> NetCDF
> >>> > > file
> >>> > > > >> into
> >>> > > > >> > >> MET.
> >>> > > > >> > >> > > > Can
> >>> > > > >> > >> > > > > you please post the problematic file to
our
> >>> anonymous
> >>> > ftp
> >>> > > > >> site
> >>> > > > >> > so
> >>> > > > >> > >> I
> >>> > > > >> > >> > can
> >>> > > > >> > >> > > > > take a look?
> >>> > > > >> > >> > > > >
> >>> > > > >> > >> > > > > http://www.dtcenter.org/met/
> >>> > > users/support/met_help.php#ftp
> >>> > > > >> > >> > > > >
> >>> > > > >> > >> > > > > Thanks,
> >>> > > > >> > >> > > > > John Halley Gotway
> >>> > > > >> > >> > > > >
> >>> > > > >> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong
Yoo via
> >>> RT <
> >>> > > > >> > >> > met_help at ucar.edu
> >>> > > > >> > >> > > >
> >>> > > > >> > >> > > > > wrote:
> >>> > > > >> > >> > > > >
> >>> > > > >> > >> > > > > >
> >>> > > > >> > >> > > > > > <URL: https://rt.rap.ucar.edu/rt/Tic
> >>> > > > >> ket/Display.html?id=81063
> >>> > > > >> > >
> >>> > > > >> > >> > > > > >
> >>> > > > >> > >> > > > > > Hi,
> >>> > > > >> > >> > > > > >
> >>> > > > >> > >> > > > > > TRMM data comes in as netCDF-4 classic
model.
> >>> > > > >> > >> > > > > > I changed it to netCDF classic and run
the same
> >>> > command
> >>> > > > >> for a
> >>> > > > >> > >> test.
> >>> > > > >> > >> > > > > > But I got the same error as below.
> >>> > > > >> > >> > > > > >
> >>> > > > >> > >> > > > > > yoo108 at halstead-fe00:*/scratch
> >>> /halstead/y/yoo108/
> >>> > TRMM*
> >>> > > $
> >>> > > > >> > >> > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> >>> > > > >> > >> /scratch/halstead/y/yoo108/
> >>> > > > >> > >> > > TRMM/
> >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> >>> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/ND_
> >>> grided_obs/daily_T2m_
> >>> > > > >> > >> > > maxminmean_1976.nc
> >>> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/TRMM/
> >>> > regrid_trmm_sample.nc
> >>> > > > >> -field
> >>> > > > >> > >> > > > > > 'name="precipitation";'
> >>> > > > >> > >> > > > > >
> >>> > > > >> > >> > > > > > DEBUG 1: Reading data file:
> >>> > > > /scratch/halstead/y/yoo108/TRM
> >>> > > > >> M/
> >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> >>> > > > >> > >> > > > > >
> >>> > > > >> > >> > > > > > ERROR :
> >>> > > > >> > >> > > > > >
> >>> > > > >> > >> > > > > > ERROR : process_data_file() ->
> >>> > > > >> "/scratch/halstead/y/yoo108/TR
> >>> > > > >> > >> MM/
> >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc" not a
valid data
> >>> file
> >>> > > > >> > >> > > > > >
> >>> > > > >> > >> > > > > > Thank you.
> >>> > > > >> > >> > > > > >
> >>> > > > >> > >> > > > > > Regards,
> >>> > > > >> > >> > > > > >
> >>> > > > >> > >> > > > > >
> >>> > > > >> > >> > > > > > Jinwoong
> >>> > > > >> > >> > > > > >
> >>> > > > >> > >> > > > > > On Mon, Jul 3, 2017 at 11:41 AM,
Jinwoong Yoo <
> >>> > > > >> > >> > > jinwoong.yoo at gmail.com>
> >>> > > > >> > >> > > > > > wrote:
> >>> > > > >> > >> > > > > >
> >>> > > > >> > >> > > > > > > Hi,
> >>> > > > >> > >> > > > > > >
> >>> > > > >> > >> > > > > > > I noticed that TRMM data dimension was
(lon,
> >>> lat).
> >>> > > > >> > >> > > > > > > So I switched their order to (lat,
lon) and
> >>> ran the
> >>> > > > >> command
> >>> > > > >> > >> > again.
> >>> > > > >> > >> > > > > > > However, I got the same error message
as
> below.
> >>> > > > >> > >> > > > > > >
> >>> > > > >> > >> > > > > > > yoo108 at halstead-fe00:*/scratch
> >>> /halstead/y/yoo108/
> >>> > > TRMM*
> >>> > > > $
> >>> > > > >> > >> > > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> >>> > > > >> > >> > /scratch/halstead/y/yoo108/
> >>> > > > >> > >> > > > > TRMM/
> >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> >>> > > > /scratch/halstead/y/yoo108/ND_
> >>> > > > >> > >> > > > > > >
grided_obs/daily_T2m_maxminmean_1976.nc
> >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> >>> > > > >> > >> > > > > TRMM/
> >>> > > > >> > >> > > > > > > regrid_trmm_sample.nc -field
> >>> > 'name="precipitation";'
> >>> > > > >> > >> > > > > > >
> >>> > > > >> > >> > > > > > > DEBUG 1: Reading data file:
> >>> > > > >> /scratch/halstead/y/yoo108/TRM
> >>> > > > >> > M/
> >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> >>> > > > >> > >> > > > > > >
> >>> > > > >> > >> > > > > > > ERROR :
> >>> > > > >> > >> > > > > > >
> >>> > > > >> > >> > > > > > > ERROR : process_data_file() ->
> >>> > > > >> > "/scratch/halstead/y/yoo108/TR
> >>> > > > >> > >> > MM/
> >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc" not a valid
data
> >>> file
> >>> > > > >> > >> > > > > > >
> >>> > > > >> > >> > > > > > >
> >>> > > > >> > >> > > > > > > Thank you.
> >>> > > > >> > >> > > > > > >
> >>> > > > >> > >> > > > > > > Regards,
> >>> > > > >> > >> > > > > > >
> >>> > > > >> > >> > > > > > >
> >>> > > > >> > >> > > > > > > Jinwoong
> >>> > > > >> > >> > > > > > >
> >>> > > > >> > >> > > > > > >
> >>> > > > >> > >> > > > > > >
> >>> > > > >> > >> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM,
Jinwoong
> Yoo <
> >>> > > > >> > >> > > > jinwoong.yoo at gmail.com>
> >>> > > > >> > >> > > > > > > wrote:
> >>> > > > >> > >> > > > > > >
> >>> > > > >> > >> > > > > > >> Hi,
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> I got a similar result with a TRMM
data.
> >>> > > > >> > >> > > > > > >> Please see below:
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/scratch
> >>> /halstead/y/yoo108/
> >>> > > > TRMM*
> >>> > > > >> $
> >>> > > > >> > >> > > > > > >> ~/met-
6.0_bugfix/bin/regrid_data_plane
> >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> >>> > > > >> > >> > > > > TRMM/
> >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> >>> > > > >> /scratch/halstead/y/yoo108/ND_
> >>> > > > >> > >> > > > > > >>
grided_obs/daily_T2m_maxminmean_1976.nc
> >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> >>> > > > >> > >> > > > > > TRMM/
> >>> > > > >> > >> > > > > > >> regrid_trmm_sample.nc -field
> >>> > > 'name="precipitation";'
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> DEBUG 1: Reading data file:
> >>> > > > >> /scratch/halstead/y/yoo108/TRM
> >>> > > > >> > M/
> >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> ERROR : process_data_file() ->
> >>> > > > >> > >> "/scratch/halstead/y/yoo108/TR
> >>> > > > >> > >> > MM/
> >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc" not a
valid
> data
> >>> file
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> A part of ncdump output for the TRMM
data is
> >>> > pasted
> >>> > > > >> below:
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/scratch
> >>> /halstead/y/yoo108/
> >>> > > > TRMM*
> >>> > > > >> $
> >>> > > > >> > >> ncdump
> >>> > > > >> > >> > > -h
> >>> > > > >> > >> > > > > > >> subset_200003-200512/3B42RT_
> >>> > > Daily.20051231.7.nc4.nc4
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> netcdf \3B42RT_Daily.20051231.7.nc4 {
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> dimensions:
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> lon = 59 ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> lat = 58 ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> variables:
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> short precipitation_cnt(lon, lat) ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> precipitation_cnt:units = "count" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> precipitation_cnt:long_name = "Count
of
> valid
> >>> 3-hr
> >>> > > > >> > >> precipitation
> >>> > > > >> > >> > > > > > >> retrievals for the day" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> precipitation_cnt:coordinates = "lat
lon" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> precipitation_cnt:origname =
> >>> "precipitation_cnt" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> precipitation_cnt:fullnamepath =
> >>> > > "/precipitation_cnt"
> >>> > > > ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> float uncal_precipitation(lon, lat) ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> uncal_precipitation:units = "mm" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> uncal_precipitation:long_name =
"Daily
> >>> accumulated
> >>> > > > >> > >> uncalibrated
> >>> > > > >> > >> > > > > > >> precipitation" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> uncal_precipitation:coordinates =
"lat
> lon" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> uncal_precipitation:_FillValue =
-9999.9f ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> uncal_precipitation:origname =
> >>> > > "uncal_precipitation" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> uncal_precipitation:fullnamepath =
> >>> > > > >> "/uncal_precipitation"
> >>> > > > >> > ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> short uncal_precipitation_cnt(lon,
lat) ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:units =
"count" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:long_name =
"Count
> of
> >>> > valid
> >>> > > > >> 3-hr
> >>> > > > >> > >> uncal
> >>> > > > >> > >> > > > > > >> precipitation retrievals for the day"
;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:coordinates =
"lat
> >>> lon" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:origname =
> >>> > > > >> > >> "uncal_precipitation_cnt" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:fullnamepath
=
> >>> > > > >> > >> > > "/uncal_precipitation_cnt" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> float precipitation(lon, lat) ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> precipitation:units = "mm" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> precipitation:long_name = "Daily
accumulated
> >>> > > > >> precipitation
> >>> > > > >> > >> > > (combined
> >>> > > > >> > >> > > > > > >> microwave-IR) estimate" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> precipitation:coordinates = "lat lon"
;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> precipitation:_FillValue = -9999.9f ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> precipitation:origname =
"precipitation" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> precipitation:fullnamepath =
> "/precipitation"
> >>> ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> short randomError_cnt(lon, lat) ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> randomError_cnt:units = "count" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> randomError_cnt:long_name = "Count of
> >>> randomError
> >>> > > for
> >>> > > > >> the
> >>> > > > >> > >> day" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> randomError_cnt:coordinates = "lat
lon" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> randomError_cnt:origname =
> "randomError_cnt" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> randomError_cnt:fullnamepath =
> >>> "/randomError_cnt"
> >>> > ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> float randomError(lon, lat) ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> randomError:units = "mm" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> randomError:long_name = "Daily total
error
> of
> >>> > > combined
> >>> > > > >> > >> > > microwave-IR
> >>> > > > >> > >> > > > > > >> precipitation estimate" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> randomError:_FillValue = -9999.9f ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> randomError:origname = "randomError"
;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> randomError:fullnamepath =
"/randomError" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> float lat(lat) ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> lat:units = "degrees_north" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> lat:long_name = "Latitude" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> lat:origname = "lat" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> lat:fullnamepath = "/lat" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> float lon(lon) ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> lon:units = "degrees_east" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> lon:long_name = "Longitude" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> lon:origname = "lon" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> lon:fullnamepath = "/lon" ;
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> Thank you.
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> Regards,
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> Jinwoong
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >> On Thu, Jun 29, 2017 at 3:11 PM,
> >>> > met_help at ucar.edu
> >>> > > > via
> >>> > > > >> RT
> >>> > > > >> > <
> >>> > > > >> > >> > > > > > >> met_help at ucar.edu> wrote:
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED
AVAILABILITY
> >>> > BETWEEN
> >>> > > > >> > 5/23/17
> >>> > > > >> > >> AND
> >>> > > > >> > >> > > > > > >>> 5/30/17. RESPONSES MAY BE DELAYED.
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> Greetings,
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> This message has been automatically
> >>> generated in
> >>> > > > >> response
> >>> > > > >> > to
> >>> > > > >> > >> > the
> >>> > > > >> > >> > > > > > >>> creation of a trouble ticket
regarding:
> >>> > > > >> > >> > > > > > >>> "regrid_data_plane: not a
valid
> data
> >>> > file",
> >>> > > > >> > >> > > > > > >>> a summary of which appears below.
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> There is no need to reply to this
message
> >>> right
> >>> > > now.
> >>> > > > >> Your
> >>> > > > >> > >> > ticket
> >>> > > > >> > >> > > > has
> >>> > > > >> > >> > > > > > >>> been
> >>> > > > >> > >> > > > > > >>> assigned an ID of [rt.rap.ucar.edu
> #81063].
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> Please include the string:
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> [rt.rap.ucar.edu #81063]
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> in the subject line of all future
> >>> correspondence
> >>> > > > about
> >>> > > > >> > this
> >>> > > > >> > >> > > issue.
> >>> > > > >> > >> > > > To
> >>> > > > >> > >> > > > > > do
> >>> > > > >> > >> > > > > > >>> so,
> >>> > > > >> > >> > > > > > >>> you may reply to this message.
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> Thank you,
> >>> > > > >> > >> > > > > > >>>
met_help at ucar.edu
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> ------------------------------
> >>> > > > >> > >> ------------------------------
> >>> > > > >> > >> > > > > > >>> -------------
> >>> > > > >> > >> > > > > > >>> Hi,
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> I am trying to regrid one of my
observation
> >>> files
> >>> > > in
> >>> > > > >> lat
> >>> > > > >> > lon
> >>> > > > >> > >> > > > > coordinate
> >>> > > > >> > >> > > > > > >>> grid to WRF curvilinear grid.
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> I ran bin/regrid_data_plane using a
sample
> >>> lat
> >>> > lon
> >>> > > > grid
> >>> > > > >> > file
> >>> > > > >> > >> > and
> >>> > > > >> > >> > > a
> >>> > > > >> > >> > > > > file
> >>> > > > >> > >> > > > > > >>> in
> >>> > > > >> > >> > > > > > >>> the WRF grid. But I got error as
shown
> below:
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> >>> > > > >> > /halstead/y/yoo108/ND_grided_
> >>> > > > >> > >> > obs*
> >>> > > > >> > >> > > $
> >>> > > > >> > >> > > > > > >>> ~/met-
6.0_bugfix/bin/regrid_data_plane
> >>> > > > >> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_grided_obs/
> >>> > > > >> sample_tmax.nc
> >>> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> >>> > > grided_obs/daily_T2m_
> >>> > > > >> > >> > > > > maxminmean_1976.nc
> >>> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> >>> > > > >> > >> grided_obs/NDtoWRFgrid_sample_
> >>> > > > >> > >> > > > tmax.nc
> >>> > > > >> > >> > > > > > >>> -field
> >>> > > > >> > >> > > > > > >>> 'name="tmax";'
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> DEBUG 1: Reading data file:
> >>> > > > >> /scratch/halstead/y/yoo108/ND_
> >>> > > > >> > >> > > > > grided_obs/
> >>> > > > >> > >> > > > > > >>> sample_tmax.nc
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> ERROR : process_data_file() ->
> >>> > > > >> > >> "/scratch/halstead/y/yoo108/ND
> >>> > > > >> > >> > > > > > >>> _grided_obs/
> >>> > > > >> > >> > > > > > >>> sample_tmax.nc" not a valid data
file
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> I wonder which part of the input
file does
> >>> not
> >>> > > > satisfy
> >>> > > > >> the
> >>> > > > >> > >> > MET's
> >>> > > > >> > >> > > > > "valid
> >>> > > > >> > >> > > > > > >>> file" criteria.
> >>> > > > >> > >> > > > > > >>> ncdump output of the input file
looks as
> >>> below:
> >>> > > > >> > >> > > > > > >>> Input file was originally generated
by VIC
> >>> model
> >>> > > and
> >>> > > > >> > >> converted
> >>> > > > >> > >> > > into
> >>> > > > >> > >> > > > > cf
> >>> > > > >> > >> > > > > > >>> netcdf format.
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> Thank you in advance.
> >>> > > > >> > >> > > > > > >>> Regards,
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> Jinwoong
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> >>> > > > >> > /halstead/y/yoo108/ND_grided_
> >>> > > > >> > >> > obs*
> >>> > > > >> > >> > > $
> >>> > > > >> > >> > > > > > >>> ncdump -h
> >>> > > > >> > >> > > > > > >>> sample_tmax.nc
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> netcdf sample_tmax {
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> dimensions:
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> T = 1 ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> X = 55 ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> Y = 65 ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> variables:
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> double T(T) ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> T:units = "days since 1915-01-01" ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> T:long_name = "Time" ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> double X(X) ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> X:units = "degrees_east" ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> X:long_name = "Longitude" ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> double Y(Y) ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> Y:units = "degrees_north" ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> Y:long_name = "Latitude" ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> double tmax(T, Y, X) ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> tmax:units = "degC" ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> tmax:long_name = "tmax calculated by
VIC" ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> tmax:missing_value = -9999.f ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> // global attributes:
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>> :production = "VIC output" ;
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>>
> >>> > > > >> > >> > > > > > >>
> >>> > > > >> > >> > > > > > >
> >>> > > > >> > >> > > > > >
> >>> > > > >> > >> > > > > >
> >>> > > > >> > >> > > > >
> >>> > > > >> > >> > > > >
> >>> > > > >> > >> > > >
> >>> > > > >> > >> > > >
> >>> > > > >> > >> > >
> >>> > > > >> > >> > >
> >>> > > > >> > >> >
> >>> > > > >> > >> >
> >>> > > > >> > >>
> >>> > > > >> > >>
> >>> > > > >> > >
> >>> > > > >> >
> >>> > > > >> >
> >>> > > > >>
> >>> > > > >>
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
> >>>
> >>
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Wed Jul 12 12:46:49 2017
Hi John,
I am still experiencing troubles to read in netcdf files for grid_stat
command.
Please read the last two previous emails that I sent.
Thank you very much.
Regards,
Jinwoong
On Wed, Jul 12, 2017 at 1:44 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Great, glad you were able to get it working.
>
> Thanks,
> John
>
> On Tue, Jul 11, 2017 at 9:44 AM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >
> > Hi John,
> >
> > Even with the plot_data_plane command,
> > I noticed that "file_type = NETCDF_PINT;" argument should be
provided in
> > the command line.
> > Otherwise, it fails. Please see below.
> >
> > yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal* $
> > ~/met-6.0_bugfix/bin/plot_data_plane
> > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> > 00.nc
> > met_em.d03.2005-12-31_18:00:00.ps 'name="TT";level="(0,0,*,*)";'
> >
> > DEBUG 1: Opening data file:
> > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> > 00.nc
> >
> > ERROR : plot_data_plane -> file
> > "/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> > 00.nc"
> > not a valid data file
> >
> >
> >
> > yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal* $
> > ~/met-6.0_bugfix/bin/plot_data_plane
> > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> > 00.nc
> > met_em.d03.2005-12-31_18:00:00.ps
'name="TT";level="(0,0,*,*)";file_type
> =
> > NETCDF_PINT;'
> >
> > DEBUG 1: Opening data file:
> > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> > 00.nc
> >
> > DEBUG 1: Creating postscript file: met_em.d03.2005-12-
31_18:00:00.ps
> >
> >
> >
> > Thank you.
> >
> > Regards,
> >
> >
> > Jinwoong
> >
> >
> > On Tue, Jul 11, 2017 at 11:12 AM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > wrote:
> >
> > > Hi John,
> > >
> > > Now I am trying to execute grid_stat against these netcdf files
that
> have
> > > been patted with the WRF global attributes.
> > >
> > > I tried to include 'file_type = NETCDF_PINT;' argument both in
its
> > > configuration file and in the command line.
> > > However, both failed to run (Please see below).
> > >
> > > Could you please guide me how to specify the netcdf file type in
the
> > > grid_stat application?
> > > Thank you.
> > >
> > > Regards,
> > >
> > > Jinwoong
> > >
> > >
> > > 1.
> > >
> > > .......
> > >
> > > obs = {
> > >
> > >
> > > field = [
> > >
> > > {
> > >
> > > name = "TT";
> > >
> > > level = [ "(0,0,*,*)" ];
> > >
> > > file_type = NETCDF_PINT;
> > >
> > > cat_thresh = [];
> > >
> > > }
> > >
> > > .......
> > >
> > > DEBUG 1: Default Config File: /home/yoo108/met-6.0_bugfix/
> > > share/met/config/GridStatConfig_default
> > >
> > > DEBUG 1: User Config File: /scratch/halstead/y/yoo108/
> > wrfAnalysis/METanal/
> > > GridStatConfig_met_em
> > >
> > > DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() -> created
new
> > > Met2dDataFile object of type "FileType_Gb2".
> > >
> > > DEBUG 4: Switching the GRIB2 radius of the earth value of
6371.23 km to
> > > 6371.2 km for internal consistency.
> > >
> > > DEBUG 4:
> > >
> > > DEBUG 4: Lambert Conformal Grid Data:
> > >
> > > DEBUG 4: scale_lat_1: 48
> > >
> > > DEBUG 4: scale_lat_2: 32
> > >
> > > DEBUG 4: lat_pin: 36.9132
> > >
> > > DEBUG 4: lon_pin: 92.0748
> > >
> > > DEBUG 4: x_pin: 0
> > >
> > > DEBUG 4: y_pin: 0
> > >
> > > DEBUG 4: lon_orient: 97
> > >
> > > DEBUG 4: d_km: 4
> > >
> > > DEBUG 4: r_km: 6371.2
> > >
> > > DEBUG 4: nx: 189
> > >
> > > DEBUG 4: ny: 270
> > >
> > > DEBUG 4:
> > >
> > > DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() -> created
new
> > > Met2dDataFile object of type "FileType_None".
> > >
> > > ERROR :
> > >
> > > ERROR : Trouble reading observation file
"/scratch/halstead/y/yoo108/
> > > NCAR_BC_met_em/met_em.d03.1980-01-01_00:00:00.nc"
> > >
> > >
> > >
> > > 2.
> > >
> > > /home/yoo108/met-6.0_bugfix/bin/grid_stat
> $dir_data/$yyyy/$yyyy$nummon/$
> > > grib_date1 $dir_data2/$met_em_date1 $analDir/$GridStatConfig
> 'file_type =
> > > NETCDF_PINT;' -outdir $workDir -v 4
> > >
> > > *** Model Evaluation Tools (METV6.0) ***
> > >
> > >
> > > Usage: grid_stat
> > >
> > > fcst_file
> > >
> > > obs_file
> > >
> > > config_file
> > >
> > > [-outdir path]
> > >
> > > [-log file]
> > >
> > > [-v level]
> > >
> > > [-compress level]
> > >
> > >
> > > where "fcst_file" is a gridded forecast file containing the
field(s) to
> > > be verified (required).
> > >
> > > "obs_file" is a gridded observation file containing the
verifying
> > field(s)
> > > (required).
> > >
> > > "config_file" is a GridStatConfig file containing the desired
> > > configuration settings (required).
> > >
> > > "-outdir path" overrides the default output directory
> > > (/scratch/halstead/y/yoo108/wrfAnalysis/METanal/wrf2met_em)
> (optional).
> > >
> > > "-log file" outputs log messages to the specified file
(optional).
> > >
> > > "-v level" overrides the default level of logging (4)
(optional).
> > >
> > > "-compress level" overrides the compression level of NetCDF
variable
> (0)
> > > (optional).
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Jul 10, 2017 at 4:53 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > > wrote:
> > >
> > >> Hi John,
> > >>
> > >> I was able to open netcdf files that share the same coordinates
with
> WRF
> > >> output by copying the global attribute of the WRF output to
these
> netcdf
> > >> files:
> > >>
> > >> ncks -A -x wrfout.nc target.nc
> > >>
> > >> This enabled me to open netcdf files in MET using
> > >> 'name="TT";level="(0,0,*,*)";file_type = NETCDF_PINT;'
argument.
> > >>
> > >> Thank you very much!
> > >> Regards,
> > >>
> > >> Jinwoong
> > >>
> > >> On Mon, Jul 10, 2017 at 3:04 PM, John Halley Gotway via RT <
> > >> met_help at ucar.edu> wrote:
> > >>
> > >>> Jinwoong,
> > >>>
> > >>> I tried running the sample file (daily_T2m_maxminmean_1981.nc)
> through
> > >>> plot_data_plane and saw the same behavior you did. Looking
closely
> at
> > >>> that
> > >>> file I see that is not the NetCDF output generated by WRF.
The
> history
> > >>> attribute indicates that it was created by the "ncks" utility:
> > >>>
> > >>> :history = "Sun Jul 2 15:47:18 2017: ncks -d days,0,0
> > >>> /scratch/halstead/k/khoogewi/CCRC_wrf/analysis/T2m/daily_T2m_
> > >>> maxminmean_1981.nc
> > >>> /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_maxminm
> > >>> ean_19810101.nc"
> > >>>
> > >>>
> > >>> This is not a CF-compliant NetCDF file and it does not look
like the
> > >>> output
> > >>> from WRF. Another alternative is making it look like the
NetCDF file
> > >>> format used by the MET tools themselves.
> > >>>
> > >>> I ran the following command to add global attributes to define
the
> grid
> > >>> spec for MET:
> > >>>
> > >>> ncatted \
> > >>> -a MET_version,global,o,c,"V6.0" \
> > >>> -a Projection,global,o,c,"Lambert Conformal" \
> > >>> -a scale_lat_1,global,o,c,"48" \
> > >>> -a scale_lat_2,global,o,c,"32" \
> > >>> -a lat_pin,global,o,c,"48" \
> > >>> -a lon_pin,global,o,c,"-97" \
> > >>> -a x_pin,global,o,c,"0" \
> > >>> -a y_pin,global,o,c,"0" \
> > >>> -a lon_orient,global,o,c,"-97" \
> > >>> -a d_km,global,o,c,"3" \
> > >>> -a r_km,global,o,c,"6371.2" \
> > >>> -a nx,global,o,c,"189" \
> > >>> -a ny,global,o,c,"270" \
> > >>> daily_T2m_maxminmean_1976.nc -o
daily_T2m_maxminmean_1976_MET.nc
> > >>>
> > >>> However, I don't think these are all correct. Specifically, I
don't
> > know
> > >>> how the "lon_orient" should be set. So I set it to the
longitude of
> > the
> > >>> lower-left corner. Also, I don't know how the d_km should be
set.
> > >>> That's
> > >>> the grid spacing in km. So I just guess with a value of 3.
> > >>>
> > >>> This enables MET to plot the result, but you should work on
making
> the
> > >>> grid
> > >>> info correct:
> > >>> met-6.0/bin/plot_data_plane \
> > >>> daily_T2m_maxminmean_1976_MET.nc \
> > >>> daily_T2m_maxminmean_1976_MET.ps \
> > >>> 'name="T2m_max"; level="(10,*,*)";' -v 4
> > >>>
> > >>> Thanks,
> > >>> John
> > >>>
> > >>>
> > >>>
> > >>> On Fri, Jul 7, 2017 at 5:06 PM, Jinwoong Yoo via RT <
> met_help at ucar.edu
> > >
> > >>> wrote:
> > >>>
> > >>> >
> > >>> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > >>> >
> > >>> > Hi John,
> > >>> >
> > >>> > Thank you for your comment.
> > >>> > I tried it but it failed.
> > >>> > Please see below.
> > >>> >
> > >>> > yoo108 at halstead-fe03:*/scratch/halstead/y/yoo108/
> > wrfAnalysis/METanal*
> > >>> $
> > >>> > ~/met-6.0_bugfix/bin/plot_data_plane
> > >>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > >>> > maxminmean_20051231.nc
> > >>> > wrfDaily_T2m_maxminmean_20051231.ps
> > >>> > 'name="T2m_max";level="(0,*,*)";file_type = NETCDF_PINT;'
> > >>> >
> > >>> > DEBUG 1: Opening data file:
> > >>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > >>> > maxminmean_20051231.nc
> > >>> >
> > >>> > ERROR : MetNcPinterpDataFile::open(const char *) -> unable
to
> open
> > >>> NetCDF
> > >>> > file
> > >>> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > >>> > maxminmean_20051231.nc"
> > >>> >
> > >>> > ERROR : Met2dDataFileFactory::new_met_2d_data_file() ->
error
> > opening
> > >>> > file
> > >>> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > >>> > maxminmean_20051231.nc"
> > >>> >
> > >>> >
> > >>> >
> > >>> > One sample file (wrfDaily_T2m_maxminmean_19810101.nc) is
also
> > >>> included in
> > >>> > the Yoo_data4.tar file that I uploaded previously.
> > >>> > Thank you.
> > >>> > Haver a nice weekend.
> > >>> >
> > >>> > Regards,
> > >>> >
> > >>> > Jinwoong
> > >>> >
> > >>> >
> > >>> >
> > >>> > On Fri, Jul 7, 2017 at 6:04 PM, John Halley Gotway via RT <
> > >>> > met_help at ucar.edu
> > >>> > > wrote:
> > >>> >
> > >>> > > Jinwoong,
> > >>> > >
> > >>> > > If they really are output from WRF, one simple thing to
try is
> > >>> telling
> > >>> > MET
> > >>> > > to interpret them as the NetCDF output of the wrf_interp
utility
> > >>> > > :
> > >>> > > file_type = NETCDF_PINT;
> > >>> > >
> > >>> > > "PINT" stands for "pressure interpolated"... pinterp was
the
> > >>> precursor to
> > >>> > > the current wrf_interp tool.
> > >>> > >
> > >>> > > If that doesn't work, I'll need to see a sample file
before
> making
> > >>> any
> > >>> > > other suggestions.
> > >>> > >
> > >>> > > Thanks,
> > >>> > > John
> > >>> > >
> > >>> > >
> > >>> > >
> > >>> > > On Fri, Jul 7, 2017 at 3:36 PM, Jinwoong Yoo via RT <
> > >>> met_help at ucar.edu>
> > >>> > > wrote:
> > >>> > >
> > >>> > > >
> > >>> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
> >
> > >>> > > >
> > >>> > > > Hi John,
> > >>> > > >
> > >>> > > > I was able to read in a "home brew" netcdf data file
using
> > >>> > > plot_data_plane.
> > >>> > > >
> > >>> > > > Then, I went ahead and tried another netcdf file in
curvilinear
> > >>> > > coordinate
> > >>> > > > which is in the same coordinate grid as my WRF output.
But it
> > >>> failed.
> > >>> > > >
> > >>> > > > I have many netcdf climatology files from the WRF
simulation
> such
> > >>> as
> > >>> > > daily,
> > >>> > > > monthly, and annual, etc. Therefore, they are all in
> curvilinear
> > >>> > > coordinate
> > >>> > > > (Lambert).
> > >>> > > >
> > >>> > > > I wonder if there is any work around so that I can feed
these
> > files
> > >>> > into
> > >>> > > > MET?
> > >>> > > > Or should I regrid them all into lat lon coordinate
files
> first?
> > >>> > > >
> > >>> > > > Thank you, John.
> > >>> > > >
> > >>> > > > Regards,
> > >>> > > >
> > >>> > > > Jinwoong Yoo
> > >>> > > >
> > >>> > > >
> > >>> > > > On Fri, Jul 7, 2017 at 3:01 PM, Jinwoong Yoo <
> > >>> jinwoong.yoo at gmail.com>
> > >>> > > > wrote:
> > >>> > > >
> > >>> > > > > Hi John,
> > >>> > > > >
> > >>> > > > > Thank you very much.
> > >>> > > > > Let me try and let you know how it goes.
> > >>> > > > > Thank you.
> > >>> > > > > Regards,
> > >>> > > > >
> > >>> > > > > Jinwoong
> > >>> > > > >
> > >>> > > > > On Fri, Jul 7, 2017 at 2:59 PM, John Halley Gotway via
RT <
> > >>> > > > > met_help at ucar.edu> wrote:
> > >>> > > > >
> > >>> > > > >> Jinwoong,
> > >>> > > > >>
> > >>> > > > >> Yes, you can give it a try. The closer you can make
the
> > NetCDF
> > >>> > files
> > >>> > > to
> > >>> > > > >> the CF-convention, the more likely MET will be able
to read
> > it.
> > >>> > > > >>
> > >>> > > > >> The reason that's its able to read the TRMM data are
that
> the
> > >>> > lat/lon
> > >>> > > > >> values are equally spaced. Non-equally spaced
lat/lon
> values
> > >>> on a
> > >>> > map
> > >>> > > > >> projection require that the map projection
information be
> > >>> specified.
> > >>> > > > >> Unfortunately, specifying map projection information
in
> > >>> CF-compliant
> > >>> > > > >> NetCDF
> > >>> > > > >> files is not as easy as I think it should be!
> > >>> > > > >>
> > >>> > > > >> Hope it works out ok for you.
> > >>> > > > >>
> > >>> > > > >> Thanks,
> > >>> > > > >> John
> > >>> > > > >>
> > >>> > > > >> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo via RT
<
> > >>> > > met_help at ucar.edu
> > >>> > > > >
> > >>> > > > >> wrote:
> > >>> > > > >>
> > >>> > > > >> >
> > >>> > > > >> > <URL: https://rt.rap.ucar.edu/rt/
> > Ticket/Display.html?id=81063
> > >>> >
> > >>> > > > >> >
> > >>> > > > >> > investigating not investing :)
> > >>> > > > >> >
> > >>> > > > >> > Thanks!
> > >>> > > > >> > Regards,
> > >>> > > > >> >
> > >>> > > > >> > Jinwoong
> > >>> > > > >> >
> > >>> > > > >> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo <
> > >>> > > jinwoong.yoo at gmail.com>
> > >>> > > > >> > wrote:
> > >>> > > > >> >
> > >>> > > > >> > > Hi John,
> > >>> > > > >> > >
> > >>> > > > >> > > Thank you very much for your time investing the
issue.
> > >>> > > > >> > > I am glad to hear that there is a trick to work
around
> the
> > >>> issue
> > >>> > > to
> > >>> > > > >> read
> > >>> > > > >> > > in TRMM data in netcdf format.
> > >>> > > > >> > > I wonder if I can apply the same trick (
> > >>> file_type=NETCDF_NCCF;)
> > >>> > > to
> > >>> > > > >> read
> > >>> > > > >> > > in any other observation files in netcdf format?
> > >>> > > > >> > > In fact, I would like to read in "home brew"
netcdf
> > dataset
> > >>> > files
> > >>> > > > into
> > >>> > > > >> > > MET.
> > >>> > > > >> > > One sample file of them was included in the
uploaded
> data
> > >>> > folder (
> > >>> > > > >> > > sample_tmax.nc).
> > >>> > > > >> > > The data in this sample file was originally
generated by
> > VIC
> > >>> > > model.
> > >>> > > > >> > > Then the file format was converted into a generic
netcdf
> > >>> file
> > >>> > > format
> > >>> > > > >> > > although the dimension names are T, X, Y not
time, lat,
> > lon.
> > >>> > > > >> > > But their coordinates have units in
"degrees_east" or
> > >>> > > > "degrees_north"
> > >>> > > > >> as
> > >>> > > > >> > > well as their long_name as "Longitude" and
"Latitude",
> > >>> > > respectively.
> > >>> > > > >> > >
> > >>> > > > >> > > Of course, I will try to read those in for Grid-
stat
> > today.
> > >>> > > > >> > > But I would like to hear from you if the trick (
> > >>> > > > >> file_type=NETCDF_NCCF;)
> > >>> > > > >> > > can be applied generally, which I wish very much.
> > >>> > > > >> > >
> > >>> > > > >> > > Thank you so much, John.
> > >>> > > > >> > >
> > >>> > > > >> > > Regards,
> > >>> > > > >> > >
> > >>> > > > >> > > Jinwoong Yoo
> > >>> > > > >> > >
> > >>> > > > >> > >
> > >>> > > > >> > > On Fri, Jul 7, 2017 at 1:16 PM, John Halley
Gotway via
> RT
> > <
> > >>> > > > >> > > met_help at ucar.edu> wrote:
> > >>> > > > >> > >
> > >>> > > > >> > >> Jinwoong,
> > >>> > > > >> > >>
> > >>> > > > >> > >> Thanks for sending your sample data and for your
> patience
> > >>> > while I
> > >>> > > > was
> > >>> > > > >> > out
> > >>> > > > >> > >> of town.
> > >>> > > > >> > >>
> > >>> > > > >> > >> Using met-6.0, I'm able to process the TRMM
NetCDF file
> > you
> > >>> > sent.
> > >>> > > > >> The
> > >>> > > > >> > >> trick is that I had to tell it which NetCDF file
type
> > >>> should be
> > >>> > > > used
> > >>> > > > >> to
> > >>> > > > >> > >> interpret the data. Using "file_type =
NETCDF_NCCF;"
> I'm
> > >>> > telling
> > >>> > > > >> MET to
> > >>> > > > >> > >> interpret it as if it were a CF-compliant NetCDF
file:
> > >>> > > > >> > >>
> > >>> > > > >> > >> met-6.0/bin/plot_data_plane \
> > >>> > > > >> > >> trmm_daily.20051231.7.nc
trmm_daily.20051231.7.ps \
> > >>> > > > >> > >> 'name="precipitation"; level="(*,*)";
> > >>> file_type=NETCDF_NCCF;'
> > >>> > > > >> > >>
> > >>> > > > >> > >> DEBUG 1: Opening data file:
trmm_daily.20051231.7.nc
> > >>> > > > >> > >> WARNING: NcCfFile::open() -> could not determine
the
> > valid
> > >>> > time,
> > >>> > > > >> using
> > >>> > > > >> > 0.
> > >>> > > > >> > >> WARNING: NcCfFile::open() -> could not determine
the
> > valid
> > >>> > time,
> > >>> > > > >> using
> > >>> > > > >> > 0.
> > >>> > > > >> > >> DEBUG 1: Creating postscript file:
> > >>> trmm_daily.20051231.7.ps
> > >>> > > > >> > >>
> > >>> > > > >> > >> The plot_data_plane tool is able to read the
data, and
> > I've
> > >>> > > > attached
> > >>> > > > >> the
> > >>> > > > >> > >> resulting image. However, notice the warning
messages
> > >>> about
> > >>> > the
> > >>> > > > >> valid
> > >>> > > > >> > >> time.
> > >>> > > > >> > >>
> > >>> > > > >> > >> Using ncdump to see that file attributes, I see
this
> > timing
> > >>> > > > >> information:
> > >>> > > > >> > >> :HDF5_GLOBAL.BeginDate = "2005-
12-31" ;
> > >>> > > > >> > >> :HDF5_GLOBAL.BeginTime =
> "01:30:00.000Z"
> > ;
> > >>> > > > >> > >> :HDF5_GLOBAL.EndDate = "2006-01-
01" ;
> > >>> > > > >> > >> :HDF5_GLOBAL.EndTime =
"01:29:59.999Z"
> ;
> > >>> > > > >> > >>
> > >>> > > > >> > >> However that is not the CF-compliant way of
specifying
> > >>> timing
> > >>> > > info.
> > >>> > > > >> So
> > >>> > > > >> > >> while MET will be able to read the data, the
timing
> info
> > >>> won't
> > >>> > be
> > >>> > > > >> > accurate
> > >>> > > > >> > >> in the MET output files. Instead, you'll see
> "19700101"
> > >>> which
> > >>> > is
> > >>> > > > >> > unixtime
> > >>> > > > >> > >> = 0.
> > >>> > > > >> > >>
> > >>> > > > >> > >> Another option would be pulling the binary TRMM
data
> and
> > >>> using
> > >>> > > this
> > >>> > > > >> > >> Rscript
> > >>> > > > >> > >> to convert the binary to NetCDF:
> > >>> > > > >> > >> http://www.dtcenter.org/met/
> users/downloads/Rscripts/
> > >>> > > > trmmbin2nc.R
> > >>> > > > >> > >>
> > >>> > > > >> > >> However, I haven't done this in a while and am
not sure
> > if
> > >>> > you'll
> > >>> > > > run
> > >>> > > > >> > into
> > >>> > > > >> > >> any issues.
> > >>> > > > >> > >>
> > >>> > > > >> > >> Hope that helps.
> > >>> > > > >> > >>
> > >>> > > > >> > >> Thanks,
> > >>> > > > >> > >> John
> > >>> > > > >> > >>
> > >>> > > > >> > >>
> > >>> > > > >> > >>
> > >>> > > > >> > >>
> > >>> > > > >> > >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo via
RT <
> > >>> > > > >> met_help at ucar.edu>
> > >>> > > > >> > >> wrote:
> > >>> > > > >> > >>
> > >>> > > > >> > >> >
> > >>> > > > >> > >> > <URL: https://rt.rap.ucar.edu/rt/
> > >>> > Ticket/Display.html?id=81063
> > >>> > > >
> > >>> > > > >> > >> >
> > >>> > > > >> > >> > Hi John,
> > >>> > > > >> > >> >
> > >>> > > > >> > >> > Thank you very much.
> > >>> > > > >> > >> > Regards,
> > >>> > > > >> > >> >
> > >>> > > > >> > >> > Jinwoong
> > >>> > > > >> > >> >
> > >>> > > > >> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John Halley
Gotway
> via
> > >>> RT <
> > >>> > > > >> > >> > met_help at ucar.edu> wrote:
> > >>> > > > >> > >> >
> > >>> > > > >> > >> > > Jinwoong,
> > >>> > > > >> > >> > >
> > >>> > > > >> > >> > > I'm out of the office today but will take a
closer
> > look
> > >>> > > > tomorrow.
> > >>> > > > >> > >> > >
> > >>> > > > >> > >> > > Thanks
> > >>> > > > >> > >> > > John
> > >>> > > > >> > >> > >
> > >>> > > > >> > >> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong Yoo
via
> RT <
> > >>> > > > >> > >> met_help at ucar.edu>
> > >>> > > > >> > >> > > wrote:
> > >>> > > > >> > >> > >
> > >>> > > > >> > >> > > >
> > >>> > > > >> > >> > > > <URL: https://rt.rap.ucar.edu/rt/
> > >>> > > > Ticket/Display.html?id=81063
> > >>> > > > >> >
> > >>> > > > >> > >> > > >
> > >>> > > > >> > >> > > > Hi John,
> > >>> > > > >> > >> > > >
> > >>> > > > >> > >> > > > Thank you for your reply.
> > >>> > > > >> > >> > > > I uploaded my data as in Yoo_data4.tar on
the ftp
> > >>> site.
> > >>> > > > >> > >> > > > I included several files for the message
of ID
> of [
> > >>> > > > >> > rt.rap.ucar.edu
> > >>> > > > >> > >> > > #81074]
> > >>> > > > >> > >> > > > as well.
> > >>> > > > >> > >> > > > Thank you.
> > >>> > > > >> > >> > > > Regards,
> > >>> > > > >> > >> > > >
> > >>> > > > >> > >> > > > Jinwoong
> > >>> > > > >> > >> > > >
> > >>> > > > >> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM, John
Halley
> Gotway
> > >>> via
> > >>> > RT
> > >>> > > <
> > >>> > > > >> > >> > > > met_help at ucar.edu> wrote:
> > >>> > > > >> > >> > > >
> > >>> > > > >> > >> > > > > Jinwoong,
> > >>> > > > >> > >> > > > >
> > >>> > > > >> > >> > > > > I see that you're having trouble reading
a TRMM
> > >>> NetCDF
> > >>> > > file
> > >>> > > > >> into
> > >>> > > > >> > >> MET.
> > >>> > > > >> > >> > > > Can
> > >>> > > > >> > >> > > > > you please post the problematic file to
our
> > >>> anonymous
> > >>> > ftp
> > >>> > > > >> site
> > >>> > > > >> > so
> > >>> > > > >> > >> I
> > >>> > > > >> > >> > can
> > >>> > > > >> > >> > > > > take a look?
> > >>> > > > >> > >> > > > >
> > >>> > > > >> > >> > > > > http://www.dtcenter.org/met/
> > >>> > > users/support/met_help.php#ftp
> > >>> > > > >> > >> > > > >
> > >>> > > > >> > >> > > > > Thanks,
> > >>> > > > >> > >> > > > > John Halley Gotway
> > >>> > > > >> > >> > > > >
> > >>> > > > >> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM, Jinwoong
Yoo
> via
> > >>> RT <
> > >>> > > > >> > >> > met_help at ucar.edu
> > >>> > > > >> > >> > > >
> > >>> > > > >> > >> > > > > wrote:
> > >>> > > > >> > >> > > > >
> > >>> > > > >> > >> > > > > >
> > >>> > > > >> > >> > > > > > <URL: https://rt.rap.ucar.edu/rt/Tic
> > >>> > > > >> ket/Display.html?id=81063
> > >>> > > > >> > >
> > >>> > > > >> > >> > > > > >
> > >>> > > > >> > >> > > > > > Hi,
> > >>> > > > >> > >> > > > > >
> > >>> > > > >> > >> > > > > > TRMM data comes in as netCDF-4 classic
model.
> > >>> > > > >> > >> > > > > > I changed it to netCDF classic and run
the
> same
> > >>> > command
> > >>> > > > >> for a
> > >>> > > > >> > >> test.
> > >>> > > > >> > >> > > > > > But I got the same error as below.
> > >>> > > > >> > >> > > > > >
> > >>> > > > >> > >> > > > > > yoo108 at halstead-fe00:*/scratch
> > >>> /halstead/y/yoo108/
> > >>> > TRMM*
> > >>> > > $
> > >>> > > > >> > >> > > > > > ~/met-6.0_bugfix/bin/regrid_data_plane
> > >>> > > > >> > >> /scratch/halstead/y/yoo108/
> > >>> > > > >> > >> > > TRMM/
> > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > >>> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/ND_
> > >>> grided_obs/daily_T2m_
> > >>> > > > >> > >> > > maxminmean_1976.nc
> > >>> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/TRMM/
> > >>> > regrid_trmm_sample.nc
> > >>> > > > >> -field
> > >>> > > > >> > >> > > > > > 'name="precipitation";'
> > >>> > > > >> > >> > > > > >
> > >>> > > > >> > >> > > > > > DEBUG 1: Reading data file:
> > >>> > > > /scratch/halstead/y/yoo108/TRM
> > >>> > > > >> M/
> > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > >>> > > > >> > >> > > > > >
> > >>> > > > >> > >> > > > > > ERROR :
> > >>> > > > >> > >> > > > > >
> > >>> > > > >> > >> > > > > > ERROR : process_data_file() ->
> > >>> > > > >> "/scratch/halstead/y/yoo108/TR
> > >>> > > > >> > >> MM/
> > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc" not a
valid
> data
> > >>> file
> > >>> > > > >> > >> > > > > >
> > >>> > > > >> > >> > > > > > Thank you.
> > >>> > > > >> > >> > > > > >
> > >>> > > > >> > >> > > > > > Regards,
> > >>> > > > >> > >> > > > > >
> > >>> > > > >> > >> > > > > >
> > >>> > > > >> > >> > > > > > Jinwoong
> > >>> > > > >> > >> > > > > >
> > >>> > > > >> > >> > > > > > On Mon, Jul 3, 2017 at 11:41 AM,
Jinwoong
> Yoo <
> > >>> > > > >> > >> > > jinwoong.yoo at gmail.com>
> > >>> > > > >> > >> > > > > > wrote:
> > >>> > > > >> > >> > > > > >
> > >>> > > > >> > >> > > > > > > Hi,
> > >>> > > > >> > >> > > > > > >
> > >>> > > > >> > >> > > > > > > I noticed that TRMM data dimension
was
> (lon,
> > >>> lat).
> > >>> > > > >> > >> > > > > > > So I switched their order to (lat,
lon) and
> > >>> ran the
> > >>> > > > >> command
> > >>> > > > >> > >> > again.
> > >>> > > > >> > >> > > > > > > However, I got the same error
message as
> > below.
> > >>> > > > >> > >> > > > > > >
> > >>> > > > >> > >> > > > > > > yoo108 at halstead-fe00:*/scratch
> > >>> /halstead/y/yoo108/
> > >>> > > TRMM*
> > >>> > > > $
> > >>> > > > >> > >> > > > > > > ~/met-
6.0_bugfix/bin/regrid_data_plane
> > >>> > > > >> > >> > /scratch/halstead/y/yoo108/
> > >>> > > > >> > >> > > > > TRMM/
> > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > >>> > > > /scratch/halstead/y/yoo108/ND_
> > >>> > > > >> > >> > > > > > >
grided_obs/daily_T2m_maxminmean_1976.nc
> > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > >>> > > > >> > >> > > > > TRMM/
> > >>> > > > >> > >> > > > > > > regrid_trmm_sample.nc -field
> > >>> > 'name="precipitation";'
> > >>> > > > >> > >> > > > > > >
> > >>> > > > >> > >> > > > > > > DEBUG 1: Reading data file:
> > >>> > > > >> /scratch/halstead/y/yoo108/TRM
> > >>> > > > >> > M/
> > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > >>> > > > >> > >> > > > > > >
> > >>> > > > >> > >> > > > > > > ERROR :
> > >>> > > > >> > >> > > > > > >
> > >>> > > > >> > >> > > > > > > ERROR : process_data_file() ->
> > >>> > > > >> > "/scratch/halstead/y/yoo108/TR
> > >>> > > > >> > >> > MM/
> > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc" not a
valid data
> > >>> file
> > >>> > > > >> > >> > > > > > >
> > >>> > > > >> > >> > > > > > >
> > >>> > > > >> > >> > > > > > > Thank you.
> > >>> > > > >> > >> > > > > > >
> > >>> > > > >> > >> > > > > > > Regards,
> > >>> > > > >> > >> > > > > > >
> > >>> > > > >> > >> > > > > > >
> > >>> > > > >> > >> > > > > > > Jinwoong
> > >>> > > > >> > >> > > > > > >
> > >>> > > > >> > >> > > > > > >
> > >>> > > > >> > >> > > > > > >
> > >>> > > > >> > >> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM,
Jinwoong
> > Yoo <
> > >>> > > > >> > >> > > > jinwoong.yoo at gmail.com>
> > >>> > > > >> > >> > > > > > > wrote:
> > >>> > > > >> > >> > > > > > >
> > >>> > > > >> > >> > > > > > >> Hi,
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> I got a similar result with a TRMM
data.
> > >>> > > > >> > >> > > > > > >> Please see below:
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/scratch
> > >>> /halstead/y/yoo108/
> > >>> > > > TRMM*
> > >>> > > > >> $
> > >>> > > > >> > >> > > > > > >> ~/met-
6.0_bugfix/bin/regrid_data_plane
> > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > >>> > > > >> > >> > > > > TRMM/
> > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > >>> > > > >> /scratch/halstead/y/yoo108/ND_
> > >>> > > > >> > >> > > > > > >>
grided_obs/daily_T2m_maxminmean_1976.nc
> > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > >>> > > > >> > >> > > > > > TRMM/
> > >>> > > > >> > >> > > > > > >> regrid_trmm_sample.nc -field
> > >>> > > 'name="precipitation";'
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> DEBUG 1: Reading data file:
> > >>> > > > >> /scratch/halstead/y/yoo108/TRM
> > >>> > > > >> > M/
> > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> ERROR : process_data_file() ->
> > >>> > > > >> > >> "/scratch/halstead/y/yoo108/TR
> > >>> > > > >> > >> > MM/
> > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc" not a
valid
> > data
> > >>> file
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> A part of ncdump output for the
TRMM data
> is
> > >>> > pasted
> > >>> > > > >> below:
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/scratch
> > >>> /halstead/y/yoo108/
> > >>> > > > TRMM*
> > >>> > > > >> $
> > >>> > > > >> > >> ncdump
> > >>> > > > >> > >> > > -h
> > >>> > > > >> > >> > > > > > >> subset_200003-200512/3B42RT_
> > >>> > > Daily.20051231.7.nc4.nc4
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> netcdf \3B42RT_Daily.20051231.7.nc4
{
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> dimensions:
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> lon = 59 ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> lat = 58 ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> variables:
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> short precipitation_cnt(lon, lat) ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> precipitation_cnt:units = "count" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> precipitation_cnt:long_name =
"Count of
> > valid
> > >>> 3-hr
> > >>> > > > >> > >> precipitation
> > >>> > > > >> > >> > > > > > >> retrievals for the day" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> precipitation_cnt:coordinates =
"lat lon"
> ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> precipitation_cnt:origname =
> > >>> "precipitation_cnt" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> precipitation_cnt:fullnamepath =
> > >>> > > "/precipitation_cnt"
> > >>> > > > ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> float uncal_precipitation(lon, lat)
;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> uncal_precipitation:units = "mm" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> uncal_precipitation:long_name =
"Daily
> > >>> accumulated
> > >>> > > > >> > >> uncalibrated
> > >>> > > > >> > >> > > > > > >> precipitation" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> uncal_precipitation:coordinates =
"lat
> > lon" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> uncal_precipitation:_FillValue =
-9999.9f
> ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> uncal_precipitation:origname =
> > >>> > > "uncal_precipitation" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> uncal_precipitation:fullnamepath =
> > >>> > > > >> "/uncal_precipitation"
> > >>> > > > >> > ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> short uncal_precipitation_cnt(lon,
lat) ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:units =
"count" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:long_name =
> "Count
> > of
> > >>> > valid
> > >>> > > > >> 3-hr
> > >>> > > > >> > >> uncal
> > >>> > > > >> > >> > > > > > >> precipitation retrievals for the
day" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:coordinates
=
> "lat
> > >>> lon" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:origname =
> > >>> > > > >> > >> "uncal_precipitation_cnt" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:fullnamepath =
> > >>> > > > >> > >> > > "/uncal_precipitation_cnt" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> float precipitation(lon, lat) ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> precipitation:units = "mm" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> precipitation:long_name = "Daily
> accumulated
> > >>> > > > >> precipitation
> > >>> > > > >> > >> > > (combined
> > >>> > > > >> > >> > > > > > >> microwave-IR) estimate" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> precipitation:coordinates = "lat
lon" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> precipitation:_FillValue = -9999.9f
;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> precipitation:origname =
"precipitation" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> precipitation:fullnamepath =
> > "/precipitation"
> > >>> ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> short randomError_cnt(lon, lat) ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> randomError_cnt:units = "count" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> randomError_cnt:long_name = "Count
of
> > >>> randomError
> > >>> > > for
> > >>> > > > >> the
> > >>> > > > >> > >> day" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> randomError_cnt:coordinates = "lat
lon" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> randomError_cnt:origname =
> > "randomError_cnt" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> randomError_cnt:fullnamepath =
> > >>> "/randomError_cnt"
> > >>> > ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> float randomError(lon, lat) ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> randomError:units = "mm" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> randomError:long_name = "Daily
total error
> > of
> > >>> > > combined
> > >>> > > > >> > >> > > microwave-IR
> > >>> > > > >> > >> > > > > > >> precipitation estimate" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> randomError:_FillValue = -9999.9f ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> randomError:origname =
"randomError" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> randomError:fullnamepath =
"/randomError"
> ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> float lat(lat) ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> lat:units = "degrees_north" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> lat:long_name = "Latitude" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> lat:origname = "lat" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> lat:fullnamepath = "/lat" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> float lon(lon) ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> lon:units = "degrees_east" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> lon:long_name = "Longitude" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> lon:origname = "lon" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> lon:fullnamepath = "/lon" ;
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> Thank you.
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> Regards,
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> Jinwoong
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >> On Thu, Jun 29, 2017 at 3:11 PM,
> > >>> > met_help at ucar.edu
> > >>> > > > via
> > >>> > > > >> RT
> > >>> > > > >> > <
> > >>> > > > >> > >> > > > > > >> met_help at ucar.edu> wrote:
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED
> AVAILABILITY
> > >>> > BETWEEN
> > >>> > > > >> > 5/23/17
> > >>> > > > >> > >> AND
> > >>> > > > >> > >> > > > > > >>> 5/30/17. RESPONSES MAY BE
DELAYED.
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> Greetings,
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> This message has been
automatically
> > >>> generated in
> > >>> > > > >> response
> > >>> > > > >> > to
> > >>> > > > >> > >> > the
> > >>> > > > >> > >> > > > > > >>> creation of a trouble ticket
regarding:
> > >>> > > > >> > >> > > > > > >>> "regrid_data_plane: not a
valid
> > data
> > >>> > file",
> > >>> > > > >> > >> > > > > > >>> a summary of which appears below.
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> There is no need to reply to this
message
> > >>> right
> > >>> > > now.
> > >>> > > > >> Your
> > >>> > > > >> > >> > ticket
> > >>> > > > >> > >> > > > has
> > >>> > > > >> > >> > > > > > >>> been
> > >>> > > > >> > >> > > > > > >>> assigned an ID of [rt.rap.ucar.edu
> > #81063].
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> Please include the string:
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> [rt.rap.ucar.edu #81063]
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> in the subject line of all future
> > >>> correspondence
> > >>> > > > about
> > >>> > > > >> > this
> > >>> > > > >> > >> > > issue.
> > >>> > > > >> > >> > > > To
> > >>> > > > >> > >> > > > > > do
> > >>> > > > >> > >> > > > > > >>> so,
> > >>> > > > >> > >> > > > > > >>> you may reply to this message.
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> Thank you,
> > >>> > > > >> > >> > > > > > >>>
> met_help at ucar.edu
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> ------------------------------
> > >>> > > > >> > >> ------------------------------
> > >>> > > > >> > >> > > > > > >>> -------------
> > >>> > > > >> > >> > > > > > >>> Hi,
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> I am trying to regrid one of my
> observation
> > >>> files
> > >>> > > in
> > >>> > > > >> lat
> > >>> > > > >> > lon
> > >>> > > > >> > >> > > > > coordinate
> > >>> > > > >> > >> > > > > > >>> grid to WRF curvilinear grid.
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> I ran bin/regrid_data_plane using
a
> sample
> > >>> lat
> > >>> > lon
> > >>> > > > grid
> > >>> > > > >> > file
> > >>> > > > >> > >> > and
> > >>> > > > >> > >> > > a
> > >>> > > > >> > >> > > > > file
> > >>> > > > >> > >> > > > > > >>> in
> > >>> > > > >> > >> > > > > > >>> the WRF grid. But I got error as
shown
> > below:
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > >>> > > > >> > /halstead/y/yoo108/ND_grided_
> > >>> > > > >> > >> > obs*
> > >>> > > > >> > >> > > $
> > >>> > > > >> > >> > > > > > >>> ~/met-
6.0_bugfix/bin/regrid_data_plane
> > >>> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> grided_obs/
> > >>> > > > >> sample_tmax.nc
> > >>> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > >>> > > grided_obs/daily_T2m_
> > >>> > > > >> > >> > > > > maxminmean_1976.nc
> > >>> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > >>> > > > >> > >> grided_obs/NDtoWRFgrid_sample_
> > >>> > > > >> > >> > > > tmax.nc
> > >>> > > > >> > >> > > > > > >>> -field
> > >>> > > > >> > >> > > > > > >>> 'name="tmax";'
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> DEBUG 1: Reading data file:
> > >>> > > > >> /scratch/halstead/y/yoo108/ND_
> > >>> > > > >> > >> > > > > grided_obs/
> > >>> > > > >> > >> > > > > > >>> sample_tmax.nc
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> ERROR : process_data_file() ->
> > >>> > > > >> > >> "/scratch/halstead/y/yoo108/ND
> > >>> > > > >> > >> > > > > > >>> _grided_obs/
> > >>> > > > >> > >> > > > > > >>> sample_tmax.nc" not a valid data
file
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> I wonder which part of the input
file
> does
> > >>> not
> > >>> > > > satisfy
> > >>> > > > >> the
> > >>> > > > >> > >> > MET's
> > >>> > > > >> > >> > > > > "valid
> > >>> > > > >> > >> > > > > > >>> file" criteria.
> > >>> > > > >> > >> > > > > > >>> ncdump output of the input file
looks as
> > >>> below:
> > >>> > > > >> > >> > > > > > >>> Input file was originally
generated by
> VIC
> > >>> model
> > >>> > > and
> > >>> > > > >> > >> converted
> > >>> > > > >> > >> > > into
> > >>> > > > >> > >> > > > > cf
> > >>> > > > >> > >> > > > > > >>> netcdf format.
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> Thank you in advance.
> > >>> > > > >> > >> > > > > > >>> Regards,
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> Jinwoong
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > >>> > > > >> > /halstead/y/yoo108/ND_grided_
> > >>> > > > >> > >> > obs*
> > >>> > > > >> > >> > > $
> > >>> > > > >> > >> > > > > > >>> ncdump -h
> > >>> > > > >> > >> > > > > > >>> sample_tmax.nc
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> netcdf sample_tmax {
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> dimensions:
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> T = 1 ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> X = 55 ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> Y = 65 ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> variables:
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> double T(T) ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> T:units = "days since 1915-01-01"
;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> T:long_name = "Time" ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> double X(X) ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> X:units = "degrees_east" ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> X:long_name = "Longitude" ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> double Y(Y) ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> Y:units = "degrees_north" ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> Y:long_name = "Latitude" ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> double tmax(T, Y, X) ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> tmax:units = "degC" ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> tmax:long_name = "tmax calculated
by
> VIC" ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> tmax:missing_value = -9999.f ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> // global attributes:
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>> :production = "VIC output" ;
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>>
> > >>> > > > >> > >> > > > > > >>
> > >>> > > > >> > >> > > > > > >
> > >>> > > > >> > >> > > > > >
> > >>> > > > >> > >> > > > > >
> > >>> > > > >> > >> > > > >
> > >>> > > > >> > >> > > > >
> > >>> > > > >> > >> > > >
> > >>> > > > >> > >> > > >
> > >>> > > > >> > >> > >
> > >>> > > > >> > >> > >
> > >>> > > > >> > >> >
> > >>> > > > >> > >> >
> > >>> > > > >> > >>
> > >>> > > > >> > >>
> > >>> > > > >> > >
> > >>> > > > >> >
> > >>> > > > >> >
> > >>> > > > >>
> > >>> > > > >>
> > >>> > > > >
> > >>> > > >
> > >>> > > >
> > >>> > >
> > >>> > >
> > >>> >
> > >>> >
> > >>>
> > >>>
> > >>
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: John Halley Gotway
Time: Wed Jul 12 12:59:43 2017
Jinwoong,
OK, sorry for the confusion. Honestly, I don't know how you're
getting
plot_data_plane to work at all. When I run it using the sample data
file
you sent me (met_em.d03.2005-01-01_00:00:00.nc), it doesn't work:
met-6.0/bin/plot_data_plane met_em.d03.2005-01-01_00:00:00.nc test.ps
\
'name="TT"; level="(0,0,*,*)"; file_type = NETCDF_PINT;'
DEBUG 1: Opening data file: met_em.d03.2005-01-01_00:00:00.nc
ERROR :
ERROR : MetNcPinterpDataFile::open(const char *) -> unable to open
NetCDF
file "met_em.d03.2005-01-01_00:00:00.nc"
ERROR :
ERROR :
ERROR : Met2dDataFileFactory::new_met_2d_data_file() -> error opening
file
"met_em.d03.2005-01-01_00:00:00.nc"
ERROR :
There must be something different between the sample file you sent and
the
one you're actually using:
/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
00.nc
John
On Wed, Jul 12, 2017 at 12:46 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>
> Hi John,
>
> I am still experiencing troubles to read in netcdf files for
grid_stat
> command.
> Please read the last two previous emails that I sent.
> Thank you very much.
>
> Regards,
>
> Jinwoong
>
> On Wed, Jul 12, 2017 at 1:44 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Great, glad you were able to get it working.
> >
> > Thanks,
> > John
> >
> > On Tue, Jul 11, 2017 at 9:44 AM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > >
> > > Hi John,
> > >
> > > Even with the plot_data_plane command,
> > > I noticed that "file_type = NETCDF_PINT;" argument should be
provided
> in
> > > the command line.
> > > Otherwise, it fails. Please see below.
> > >
> > > yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal*
> $
> > > ~/met-6.0_bugfix/bin/plot_data_plane
> > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> > > 00.nc
> > > met_em.d03.2005-12-31_18:00:00.ps 'name="TT";level="(0,0,*,*)";'
> > >
> > > DEBUG 1: Opening data file:
> > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> > > 00.nc
> > >
> > > ERROR : plot_data_plane -> file
> > > "/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> 2005-12-31_18:00:
> > > 00.nc"
> > > not a valid data file
> > >
> > >
> > >
> > > yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal*
> $
> > > ~/met-6.0_bugfix/bin/plot_data_plane
> > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> > > 00.nc
> > > met_em.d03.2005-12-31_18:00:00.ps 'name="TT";level="(0,0,*,*)";
> file_type
> > =
> > > NETCDF_PINT;'
> > >
> > > DEBUG 1: Opening data file:
> > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> > > 00.nc
> > >
> > > DEBUG 1: Creating postscript file: met_em.d03.2005-12-
31_18:00:00.ps
> > >
> > >
> > >
> > > Thank you.
> > >
> > > Regards,
> > >
> > >
> > > Jinwoong
> > >
> > >
> > > On Tue, Jul 11, 2017 at 11:12 AM, Jinwoong Yoo
<jinwoong.yoo at gmail.com
> >
> > > wrote:
> > >
> > > > Hi John,
> > > >
> > > > Now I am trying to execute grid_stat against these netcdf
files that
> > have
> > > > been patted with the WRF global attributes.
> > > >
> > > > I tried to include 'file_type = NETCDF_PINT;' argument both in
its
> > > > configuration file and in the command line.
> > > > However, both failed to run (Please see below).
> > > >
> > > > Could you please guide me how to specify the netcdf file type
in the
> > > > grid_stat application?
> > > > Thank you.
> > > >
> > > > Regards,
> > > >
> > > > Jinwoong
> > > >
> > > >
> > > > 1.
> > > >
> > > > .......
> > > >
> > > > obs = {
> > > >
> > > >
> > > > field = [
> > > >
> > > > {
> > > >
> > > > name = "TT";
> > > >
> > > > level = [ "(0,0,*,*)" ];
> > > >
> > > > file_type = NETCDF_PINT;
> > > >
> > > > cat_thresh = [];
> > > >
> > > > }
> > > >
> > > > .......
> > > >
> > > > DEBUG 1: Default Config File: /home/yoo108/met-6.0_bugfix/
> > > > share/met/config/GridStatConfig_default
> > > >
> > > > DEBUG 1: User Config File: /scratch/halstead/y/yoo108/
> > > wrfAnalysis/METanal/
> > > > GridStatConfig_met_em
> > > >
> > > > DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() ->
created new
> > > > Met2dDataFile object of type "FileType_Gb2".
> > > >
> > > > DEBUG 4: Switching the GRIB2 radius of the earth value of
6371.23 km
> to
> > > > 6371.2 km for internal consistency.
> > > >
> > > > DEBUG 4:
> > > >
> > > > DEBUG 4: Lambert Conformal Grid Data:
> > > >
> > > > DEBUG 4: scale_lat_1: 48
> > > >
> > > > DEBUG 4: scale_lat_2: 32
> > > >
> > > > DEBUG 4: lat_pin: 36.9132
> > > >
> > > > DEBUG 4: lon_pin: 92.0748
> > > >
> > > > DEBUG 4: x_pin: 0
> > > >
> > > > DEBUG 4: y_pin: 0
> > > >
> > > > DEBUG 4: lon_orient: 97
> > > >
> > > > DEBUG 4: d_km: 4
> > > >
> > > > DEBUG 4: r_km: 6371.2
> > > >
> > > > DEBUG 4: nx: 189
> > > >
> > > > DEBUG 4: ny: 270
> > > >
> > > > DEBUG 4:
> > > >
> > > > DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() ->
created new
> > > > Met2dDataFile object of type "FileType_None".
> > > >
> > > > ERROR :
> > > >
> > > > ERROR : Trouble reading observation file
> "/scratch/halstead/y/yoo108/
> > > > NCAR_BC_met_em/met_em.d03.1980-01-01_00:00:00.nc"
> > > >
> > > >
> > > >
> > > > 2.
> > > >
> > > > /home/yoo108/met-6.0_bugfix/bin/grid_stat
> > $dir_data/$yyyy/$yyyy$nummon/$
> > > > grib_date1 $dir_data2/$met_em_date1 $analDir/$GridStatConfig
> > 'file_type =
> > > > NETCDF_PINT;' -outdir $workDir -v 4
> > > >
> > > > *** Model Evaluation Tools (METV6.0) ***
> > > >
> > > >
> > > > Usage: grid_stat
> > > >
> > > > fcst_file
> > > >
> > > > obs_file
> > > >
> > > > config_file
> > > >
> > > > [-outdir path]
> > > >
> > > > [-log file]
> > > >
> > > > [-v level]
> > > >
> > > > [-compress level]
> > > >
> > > >
> > > > where "fcst_file" is a gridded forecast file containing the
field(s)
> to
> > > > be verified (required).
> > > >
> > > > "obs_file" is a gridded observation file containing the
verifying
> > > field(s)
> > > > (required).
> > > >
> > > > "config_file" is a GridStatConfig file containing the desired
> > > > configuration settings (required).
> > > >
> > > > "-outdir path" overrides the default output directory
> > > > (/scratch/halstead/y/yoo108/wrfAnalysis/METanal/wrf2met_em)
> > (optional).
> > > >
> > > > "-log file" outputs log messages to the specified file
(optional).
> > > >
> > > > "-v level" overrides the default level of logging (4)
(optional).
> > > >
> > > > "-compress level" overrides the compression level of NetCDF
variable
> > (0)
> > > > (optional).
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Jul 10, 2017 at 4:53 PM, Jinwoong Yoo <
> jinwoong.yoo at gmail.com>
> > > > wrote:
> > > >
> > > >> Hi John,
> > > >>
> > > >> I was able to open netcdf files that share the same
coordinates with
> > WRF
> > > >> output by copying the global attribute of the WRF output to
these
> > netcdf
> > > >> files:
> > > >>
> > > >> ncks -A -x wrfout.nc target.nc
> > > >>
> > > >> This enabled me to open netcdf files in MET using
> > > >> 'name="TT";level="(0,0,*,*)";file_type = NETCDF_PINT;'
argument.
> > > >>
> > > >> Thank you very much!
> > > >> Regards,
> > > >>
> > > >> Jinwoong
> > > >>
> > > >> On Mon, Jul 10, 2017 at 3:04 PM, John Halley Gotway via RT <
> > > >> met_help at ucar.edu> wrote:
> > > >>
> > > >>> Jinwoong,
> > > >>>
> > > >>> I tried running the sample file
(daily_T2m_maxminmean_1981.nc)
> > through
> > > >>> plot_data_plane and saw the same behavior you did. Looking
closely
> > at
> > > >>> that
> > > >>> file I see that is not the NetCDF output generated by WRF.
The
> > history
> > > >>> attribute indicates that it was created by the "ncks"
utility:
> > > >>>
> > > >>> :history = "Sun Jul 2 15:47:18 2017: ncks -d days,0,0
> > > >>>
/scratch/halstead/k/khoogewi/CCRC_wrf/analysis/T2m/daily_T2m_
> > > >>> maxminmean_1981.nc
> > > >>> /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_maxminm
> > > >>> ean_19810101.nc"
> > > >>>
> > > >>>
> > > >>> This is not a CF-compliant NetCDF file and it does not look
like
> the
> > > >>> output
> > > >>> from WRF. Another alternative is making it look like the
NetCDF
> file
> > > >>> format used by the MET tools themselves.
> > > >>>
> > > >>> I ran the following command to add global attributes to
define the
> > grid
> > > >>> spec for MET:
> > > >>>
> > > >>> ncatted \
> > > >>> -a MET_version,global,o,c,"V6.0" \
> > > >>> -a Projection,global,o,c,"Lambert Conformal" \
> > > >>> -a scale_lat_1,global,o,c,"48" \
> > > >>> -a scale_lat_2,global,o,c,"32" \
> > > >>> -a lat_pin,global,o,c,"48" \
> > > >>> -a lon_pin,global,o,c,"-97" \
> > > >>> -a x_pin,global,o,c,"0" \
> > > >>> -a y_pin,global,o,c,"0" \
> > > >>> -a lon_orient,global,o,c,"-97" \
> > > >>> -a d_km,global,o,c,"3" \
> > > >>> -a r_km,global,o,c,"6371.2" \
> > > >>> -a nx,global,o,c,"189" \
> > > >>> -a ny,global,o,c,"270" \
> > > >>> daily_T2m_maxminmean_1976.nc -o
daily_T2m_maxminmean_1976_MET.nc
> > > >>>
> > > >>> However, I don't think these are all correct. Specifically,
I
> don't
> > > know
> > > >>> how the "lon_orient" should be set. So I set it to the
longitude
> of
> > > the
> > > >>> lower-left corner. Also, I don't know how the d_km should
be set.
> > > >>> That's
> > > >>> the grid spacing in km. So I just guess with a value of 3.
> > > >>>
> > > >>> This enables MET to plot the result, but you should work on
making
> > the
> > > >>> grid
> > > >>> info correct:
> > > >>> met-6.0/bin/plot_data_plane \
> > > >>> daily_T2m_maxminmean_1976_MET.nc \
> > > >>> daily_T2m_maxminmean_1976_MET.ps \
> > > >>> 'name="T2m_max"; level="(10,*,*)";' -v 4
> > > >>>
> > > >>> Thanks,
> > > >>> John
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Fri, Jul 7, 2017 at 5:06 PM, Jinwoong Yoo via RT <
> > met_help at ucar.edu
> > > >
> > > >>> wrote:
> > > >>>
> > > >>> >
> > > >>> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > > >>> >
> > > >>> > Hi John,
> > > >>> >
> > > >>> > Thank you for your comment.
> > > >>> > I tried it but it failed.
> > > >>> > Please see below.
> > > >>> >
> > > >>> > yoo108 at halstead-fe03:*/scratch/halstead/y/yoo108/
> > > wrfAnalysis/METanal*
> > > >>> $
> > > >>> > ~/met-6.0_bugfix/bin/plot_data_plane
> > > >>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > > >>> > maxminmean_20051231.nc
> > > >>> > wrfDaily_T2m_maxminmean_20051231.ps
> > > >>> > 'name="T2m_max";level="(0,*,*)";file_type = NETCDF_PINT;'
> > > >>> >
> > > >>> > DEBUG 1: Opening data file:
> > > >>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > > >>> > maxminmean_20051231.nc
> > > >>> >
> > > >>> > ERROR : MetNcPinterpDataFile::open(const char *) ->
unable to
> > open
> > > >>> NetCDF
> > > >>> > file
> > > >>> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > > >>> > maxminmean_20051231.nc"
> > > >>> >
> > > >>> > ERROR : Met2dDataFileFactory::new_met_2d_data_file() ->
error
> > > opening
> > > >>> > file
> > > >>> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > > >>> > maxminmean_20051231.nc"
> > > >>> >
> > > >>> >
> > > >>> >
> > > >>> > One sample file (wrfDaily_T2m_maxminmean_19810101.nc) is
also
> > > >>> included in
> > > >>> > the Yoo_data4.tar file that I uploaded previously.
> > > >>> > Thank you.
> > > >>> > Haver a nice weekend.
> > > >>> >
> > > >>> > Regards,
> > > >>> >
> > > >>> > Jinwoong
> > > >>> >
> > > >>> >
> > > >>> >
> > > >>> > On Fri, Jul 7, 2017 at 6:04 PM, John Halley Gotway via RT
<
> > > >>> > met_help at ucar.edu
> > > >>> > > wrote:
> > > >>> >
> > > >>> > > Jinwoong,
> > > >>> > >
> > > >>> > > If they really are output from WRF, one simple thing to
try is
> > > >>> telling
> > > >>> > MET
> > > >>> > > to interpret them as the NetCDF output of the wrf_interp
> utility
> > > >>> > > :
> > > >>> > > file_type = NETCDF_PINT;
> > > >>> > >
> > > >>> > > "PINT" stands for "pressure interpolated"... pinterp was
the
> > > >>> precursor to
> > > >>> > > the current wrf_interp tool.
> > > >>> > >
> > > >>> > > If that doesn't work, I'll need to see a sample file
before
> > making
> > > >>> any
> > > >>> > > other suggestions.
> > > >>> > >
> > > >>> > > Thanks,
> > > >>> > > John
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> > > On Fri, Jul 7, 2017 at 3:36 PM, Jinwoong Yoo via RT <
> > > >>> met_help at ucar.edu>
> > > >>> > > wrote:
> > > >>> > >
> > > >>> > > >
> > > >>> > > > <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=81063
> > >
> > > >>> > > >
> > > >>> > > > Hi John,
> > > >>> > > >
> > > >>> > > > I was able to read in a "home brew" netcdf data file
using
> > > >>> > > plot_data_plane.
> > > >>> > > >
> > > >>> > > > Then, I went ahead and tried another netcdf file in
> curvilinear
> > > >>> > > coordinate
> > > >>> > > > which is in the same coordinate grid as my WRF output.
But it
> > > >>> failed.
> > > >>> > > >
> > > >>> > > > I have many netcdf climatology files from the WRF
simulation
> > such
> > > >>> as
> > > >>> > > daily,
> > > >>> > > > monthly, and annual, etc. Therefore, they are all in
> > curvilinear
> > > >>> > > coordinate
> > > >>> > > > (Lambert).
> > > >>> > > >
> > > >>> > > > I wonder if there is any work around so that I can
feed these
> > > files
> > > >>> > into
> > > >>> > > > MET?
> > > >>> > > > Or should I regrid them all into lat lon coordinate
files
> > first?
> > > >>> > > >
> > > >>> > > > Thank you, John.
> > > >>> > > >
> > > >>> > > > Regards,
> > > >>> > > >
> > > >>> > > > Jinwoong Yoo
> > > >>> > > >
> > > >>> > > >
> > > >>> > > > On Fri, Jul 7, 2017 at 3:01 PM, Jinwoong Yoo <
> > > >>> jinwoong.yoo at gmail.com>
> > > >>> > > > wrote:
> > > >>> > > >
> > > >>> > > > > Hi John,
> > > >>> > > > >
> > > >>> > > > > Thank you very much.
> > > >>> > > > > Let me try and let you know how it goes.
> > > >>> > > > > Thank you.
> > > >>> > > > > Regards,
> > > >>> > > > >
> > > >>> > > > > Jinwoong
> > > >>> > > > >
> > > >>> > > > > On Fri, Jul 7, 2017 at 2:59 PM, John Halley Gotway
via RT <
> > > >>> > > > > met_help at ucar.edu> wrote:
> > > >>> > > > >
> > > >>> > > > >> Jinwoong,
> > > >>> > > > >>
> > > >>> > > > >> Yes, you can give it a try. The closer you can
make the
> > > NetCDF
> > > >>> > files
> > > >>> > > to
> > > >>> > > > >> the CF-convention, the more likely MET will be able
to
> read
> > > it.
> > > >>> > > > >>
> > > >>> > > > >> The reason that's its able to read the TRMM data
are that
> > the
> > > >>> > lat/lon
> > > >>> > > > >> values are equally spaced. Non-equally spaced
lat/lon
> > values
> > > >>> on a
> > > >>> > map
> > > >>> > > > >> projection require that the map projection
information be
> > > >>> specified.
> > > >>> > > > >> Unfortunately, specifying map projection
information in
> > > >>> CF-compliant
> > > >>> > > > >> NetCDF
> > > >>> > > > >> files is not as easy as I think it should be!
> > > >>> > > > >>
> > > >>> > > > >> Hope it works out ok for you.
> > > >>> > > > >>
> > > >>> > > > >> Thanks,
> > > >>> > > > >> John
> > > >>> > > > >>
> > > >>> > > > >> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo via
RT <
> > > >>> > > met_help at ucar.edu
> > > >>> > > > >
> > > >>> > > > >> wrote:
> > > >>> > > > >>
> > > >>> > > > >> >
> > > >>> > > > >> > <URL: https://rt.rap.ucar.edu/rt/
> > > Ticket/Display.html?id=81063
> > > >>> >
> > > >>> > > > >> >
> > > >>> > > > >> > investigating not investing :)
> > > >>> > > > >> >
> > > >>> > > > >> > Thanks!
> > > >>> > > > >> > Regards,
> > > >>> > > > >> >
> > > >>> > > > >> > Jinwoong
> > > >>> > > > >> >
> > > >>> > > > >> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo <
> > > >>> > > jinwoong.yoo at gmail.com>
> > > >>> > > > >> > wrote:
> > > >>> > > > >> >
> > > >>> > > > >> > > Hi John,
> > > >>> > > > >> > >
> > > >>> > > > >> > > Thank you very much for your time investing the
issue.
> > > >>> > > > >> > > I am glad to hear that there is a trick to work
around
> > the
> > > >>> issue
> > > >>> > > to
> > > >>> > > > >> read
> > > >>> > > > >> > > in TRMM data in netcdf format.
> > > >>> > > > >> > > I wonder if I can apply the same trick (
> > > >>> file_type=NETCDF_NCCF;)
> > > >>> > > to
> > > >>> > > > >> read
> > > >>> > > > >> > > in any other observation files in netcdf
format?
> > > >>> > > > >> > > In fact, I would like to read in "home brew"
netcdf
> > > dataset
> > > >>> > files
> > > >>> > > > into
> > > >>> > > > >> > > MET.
> > > >>> > > > >> > > One sample file of them was included in the
uploaded
> > data
> > > >>> > folder (
> > > >>> > > > >> > > sample_tmax.nc).
> > > >>> > > > >> > > The data in this sample file was originally
generated
> by
> > > VIC
> > > >>> > > model.
> > > >>> > > > >> > > Then the file format was converted into a
generic
> netcdf
> > > >>> file
> > > >>> > > format
> > > >>> > > > >> > > although the dimension names are T, X, Y not
time,
> lat,
> > > lon.
> > > >>> > > > >> > > But their coordinates have units in
"degrees_east" or
> > > >>> > > > "degrees_north"
> > > >>> > > > >> as
> > > >>> > > > >> > > well as their long_name as "Longitude" and
"Latitude",
> > > >>> > > respectively.
> > > >>> > > > >> > >
> > > >>> > > > >> > > Of course, I will try to read those in for
Grid-stat
> > > today.
> > > >>> > > > >> > > But I would like to hear from you if the trick
(
> > > >>> > > > >> file_type=NETCDF_NCCF;)
> > > >>> > > > >> > > can be applied generally, which I wish very
much.
> > > >>> > > > >> > >
> > > >>> > > > >> > > Thank you so much, John.
> > > >>> > > > >> > >
> > > >>> > > > >> > > Regards,
> > > >>> > > > >> > >
> > > >>> > > > >> > > Jinwoong Yoo
> > > >>> > > > >> > >
> > > >>> > > > >> > >
> > > >>> > > > >> > > On Fri, Jul 7, 2017 at 1:16 PM, John Halley
Gotway via
> > RT
> > > <
> > > >>> > > > >> > > met_help at ucar.edu> wrote:
> > > >>> > > > >> > >
> > > >>> > > > >> > >> Jinwoong,
> > > >>> > > > >> > >>
> > > >>> > > > >> > >> Thanks for sending your sample data and for
your
> > patience
> > > >>> > while I
> > > >>> > > > was
> > > >>> > > > >> > out
> > > >>> > > > >> > >> of town.
> > > >>> > > > >> > >>
> > > >>> > > > >> > >> Using met-6.0, I'm able to process the TRMM
NetCDF
> file
> > > you
> > > >>> > sent.
> > > >>> > > > >> The
> > > >>> > > > >> > >> trick is that I had to tell it which NetCDF
file type
> > > >>> should be
> > > >>> > > > used
> > > >>> > > > >> to
> > > >>> > > > >> > >> interpret the data. Using "file_type =
NETCDF_NCCF;"
> > I'm
> > > >>> > telling
> > > >>> > > > >> MET to
> > > >>> > > > >> > >> interpret it as if it were a CF-compliant
NetCDF
> file:
> > > >>> > > > >> > >>
> > > >>> > > > >> > >> met-6.0/bin/plot_data_plane \
> > > >>> > > > >> > >> trmm_daily.20051231.7.nc
trmm_daily.20051231.7.ps \
> > > >>> > > > >> > >> 'name="precipitation"; level="(*,*)";
> > > >>> file_type=NETCDF_NCCF;'
> > > >>> > > > >> > >>
> > > >>> > > > >> > >> DEBUG 1: Opening data file:
trmm_daily.20051231.7.nc
> > > >>> > > > >> > >> WARNING: NcCfFile::open() -> could not
determine the
> > > valid
> > > >>> > time,
> > > >>> > > > >> using
> > > >>> > > > >> > 0.
> > > >>> > > > >> > >> WARNING: NcCfFile::open() -> could not
determine the
> > > valid
> > > >>> > time,
> > > >>> > > > >> using
> > > >>> > > > >> > 0.
> > > >>> > > > >> > >> DEBUG 1: Creating postscript file:
> > > >>> trmm_daily.20051231.7.ps
> > > >>> > > > >> > >>
> > > >>> > > > >> > >> The plot_data_plane tool is able to read the
data,
> and
> > > I've
> > > >>> > > > attached
> > > >>> > > > >> the
> > > >>> > > > >> > >> resulting image. However, notice the warning
> messages
> > > >>> about
> > > >>> > the
> > > >>> > > > >> valid
> > > >>> > > > >> > >> time.
> > > >>> > > > >> > >>
> > > >>> > > > >> > >> Using ncdump to see that file attributes, I
see this
> > > timing
> > > >>> > > > >> information:
> > > >>> > > > >> > >> :HDF5_GLOBAL.BeginDate =
> "2005-12-31" ;
> > > >>> > > > >> > >> :HDF5_GLOBAL.BeginTime =
> > "01:30:00.000Z"
> > > ;
> > > >>> > > > >> > >> :HDF5_GLOBAL.EndDate = "2006-
01-01" ;
> > > >>> > > > >> > >> :HDF5_GLOBAL.EndTime =
> "01:29:59.999Z"
> > ;
> > > >>> > > > >> > >>
> > > >>> > > > >> > >> However that is not the CF-compliant way of
> specifying
> > > >>> timing
> > > >>> > > info.
> > > >>> > > > >> So
> > > >>> > > > >> > >> while MET will be able to read the data, the
timing
> > info
> > > >>> won't
> > > >>> > be
> > > >>> > > > >> > accurate
> > > >>> > > > >> > >> in the MET output files. Instead, you'll see
> > "19700101"
> > > >>> which
> > > >>> > is
> > > >>> > > > >> > unixtime
> > > >>> > > > >> > >> = 0.
> > > >>> > > > >> > >>
> > > >>> > > > >> > >> Another option would be pulling the binary
TRMM data
> > and
> > > >>> using
> > > >>> > > this
> > > >>> > > > >> > >> Rscript
> > > >>> > > > >> > >> to convert the binary to NetCDF:
> > > >>> > > > >> > >> http://www.dtcenter.org/met/
> > users/downloads/Rscripts/
> > > >>> > > > trmmbin2nc.R
> > > >>> > > > >> > >>
> > > >>> > > > >> > >> However, I haven't done this in a while and am
not
> sure
> > > if
> > > >>> > you'll
> > > >>> > > > run
> > > >>> > > > >> > into
> > > >>> > > > >> > >> any issues.
> > > >>> > > > >> > >>
> > > >>> > > > >> > >> Hope that helps.
> > > >>> > > > >> > >>
> > > >>> > > > >> > >> Thanks,
> > > >>> > > > >> > >> John
> > > >>> > > > >> > >>
> > > >>> > > > >> > >>
> > > >>> > > > >> > >>
> > > >>> > > > >> > >>
> > > >>> > > > >> > >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo
via RT <
> > > >>> > > > >> met_help at ucar.edu>
> > > >>> > > > >> > >> wrote:
> > > >>> > > > >> > >>
> > > >>> > > > >> > >> >
> > > >>> > > > >> > >> > <URL: https://rt.rap.ucar.edu/rt/
> > > >>> > Ticket/Display.html?id=81063
> > > >>> > > >
> > > >>> > > > >> > >> >
> > > >>> > > > >> > >> > Hi John,
> > > >>> > > > >> > >> >
> > > >>> > > > >> > >> > Thank you very much.
> > > >>> > > > >> > >> > Regards,
> > > >>> > > > >> > >> >
> > > >>> > > > >> > >> > Jinwoong
> > > >>> > > > >> > >> >
> > > >>> > > > >> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John Halley
Gotway
> > via
> > > >>> RT <
> > > >>> > > > >> > >> > met_help at ucar.edu> wrote:
> > > >>> > > > >> > >> >
> > > >>> > > > >> > >> > > Jinwoong,
> > > >>> > > > >> > >> > >
> > > >>> > > > >> > >> > > I'm out of the office today but will take
a
> closer
> > > look
> > > >>> > > > tomorrow.
> > > >>> > > > >> > >> > >
> > > >>> > > > >> > >> > > Thanks
> > > >>> > > > >> > >> > > John
> > > >>> > > > >> > >> > >
> > > >>> > > > >> > >> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong
Yoo via
> > RT <
> > > >>> > > > >> > >> met_help at ucar.edu>
> > > >>> > > > >> > >> > > wrote:
> > > >>> > > > >> > >> > >
> > > >>> > > > >> > >> > > >
> > > >>> > > > >> > >> > > > <URL: https://rt.rap.ucar.edu/rt/
> > > >>> > > > Ticket/Display.html?id=81063
> > > >>> > > > >> >
> > > >>> > > > >> > >> > > >
> > > >>> > > > >> > >> > > > Hi John,
> > > >>> > > > >> > >> > > >
> > > >>> > > > >> > >> > > > Thank you for your reply.
> > > >>> > > > >> > >> > > > I uploaded my data as in Yoo_data4.tar
on the
> ftp
> > > >>> site.
> > > >>> > > > >> > >> > > > I included several files for the message
of ID
> > of [
> > > >>> > > > >> > rt.rap.ucar.edu
> > > >>> > > > >> > >> > > #81074]
> > > >>> > > > >> > >> > > > as well.
> > > >>> > > > >> > >> > > > Thank you.
> > > >>> > > > >> > >> > > > Regards,
> > > >>> > > > >> > >> > > >
> > > >>> > > > >> > >> > > > Jinwoong
> > > >>> > > > >> > >> > > >
> > > >>> > > > >> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM, John
Halley
> > Gotway
> > > >>> via
> > > >>> > RT
> > > >>> > > <
> > > >>> > > > >> > >> > > > met_help at ucar.edu> wrote:
> > > >>> > > > >> > >> > > >
> > > >>> > > > >> > >> > > > > Jinwoong,
> > > >>> > > > >> > >> > > > >
> > > >>> > > > >> > >> > > > > I see that you're having trouble
reading a
> TRMM
> > > >>> NetCDF
> > > >>> > > file
> > > >>> > > > >> into
> > > >>> > > > >> > >> MET.
> > > >>> > > > >> > >> > > > Can
> > > >>> > > > >> > >> > > > > you please post the problematic file
to our
> > > >>> anonymous
> > > >>> > ftp
> > > >>> > > > >> site
> > > >>> > > > >> > so
> > > >>> > > > >> > >> I
> > > >>> > > > >> > >> > can
> > > >>> > > > >> > >> > > > > take a look?
> > > >>> > > > >> > >> > > > >
> > > >>> > > > >> > >> > > > > http://www.dtcenter.org/met/
> > > >>> > > users/support/met_help.php#ftp
> > > >>> > > > >> > >> > > > >
> > > >>> > > > >> > >> > > > > Thanks,
> > > >>> > > > >> > >> > > > > John Halley Gotway
> > > >>> > > > >> > >> > > > >
> > > >>> > > > >> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM,
Jinwoong Yoo
> > via
> > > >>> RT <
> > > >>> > > > >> > >> > met_help at ucar.edu
> > > >>> > > > >> > >> > > >
> > > >>> > > > >> > >> > > > > wrote:
> > > >>> > > > >> > >> > > > >
> > > >>> > > > >> > >> > > > > >
> > > >>> > > > >> > >> > > > > > <URL: https://rt.rap.ucar.edu/rt/Tic
> > > >>> > > > >> ket/Display.html?id=81063
> > > >>> > > > >> > >
> > > >>> > > > >> > >> > > > > >
> > > >>> > > > >> > >> > > > > > Hi,
> > > >>> > > > >> > >> > > > > >
> > > >>> > > > >> > >> > > > > > TRMM data comes in as netCDF-4
classic
> model.
> > > >>> > > > >> > >> > > > > > I changed it to netCDF classic and
run the
> > same
> > > >>> > command
> > > >>> > > > >> for a
> > > >>> > > > >> > >> test.
> > > >>> > > > >> > >> > > > > > But I got the same error as below.
> > > >>> > > > >> > >> > > > > >
> > > >>> > > > >> > >> > > > > > yoo108 at halstead-fe00:*/scratch
> > > >>> /halstead/y/yoo108/
> > > >>> > TRMM*
> > > >>> > > $
> > > >>> > > > >> > >> > > > > > ~/met-
6.0_bugfix/bin/regrid_data_plane
> > > >>> > > > >> > >> /scratch/halstead/y/yoo108/
> > > >>> > > > >> > >> > > TRMM/
> > > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > > >>> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/ND_
> > > >>> grided_obs/daily_T2m_
> > > >>> > > > >> > >> > > maxminmean_1976.nc
> > > >>> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/TRMM/
> > > >>> > regrid_trmm_sample.nc
> > > >>> > > > >> -field
> > > >>> > > > >> > >> > > > > > 'name="precipitation";'
> > > >>> > > > >> > >> > > > > >
> > > >>> > > > >> > >> > > > > > DEBUG 1: Reading data file:
> > > >>> > > > /scratch/halstead/y/yoo108/TRM
> > > >>> > > > >> M/
> > > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > > >>> > > > >> > >> > > > > >
> > > >>> > > > >> > >> > > > > > ERROR :
> > > >>> > > > >> > >> > > > > >
> > > >>> > > > >> > >> > > > > > ERROR : process_data_file() ->
> > > >>> > > > >> "/scratch/halstead/y/yoo108/TR
> > > >>> > > > >> > >> MM/
> > > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc" not a
valid
> > data
> > > >>> file
> > > >>> > > > >> > >> > > > > >
> > > >>> > > > >> > >> > > > > > Thank you.
> > > >>> > > > >> > >> > > > > >
> > > >>> > > > >> > >> > > > > > Regards,
> > > >>> > > > >> > >> > > > > >
> > > >>> > > > >> > >> > > > > >
> > > >>> > > > >> > >> > > > > > Jinwoong
> > > >>> > > > >> > >> > > > > >
> > > >>> > > > >> > >> > > > > > On Mon, Jul 3, 2017 at 11:41 AM,
Jinwoong
> > Yoo <
> > > >>> > > > >> > >> > > jinwoong.yoo at gmail.com>
> > > >>> > > > >> > >> > > > > > wrote:
> > > >>> > > > >> > >> > > > > >
> > > >>> > > > >> > >> > > > > > > Hi,
> > > >>> > > > >> > >> > > > > > >
> > > >>> > > > >> > >> > > > > > > I noticed that TRMM data dimension
was
> > (lon,
> > > >>> lat).
> > > >>> > > > >> > >> > > > > > > So I switched their order to (lat,
lon)
> and
> > > >>> ran the
> > > >>> > > > >> command
> > > >>> > > > >> > >> > again.
> > > >>> > > > >> > >> > > > > > > However, I got the same error
message as
> > > below.
> > > >>> > > > >> > >> > > > > > >
> > > >>> > > > >> > >> > > > > > > yoo108 at halstead-fe00:*/scratch
> > > >>> /halstead/y/yoo108/
> > > >>> > > TRMM*
> > > >>> > > > $
> > > >>> > > > >> > >> > > > > > > ~/met-
6.0_bugfix/bin/regrid_data_plane
> > > >>> > > > >> > >> > /scratch/halstead/y/yoo108/
> > > >>> > > > >> > >> > > > > TRMM/
> > > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > > >>> > > > /scratch/halstead/y/yoo108/ND_
> > > >>> > > > >> > >> > > > > > >
grided_obs/daily_T2m_maxminmean_1976.nc
> > > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > > >>> > > > >> > >> > > > > TRMM/
> > > >>> > > > >> > >> > > > > > > regrid_trmm_sample.nc -field
> > > >>> > 'name="precipitation";'
> > > >>> > > > >> > >> > > > > > >
> > > >>> > > > >> > >> > > > > > > DEBUG 1: Reading data file:
> > > >>> > > > >> /scratch/halstead/y/yoo108/TRM
> > > >>> > > > >> > M/
> > > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > > >>> > > > >> > >> > > > > > >
> > > >>> > > > >> > >> > > > > > > ERROR :
> > > >>> > > > >> > >> > > > > > >
> > > >>> > > > >> > >> > > > > > > ERROR : process_data_file() ->
> > > >>> > > > >> > "/scratch/halstead/y/yoo108/TR
> > > >>> > > > >> > >> > MM/
> > > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc" not a
valid
> data
> > > >>> file
> > > >>> > > > >> > >> > > > > > >
> > > >>> > > > >> > >> > > > > > >
> > > >>> > > > >> > >> > > > > > > Thank you.
> > > >>> > > > >> > >> > > > > > >
> > > >>> > > > >> > >> > > > > > > Regards,
> > > >>> > > > >> > >> > > > > > >
> > > >>> > > > >> > >> > > > > > >
> > > >>> > > > >> > >> > > > > > > Jinwoong
> > > >>> > > > >> > >> > > > > > >
> > > >>> > > > >> > >> > > > > > >
> > > >>> > > > >> > >> > > > > > >
> > > >>> > > > >> > >> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM,
Jinwoong
> > > Yoo <
> > > >>> > > > >> > >> > > > jinwoong.yoo at gmail.com>
> > > >>> > > > >> > >> > > > > > > wrote:
> > > >>> > > > >> > >> > > > > > >
> > > >>> > > > >> > >> > > > > > >> Hi,
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> I got a similar result with a
TRMM data.
> > > >>> > > > >> > >> > > > > > >> Please see below:
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/scratch
> > > >>> /halstead/y/yoo108/
> > > >>> > > > TRMM*
> > > >>> > > > >> $
> > > >>> > > > >> > >> > > > > > >> ~/met-
6.0_bugfix/bin/regrid_data_plane
> > > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > > >>> > > > >> > >> > > > > TRMM/
> > > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > > >>> > > > >> /scratch/halstead/y/yoo108/ND_
> > > >>> > > > >> > >> > > > > > >>
grided_obs/daily_T2m_maxminmean_1976.nc
> > > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > > >>> > > > >> > >> > > > > > TRMM/
> > > >>> > > > >> > >> > > > > > >> regrid_trmm_sample.nc -field
> > > >>> > > 'name="precipitation";'
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> DEBUG 1: Reading data file:
> > > >>> > > > >> /scratch/halstead/y/yoo108/TRM
> > > >>> > > > >> > M/
> > > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> ERROR : process_data_file() ->
> > > >>> > > > >> > >> "/scratch/halstead/y/yoo108/TR
> > > >>> > > > >> > >> > MM/
> > > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc" not a
valid
> > > data
> > > >>> file
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> A part of ncdump output for the
TRMM
> data
> > is
> > > >>> > pasted
> > > >>> > > > >> below:
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/scratch
> > > >>> /halstead/y/yoo108/
> > > >>> > > > TRMM*
> > > >>> > > > >> $
> > > >>> > > > >> > >> ncdump
> > > >>> > > > >> > >> > > -h
> > > >>> > > > >> > >> > > > > > >> subset_200003-200512/3B42RT_
> > > >>> > > Daily.20051231.7.nc4.nc4
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> netcdf
\3B42RT_Daily.20051231.7.nc4 {
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> dimensions:
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> lon = 59 ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> lat = 58 ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> variables:
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> short precipitation_cnt(lon, lat)
;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> precipitation_cnt:units = "count"
;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> precipitation_cnt:long_name =
"Count of
> > > valid
> > > >>> 3-hr
> > > >>> > > > >> > >> precipitation
> > > >>> > > > >> > >> > > > > > >> retrievals for the day" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> precipitation_cnt:coordinates =
"lat
> lon"
> > ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> precipitation_cnt:origname =
> > > >>> "precipitation_cnt" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> precipitation_cnt:fullnamepath =
> > > >>> > > "/precipitation_cnt"
> > > >>> > > > ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> float uncal_precipitation(lon,
lat) ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> uncal_precipitation:units = "mm"
;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> uncal_precipitation:long_name =
"Daily
> > > >>> accumulated
> > > >>> > > > >> > >> uncalibrated
> > > >>> > > > >> > >> > > > > > >> precipitation" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> uncal_precipitation:coordinates =
"lat
> > > lon" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> uncal_precipitation:_FillValue =
> -9999.9f
> > ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> uncal_precipitation:origname =
> > > >>> > > "uncal_precipitation" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> uncal_precipitation:fullnamepath
=
> > > >>> > > > >> "/uncal_precipitation"
> > > >>> > > > >> > ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> short
uncal_precipitation_cnt(lon, lat)
> ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:units =
"count"
> ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:long_name
=
> > "Count
> > > of
> > > >>> > valid
> > > >>> > > > >> 3-hr
> > > >>> > > > >> > >> uncal
> > > >>> > > > >> > >> > > > > > >> precipitation retrievals for the
day" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:coordinates =
> > "lat
> > > >>> lon" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:origname
=
> > > >>> > > > >> > >> "uncal_precipitation_cnt" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:fullnamepath =
> > > >>> > > > >> > >> > > "/uncal_precipitation_cnt" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> float precipitation(lon, lat) ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> precipitation:units = "mm" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> precipitation:long_name = "Daily
> > accumulated
> > > >>> > > > >> precipitation
> > > >>> > > > >> > >> > > (combined
> > > >>> > > > >> > >> > > > > > >> microwave-IR) estimate" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> precipitation:coordinates = "lat
lon" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> precipitation:_FillValue =
-9999.9f ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> precipitation:origname =
> "precipitation" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> precipitation:fullnamepath =
> > > "/precipitation"
> > > >>> ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> short randomError_cnt(lon, lat) ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> randomError_cnt:units = "count" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> randomError_cnt:long_name =
"Count of
> > > >>> randomError
> > > >>> > > for
> > > >>> > > > >> the
> > > >>> > > > >> > >> day" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> randomError_cnt:coordinates =
"lat lon"
> ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> randomError_cnt:origname =
> > > "randomError_cnt" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> randomError_cnt:fullnamepath =
> > > >>> "/randomError_cnt"
> > > >>> > ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> float randomError(lon, lat) ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> randomError:units = "mm" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> randomError:long_name = "Daily
total
> error
> > > of
> > > >>> > > combined
> > > >>> > > > >> > >> > > microwave-IR
> > > >>> > > > >> > >> > > > > > >> precipitation estimate" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> randomError:_FillValue = -9999.9f
;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> randomError:origname =
"randomError" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> randomError:fullnamepath =
> "/randomError"
> > ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> float lat(lat) ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> lat:units = "degrees_north" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> lat:long_name = "Latitude" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> lat:origname = "lat" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> lat:fullnamepath = "/lat" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> float lon(lon) ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> lon:units = "degrees_east" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> lon:long_name = "Longitude" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> lon:origname = "lon" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> lon:fullnamepath = "/lon" ;
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> Thank you.
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> Regards,
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> Jinwoong
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >> On Thu, Jun 29, 2017 at 3:11 PM,
> > > >>> > met_help at ucar.edu
> > > >>> > > > via
> > > >>> > > > >> RT
> > > >>> > > > >> > <
> > > >>> > > > >> > >> > > > > > >> met_help at ucar.edu> wrote:
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED
> > AVAILABILITY
> > > >>> > BETWEEN
> > > >>> > > > >> > 5/23/17
> > > >>> > > > >> > >> AND
> > > >>> > > > >> > >> > > > > > >>> 5/30/17. RESPONSES MAY BE
DELAYED.
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> Greetings,
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> This message has been
automatically
> > > >>> generated in
> > > >>> > > > >> response
> > > >>> > > > >> > to
> > > >>> > > > >> > >> > the
> > > >>> > > > >> > >> > > > > > >>> creation of a trouble ticket
regarding:
> > > >>> > > > >> > >> > > > > > >>> "regrid_data_plane: not
a valid
> > > data
> > > >>> > file",
> > > >>> > > > >> > >> > > > > > >>> a summary of which appears
below.
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> There is no need to reply to
this
> message
> > > >>> right
> > > >>> > > now.
> > > >>> > > > >> Your
> > > >>> > > > >> > >> > ticket
> > > >>> > > > >> > >> > > > has
> > > >>> > > > >> > >> > > > > > >>> been
> > > >>> > > > >> > >> > > > > > >>> assigned an ID of
[rt.rap.ucar.edu
> > > #81063].
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> Please include the string:
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> [rt.rap.ucar.edu
#81063]
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> in the subject line of all
future
> > > >>> correspondence
> > > >>> > > > about
> > > >>> > > > >> > this
> > > >>> > > > >> > >> > > issue.
> > > >>> > > > >> > >> > > > To
> > > >>> > > > >> > >> > > > > > do
> > > >>> > > > >> > >> > > > > > >>> so,
> > > >>> > > > >> > >> > > > > > >>> you may reply to this message.
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> Thank
you,
> > > >>> > > > >> > >> > > > > > >>>
> > met_help at ucar.edu
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> ------------------------------
> > > >>> > > > >> > >> ------------------------------
> > > >>> > > > >> > >> > > > > > >>> -------------
> > > >>> > > > >> > >> > > > > > >>> Hi,
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> I am trying to regrid one of my
> > observation
> > > >>> files
> > > >>> > > in
> > > >>> > > > >> lat
> > > >>> > > > >> > lon
> > > >>> > > > >> > >> > > > > coordinate
> > > >>> > > > >> > >> > > > > > >>> grid to WRF curvilinear grid.
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> I ran bin/regrid_data_plane
using a
> > sample
> > > >>> lat
> > > >>> > lon
> > > >>> > > > grid
> > > >>> > > > >> > file
> > > >>> > > > >> > >> > and
> > > >>> > > > >> > >> > > a
> > > >>> > > > >> > >> > > > > file
> > > >>> > > > >> > >> > > > > > >>> in
> > > >>> > > > >> > >> > > > > > >>> the WRF grid. But I got error as
shown
> > > below:
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > > >>> > > > >> > /halstead/y/yoo108/ND_grided_
> > > >>> > > > >> > >> > obs*
> > > >>> > > > >> > >> > > $
> > > >>> > > > >> > >> > > > > > >>> ~/met-
6.0_bugfix/bin/regrid_data_plane
> > > >>> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > grided_obs/
> > > >>> > > > >> sample_tmax.nc
> > > >>> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > > >>> > > grided_obs/daily_T2m_
> > > >>> > > > >> > >> > > > > maxminmean_1976.nc
> > > >>> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > > >>> > > > >> > >> grided_obs/NDtoWRFgrid_sample_
> > > >>> > > > >> > >> > > > tmax.nc
> > > >>> > > > >> > >> > > > > > >>> -field
> > > >>> > > > >> > >> > > > > > >>> 'name="tmax";'
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> DEBUG 1: Reading data file:
> > > >>> > > > >> /scratch/halstead/y/yoo108/ND_
> > > >>> > > > >> > >> > > > > grided_obs/
> > > >>> > > > >> > >> > > > > > >>> sample_tmax.nc
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> ERROR : process_data_file() ->
> > > >>> > > > >> > >> "/scratch/halstead/y/yoo108/ND
> > > >>> > > > >> > >> > > > > > >>> _grided_obs/
> > > >>> > > > >> > >> > > > > > >>> sample_tmax.nc" not a valid data
file
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> I wonder which part of the input
file
> > does
> > > >>> not
> > > >>> > > > satisfy
> > > >>> > > > >> the
> > > >>> > > > >> > >> > MET's
> > > >>> > > > >> > >> > > > > "valid
> > > >>> > > > >> > >> > > > > > >>> file" criteria.
> > > >>> > > > >> > >> > > > > > >>> ncdump output of the input file
looks
> as
> > > >>> below:
> > > >>> > > > >> > >> > > > > > >>> Input file was originally
generated by
> > VIC
> > > >>> model
> > > >>> > > and
> > > >>> > > > >> > >> converted
> > > >>> > > > >> > >> > > into
> > > >>> > > > >> > >> > > > > cf
> > > >>> > > > >> > >> > > > > > >>> netcdf format.
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> Thank you in advance.
> > > >>> > > > >> > >> > > > > > >>> Regards,
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> Jinwoong
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > > >>> > > > >> > /halstead/y/yoo108/ND_grided_
> > > >>> > > > >> > >> > obs*
> > > >>> > > > >> > >> > > $
> > > >>> > > > >> > >> > > > > > >>> ncdump -h
> > > >>> > > > >> > >> > > > > > >>> sample_tmax.nc
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> netcdf sample_tmax {
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> dimensions:
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> T = 1 ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> X = 55 ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> Y = 65 ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> variables:
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> double T(T) ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> T:units = "days since 1915-01-
01" ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> T:long_name = "Time" ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> double X(X) ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> X:units = "degrees_east" ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> X:long_name = "Longitude" ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> double Y(Y) ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> Y:units = "degrees_north" ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> Y:long_name = "Latitude" ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> double tmax(T, Y, X) ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> tmax:units = "degC" ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> tmax:long_name = "tmax
calculated by
> > VIC" ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> tmax:missing_value = -9999.f ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> // global attributes:
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>> :production = "VIC output" ;
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>>
> > > >>> > > > >> > >> > > > > > >>
> > > >>> > > > >> > >> > > > > > >
> > > >>> > > > >> > >> > > > > >
> > > >>> > > > >> > >> > > > > >
> > > >>> > > > >> > >> > > > >
> > > >>> > > > >> > >> > > > >
> > > >>> > > > >> > >> > > >
> > > >>> > > > >> > >> > > >
> > > >>> > > > >> > >> > >
> > > >>> > > > >> > >> > >
> > > >>> > > > >> > >> >
> > > >>> > > > >> > >> >
> > > >>> > > > >> > >>
> > > >>> > > > >> > >>
> > > >>> > > > >> > >
> > > >>> > > > >> >
> > > >>> > > > >> >
> > > >>> > > > >>
> > > >>> > > > >>
> > > >>> > > > >
> > > >>> > > >
> > > >>> > > >
> > > >>> > >
> > > >>> > >
> > > >>> >
> > > >>> >
> > > >>>
> > > >>>
> > > >>
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Wed Jul 12 13:05:32 2017
Hi John,
As I noted in the previous messages,
I was able to plot netcdf files by copying global attributes from WRF
output to the netcdf files in the same coordinate grids.
yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal*
$
~/met-6.0_bugfix/bin/plot_data_plane /scratch/halstead/y/yoo108/
NCAR_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc
met_em.d03.2005-12-31_18:00:00.ps
'name="TT";level="(0,0,*,*)";file_type =
NETCDF_PINT;'
DEBUG 1: Opening data file: /scratch/halstead/y/yoo108/
NCAR_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc
DEBUG 1: Creating postscript file: met_em.d03.2005-12-31_18:00:00.ps
However, when 'file_typ=NETCDF_PINT;' was not provided in the
plot_data_plane command, it failed.
yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal*
$
~/met-6.0_bugfix/bin/plot_data_plane /scratch/halstead/y/yoo108/
NCAR_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc
met_em.d03.2005-12-31_18:00:00.ps 'name="TT";level="(0,0,*,*)";'
DEBUG 1: Opening data file: /scratch/halstead/y/yoo108/
NCAR_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc
ERROR : plot_data_plane -> file "/scratch/halstead/y/yoo108/
NCAR_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc" not a valid data
file
Thing is that I don't know where to put the argument (
'file_typ=NETCDF_PINT;') in the grid_stat.
I tried both in config file and command line but both failed.
Thank you.
Regards,
Jinwoong
On Wed, Jul 12, 2017 at 2:59 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Jinwoong,
>
> OK, sorry for the confusion. Honestly, I don't know how you're
getting
> plot_data_plane to work at all. When I run it using the sample data
file
> you sent me (met_em.d03.2005-01-01_00:00:00.nc), it doesn't work:
>
> met-6.0/bin/plot_data_plane met_em.d03.2005-01-01_00:00:00.nc
test.ps \
> 'name="TT"; level="(0,0,*,*)"; file_type = NETCDF_PINT;'
> DEBUG 1: Opening data file: met_em.d03.2005-01-01_00:00:00.nc
> ERROR :
> ERROR : MetNcPinterpDataFile::open(const char *) -> unable to open
NetCDF
> file "met_em.d03.2005-01-01_00:00:00.nc"
> ERROR :
> ERROR :
> ERROR : Met2dDataFileFactory::new_met_2d_data_file() -> error
opening
> file
> "met_em.d03.2005-01-01_00:00:00.nc"
> ERROR :
>
> There must be something different between the sample file you sent
and the
> one you're actually using:
> /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> 00.nc
>
> John
>
> On Wed, Jul 12, 2017 at 12:46 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >
> > Hi John,
> >
> > I am still experiencing troubles to read in netcdf files for
grid_stat
> > command.
> > Please read the last two previous emails that I sent.
> > Thank you very much.
> >
> > Regards,
> >
> > Jinwoong
> >
> > On Wed, Jul 12, 2017 at 1:44 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Great, glad you were able to get it working.
> > >
> > > Thanks,
> > > John
> > >
> > > On Tue, Jul 11, 2017 at 9:44 AM, Jinwoong Yoo via RT <
> met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
> > > >
> > > > Hi John,
> > > >
> > > > Even with the plot_data_plane command,
> > > > I noticed that "file_type = NETCDF_PINT;" argument should be
provided
> > in
> > > > the command line.
> > > > Otherwise, it fails. Please see below.
> > > >
> > > > yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/
> wrfAnalysis/METanal*
> > $
> > > > ~/met-6.0_bugfix/bin/plot_data_plane
> > > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> 2005-12-31_18:00:
> > > > 00.nc
> > > > met_em.d03.2005-12-31_18:00:00.ps
'name="TT";level="(0,0,*,*)";'
> > > >
> > > > DEBUG 1: Opening data file:
> > > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> 2005-12-31_18:00:
> > > > 00.nc
> > > >
> > > > ERROR : plot_data_plane -> file
> > > > "/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> > 2005-12-31_18:00:
> > > > 00.nc"
> > > > not a valid data file
> > > >
> > > >
> > > >
> > > > yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/
> wrfAnalysis/METanal*
> > $
> > > > ~/met-6.0_bugfix/bin/plot_data_plane
> > > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> 2005-12-31_18:00:
> > > > 00.nc
> > > > met_em.d03.2005-12-31_18:00:00.ps
'name="TT";level="(0,0,*,*)";
> > file_type
> > > =
> > > > NETCDF_PINT;'
> > > >
> > > > DEBUG 1: Opening data file:
> > > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> 2005-12-31_18:00:
> > > > 00.nc
> > > >
> > > > DEBUG 1: Creating postscript file: met_em.d03.2005-12-
31_18:00:00.ps
> > > >
> > > >
> > > >
> > > > Thank you.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Jinwoong
> > > >
> > > >
> > > > On Tue, Jul 11, 2017 at 11:12 AM, Jinwoong Yoo <
> jinwoong.yoo at gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hi John,
> > > > >
> > > > > Now I am trying to execute grid_stat against these netcdf
files
> that
> > > have
> > > > > been patted with the WRF global attributes.
> > > > >
> > > > > I tried to include 'file_type = NETCDF_PINT;' argument both
in its
> > > > > configuration file and in the command line.
> > > > > However, both failed to run (Please see below).
> > > > >
> > > > > Could you please guide me how to specify the netcdf file
type in
> the
> > > > > grid_stat application?
> > > > > Thank you.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Jinwoong
> > > > >
> > > > >
> > > > > 1.
> > > > >
> > > > > .......
> > > > >
> > > > > obs = {
> > > > >
> > > > >
> > > > > field = [
> > > > >
> > > > > {
> > > > >
> > > > > name = "TT";
> > > > >
> > > > > level = [ "(0,0,*,*)" ];
> > > > >
> > > > > file_type = NETCDF_PINT;
> > > > >
> > > > > cat_thresh = [];
> > > > >
> > > > > }
> > > > >
> > > > > .......
> > > > >
> > > > > DEBUG 1: Default Config File: /home/yoo108/met-6.0_bugfix/
> > > > > share/met/config/GridStatConfig_default
> > > > >
> > > > > DEBUG 1: User Config File: /scratch/halstead/y/yoo108/
> > > > wrfAnalysis/METanal/
> > > > > GridStatConfig_met_em
> > > > >
> > > > > DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() ->
created
> new
> > > > > Met2dDataFile object of type "FileType_Gb2".
> > > > >
> > > > > DEBUG 4: Switching the GRIB2 radius of the earth value of
6371.23
> km
> > to
> > > > > 6371.2 km for internal consistency.
> > > > >
> > > > > DEBUG 4:
> > > > >
> > > > > DEBUG 4: Lambert Conformal Grid Data:
> > > > >
> > > > > DEBUG 4: scale_lat_1: 48
> > > > >
> > > > > DEBUG 4: scale_lat_2: 32
> > > > >
> > > > > DEBUG 4: lat_pin: 36.9132
> > > > >
> > > > > DEBUG 4: lon_pin: 92.0748
> > > > >
> > > > > DEBUG 4: x_pin: 0
> > > > >
> > > > > DEBUG 4: y_pin: 0
> > > > >
> > > > > DEBUG 4: lon_orient: 97
> > > > >
> > > > > DEBUG 4: d_km: 4
> > > > >
> > > > > DEBUG 4: r_km: 6371.2
> > > > >
> > > > > DEBUG 4: nx: 189
> > > > >
> > > > > DEBUG 4: ny: 270
> > > > >
> > > > > DEBUG 4:
> > > > >
> > > > > DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() ->
created
> new
> > > > > Met2dDataFile object of type "FileType_None".
> > > > >
> > > > > ERROR :
> > > > >
> > > > > ERROR : Trouble reading observation file
> > "/scratch/halstead/y/yoo108/
> > > > > NCAR_BC_met_em/met_em.d03.1980-01-01_00:00:00.nc"
> > > > >
> > > > >
> > > > >
> > > > > 2.
> > > > >
> > > > > /home/yoo108/met-6.0_bugfix/bin/grid_stat
> > > $dir_data/$yyyy/$yyyy$nummon/$
> > > > > grib_date1 $dir_data2/$met_em_date1 $analDir/$GridStatConfig
> > > 'file_type =
> > > > > NETCDF_PINT;' -outdir $workDir -v 4
> > > > >
> > > > > *** Model Evaluation Tools (METV6.0) ***
> > > > >
> > > > >
> > > > > Usage: grid_stat
> > > > >
> > > > > fcst_file
> > > > >
> > > > > obs_file
> > > > >
> > > > > config_file
> > > > >
> > > > > [-outdir path]
> > > > >
> > > > > [-log file]
> > > > >
> > > > > [-v level]
> > > > >
> > > > > [-compress level]
> > > > >
> > > > >
> > > > > where "fcst_file" is a gridded forecast file containing the
> field(s)
> > to
> > > > > be verified (required).
> > > > >
> > > > > "obs_file" is a gridded observation file containing the
verifying
> > > > field(s)
> > > > > (required).
> > > > >
> > > > > "config_file" is a GridStatConfig file containing the
desired
> > > > > configuration settings (required).
> > > > >
> > > > > "-outdir path" overrides the default output directory
> > > > > (/scratch/halstead/y/yoo108/wrfAnalysis/METanal/wrf2met_em)
> > > (optional).
> > > > >
> > > > > "-log file" outputs log messages to the specified file
(optional).
> > > > >
> > > > > "-v level" overrides the default level of logging (4)
(optional).
> > > > >
> > > > > "-compress level" overrides the compression level of NetCDF
> variable
> > > (0)
> > > > > (optional).
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Jul 10, 2017 at 4:53 PM, Jinwoong Yoo <
> > jinwoong.yoo at gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Hi John,
> > > > >>
> > > > >> I was able to open netcdf files that share the same
coordinates
> with
> > > WRF
> > > > >> output by copying the global attribute of the WRF output to
these
> > > netcdf
> > > > >> files:
> > > > >>
> > > > >> ncks -A -x wrfout.nc target.nc
> > > > >>
> > > > >> This enabled me to open netcdf files in MET using
> > > > >> 'name="TT";level="(0,0,*,*)";file_type = NETCDF_PINT;'
argument.
> > > > >>
> > > > >> Thank you very much!
> > > > >> Regards,
> > > > >>
> > > > >> Jinwoong
> > > > >>
> > > > >> On Mon, Jul 10, 2017 at 3:04 PM, John Halley Gotway via RT
<
> > > > >> met_help at ucar.edu> wrote:
> > > > >>
> > > > >>> Jinwoong,
> > > > >>>
> > > > >>> I tried running the sample file
(daily_T2m_maxminmean_1981.nc)
> > > through
> > > > >>> plot_data_plane and saw the same behavior you did.
Looking
> closely
> > > at
> > > > >>> that
> > > > >>> file I see that is not the NetCDF output generated by WRF.
The
> > > history
> > > > >>> attribute indicates that it was created by the "ncks"
utility:
> > > > >>>
> > > > >>> :history = "Sun Jul 2 15:47:18 2017: ncks -d days,0,0
> > > > >>>
/scratch/halstead/k/khoogewi/CCRC_wrf/analysis/T2m/daily_T2m_
> > > > >>> maxminmean_1981.nc
> > > > >>>
/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_maxminm
> > > > >>> ean_19810101.nc"
> > > > >>>
> > > > >>>
> > > > >>> This is not a CF-compliant NetCDF file and it does not
look like
> > the
> > > > >>> output
> > > > >>> from WRF. Another alternative is making it look like the
NetCDF
> > file
> > > > >>> format used by the MET tools themselves.
> > > > >>>
> > > > >>> I ran the following command to add global attributes to
define
> the
> > > grid
> > > > >>> spec for MET:
> > > > >>>
> > > > >>> ncatted \
> > > > >>> -a MET_version,global,o,c,"V6.0" \
> > > > >>> -a Projection,global,o,c,"Lambert Conformal" \
> > > > >>> -a scale_lat_1,global,o,c,"48" \
> > > > >>> -a scale_lat_2,global,o,c,"32" \
> > > > >>> -a lat_pin,global,o,c,"48" \
> > > > >>> -a lon_pin,global,o,c,"-97" \
> > > > >>> -a x_pin,global,o,c,"0" \
> > > > >>> -a y_pin,global,o,c,"0" \
> > > > >>> -a lon_orient,global,o,c,"-97" \
> > > > >>> -a d_km,global,o,c,"3" \
> > > > >>> -a r_km,global,o,c,"6371.2" \
> > > > >>> -a nx,global,o,c,"189" \
> > > > >>> -a ny,global,o,c,"270" \
> > > > >>> daily_T2m_maxminmean_1976.nc -o
daily_T2m_maxminmean_1976_MET.nc
> > > > >>>
> > > > >>> However, I don't think these are all correct.
Specifically, I
> > don't
> > > > know
> > > > >>> how the "lon_orient" should be set. So I set it to the
longitude
> > of
> > > > the
> > > > >>> lower-left corner. Also, I don't know how the d_km should
be
> set.
> > > > >>> That's
> > > > >>> the grid spacing in km. So I just guess with a value of
3.
> > > > >>>
> > > > >>> This enables MET to plot the result, but you should work
on
> making
> > > the
> > > > >>> grid
> > > > >>> info correct:
> > > > >>> met-6.0/bin/plot_data_plane \
> > > > >>> daily_T2m_maxminmean_1976_MET.nc \
> > > > >>> daily_T2m_maxminmean_1976_MET.ps \
> > > > >>> 'name="T2m_max"; level="(10,*,*)";' -v 4
> > > > >>>
> > > > >>> Thanks,
> > > > >>> John
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On Fri, Jul 7, 2017 at 5:06 PM, Jinwoong Yoo via RT <
> > > met_help at ucar.edu
> > > > >
> > > > >>> wrote:
> > > > >>>
> > > > >>> >
> > > > >>> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
> >
> > > > >>> >
> > > > >>> > Hi John,
> > > > >>> >
> > > > >>> > Thank you for your comment.
> > > > >>> > I tried it but it failed.
> > > > >>> > Please see below.
> > > > >>> >
> > > > >>> > yoo108 at halstead-fe03:*/scratch/halstead/y/yoo108/
> > > > wrfAnalysis/METanal*
> > > > >>> $
> > > > >>> > ~/met-6.0_bugfix/bin/plot_data_plane
> > > > >>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > > > >>> > maxminmean_20051231.nc
> > > > >>> > wrfDaily_T2m_maxminmean_20051231.ps
> > > > >>> > 'name="T2m_max";level="(0,*,*)";file_type =
NETCDF_PINT;'
> > > > >>> >
> > > > >>> > DEBUG 1: Opening data file:
> > > > >>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > > > >>> > maxminmean_20051231.nc
> > > > >>> >
> > > > >>> > ERROR : MetNcPinterpDataFile::open(const char *) ->
unable to
> > > open
> > > > >>> NetCDF
> > > > >>> > file
> > > > >>> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > > > >>> > maxminmean_20051231.nc"
> > > > >>> >
> > > > >>> > ERROR : Met2dDataFileFactory::new_met_2d_data_file() ->
error
> > > > opening
> > > > >>> > file
> > > > >>> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > > > >>> > maxminmean_20051231.nc"
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > > > >>> > One sample file (wrfDaily_T2m_maxminmean_19810101.nc) is
also
> > > > >>> included in
> > > > >>> > the Yoo_data4.tar file that I uploaded previously.
> > > > >>> > Thank you.
> > > > >>> > Haver a nice weekend.
> > > > >>> >
> > > > >>> > Regards,
> > > > >>> >
> > > > >>> > Jinwoong
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > > > >>> > On Fri, Jul 7, 2017 at 6:04 PM, John Halley Gotway via
RT <
> > > > >>> > met_help at ucar.edu
> > > > >>> > > wrote:
> > > > >>> >
> > > > >>> > > Jinwoong,
> > > > >>> > >
> > > > >>> > > If they really are output from WRF, one simple thing
to try
> is
> > > > >>> telling
> > > > >>> > MET
> > > > >>> > > to interpret them as the NetCDF output of the
wrf_interp
> > utility
> > > > >>> > > :
> > > > >>> > > file_type = NETCDF_PINT;
> > > > >>> > >
> > > > >>> > > "PINT" stands for "pressure interpolated"... pinterp
was the
> > > > >>> precursor to
> > > > >>> > > the current wrf_interp tool.
> > > > >>> > >
> > > > >>> > > If that doesn't work, I'll need to see a sample file
before
> > > making
> > > > >>> any
> > > > >>> > > other suggestions.
> > > > >>> > >
> > > > >>> > > Thanks,
> > > > >>> > > John
> > > > >>> > >
> > > > >>> > >
> > > > >>> > >
> > > > >>> > > On Fri, Jul 7, 2017 at 3:36 PM, Jinwoong Yoo via RT <
> > > > >>> met_help at ucar.edu>
> > > > >>> > > wrote:
> > > > >>> > >
> > > > >>> > > >
> > > > >>> > > > <URL: https://rt.rap.ucar.edu/rt/
> > Ticket/Display.html?id=81063
> > > >
> > > > >>> > > >
> > > > >>> > > > Hi John,
> > > > >>> > > >
> > > > >>> > > > I was able to read in a "home brew" netcdf data file
using
> > > > >>> > > plot_data_plane.
> > > > >>> > > >
> > > > >>> > > > Then, I went ahead and tried another netcdf file in
> > curvilinear
> > > > >>> > > coordinate
> > > > >>> > > > which is in the same coordinate grid as my WRF
output. But
> it
> > > > >>> failed.
> > > > >>> > > >
> > > > >>> > > > I have many netcdf climatology files from the WRF
> simulation
> > > such
> > > > >>> as
> > > > >>> > > daily,
> > > > >>> > > > monthly, and annual, etc. Therefore, they are all in
> > > curvilinear
> > > > >>> > > coordinate
> > > > >>> > > > (Lambert).
> > > > >>> > > >
> > > > >>> > > > I wonder if there is any work around so that I can
feed
> these
> > > > files
> > > > >>> > into
> > > > >>> > > > MET?
> > > > >>> > > > Or should I regrid them all into lat lon coordinate
files
> > > first?
> > > > >>> > > >
> > > > >>> > > > Thank you, John.
> > > > >>> > > >
> > > > >>> > > > Regards,
> > > > >>> > > >
> > > > >>> > > > Jinwoong Yoo
> > > > >>> > > >
> > > > >>> > > >
> > > > >>> > > > On Fri, Jul 7, 2017 at 3:01 PM, Jinwoong Yoo <
> > > > >>> jinwoong.yoo at gmail.com>
> > > > >>> > > > wrote:
> > > > >>> > > >
> > > > >>> > > > > Hi John,
> > > > >>> > > > >
> > > > >>> > > > > Thank you very much.
> > > > >>> > > > > Let me try and let you know how it goes.
> > > > >>> > > > > Thank you.
> > > > >>> > > > > Regards,
> > > > >>> > > > >
> > > > >>> > > > > Jinwoong
> > > > >>> > > > >
> > > > >>> > > > > On Fri, Jul 7, 2017 at 2:59 PM, John Halley Gotway
via
> RT <
> > > > >>> > > > > met_help at ucar.edu> wrote:
> > > > >>> > > > >
> > > > >>> > > > >> Jinwoong,
> > > > >>> > > > >>
> > > > >>> > > > >> Yes, you can give it a try. The closer you can
make the
> > > > NetCDF
> > > > >>> > files
> > > > >>> > > to
> > > > >>> > > > >> the CF-convention, the more likely MET will be
able to
> > read
> > > > it.
> > > > >>> > > > >>
> > > > >>> > > > >> The reason that's its able to read the TRMM data
are
> that
> > > the
> > > > >>> > lat/lon
> > > > >>> > > > >> values are equally spaced. Non-equally spaced
lat/lon
> > > values
> > > > >>> on a
> > > > >>> > map
> > > > >>> > > > >> projection require that the map projection
information
> be
> > > > >>> specified.
> > > > >>> > > > >> Unfortunately, specifying map projection
information in
> > > > >>> CF-compliant
> > > > >>> > > > >> NetCDF
> > > > >>> > > > >> files is not as easy as I think it should be!
> > > > >>> > > > >>
> > > > >>> > > > >> Hope it works out ok for you.
> > > > >>> > > > >>
> > > > >>> > > > >> Thanks,
> > > > >>> > > > >> John
> > > > >>> > > > >>
> > > > >>> > > > >> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo via
RT <
> > > > >>> > > met_help at ucar.edu
> > > > >>> > > > >
> > > > >>> > > > >> wrote:
> > > > >>> > > > >>
> > > > >>> > > > >> >
> > > > >>> > > > >> > <URL: https://rt.rap.ucar.edu/rt/
> > > > Ticket/Display.html?id=81063
> > > > >>> >
> > > > >>> > > > >> >
> > > > >>> > > > >> > investigating not investing :)
> > > > >>> > > > >> >
> > > > >>> > > > >> > Thanks!
> > > > >>> > > > >> > Regards,
> > > > >>> > > > >> >
> > > > >>> > > > >> > Jinwoong
> > > > >>> > > > >> >
> > > > >>> > > > >> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo <
> > > > >>> > > jinwoong.yoo at gmail.com>
> > > > >>> > > > >> > wrote:
> > > > >>> > > > >> >
> > > > >>> > > > >> > > Hi John,
> > > > >>> > > > >> > >
> > > > >>> > > > >> > > Thank you very much for your time investing
the
> issue.
> > > > >>> > > > >> > > I am glad to hear that there is a trick to
work
> around
> > > the
> > > > >>> issue
> > > > >>> > > to
> > > > >>> > > > >> read
> > > > >>> > > > >> > > in TRMM data in netcdf format.
> > > > >>> > > > >> > > I wonder if I can apply the same trick (
> > > > >>> file_type=NETCDF_NCCF;)
> > > > >>> > > to
> > > > >>> > > > >> read
> > > > >>> > > > >> > > in any other observation files in netcdf
format?
> > > > >>> > > > >> > > In fact, I would like to read in "home brew"
netcdf
> > > > dataset
> > > > >>> > files
> > > > >>> > > > into
> > > > >>> > > > >> > > MET.
> > > > >>> > > > >> > > One sample file of them was included in the
uploaded
> > > data
> > > > >>> > folder (
> > > > >>> > > > >> > > sample_tmax.nc).
> > > > >>> > > > >> > > The data in this sample file was originally
> generated
> > by
> > > > VIC
> > > > >>> > > model.
> > > > >>> > > > >> > > Then the file format was converted into a
generic
> > netcdf
> > > > >>> file
> > > > >>> > > format
> > > > >>> > > > >> > > although the dimension names are T, X, Y not
time,
> > lat,
> > > > lon.
> > > > >>> > > > >> > > But their coordinates have units in
"degrees_east"
> or
> > > > >>> > > > "degrees_north"
> > > > >>> > > > >> as
> > > > >>> > > > >> > > well as their long_name as "Longitude" and
> "Latitude",
> > > > >>> > > respectively.
> > > > >>> > > > >> > >
> > > > >>> > > > >> > > Of course, I will try to read those in for
Grid-stat
> > > > today.
> > > > >>> > > > >> > > But I would like to hear from you if the
trick (
> > > > >>> > > > >> file_type=NETCDF_NCCF;)
> > > > >>> > > > >> > > can be applied generally, which I wish very
much.
> > > > >>> > > > >> > >
> > > > >>> > > > >> > > Thank you so much, John.
> > > > >>> > > > >> > >
> > > > >>> > > > >> > > Regards,
> > > > >>> > > > >> > >
> > > > >>> > > > >> > > Jinwoong Yoo
> > > > >>> > > > >> > >
> > > > >>> > > > >> > >
> > > > >>> > > > >> > > On Fri, Jul 7, 2017 at 1:16 PM, John Halley
Gotway
> via
> > > RT
> > > > <
> > > > >>> > > > >> > > met_help at ucar.edu> wrote:
> > > > >>> > > > >> > >
> > > > >>> > > > >> > >> Jinwoong,
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >> Thanks for sending your sample data and for
your
> > > patience
> > > > >>> > while I
> > > > >>> > > > was
> > > > >>> > > > >> > out
> > > > >>> > > > >> > >> of town.
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >> Using met-6.0, I'm able to process the TRMM
NetCDF
> > file
> > > > you
> > > > >>> > sent.
> > > > >>> > > > >> The
> > > > >>> > > > >> > >> trick is that I had to tell it which NetCDF
file
> type
> > > > >>> should be
> > > > >>> > > > used
> > > > >>> > > > >> to
> > > > >>> > > > >> > >> interpret the data. Using "file_type =
> NETCDF_NCCF;"
> > > I'm
> > > > >>> > telling
> > > > >>> > > > >> MET to
> > > > >>> > > > >> > >> interpret it as if it were a CF-compliant
NetCDF
> > file:
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >> met-6.0/bin/plot_data_plane \
> > > > >>> > > > >> > >> trmm_daily.20051231.7.nc
trmm_daily.20051231.7.ps
> \
> > > > >>> > > > >> > >> 'name="precipitation"; level="(*,*)";
> > > > >>> file_type=NETCDF_NCCF;'
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >> DEBUG 1: Opening data file:
> trmm_daily.20051231.7.nc
> > > > >>> > > > >> > >> WARNING: NcCfFile::open() -> could not
determine
> the
> > > > valid
> > > > >>> > time,
> > > > >>> > > > >> using
> > > > >>> > > > >> > 0.
> > > > >>> > > > >> > >> WARNING: NcCfFile::open() -> could not
determine
> the
> > > > valid
> > > > >>> > time,
> > > > >>> > > > >> using
> > > > >>> > > > >> > 0.
> > > > >>> > > > >> > >> DEBUG 1: Creating postscript file:
> > > > >>> trmm_daily.20051231.7.ps
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >> The plot_data_plane tool is able to read the
data,
> > and
> > > > I've
> > > > >>> > > > attached
> > > > >>> > > > >> the
> > > > >>> > > > >> > >> resulting image. However, notice the
warning
> > messages
> > > > >>> about
> > > > >>> > the
> > > > >>> > > > >> valid
> > > > >>> > > > >> > >> time.
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >> Using ncdump to see that file attributes, I
see
> this
> > > > timing
> > > > >>> > > > >> information:
> > > > >>> > > > >> > >> :HDF5_GLOBAL.BeginDate =
> > "2005-12-31" ;
> > > > >>> > > > >> > >> :HDF5_GLOBAL.BeginTime =
> > > "01:30:00.000Z"
> > > > ;
> > > > >>> > > > >> > >> :HDF5_GLOBAL.EndDate =
> "2006-01-01" ;
> > > > >>> > > > >> > >> :HDF5_GLOBAL.EndTime =
> > "01:29:59.999Z"
> > > ;
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >> However that is not the CF-compliant way of
> > specifying
> > > > >>> timing
> > > > >>> > > info.
> > > > >>> > > > >> So
> > > > >>> > > > >> > >> while MET will be able to read the data, the
timing
> > > info
> > > > >>> won't
> > > > >>> > be
> > > > >>> > > > >> > accurate
> > > > >>> > > > >> > >> in the MET output files. Instead, you'll
see
> > > "19700101"
> > > > >>> which
> > > > >>> > is
> > > > >>> > > > >> > unixtime
> > > > >>> > > > >> > >> = 0.
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >> Another option would be pulling the binary
TRMM
> data
> > > and
> > > > >>> using
> > > > >>> > > this
> > > > >>> > > > >> > >> Rscript
> > > > >>> > > > >> > >> to convert the binary to NetCDF:
> > > > >>> > > > >> > >> http://www.dtcenter.org/met/
> > > users/downloads/Rscripts/
> > > > >>> > > > trmmbin2nc.R
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >> However, I haven't done this in a while and
am not
> > sure
> > > > if
> > > > >>> > you'll
> > > > >>> > > > run
> > > > >>> > > > >> > into
> > > > >>> > > > >> > >> any issues.
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >> Hope that helps.
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >> Thanks,
> > > > >>> > > > >> > >> John
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong Yoo
via
> RT <
> > > > >>> > > > >> met_help at ucar.edu>
> > > > >>> > > > >> > >> wrote:
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >> >
> > > > >>> > > > >> > >> > <URL: https://rt.rap.ucar.edu/rt/
> > > > >>> > Ticket/Display.html?id=81063
> > > > >>> > > >
> > > > >>> > > > >> > >> >
> > > > >>> > > > >> > >> > Hi John,
> > > > >>> > > > >> > >> >
> > > > >>> > > > >> > >> > Thank you very much.
> > > > >>> > > > >> > >> > Regards,
> > > > >>> > > > >> > >> >
> > > > >>> > > > >> > >> > Jinwoong
> > > > >>> > > > >> > >> >
> > > > >>> > > > >> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John
Halley
> Gotway
> > > via
> > > > >>> RT <
> > > > >>> > > > >> > >> > met_help at ucar.edu> wrote:
> > > > >>> > > > >> > >> >
> > > > >>> > > > >> > >> > > Jinwoong,
> > > > >>> > > > >> > >> > >
> > > > >>> > > > >> > >> > > I'm out of the office today but will
take a
> > closer
> > > > look
> > > > >>> > > > tomorrow.
> > > > >>> > > > >> > >> > >
> > > > >>> > > > >> > >> > > Thanks
> > > > >>> > > > >> > >> > > John
> > > > >>> > > > >> > >> > >
> > > > >>> > > > >> > >> > > On Mon, Jul 3, 2017 at 12:20 PM Jinwoong
Yoo
> via
> > > RT <
> > > > >>> > > > >> > >> met_help at ucar.edu>
> > > > >>> > > > >> > >> > > wrote:
> > > > >>> > > > >> > >> > >
> > > > >>> > > > >> > >> > > >
> > > > >>> > > > >> > >> > > > <URL: https://rt.rap.ucar.edu/rt/
> > > > >>> > > > Ticket/Display.html?id=81063
> > > > >>> > > > >> >
> > > > >>> > > > >> > >> > > >
> > > > >>> > > > >> > >> > > > Hi John,
> > > > >>> > > > >> > >> > > >
> > > > >>> > > > >> > >> > > > Thank you for your reply.
> > > > >>> > > > >> > >> > > > I uploaded my data as in Yoo_data4.tar
on the
> > ftp
> > > > >>> site.
> > > > >>> > > > >> > >> > > > I included several files for the
message of
> ID
> > > of [
> > > > >>> > > > >> > rt.rap.ucar.edu
> > > > >>> > > > >> > >> > > #81074]
> > > > >>> > > > >> > >> > > > as well.
> > > > >>> > > > >> > >> > > > Thank you.
> > > > >>> > > > >> > >> > > > Regards,
> > > > >>> > > > >> > >> > > >
> > > > >>> > > > >> > >> > > > Jinwoong
> > > > >>> > > > >> > >> > > >
> > > > >>> > > > >> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM, John
Halley
> > > Gotway
> > > > >>> via
> > > > >>> > RT
> > > > >>> > > <
> > > > >>> > > > >> > >> > > > met_help at ucar.edu> wrote:
> > > > >>> > > > >> > >> > > >
> > > > >>> > > > >> > >> > > > > Jinwoong,
> > > > >>> > > > >> > >> > > > >
> > > > >>> > > > >> > >> > > > > I see that you're having trouble
reading a
> > TRMM
> > > > >>> NetCDF
> > > > >>> > > file
> > > > >>> > > > >> into
> > > > >>> > > > >> > >> MET.
> > > > >>> > > > >> > >> > > > Can
> > > > >>> > > > >> > >> > > > > you please post the problematic file
to our
> > > > >>> anonymous
> > > > >>> > ftp
> > > > >>> > > > >> site
> > > > >>> > > > >> > so
> > > > >>> > > > >> > >> I
> > > > >>> > > > >> > >> > can
> > > > >>> > > > >> > >> > > > > take a look?
> > > > >>> > > > >> > >> > > > >
> > > > >>> > > > >> > >> > > > > http://www.dtcenter.org/met/
> > > > >>> > > users/support/met_help.php#ftp
> > > > >>> > > > >> > >> > > > >
> > > > >>> > > > >> > >> > > > > Thanks,
> > > > >>> > > > >> > >> > > > > John Halley Gotway
> > > > >>> > > > >> > >> > > > >
> > > > >>> > > > >> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM,
Jinwoong
> Yoo
> > > via
> > > > >>> RT <
> > > > >>> > > > >> > >> > met_help at ucar.edu
> > > > >>> > > > >> > >> > > >
> > > > >>> > > > >> > >> > > > > wrote:
> > > > >>> > > > >> > >> > > > >
> > > > >>> > > > >> > >> > > > > >
> > > > >>> > > > >> > >> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Tic
> > > > >>> > > > >> ket/Display.html?id=81063
> > > > >>> > > > >> > >
> > > > >>> > > > >> > >> > > > > >
> > > > >>> > > > >> > >> > > > > > Hi,
> > > > >>> > > > >> > >> > > > > >
> > > > >>> > > > >> > >> > > > > > TRMM data comes in as netCDF-4
classic
> > model.
> > > > >>> > > > >> > >> > > > > > I changed it to netCDF classic and
run
> the
> > > same
> > > > >>> > command
> > > > >>> > > > >> for a
> > > > >>> > > > >> > >> test.
> > > > >>> > > > >> > >> > > > > > But I got the same error as below.
> > > > >>> > > > >> > >> > > > > >
> > > > >>> > > > >> > >> > > > > > yoo108 at halstead-fe00:*/scratch
> > > > >>> /halstead/y/yoo108/
> > > > >>> > TRMM*
> > > > >>> > > $
> > > > >>> > > > >> > >> > > > > > ~/met-
6.0_bugfix/bin/regrid_data_plane
> > > > >>> > > > >> > >> /scratch/halstead/y/yoo108/
> > > > >>> > > > >> > >> > > TRMM/
> > > > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > > > >>> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/ND_
> > > > >>> grided_obs/daily_T2m_
> > > > >>> > > > >> > >> > > maxminmean_1976.nc
> > > > >>> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/TRMM/
> > > > >>> > regrid_trmm_sample.nc
> > > > >>> > > > >> -field
> > > > >>> > > > >> > >> > > > > > 'name="precipitation";'
> > > > >>> > > > >> > >> > > > > >
> > > > >>> > > > >> > >> > > > > > DEBUG 1: Reading data file:
> > > > >>> > > > /scratch/halstead/y/yoo108/TRM
> > > > >>> > > > >> M/
> > > > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > > > >>> > > > >> > >> > > > > >
> > > > >>> > > > >> > >> > > > > > ERROR :
> > > > >>> > > > >> > >> > > > > >
> > > > >>> > > > >> > >> > > > > > ERROR : process_data_file() ->
> > > > >>> > > > >> "/scratch/halstead/y/yoo108/TR
> > > > >>> > > > >> > >> MM/
> > > > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc" not
a
> valid
> > > data
> > > > >>> file
> > > > >>> > > > >> > >> > > > > >
> > > > >>> > > > >> > >> > > > > > Thank you.
> > > > >>> > > > >> > >> > > > > >
> > > > >>> > > > >> > >> > > > > > Regards,
> > > > >>> > > > >> > >> > > > > >
> > > > >>> > > > >> > >> > > > > >
> > > > >>> > > > >> > >> > > > > > Jinwoong
> > > > >>> > > > >> > >> > > > > >
> > > > >>> > > > >> > >> > > > > > On Mon, Jul 3, 2017 at 11:41 AM,
Jinwoong
> > > Yoo <
> > > > >>> > > > >> > >> > > jinwoong.yoo at gmail.com>
> > > > >>> > > > >> > >> > > > > > wrote:
> > > > >>> > > > >> > >> > > > > >
> > > > >>> > > > >> > >> > > > > > > Hi,
> > > > >>> > > > >> > >> > > > > > >
> > > > >>> > > > >> > >> > > > > > > I noticed that TRMM data
dimension was
> > > (lon,
> > > > >>> lat).
> > > > >>> > > > >> > >> > > > > > > So I switched their order to
(lat, lon)
> > and
> > > > >>> ran the
> > > > >>> > > > >> command
> > > > >>> > > > >> > >> > again.
> > > > >>> > > > >> > >> > > > > > > However, I got the same error
message
> as
> > > > below.
> > > > >>> > > > >> > >> > > > > > >
> > > > >>> > > > >> > >> > > > > > > yoo108 at halstead-fe00:*/scratch
> > > > >>> /halstead/y/yoo108/
> > > > >>> > > TRMM*
> > > > >>> > > > $
> > > > >>> > > > >> > >> > > > > > > ~/met-
6.0_bugfix/bin/regrid_data_plane
> > > > >>> > > > >> > >> > /scratch/halstead/y/yoo108/
> > > > >>> > > > >> > >> > > > > TRMM/
> > > > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > > > >>> > > > /scratch/halstead/y/yoo108/ND_
> > > > >>> > > > >> > >> > > > > > > grided_obs/daily_T2m_
> maxminmean_1976.nc
> > > > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > > > >>> > > > >> > >> > > > > TRMM/
> > > > >>> > > > >> > >> > > > > > > regrid_trmm_sample.nc -field
> > > > >>> > 'name="precipitation";'
> > > > >>> > > > >> > >> > > > > > >
> > > > >>> > > > >> > >> > > > > > > DEBUG 1: Reading data file:
> > > > >>> > > > >> /scratch/halstead/y/yoo108/TRM
> > > > >>> > > > >> > M/
> > > > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > > > >>> > > > >> > >> > > > > > >
> > > > >>> > > > >> > >> > > > > > > ERROR :
> > > > >>> > > > >> > >> > > > > > >
> > > > >>> > > > >> > >> > > > > > > ERROR : process_data_file() ->
> > > > >>> > > > >> > "/scratch/halstead/y/yoo108/TR
> > > > >>> > > > >> > >> > MM/
> > > > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc" not a
valid
> > data
> > > > >>> file
> > > > >>> > > > >> > >> > > > > > >
> > > > >>> > > > >> > >> > > > > > >
> > > > >>> > > > >> > >> > > > > > > Thank you.
> > > > >>> > > > >> > >> > > > > > >
> > > > >>> > > > >> > >> > > > > > > Regards,
> > > > >>> > > > >> > >> > > > > > >
> > > > >>> > > > >> > >> > > > > > >
> > > > >>> > > > >> > >> > > > > > > Jinwoong
> > > > >>> > > > >> > >> > > > > > >
> > > > >>> > > > >> > >> > > > > > >
> > > > >>> > > > >> > >> > > > > > >
> > > > >>> > > > >> > >> > > > > > > On Thu, Jun 29, 2017 at 4:36 PM,
> Jinwoong
> > > > Yoo <
> > > > >>> > > > >> > >> > > > jinwoong.yoo at gmail.com>
> > > > >>> > > > >> > >> > > > > > > wrote:
> > > > >>> > > > >> > >> > > > > > >
> > > > >>> > > > >> > >> > > > > > >> Hi,
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> I got a similar result with a
TRMM
> data.
> > > > >>> > > > >> > >> > > > > > >> Please see below:
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/scratch
> > > > >>> /halstead/y/yoo108/
> > > > >>> > > > TRMM*
> > > > >>> > > > >> $
> > > > >>> > > > >> > >> > > > > > >> ~/met-6.0_bugfix/bin/regrid_
> data_plane
> > > > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > > > >>> > > > >> > >> > > > > TRMM/
> > > > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > > > >>> > > > >> /scratch/halstead/y/yoo108/ND_
> > > > >>> > > > >> > >> > > > > > >> grided_obs/daily_T2m_
> maxminmean_1976.nc
> > > > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > > > >>> > > > >> > >> > > > > > TRMM/
> > > > >>> > > > >> > >> > > > > > >> regrid_trmm_sample.nc -field
> > > > >>> > > 'name="precipitation";'
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> DEBUG 1: Reading data file:
> > > > >>> > > > >> /scratch/halstead/y/yoo108/TRM
> > > > >>> > > > >> > M/
> > > > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> ERROR : process_data_file() ->
> > > > >>> > > > >> > >> "/scratch/halstead/y/yoo108/TR
> > > > >>> > > > >> > >> > MM/
> > > > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc" not
a
> valid
> > > > data
> > > > >>> file
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> A part of ncdump output for the
TRMM
> > data
> > > is
> > > > >>> > pasted
> > > > >>> > > > >> below:
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/scratch
> > > > >>> /halstead/y/yoo108/
> > > > >>> > > > TRMM*
> > > > >>> > > > >> $
> > > > >>> > > > >> > >> ncdump
> > > > >>> > > > >> > >> > > -h
> > > > >>> > > > >> > >> > > > > > >> subset_200003-200512/3B42RT_
> > > > >>> > > Daily.20051231.7.nc4.nc4
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> netcdf
\3B42RT_Daily.20051231.7.nc4 {
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> dimensions:
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> lon = 59 ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> lat = 58 ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> variables:
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> short precipitation_cnt(lon,
lat) ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> precipitation_cnt:units =
"count" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> precipitation_cnt:long_name =
"Count
> of
> > > > valid
> > > > >>> 3-hr
> > > > >>> > > > >> > >> precipitation
> > > > >>> > > > >> > >> > > > > > >> retrievals for the day" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> precipitation_cnt:coordinates =
"lat
> > lon"
> > > ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> precipitation_cnt:origname =
> > > > >>> "precipitation_cnt" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> precipitation_cnt:fullnamepath
=
> > > > >>> > > "/precipitation_cnt"
> > > > >>> > > > ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> float uncal_precipitation(lon,
lat) ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation:units =
"mm" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation:long_name =
"Daily
> > > > >>> accumulated
> > > > >>> > > > >> > >> uncalibrated
> > > > >>> > > > >> > >> > > > > > >> precipitation" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation:coordinates
=
> "lat
> > > > lon" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation:_FillValue
=
> > -9999.9f
> > > ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation:origname =
> > > > >>> > > "uncal_precipitation" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation:fullnamepath =
> > > > >>> > > > >> "/uncal_precipitation"
> > > > >>> > > > >> > ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> short
uncal_precipitation_cnt(lon,
> lat)
> > ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:units =
> "count"
> > ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:long_name =
> > > "Count
> > > > of
> > > > >>> > valid
> > > > >>> > > > >> 3-hr
> > > > >>> > > > >> > >> uncal
> > > > >>> > > > >> > >> > > > > > >> precipitation retrievals for
the day"
> ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:coordinates =
> > > "lat
> > > > >>> lon" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:origname =
> > > > >>> > > > >> > >> "uncal_precipitation_cnt" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:fullnamepath
> =
> > > > >>> > > > >> > >> > > "/uncal_precipitation_cnt" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> float precipitation(lon, lat) ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> precipitation:units = "mm" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> precipitation:long_name =
"Daily
> > > accumulated
> > > > >>> > > > >> precipitation
> > > > >>> > > > >> > >> > > (combined
> > > > >>> > > > >> > >> > > > > > >> microwave-IR) estimate" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> precipitation:coordinates =
"lat lon"
> ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> precipitation:_FillValue =
-9999.9f ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> precipitation:origname =
> > "precipitation" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> precipitation:fullnamepath =
> > > > "/precipitation"
> > > > >>> ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> short randomError_cnt(lon, lat)
;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:units = "count"
;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:long_name =
"Count of
> > > > >>> randomError
> > > > >>> > > for
> > > > >>> > > > >> the
> > > > >>> > > > >> > >> day" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:coordinates =
"lat
> lon"
> > ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:origname =
> > > > "randomError_cnt" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:fullnamepath =
> > > > >>> "/randomError_cnt"
> > > > >>> > ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> float randomError(lon, lat) ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> randomError:units = "mm" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> randomError:long_name = "Daily
total
> > error
> > > > of
> > > > >>> > > combined
> > > > >>> > > > >> > >> > > microwave-IR
> > > > >>> > > > >> > >> > > > > > >> precipitation estimate" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> randomError:_FillValue =
-9999.9f ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> randomError:origname =
"randomError" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> randomError:fullnamepath =
> > "/randomError"
> > > ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> float lat(lat) ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> lat:units = "degrees_north" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> lat:long_name = "Latitude" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> lat:origname = "lat" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> lat:fullnamepath = "/lat" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> float lon(lon) ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> lon:units = "degrees_east" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> lon:long_name = "Longitude" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> lon:origname = "lon" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> lon:fullnamepath = "/lon" ;
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> Thank you.
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> Regards,
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> Jinwoong
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >> On Thu, Jun 29, 2017 at 3:11
PM,
> > > > >>> > met_help at ucar.edu
> > > > >>> > > > via
> > > > >>> > > > >> RT
> > > > >>> > > > >> > <
> > > > >>> > > > >> > >> > > > > > >> met_help at ucar.edu> wrote:
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >>> NOTE: THE MET TEAM HAS LIMITED
> > > AVAILABILITY
> > > > >>> > BETWEEN
> > > > >>> > > > >> > 5/23/17
> > > > >>> > > > >> > >> AND
> > > > >>> > > > >> > >> > > > > > >>> 5/30/17. RESPONSES MAY BE
DELAYED.
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> Greetings,
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> This message has been
automatically
> > > > >>> generated in
> > > > >>> > > > >> response
> > > > >>> > > > >> > to
> > > > >>> > > > >> > >> > the
> > > > >>> > > > >> > >> > > > > > >>> creation of a trouble ticket
> regarding:
> > > > >>> > > > >> > >> > > > > > >>> "regrid_data_plane:
not a
> valid
> > > > data
> > > > >>> > file",
> > > > >>> > > > >> > >> > > > > > >>> a summary of which appears
below.
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> There is no need to reply to
this
> > message
> > > > >>> right
> > > > >>> > > now.
> > > > >>> > > > >> Your
> > > > >>> > > > >> > >> > ticket
> > > > >>> > > > >> > >> > > > has
> > > > >>> > > > >> > >> > > > > > >>> been
> > > > >>> > > > >> > >> > > > > > >>> assigned an ID of
[rt.rap.ucar.edu
> > > > #81063].
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> Please include the string:
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> [rt.rap.ucar.edu
#81063]
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> in the subject line of all
future
> > > > >>> correspondence
> > > > >>> > > > about
> > > > >>> > > > >> > this
> > > > >>> > > > >> > >> > > issue.
> > > > >>> > > > >> > >> > > > To
> > > > >>> > > > >> > >> > > > > > do
> > > > >>> > > > >> > >> > > > > > >>> so,
> > > > >>> > > > >> > >> > > > > > >>> you may reply to this message.
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> Thank
you,
> > > > >>> > > > >> > >> > > > > > >>>
> > > met_help at ucar.edu
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> ------------------------------
> > > > >>> > > > >> > >> ------------------------------
> > > > >>> > > > >> > >> > > > > > >>> -------------
> > > > >>> > > > >> > >> > > > > > >>> Hi,
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> I am trying to regrid one of
my
> > > observation
> > > > >>> files
> > > > >>> > > in
> > > > >>> > > > >> lat
> > > > >>> > > > >> > lon
> > > > >>> > > > >> > >> > > > > coordinate
> > > > >>> > > > >> > >> > > > > > >>> grid to WRF curvilinear grid.
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> I ran bin/regrid_data_plane
using a
> > > sample
> > > > >>> lat
> > > > >>> > lon
> > > > >>> > > > grid
> > > > >>> > > > >> > file
> > > > >>> > > > >> > >> > and
> > > > >>> > > > >> > >> > > a
> > > > >>> > > > >> > >> > > > > file
> > > > >>> > > > >> > >> > > > > > >>> in
> > > > >>> > > > >> > >> > > > > > >>> the WRF grid. But I got error
as
> shown
> > > > below:
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > > > >>> > > > >> > /halstead/y/yoo108/ND_grided_
> > > > >>> > > > >> > >> > obs*
> > > > >>> > > > >> > >> > > $
> > > > >>> > > > >> > >> > > > > > >>> ~/met-6.0_bugfix/bin/regrid_
> data_plane
> > > > >>> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > > grided_obs/
> > > > >>> > > > >> sample_tmax.nc
> > > > >>> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > > > >>> > > grided_obs/daily_T2m_
> > > > >>> > > > >> > >> > > > > maxminmean_1976.nc
> > > > >>> > > > >> > >> > > > > > >>> /scratch/halstead/y/yoo108/ND_
> > > > >>> > > > >> > >> grided_obs/NDtoWRFgrid_sample_
> > > > >>> > > > >> > >> > > > tmax.nc
> > > > >>> > > > >> > >> > > > > > >>> -field
> > > > >>> > > > >> > >> > > > > > >>> 'name="tmax";'
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> DEBUG 1: Reading data file:
> > > > >>> > > > >> /scratch/halstead/y/yoo108/ND_
> > > > >>> > > > >> > >> > > > > grided_obs/
> > > > >>> > > > >> > >> > > > > > >>> sample_tmax.nc
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> ERROR : process_data_file()
->
> > > > >>> > > > >> > >> "/scratch/halstead/y/yoo108/ND
> > > > >>> > > > >> > >> > > > > > >>> _grided_obs/
> > > > >>> > > > >> > >> > > > > > >>> sample_tmax.nc" not a valid
data
> file
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> I wonder which part of the
input file
> > > does
> > > > >>> not
> > > > >>> > > > satisfy
> > > > >>> > > > >> the
> > > > >>> > > > >> > >> > MET's
> > > > >>> > > > >> > >> > > > > "valid
> > > > >>> > > > >> > >> > > > > > >>> file" criteria.
> > > > >>> > > > >> > >> > > > > > >>> ncdump output of the input
file looks
> > as
> > > > >>> below:
> > > > >>> > > > >> > >> > > > > > >>> Input file was originally
generated
> by
> > > VIC
> > > > >>> model
> > > > >>> > > and
> > > > >>> > > > >> > >> converted
> > > > >>> > > > >> > >> > > into
> > > > >>> > > > >> > >> > > > > cf
> > > > >>> > > > >> > >> > > > > > >>> netcdf format.
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> Thank you in advance.
> > > > >>> > > > >> > >> > > > > > >>> Regards,
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> Jinwoong
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> yoo108 at halstead-fe00:*/scratch
> > > > >>> > > > >> > /halstead/y/yoo108/ND_grided_
> > > > >>> > > > >> > >> > obs*
> > > > >>> > > > >> > >> > > $
> > > > >>> > > > >> > >> > > > > > >>> ncdump -h
> > > > >>> > > > >> > >> > > > > > >>> sample_tmax.nc
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> netcdf sample_tmax {
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> dimensions:
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> T = 1 ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> X = 55 ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> Y = 65 ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> variables:
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> double T(T) ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> T:units = "days since 1915-01-
01" ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> T:long_name = "Time" ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> double X(X) ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> X:units = "degrees_east" ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> X:long_name = "Longitude" ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> double Y(Y) ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> Y:units = "degrees_north" ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> Y:long_name = "Latitude" ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> double tmax(T, Y, X) ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> tmax:units = "degC" ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> tmax:long_name = "tmax
calculated by
> > > VIC" ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> tmax:missing_value = -9999.f ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> // global attributes:
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>> :production = "VIC output" ;
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>>
> > > > >>> > > > >> > >> > > > > > >>
> > > > >>> > > > >> > >> > > > > > >
> > > > >>> > > > >> > >> > > > > >
> > > > >>> > > > >> > >> > > > > >
> > > > >>> > > > >> > >> > > > >
> > > > >>> > > > >> > >> > > > >
> > > > >>> > > > >> > >> > > >
> > > > >>> > > > >> > >> > > >
> > > > >>> > > > >> > >> > >
> > > > >>> > > > >> > >> > >
> > > > >>> > > > >> > >> >
> > > > >>> > > > >> > >> >
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >>
> > > > >>> > > > >> > >
> > > > >>> > > > >> >
> > > > >>> > > > >> >
> > > > >>> > > > >>
> > > > >>> > > > >>
> > > > >>> > > > >
> > > > >>> > > >
> > > > >>> > > >
> > > > >>> > >
> > > > >>> > >
> > > > >>> >
> > > > >>> >
> > > > >>>
> > > > >>>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Thu Jul 13 23:35:15 2017
Hi John,
I wonder if you had a chance to take a look at the issue regarding how
to
make grid_stat read in netcdf file that has WRF coordinate grid info?
Please let me know.
Thank you.
Regards,
Jinwoong
On Wed, Jul 12, 2017 at 3:05 PM, Jinwoong Yoo <jinwoong.yoo at gmail.com>
wrote:
> Hi John,
> As I noted in the previous messages,
> I was able to plot netcdf files by copying global attributes from
WRF
> output to the netcdf files in the same coordinate grids.
>
> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal* $
> ~/met-6.0_bugfix/bin/plot_data_plane /scratch/halstead/y/yoo108/NCA
> R_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc met_em.d03.2005-12-
31_18:00:
> 00.ps 'name="TT";level="(0,0,*,*)";file_type = NETCDF_PINT;'
>
> DEBUG 1: Opening data file: /scratch/halstead/y/yoo108/NCA
> R_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc
>
> DEBUG 1: Creating postscript file: met_em.d03.2005-12-31_18:00:00.ps
>
> However, when 'file_typ=NETCDF_PINT;' was not provided in the
> plot_data_plane command, it failed.
>
> yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal* $
> ~/met-6.0_bugfix/bin/plot_data_plane /scratch/halstead/y/yoo108/NCA
> R_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc met_em.d03.2005-12-
31_18:00:
> 00.ps 'name="TT";level="(0,0,*,*)";'
>
> DEBUG 1: Opening data file: /scratch/halstead/y/yoo108/NCA
> R_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc
>
> ERROR : plot_data_plane -> file "/scratch/halstead/y/yoo108/NC
> AR_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc" not a valid data
file
>
> Thing is that I don't know where to put the argument (
> 'file_typ=NETCDF_PINT;') in the grid_stat.
>
> I tried both in config file and command line but both failed.
>
>
> Thank you.
>
>
> Regards,
>
>
> Jinwoong
>
>
>
> On Wed, Jul 12, 2017 at 2:59 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Jinwoong,
>>
>> OK, sorry for the confusion. Honestly, I don't know how you're
getting
>> plot_data_plane to work at all. When I run it using the sample
data file
>> you sent me (met_em.d03.2005-01-01_00:00:00.nc), it doesn't work:
>>
>> met-6.0/bin/plot_data_plane met_em.d03.2005-01-01_00:00:00.nc
test.ps \
>> 'name="TT"; level="(0,0,*,*)"; file_type = NETCDF_PINT;'
>> DEBUG 1: Opening data file: met_em.d03.2005-01-01_00:00:00.nc
>> ERROR :
>> ERROR : MetNcPinterpDataFile::open(const char *) -> unable to open
>> NetCDF
>> file "met_em.d03.2005-01-01_00:00:00.nc"
>> ERROR :
>> ERROR :
>> ERROR : Met2dDataFileFactory::new_met_2d_data_file() -> error
opening
>> file
>> "met_em.d03.2005-01-01_00:00:00.nc"
>> ERROR :
>>
>> There must be something different between the sample file you sent
and the
>> one you're actually using:
>> /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
>> 00.nc
>>
>> John
>>
>> On Wed, Jul 12, 2017 at 12:46 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
>> wrote:
>>
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>> >
>> > Hi John,
>> >
>> > I am still experiencing troubles to read in netcdf files for
grid_stat
>> > command.
>> > Please read the last two previous emails that I sent.
>> > Thank you very much.
>> >
>> > Regards,
>> >
>> > Jinwoong
>> >
>> > On Wed, Jul 12, 2017 at 1:44 PM, John Halley Gotway via RT <
>> > met_help at ucar.edu> wrote:
>> >
>> > > Great, glad you were able to get it working.
>> > >
>> > > Thanks,
>> > > John
>> > >
>> > > On Tue, Jul 11, 2017 at 9:44 AM, Jinwoong Yoo via RT <
>> met_help at ucar.edu>
>> > > wrote:
>> > >
>> > > >
>> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
>> > > >
>> > > > Hi John,
>> > > >
>> > > > Even with the plot_data_plane command,
>> > > > I noticed that "file_type = NETCDF_PINT;" argument should be
>> provided
>> > in
>> > > > the command line.
>> > > > Otherwise, it fails. Please see below.
>> > > >
>> > > > yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/wrfAnalysis
>> /METanal*
>> > $
>> > > > ~/met-6.0_bugfix/bin/plot_data_plane
>> > > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-
>> 12-31_18:00:
>> > > > 00.nc
>> > > > met_em.d03.2005-12-31_18:00:00.ps
'name="TT";level="(0,0,*,*)";'
>> > > >
>> > > > DEBUG 1: Opening data file:
>> > > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-
>> 12-31_18:00:
>> > > > 00.nc
>> > > >
>> > > > ERROR : plot_data_plane -> file
>> > > > "/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
>> > 2005-12-31_18:00:
>> > > > 00.nc"
>> > > > not a valid data file
>> > > >
>> > > >
>> > > >
>> > > > yoo108 at halstead-fe01:*/scratch/halstead/y/yoo108/wrfAnalysis
>> /METanal*
>> > $
>> > > > ~/met-6.0_bugfix/bin/plot_data_plane
>> > > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-
>> 12-31_18:00:
>> > > > 00.nc
>> > > > met_em.d03.2005-12-31_18:00:00.ps
'name="TT";level="(0,0,*,*)";
>> > file_type
>> > > =
>> > > > NETCDF_PINT;'
>> > > >
>> > > > DEBUG 1: Opening data file:
>> > > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-
>> 12-31_18:00:
>> > > > 00.nc
>> > > >
>> > > > DEBUG 1: Creating postscript file: met_em.d03.2005-12-
31_18:00:00
>> .ps
>> > > >
>> > > >
>> > > >
>> > > > Thank you.
>> > > >
>> > > > Regards,
>> > > >
>> > > >
>> > > > Jinwoong
>> > > >
>> > > >
>> > > > On Tue, Jul 11, 2017 at 11:12 AM, Jinwoong Yoo <
>> jinwoong.yoo at gmail.com
>> > >
>> > > > wrote:
>> > > >
>> > > > > Hi John,
>> > > > >
>> > > > > Now I am trying to execute grid_stat against these netcdf
files
>> that
>> > > have
>> > > > > been patted with the WRF global attributes.
>> > > > >
>> > > > > I tried to include 'file_type = NETCDF_PINT;' argument both
in its
>> > > > > configuration file and in the command line.
>> > > > > However, both failed to run (Please see below).
>> > > > >
>> > > > > Could you please guide me how to specify the netcdf file
type in
>> the
>> > > > > grid_stat application?
>> > > > > Thank you.
>> > > > >
>> > > > > Regards,
>> > > > >
>> > > > > Jinwoong
>> > > > >
>> > > > >
>> > > > > 1.
>> > > > >
>> > > > > .......
>> > > > >
>> > > > > obs = {
>> > > > >
>> > > > >
>> > > > > field = [
>> > > > >
>> > > > > {
>> > > > >
>> > > > > name = "TT";
>> > > > >
>> > > > > level = [ "(0,0,*,*)" ];
>> > > > >
>> > > > > file_type = NETCDF_PINT;
>> > > > >
>> > > > > cat_thresh = [];
>> > > > >
>> > > > > }
>> > > > >
>> > > > > .......
>> > > > >
>> > > > > DEBUG 1: Default Config File: /home/yoo108/met-6.0_bugfix/
>> > > > > share/met/config/GridStatConfig_default
>> > > > >
>> > > > > DEBUG 1: User Config File: /scratch/halstead/y/yoo108/
>> > > > wrfAnalysis/METanal/
>> > > > > GridStatConfig_met_em
>> > > > >
>> > > > > DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() ->
created
>> new
>> > > > > Met2dDataFile object of type "FileType_Gb2".
>> > > > >
>> > > > > DEBUG 4: Switching the GRIB2 radius of the earth value of
6371.23
>> km
>> > to
>> > > > > 6371.2 km for internal consistency.
>> > > > >
>> > > > > DEBUG 4:
>> > > > >
>> > > > > DEBUG 4: Lambert Conformal Grid Data:
>> > > > >
>> > > > > DEBUG 4: scale_lat_1: 48
>> > > > >
>> > > > > DEBUG 4: scale_lat_2: 32
>> > > > >
>> > > > > DEBUG 4: lat_pin: 36.9132
>> > > > >
>> > > > > DEBUG 4: lon_pin: 92.0748
>> > > > >
>> > > > > DEBUG 4: x_pin: 0
>> > > > >
>> > > > > DEBUG 4: y_pin: 0
>> > > > >
>> > > > > DEBUG 4: lon_orient: 97
>> > > > >
>> > > > > DEBUG 4: d_km: 4
>> > > > >
>> > > > > DEBUG 4: r_km: 6371.2
>> > > > >
>> > > > > DEBUG 4: nx: 189
>> > > > >
>> > > > > DEBUG 4: ny: 270
>> > > > >
>> > > > > DEBUG 4:
>> > > > >
>> > > > > DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() ->
created
>> new
>> > > > > Met2dDataFile object of type "FileType_None".
>> > > > >
>> > > > > ERROR :
>> > > > >
>> > > > > ERROR : Trouble reading observation file
>> > "/scratch/halstead/y/yoo108/
>> > > > > NCAR_BC_met_em/met_em.d03.1980-01-01_00:00:00.nc"
>> > > > >
>> > > > >
>> > > > >
>> > > > > 2.
>> > > > >
>> > > > > /home/yoo108/met-6.0_bugfix/bin/grid_stat
>> > > $dir_data/$yyyy/$yyyy$nummon/$
>> > > > > grib_date1 $dir_data2/$met_em_date1
$analDir/$GridStatConfig
>> > > 'file_type =
>> > > > > NETCDF_PINT;' -outdir $workDir -v 4
>> > > > >
>> > > > > *** Model Evaluation Tools (METV6.0) ***
>> > > > >
>> > > > >
>> > > > > Usage: grid_stat
>> > > > >
>> > > > > fcst_file
>> > > > >
>> > > > > obs_file
>> > > > >
>> > > > > config_file
>> > > > >
>> > > > > [-outdir path]
>> > > > >
>> > > > > [-log file]
>> > > > >
>> > > > > [-v level]
>> > > > >
>> > > > > [-compress level]
>> > > > >
>> > > > >
>> > > > > where "fcst_file" is a gridded forecast file containing the
>> field(s)
>> > to
>> > > > > be verified (required).
>> > > > >
>> > > > > "obs_file" is a gridded observation file containing the
verifying
>> > > > field(s)
>> > > > > (required).
>> > > > >
>> > > > > "config_file" is a GridStatConfig file containing the
desired
>> > > > > configuration settings (required).
>> > > > >
>> > > > > "-outdir path" overrides the default output directory
>> > > > > (/scratch/halstead/y/yoo108/wrfAnalysis/METanal/wrf2met_em)
>> > > (optional).
>> > > > >
>> > > > > "-log file" outputs log messages to the specified file
(optional).
>> > > > >
>> > > > > "-v level" overrides the default level of logging (4)
(optional).
>> > > > >
>> > > > > "-compress level" overrides the compression level of NetCDF
>> variable
>> > > (0)
>> > > > > (optional).
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Mon, Jul 10, 2017 at 4:53 PM, Jinwoong Yoo <
>> > jinwoong.yoo at gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > >> Hi John,
>> > > > >>
>> > > > >> I was able to open netcdf files that share the same
coordinates
>> with
>> > > WRF
>> > > > >> output by copying the global attribute of the WRF output
to these
>> > > netcdf
>> > > > >> files:
>> > > > >>
>> > > > >> ncks -A -x wrfout.nc target.nc
>> > > > >>
>> > > > >> This enabled me to open netcdf files in MET using
>> > > > >> 'name="TT";level="(0,0,*,*)";file_type = NETCDF_PINT;'
argument.
>> > > > >>
>> > > > >> Thank you very much!
>> > > > >> Regards,
>> > > > >>
>> > > > >> Jinwoong
>> > > > >>
>> > > > >> On Mon, Jul 10, 2017 at 3:04 PM, John Halley Gotway via RT
<
>> > > > >> met_help at ucar.edu> wrote:
>> > > > >>
>> > > > >>> Jinwoong,
>> > > > >>>
>> > > > >>> I tried running the sample file
(daily_T2m_maxminmean_1981.nc)
>> > > through
>> > > > >>> plot_data_plane and saw the same behavior you did.
Looking
>> closely
>> > > at
>> > > > >>> that
>> > > > >>> file I see that is not the NetCDF output generated by
WRF. The
>> > > history
>> > > > >>> attribute indicates that it was created by the "ncks"
utility:
>> > > > >>>
>> > > > >>> :history = "Sun Jul 2 15:47:18 2017: ncks -d days,0,0
>> > > > >>>
/scratch/halstead/k/khoogewi/CCRC_wrf/analysis/T2m/daily_T2m_
>> > > > >>> maxminmean_1981.nc
>> > > > >>>
/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_maxminm
>> > > > >>> ean_19810101.nc"
>> > > > >>>
>> > > > >>>
>> > > > >>> This is not a CF-compliant NetCDF file and it does not
look like
>> > the
>> > > > >>> output
>> > > > >>> from WRF. Another alternative is making it look like the
NetCDF
>> > file
>> > > > >>> format used by the MET tools themselves.
>> > > > >>>
>> > > > >>> I ran the following command to add global attributes to
define
>> the
>> > > grid
>> > > > >>> spec for MET:
>> > > > >>>
>> > > > >>> ncatted \
>> > > > >>> -a MET_version,global,o,c,"V6.0" \
>> > > > >>> -a Projection,global,o,c,"Lambert Conformal" \
>> > > > >>> -a scale_lat_1,global,o,c,"48" \
>> > > > >>> -a scale_lat_2,global,o,c,"32" \
>> > > > >>> -a lat_pin,global,o,c,"48" \
>> > > > >>> -a lon_pin,global,o,c,"-97" \
>> > > > >>> -a x_pin,global,o,c,"0" \
>> > > > >>> -a y_pin,global,o,c,"0" \
>> > > > >>> -a lon_orient,global,o,c,"-97" \
>> > > > >>> -a d_km,global,o,c,"3" \
>> > > > >>> -a r_km,global,o,c,"6371.2" \
>> > > > >>> -a nx,global,o,c,"189" \
>> > > > >>> -a ny,global,o,c,"270" \
>> > > > >>> daily_T2m_maxminmean_1976.nc -o
daily_T2m_maxminmean_1976_MET.
>> nc
>> > > > >>>
>> > > > >>> However, I don't think these are all correct.
Specifically, I
>> > don't
>> > > > know
>> > > > >>> how the "lon_orient" should be set. So I set it to the
>> longitude
>> > of
>> > > > the
>> > > > >>> lower-left corner. Also, I don't know how the d_km
should be
>> set.
>> > > > >>> That's
>> > > > >>> the grid spacing in km. So I just guess with a value of
3.
>> > > > >>>
>> > > > >>> This enables MET to plot the result, but you should work
on
>> making
>> > > the
>> > > > >>> grid
>> > > > >>> info correct:
>> > > > >>> met-6.0/bin/plot_data_plane \
>> > > > >>> daily_T2m_maxminmean_1976_MET.nc \
>> > > > >>> daily_T2m_maxminmean_1976_MET.ps \
>> > > > >>> 'name="T2m_max"; level="(10,*,*)";' -v 4
>> > > > >>>
>> > > > >>> Thanks,
>> > > > >>> John
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>> On Fri, Jul 7, 2017 at 5:06 PM, Jinwoong Yoo via RT <
>> > > met_help at ucar.edu
>> > > > >
>> > > > >>> wrote:
>> > > > >>>
>> > > > >>> >
>> > > > >>> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>> >
>> > > > >>> >
>> > > > >>> > Hi John,
>> > > > >>> >
>> > > > >>> > Thank you for your comment.
>> > > > >>> > I tried it but it failed.
>> > > > >>> > Please see below.
>> > > > >>> >
>> > > > >>> > yoo108 at halstead-fe03:*/scratch/halstead/y/yoo108/
>> > > > wrfAnalysis/METanal*
>> > > > >>> $
>> > > > >>> > ~/met-6.0_bugfix/bin/plot_data_plane
>> > > > >>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
>> > > > >>> > maxminmean_20051231.nc
>> > > > >>> > wrfDaily_T2m_maxminmean_20051231.ps
>> > > > >>> > 'name="T2m_max";level="(0,*,*)";file_type =
NETCDF_PINT;'
>> > > > >>> >
>> > > > >>> > DEBUG 1: Opening data file:
>> > > > >>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
>> > > > >>> > maxminmean_20051231.nc
>> > > > >>> >
>> > > > >>> > ERROR : MetNcPinterpDataFile::open(const char *) ->
unable
>> to
>> > > open
>> > > > >>> NetCDF
>> > > > >>> > file
>> > > > >>> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
>> > > > >>> > maxminmean_20051231.nc"
>> > > > >>> >
>> > > > >>> > ERROR : Met2dDataFileFactory::new_met_2d_data_file()
->
>> error
>> > > > opening
>> > > > >>> > file
>> > > > >>> > "/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
>> > > > >>> > maxminmean_20051231.nc"
>> > > > >>> >
>> > > > >>> >
>> > > > >>> >
>> > > > >>> > One sample file (wrfDaily_T2m_maxminmean_19810101.nc)
is also
>> > > > >>> included in
>> > > > >>> > the Yoo_data4.tar file that I uploaded previously.
>> > > > >>> > Thank you.
>> > > > >>> > Haver a nice weekend.
>> > > > >>> >
>> > > > >>> > Regards,
>> > > > >>> >
>> > > > >>> > Jinwoong
>> > > > >>> >
>> > > > >>> >
>> > > > >>> >
>> > > > >>> > On Fri, Jul 7, 2017 at 6:04 PM, John Halley Gotway via
RT <
>> > > > >>> > met_help at ucar.edu
>> > > > >>> > > wrote:
>> > > > >>> >
>> > > > >>> > > Jinwoong,
>> > > > >>> > >
>> > > > >>> > > If they really are output from WRF, one simple thing
to try
>> is
>> > > > >>> telling
>> > > > >>> > MET
>> > > > >>> > > to interpret them as the NetCDF output of the
wrf_interp
>> > utility
>> > > > >>> > > :
>> > > > >>> > > file_type = NETCDF_PINT;
>> > > > >>> > >
>> > > > >>> > > "PINT" stands for "pressure interpolated"... pinterp
was the
>> > > > >>> precursor to
>> > > > >>> > > the current wrf_interp tool.
>> > > > >>> > >
>> > > > >>> > > If that doesn't work, I'll need to see a sample file
before
>> > > making
>> > > > >>> any
>> > > > >>> > > other suggestions.
>> > > > >>> > >
>> > > > >>> > > Thanks,
>> > > > >>> > > John
>> > > > >>> > >
>> > > > >>> > >
>> > > > >>> > >
>> > > > >>> > > On Fri, Jul 7, 2017 at 3:36 PM, Jinwoong Yoo via RT <
>> > > > >>> met_help at ucar.edu>
>> > > > >>> > > wrote:
>> > > > >>> > >
>> > > > >>> > > >
>> > > > >>> > > > <URL: https://rt.rap.ucar.edu/rt/
>> > Ticket/Display.html?id=81063
>> > > >
>> > > > >>> > > >
>> > > > >>> > > > Hi John,
>> > > > >>> > > >
>> > > > >>> > > > I was able to read in a "home brew" netcdf data
file using
>> > > > >>> > > plot_data_plane.
>> > > > >>> > > >
>> > > > >>> > > > Then, I went ahead and tried another netcdf file in
>> > curvilinear
>> > > > >>> > > coordinate
>> > > > >>> > > > which is in the same coordinate grid as my WRF
output.
>> But it
>> > > > >>> failed.
>> > > > >>> > > >
>> > > > >>> > > > I have many netcdf climatology files from the WRF
>> simulation
>> > > such
>> > > > >>> as
>> > > > >>> > > daily,
>> > > > >>> > > > monthly, and annual, etc. Therefore, they are all
in
>> > > curvilinear
>> > > > >>> > > coordinate
>> > > > >>> > > > (Lambert).
>> > > > >>> > > >
>> > > > >>> > > > I wonder if there is any work around so that I can
feed
>> these
>> > > > files
>> > > > >>> > into
>> > > > >>> > > > MET?
>> > > > >>> > > > Or should I regrid them all into lat lon coordinate
files
>> > > first?
>> > > > >>> > > >
>> > > > >>> > > > Thank you, John.
>> > > > >>> > > >
>> > > > >>> > > > Regards,
>> > > > >>> > > >
>> > > > >>> > > > Jinwoong Yoo
>> > > > >>> > > >
>> > > > >>> > > >
>> > > > >>> > > > On Fri, Jul 7, 2017 at 3:01 PM, Jinwoong Yoo <
>> > > > >>> jinwoong.yoo at gmail.com>
>> > > > >>> > > > wrote:
>> > > > >>> > > >
>> > > > >>> > > > > Hi John,
>> > > > >>> > > > >
>> > > > >>> > > > > Thank you very much.
>> > > > >>> > > > > Let me try and let you know how it goes.
>> > > > >>> > > > > Thank you.
>> > > > >>> > > > > Regards,
>> > > > >>> > > > >
>> > > > >>> > > > > Jinwoong
>> > > > >>> > > > >
>> > > > >>> > > > > On Fri, Jul 7, 2017 at 2:59 PM, John Halley
Gotway via
>> RT <
>> > > > >>> > > > > met_help at ucar.edu> wrote:
>> > > > >>> > > > >
>> > > > >>> > > > >> Jinwoong,
>> > > > >>> > > > >>
>> > > > >>> > > > >> Yes, you can give it a try. The closer you can
make
>> the
>> > > > NetCDF
>> > > > >>> > files
>> > > > >>> > > to
>> > > > >>> > > > >> the CF-convention, the more likely MET will be
able to
>> > read
>> > > > it.
>> > > > >>> > > > >>
>> > > > >>> > > > >> The reason that's its able to read the TRMM data
are
>> that
>> > > the
>> > > > >>> > lat/lon
>> > > > >>> > > > >> values are equally spaced. Non-equally spaced
lat/lon
>> > > values
>> > > > >>> on a
>> > > > >>> > map
>> > > > >>> > > > >> projection require that the map projection
information
>> be
>> > > > >>> specified.
>> > > > >>> > > > >> Unfortunately, specifying map projection
information in
>> > > > >>> CF-compliant
>> > > > >>> > > > >> NetCDF
>> > > > >>> > > > >> files is not as easy as I think it should be!
>> > > > >>> > > > >>
>> > > > >>> > > > >> Hope it works out ok for you.
>> > > > >>> > > > >>
>> > > > >>> > > > >> Thanks,
>> > > > >>> > > > >> John
>> > > > >>> > > > >>
>> > > > >>> > > > >> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo
via RT <
>> > > > >>> > > met_help at ucar.edu
>> > > > >>> > > > >
>> > > > >>> > > > >> wrote:
>> > > > >>> > > > >>
>> > > > >>> > > > >> >
>> > > > >>> > > > >> > <URL: https://rt.rap.ucar.edu/rt/
>> > > > Ticket/Display.html?id=81063
>> > > > >>> >
>> > > > >>> > > > >> >
>> > > > >>> > > > >> > investigating not investing :)
>> > > > >>> > > > >> >
>> > > > >>> > > > >> > Thanks!
>> > > > >>> > > > >> > Regards,
>> > > > >>> > > > >> >
>> > > > >>> > > > >> > Jinwoong
>> > > > >>> > > > >> >
>> > > > >>> > > > >> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo <
>> > > > >>> > > jinwoong.yoo at gmail.com>
>> > > > >>> > > > >> > wrote:
>> > > > >>> > > > >> >
>> > > > >>> > > > >> > > Hi John,
>> > > > >>> > > > >> > >
>> > > > >>> > > > >> > > Thank you very much for your time investing
the
>> issue.
>> > > > >>> > > > >> > > I am glad to hear that there is a trick to
work
>> around
>> > > the
>> > > > >>> issue
>> > > > >>> > > to
>> > > > >>> > > > >> read
>> > > > >>> > > > >> > > in TRMM data in netcdf format.
>> > > > >>> > > > >> > > I wonder if I can apply the same trick (
>> > > > >>> file_type=NETCDF_NCCF;)
>> > > > >>> > > to
>> > > > >>> > > > >> read
>> > > > >>> > > > >> > > in any other observation files in netcdf
format?
>> > > > >>> > > > >> > > In fact, I would like to read in "home brew"
netcdf
>> > > > dataset
>> > > > >>> > files
>> > > > >>> > > > into
>> > > > >>> > > > >> > > MET.
>> > > > >>> > > > >> > > One sample file of them was included in the
>> uploaded
>> > > data
>> > > > >>> > folder (
>> > > > >>> > > > >> > > sample_tmax.nc).
>> > > > >>> > > > >> > > The data in this sample file was originally
>> generated
>> > by
>> > > > VIC
>> > > > >>> > > model.
>> > > > >>> > > > >> > > Then the file format was converted into a
generic
>> > netcdf
>> > > > >>> file
>> > > > >>> > > format
>> > > > >>> > > > >> > > although the dimension names are T, X, Y not
time,
>> > lat,
>> > > > lon.
>> > > > >>> > > > >> > > But their coordinates have units in
"degrees_east"
>> or
>> > > > >>> > > > "degrees_north"
>> > > > >>> > > > >> as
>> > > > >>> > > > >> > > well as their long_name as "Longitude" and
>> "Latitude",
>> > > > >>> > > respectively.
>> > > > >>> > > > >> > >
>> > > > >>> > > > >> > > Of course, I will try to read those in for
>> Grid-stat
>> > > > today.
>> > > > >>> > > > >> > > But I would like to hear from you if the
trick (
>> > > > >>> > > > >> file_type=NETCDF_NCCF;)
>> > > > >>> > > > >> > > can be applied generally, which I wish very
much.
>> > > > >>> > > > >> > >
>> > > > >>> > > > >> > > Thank you so much, John.
>> > > > >>> > > > >> > >
>> > > > >>> > > > >> > > Regards,
>> > > > >>> > > > >> > >
>> > > > >>> > > > >> > > Jinwoong Yoo
>> > > > >>> > > > >> > >
>> > > > >>> > > > >> > >
>> > > > >>> > > > >> > > On Fri, Jul 7, 2017 at 1:16 PM, John Halley
Gotway
>> via
>> > > RT
>> > > > <
>> > > > >>> > > > >> > > met_help at ucar.edu> wrote:
>> > > > >>> > > > >> > >
>> > > > >>> > > > >> > >> Jinwoong,
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >> Thanks for sending your sample data and for
your
>> > > patience
>> > > > >>> > while I
>> > > > >>> > > > was
>> > > > >>> > > > >> > out
>> > > > >>> > > > >> > >> of town.
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >> Using met-6.0, I'm able to process the TRMM
NetCDF
>> > file
>> > > > you
>> > > > >>> > sent.
>> > > > >>> > > > >> The
>> > > > >>> > > > >> > >> trick is that I had to tell it which NetCDF
file
>> type
>> > > > >>> should be
>> > > > >>> > > > used
>> > > > >>> > > > >> to
>> > > > >>> > > > >> > >> interpret the data. Using "file_type =
>> NETCDF_NCCF;"
>> > > I'm
>> > > > >>> > telling
>> > > > >>> > > > >> MET to
>> > > > >>> > > > >> > >> interpret it as if it were a CF-compliant
NetCDF
>> > file:
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >> met-6.0/bin/plot_data_plane \
>> > > > >>> > > > >> > >> trmm_daily.20051231.7.nc
trmm_daily.20051231.7.ps
>> \
>> > > > >>> > > > >> > >> 'name="precipitation"; level="(*,*)";
>> > > > >>> file_type=NETCDF_NCCF;'
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >> DEBUG 1: Opening data file:
>> trmm_daily.20051231.7.nc
>> > > > >>> > > > >> > >> WARNING: NcCfFile::open() -> could not
determine
>> the
>> > > > valid
>> > > > >>> > time,
>> > > > >>> > > > >> using
>> > > > >>> > > > >> > 0.
>> > > > >>> > > > >> > >> WARNING: NcCfFile::open() -> could not
determine
>> the
>> > > > valid
>> > > > >>> > time,
>> > > > >>> > > > >> using
>> > > > >>> > > > >> > 0.
>> > > > >>> > > > >> > >> DEBUG 1: Creating postscript file:
>> > > > >>> trmm_daily.20051231.7.ps
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >> The plot_data_plane tool is able to read
the data,
>> > and
>> > > > I've
>> > > > >>> > > > attached
>> > > > >>> > > > >> the
>> > > > >>> > > > >> > >> resulting image. However, notice the
warning
>> > messages
>> > > > >>> about
>> > > > >>> > the
>> > > > >>> > > > >> valid
>> > > > >>> > > > >> > >> time.
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >> Using ncdump to see that file attributes, I
see
>> this
>> > > > timing
>> > > > >>> > > > >> information:
>> > > > >>> > > > >> > >> :HDF5_GLOBAL.BeginDate =
>> > "2005-12-31" ;
>> > > > >>> > > > >> > >> :HDF5_GLOBAL.BeginTime =
>> > > "01:30:00.000Z"
>> > > > ;
>> > > > >>> > > > >> > >> :HDF5_GLOBAL.EndDate =
>> "2006-01-01" ;
>> > > > >>> > > > >> > >> :HDF5_GLOBAL.EndTime =
>> > "01:29:59.999Z"
>> > > ;
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >> However that is not the CF-compliant way of
>> > specifying
>> > > > >>> timing
>> > > > >>> > > info.
>> > > > >>> > > > >> So
>> > > > >>> > > > >> > >> while MET will be able to read the data,
the
>> timing
>> > > info
>> > > > >>> won't
>> > > > >>> > be
>> > > > >>> > > > >> > accurate
>> > > > >>> > > > >> > >> in the MET output files. Instead, you'll
see
>> > > "19700101"
>> > > > >>> which
>> > > > >>> > is
>> > > > >>> > > > >> > unixtime
>> > > > >>> > > > >> > >> = 0.
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >> Another option would be pulling the binary
TRMM
>> data
>> > > and
>> > > > >>> using
>> > > > >>> > > this
>> > > > >>> > > > >> > >> Rscript
>> > > > >>> > > > >> > >> to convert the binary to NetCDF:
>> > > > >>> > > > >> > >> http://www.dtcenter.org/met/
>> > > users/downloads/Rscripts/
>> > > > >>> > > > trmmbin2nc.R
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >> However, I haven't done this in a while and
am not
>> > sure
>> > > > if
>> > > > >>> > you'll
>> > > > >>> > > > run
>> > > > >>> > > > >> > into
>> > > > >>> > > > >> > >> any issues.
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >> Hope that helps.
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >> Thanks,
>> > > > >>> > > > >> > >> John
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong
Yoo via
>> RT <
>> > > > >>> > > > >> met_help at ucar.edu>
>> > > > >>> > > > >> > >> wrote:
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >> >
>> > > > >>> > > > >> > >> > <URL: https://rt.rap.ucar.edu/rt/
>> > > > >>> > Ticket/Display.html?id=81063
>> > > > >>> > > >
>> > > > >>> > > > >> > >> >
>> > > > >>> > > > >> > >> > Hi John,
>> > > > >>> > > > >> > >> >
>> > > > >>> > > > >> > >> > Thank you very much.
>> > > > >>> > > > >> > >> > Regards,
>> > > > >>> > > > >> > >> >
>> > > > >>> > > > >> > >> > Jinwoong
>> > > > >>> > > > >> > >> >
>> > > > >>> > > > >> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John
Halley
>> Gotway
>> > > via
>> > > > >>> RT <
>> > > > >>> > > > >> > >> > met_help at ucar.edu> wrote:
>> > > > >>> > > > >> > >> >
>> > > > >>> > > > >> > >> > > Jinwoong,
>> > > > >>> > > > >> > >> > >
>> > > > >>> > > > >> > >> > > I'm out of the office today but will
take a
>> > closer
>> > > > look
>> > > > >>> > > > tomorrow.
>> > > > >>> > > > >> > >> > >
>> > > > >>> > > > >> > >> > > Thanks
>> > > > >>> > > > >> > >> > > John
>> > > > >>> > > > >> > >> > >
>> > > > >>> > > > >> > >> > > On Mon, Jul 3, 2017 at 12:20 PM
Jinwoong Yoo
>> via
>> > > RT <
>> > > > >>> > > > >> > >> met_help at ucar.edu>
>> > > > >>> > > > >> > >> > > wrote:
>> > > > >>> > > > >> > >> > >
>> > > > >>> > > > >> > >> > > >
>> > > > >>> > > > >> > >> > > > <URL: https://rt.rap.ucar.edu/rt/
>> > > > >>> > > > Ticket/Display.html?id=81063
>> > > > >>> > > > >> >
>> > > > >>> > > > >> > >> > > >
>> > > > >>> > > > >> > >> > > > Hi John,
>> > > > >>> > > > >> > >> > > >
>> > > > >>> > > > >> > >> > > > Thank you for your reply.
>> > > > >>> > > > >> > >> > > > I uploaded my data as in
Yoo_data4.tar on
>> the
>> > ftp
>> > > > >>> site.
>> > > > >>> > > > >> > >> > > > I included several files for the
message of
>> ID
>> > > of [
>> > > > >>> > > > >> > rt.rap.ucar.edu
>> > > > >>> > > > >> > >> > > #81074]
>> > > > >>> > > > >> > >> > > > as well.
>> > > > >>> > > > >> > >> > > > Thank you.
>> > > > >>> > > > >> > >> > > > Regards,
>> > > > >>> > > > >> > >> > > >
>> > > > >>> > > > >> > >> > > > Jinwoong
>> > > > >>> > > > >> > >> > > >
>> > > > >>> > > > >> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM, John
Halley
>> > > Gotway
>> > > > >>> via
>> > > > >>> > RT
>> > > > >>> > > <
>> > > > >>> > > > >> > >> > > > met_help at ucar.edu> wrote:
>> > > > >>> > > > >> > >> > > >
>> > > > >>> > > > >> > >> > > > > Jinwoong,
>> > > > >>> > > > >> > >> > > > >
>> > > > >>> > > > >> > >> > > > > I see that you're having trouble
reading a
>> > TRMM
>> > > > >>> NetCDF
>> > > > >>> > > file
>> > > > >>> > > > >> into
>> > > > >>> > > > >> > >> MET.
>> > > > >>> > > > >> > >> > > > Can
>> > > > >>> > > > >> > >> > > > > you please post the problematic
file to
>> our
>> > > > >>> anonymous
>> > > > >>> > ftp
>> > > > >>> > > > >> site
>> > > > >>> > > > >> > so
>> > > > >>> > > > >> > >> I
>> > > > >>> > > > >> > >> > can
>> > > > >>> > > > >> > >> > > > > take a look?
>> > > > >>> > > > >> > >> > > > >
>> > > > >>> > > > >> > >> > > > > http://www.dtcenter.org/met/
>> > > > >>> > > users/support/met_help.php#ftp
>> > > > >>> > > > >> > >> > > > >
>> > > > >>> > > > >> > >> > > > > Thanks,
>> > > > >>> > > > >> > >> > > > > John Halley Gotway
>> > > > >>> > > > >> > >> > > > >
>> > > > >>> > > > >> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM,
Jinwoong
>> Yoo
>> > > via
>> > > > >>> RT <
>> > > > >>> > > > >> > >> > met_help at ucar.edu
>> > > > >>> > > > >> > >> > > >
>> > > > >>> > > > >> > >> > > > > wrote:
>> > > > >>> > > > >> > >> > > > >
>> > > > >>> > > > >> > >> > > > > >
>> > > > >>> > > > >> > >> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Tic
>> > > > >>> > > > >> ket/Display.html?id=81063
>> > > > >>> > > > >> > >
>> > > > >>> > > > >> > >> > > > > >
>> > > > >>> > > > >> > >> > > > > > Hi,
>> > > > >>> > > > >> > >> > > > > >
>> > > > >>> > > > >> > >> > > > > > TRMM data comes in as netCDF-4
classic
>> > model.
>> > > > >>> > > > >> > >> > > > > > I changed it to netCDF classic
and run
>> the
>> > > same
>> > > > >>> > command
>> > > > >>> > > > >> for a
>> > > > >>> > > > >> > >> test.
>> > > > >>> > > > >> > >> > > > > > But I got the same error as
below.
>> > > > >>> > > > >> > >> > > > > >
>> > > > >>> > > > >> > >> > > > > > yoo108 at halstead-fe00:*/scratch
>> > > > >>> /halstead/y/yoo108/
>> > > > >>> > TRMM*
>> > > > >>> > > $
>> > > > >>> > > > >> > >> > > > > > ~/met-
6.0_bugfix/bin/regrid_data_plane
>> > > > >>> > > > >> > >> /scratch/halstead/y/yoo108/
>> > > > >>> > > > >> > >> > > TRMM/
>> > > > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
>> > > > >>> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/ND_
>> > > > >>> grided_obs/daily_T2m_
>> > > > >>> > > > >> > >> > > maxminmean_1976.nc
>> > > > >>> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/TRMM/
>> > > > >>> > regrid_trmm_sample.nc
>> > > > >>> > > > >> -field
>> > > > >>> > > > >> > >> > > > > > 'name="precipitation";'
>> > > > >>> > > > >> > >> > > > > >
>> > > > >>> > > > >> > >> > > > > > DEBUG 1: Reading data file:
>> > > > >>> > > > /scratch/halstead/y/yoo108/TRM
>> > > > >>> > > > >> M/
>> > > > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
>> > > > >>> > > > >> > >> > > > > >
>> > > > >>> > > > >> > >> > > > > > ERROR :
>> > > > >>> > > > >> > >> > > > > >
>> > > > >>> > > > >> > >> > > > > > ERROR : process_data_file() ->
>> > > > >>> > > > >> "/scratch/halstead/y/yoo108/TR
>> > > > >>> > > > >> > >> MM/
>> > > > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc" not
a
>> valid
>> > > data
>> > > > >>> file
>> > > > >>> > > > >> > >> > > > > >
>> > > > >>> > > > >> > >> > > > > > Thank you.
>> > > > >>> > > > >> > >> > > > > >
>> > > > >>> > > > >> > >> > > > > > Regards,
>> > > > >>> > > > >> > >> > > > > >
>> > > > >>> > > > >> > >> > > > > >
>> > > > >>> > > > >> > >> > > > > > Jinwoong
>> > > > >>> > > > >> > >> > > > > >
>> > > > >>> > > > >> > >> > > > > > On Mon, Jul 3, 2017 at 11:41 AM,
>> Jinwoong
>> > > Yoo <
>> > > > >>> > > > >> > >> > > jinwoong.yoo at gmail.com>
>> > > > >>> > > > >> > >> > > > > > wrote:
>> > > > >>> > > > >> > >> > > > > >
>> > > > >>> > > > >> > >> > > > > > > Hi,
>> > > > >>> > > > >> > >> > > > > > >
>> > > > >>> > > > >> > >> > > > > > > I noticed that TRMM data
dimension was
>> > > (lon,
>> > > > >>> lat).
>> > > > >>> > > > >> > >> > > > > > > So I switched their order to
(lat,
>> lon)
>> > and
>> > > > >>> ran the
>> > > > >>> > > > >> command
>> > > > >>> > > > >> > >> > again.
>> > > > >>> > > > >> > >> > > > > > > However, I got the same error
message
>> as
>> > > > below.
>> > > > >>> > > > >> > >> > > > > > >
>> > > > >>> > > > >> > >> > > > > > > yoo108 at halstead-fe00:*/scratch
>> > > > >>> /halstead/y/yoo108/
>> > > > >>> > > TRMM*
>> > > > >>> > > > $
>> > > > >>> > > > >> > >> > > > > > > ~/met-6.0_bugfix/bin/regrid_da
>> ta_plane
>> > > > >>> > > > >> > >> > /scratch/halstead/y/yoo108/
>> > > > >>> > > > >> > >> > > > > TRMM/
>> > > > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
>> > > > >>> > > > /scratch/halstead/y/yoo108/ND_
>> > > > >>> > > > >> > >> > > > > > > grided_obs/daily_T2m_maxminmea
>> n_1976.nc
>> > > > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
>> > > > >>> > > > >> > >> > > > > TRMM/
>> > > > >>> > > > >> > >> > > > > > > regrid_trmm_sample.nc -field
>> > > > >>> > 'name="precipitation";'
>> > > > >>> > > > >> > >> > > > > > >
>> > > > >>> > > > >> > >> > > > > > > DEBUG 1: Reading data file:
>> > > > >>> > > > >> /scratch/halstead/y/yoo108/TRM
>> > > > >>> > > > >> > M/
>> > > > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
>> > > > >>> > > > >> > >> > > > > > >
>> > > > >>> > > > >> > >> > > > > > > ERROR :
>> > > > >>> > > > >> > >> > > > > > >
>> > > > >>> > > > >> > >> > > > > > > ERROR : process_data_file() ->
>> > > > >>> > > > >> > "/scratch/halstead/y/yoo108/TR
>> > > > >>> > > > >> > >> > MM/
>> > > > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc" not a
valid
>> > data
>> > > > >>> file
>> > > > >>> > > > >> > >> > > > > > >
>> > > > >>> > > > >> > >> > > > > > >
>> > > > >>> > > > >> > >> > > > > > > Thank you.
>> > > > >>> > > > >> > >> > > > > > >
>> > > > >>> > > > >> > >> > > > > > > Regards,
>> > > > >>> > > > >> > >> > > > > > >
>> > > > >>> > > > >> > >> > > > > > >
>> > > > >>> > > > >> > >> > > > > > > Jinwoong
>> > > > >>> > > > >> > >> > > > > > >
>> > > > >>> > > > >> > >> > > > > > >
>> > > > >>> > > > >> > >> > > > > > >
>> > > > >>> > > > >> > >> > > > > > > On Thu, Jun 29, 2017 at 4:36
PM,
>> Jinwoong
>> > > > Yoo <
>> > > > >>> > > > >> > >> > > > jinwoong.yoo at gmail.com>
>> > > > >>> > > > >> > >> > > > > > > wrote:
>> > > > >>> > > > >> > >> > > > > > >
>> > > > >>> > > > >> > >> > > > > > >> Hi,
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> I got a similar result with a
TRMM
>> data.
>> > > > >>> > > > >> > >> > > > > > >> Please see below:
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/scratch
>> > > > >>> /halstead/y/yoo108/
>> > > > >>> > > > TRMM*
>> > > > >>> > > > >> $
>> > > > >>> > > > >> > >> > > > > > >> ~/met-6.0_bugfix/bin/regrid_da
>> ta_plane
>> > > > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
>> > > > >>> > > > >> > >> > > > > TRMM/
>> > > > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
>> > > > >>> > > > >> /scratch/halstead/y/yoo108/ND_
>> > > > >>> > > > >> > >> > > > > > >> grided_obs/daily_T2m_maxminmea
>> n_1976.nc
>> > > > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
>> > > > >>> > > > >> > >> > > > > > TRMM/
>> > > > >>> > > > >> > >> > > > > > >> regrid_trmm_sample.nc -field
>> > > > >>> > > 'name="precipitation";'
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> DEBUG 1: Reading data file:
>> > > > >>> > > > >> /scratch/halstead/y/yoo108/TRM
>> > > > >>> > > > >> > M/
>> > > > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> ERROR : process_data_file()
->
>> > > > >>> > > > >> > >> "/scratch/halstead/y/yoo108/TR
>> > > > >>> > > > >> > >> > MM/
>> > > > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc"
not a
>> valid
>> > > > data
>> > > > >>> file
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> A part of ncdump output for
the TRMM
>> > data
>> > > is
>> > > > >>> > pasted
>> > > > >>> > > > >> below:
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> yoo108 at halstead-fe01:*/scratch
>> > > > >>> /halstead/y/yoo108/
>> > > > >>> > > > TRMM*
>> > > > >>> > > > >> $
>> > > > >>> > > > >> > >> ncdump
>> > > > >>> > > > >> > >> > > -h
>> > > > >>> > > > >> > >> > > > > > >> subset_200003-200512/3B42RT_
>> > > > >>> > > Daily.20051231.7.nc4.nc4
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> netcdf
\3B42RT_Daily.20051231.7.nc4 {
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> dimensions:
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> lon = 59 ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> lat = 58 ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> variables:
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> short precipitation_cnt(lon,
lat) ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> precipitation_cnt:units =
"count" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> precipitation_cnt:long_name =
"Count
>> of
>> > > > valid
>> > > > >>> 3-hr
>> > > > >>> > > > >> > >> precipitation
>> > > > >>> > > > >> > >> > > > > > >> retrievals for the day" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> precipitation_cnt:coordinates
= "lat
>> > lon"
>> > > ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> precipitation_cnt:origname =
>> > > > >>> "precipitation_cnt" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> precipitation_cnt:fullnamepath
=
>> > > > >>> > > "/precipitation_cnt"
>> > > > >>> > > > ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> float uncal_precipitation(lon,
lat) ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation:units =
"mm" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation:long_name
=
>> "Daily
>> > > > >>> accumulated
>> > > > >>> > > > >> > >> uncalibrated
>> > > > >>> > > > >> > >> > > > > > >> precipitation" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation:coordinates =
>> "lat
>> > > > lon" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation:_FillValue
=
>> > -9999.9f
>> > > ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation:origname =
>> > > > >>> > > "uncal_precipitation" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation:fullnamepath =
>> > > > >>> > > > >> "/uncal_precipitation"
>> > > > >>> > > > >> > ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> short
uncal_precipitation_cnt(lon,
>> lat)
>> > ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:units
=
>> "count"
>> > ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:long_name =
>> > > "Count
>> > > > of
>> > > > >>> > valid
>> > > > >>> > > > >> 3-hr
>> > > > >>> > > > >> > >> uncal
>> > > > >>> > > > >> > >> > > > > > >> precipitation retrievals for
the
>> day" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:coordinates
>> =
>> > > "lat
>> > > > >>> lon" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:origname =
>> > > > >>> > > > >> > >> "uncal_precipitation_cnt" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:fullnamepath
>> =
>> > > > >>> > > > >> > >> > > "/uncal_precipitation_cnt" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> float precipitation(lon, lat)
;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> precipitation:units = "mm" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> precipitation:long_name =
"Daily
>> > > accumulated
>> > > > >>> > > > >> precipitation
>> > > > >>> > > > >> > >> > > (combined
>> > > > >>> > > > >> > >> > > > > > >> microwave-IR) estimate" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> precipitation:coordinates =
"lat
>> lon" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> precipitation:_FillValue =
-9999.9f ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> precipitation:origname =
>> > "precipitation" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> precipitation:fullnamepath =
>> > > > "/precipitation"
>> > > > >>> ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> short randomError_cnt(lon,
lat) ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:units =
"count" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:long_name =
"Count of
>> > > > >>> randomError
>> > > > >>> > > for
>> > > > >>> > > > >> the
>> > > > >>> > > > >> > >> day" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:coordinates =
"lat
>> lon"
>> > ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:origname =
>> > > > "randomError_cnt" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:fullnamepath =
>> > > > >>> "/randomError_cnt"
>> > > > >>> > ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> float randomError(lon, lat) ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> randomError:units = "mm" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> randomError:long_name = "Daily
total
>> > error
>> > > > of
>> > > > >>> > > combined
>> > > > >>> > > > >> > >> > > microwave-IR
>> > > > >>> > > > >> > >> > > > > > >> precipitation estimate" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> randomError:_FillValue =
-9999.9f ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> randomError:origname =
"randomError"
>> ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> randomError:fullnamepath =
>> > "/randomError"
>> > > ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> float lat(lat) ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> lat:units = "degrees_north" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> lat:long_name = "Latitude" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> lat:origname = "lat" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> lat:fullnamepath = "/lat" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> float lon(lon) ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> lon:units = "degrees_east" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> lon:long_name = "Longitude" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> lon:origname = "lon" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> lon:fullnamepath = "/lon" ;
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> Thank you.
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> Regards,
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> Jinwoong
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >> On Thu, Jun 29, 2017 at 3:11
PM,
>> > > > >>> > met_help at ucar.edu
>> > > > >>> > > > via
>> > > > >>> > > > >> RT
>> > > > >>> > > > >> > <
>> > > > >>> > > > >> > >> > > > > > >> met_help at ucar.edu> wrote:
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >>> NOTE: THE MET TEAM HAS
LIMITED
>> > > AVAILABILITY
>> > > > >>> > BETWEEN
>> > > > >>> > > > >> > 5/23/17
>> > > > >>> > > > >> > >> AND
>> > > > >>> > > > >> > >> > > > > > >>> 5/30/17. RESPONSES MAY BE
DELAYED.
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> Greetings,
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> This message has been
automatically
>> > > > >>> generated in
>> > > > >>> > > > >> response
>> > > > >>> > > > >> > to
>> > > > >>> > > > >> > >> > the
>> > > > >>> > > > >> > >> > > > > > >>> creation of a trouble ticket
>> regarding:
>> > > > >>> > > > >> > >> > > > > > >>> "regrid_data_plane:
not a
>> valid
>> > > > data
>> > > > >>> > file",
>> > > > >>> > > > >> > >> > > > > > >>> a summary of which appears
below.
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> There is no need to reply to
this
>> > message
>> > > > >>> right
>> > > > >>> > > now.
>> > > > >>> > > > >> Your
>> > > > >>> > > > >> > >> > ticket
>> > > > >>> > > > >> > >> > > > has
>> > > > >>> > > > >> > >> > > > > > >>> been
>> > > > >>> > > > >> > >> > > > > > >>> assigned an ID of
[rt.rap.ucar.edu
>> > > > #81063].
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> Please include the string:
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> [rt.rap.ucar.edu
#81063]
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> in the subject line of all
future
>> > > > >>> correspondence
>> > > > >>> > > > about
>> > > > >>> > > > >> > this
>> > > > >>> > > > >> > >> > > issue.
>> > > > >>> > > > >> > >> > > > To
>> > > > >>> > > > >> > >> > > > > > do
>> > > > >>> > > > >> > >> > > > > > >>> so,
>> > > > >>> > > > >> > >> > > > > > >>> you may reply to this
message.
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> Thank
you,
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > met_help at ucar.edu
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>>
------------------------------
>> > > > >>> > > > >> > >> ------------------------------
>> > > > >>> > > > >> > >> > > > > > >>> -------------
>> > > > >>> > > > >> > >> > > > > > >>> Hi,
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> I am trying to regrid one of
my
>> > > observation
>> > > > >>> files
>> > > > >>> > > in
>> > > > >>> > > > >> lat
>> > > > >>> > > > >> > lon
>> > > > >>> > > > >> > >> > > > > coordinate
>> > > > >>> > > > >> > >> > > > > > >>> grid to WRF curvilinear grid.
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> I ran bin/regrid_data_plane
using a
>> > > sample
>> > > > >>> lat
>> > > > >>> > lon
>> > > > >>> > > > grid
>> > > > >>> > > > >> > file
>> > > > >>> > > > >> > >> > and
>> > > > >>> > > > >> > >> > > a
>> > > > >>> > > > >> > >> > > > > file
>> > > > >>> > > > >> > >> > > > > > >>> in
>> > > > >>> > > > >> > >> > > > > > >>> the WRF grid. But I got error
as
>> shown
>> > > > below:
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> yoo108 at halstead-
fe00:*/scratch
>> > > > >>> > > > >> > /halstead/y/yoo108/ND_grided_
>> > > > >>> > > > >> > >> > obs*
>> > > > >>> > > > >> > >> > > $
>> > > > >>> > > > >> > >> > > > > > >>> ~/met-
6.0_bugfix/bin/regrid_da
>> ta_plane
>> > > > >>> > > > >> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_
>> > > grided_obs/
>> > > > >>> > > > >> sample_tmax.nc
>> > > > >>> > > > >> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_
>> > > > >>> > > grided_obs/daily_T2m_
>> > > > >>> > > > >> > >> > > > > maxminmean_1976.nc
>> > > > >>> > > > >> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_
>> > > > >>> > > > >> > >> grided_obs/NDtoWRFgrid_sample_
>> > > > >>> > > > >> > >> > > > tmax.nc
>> > > > >>> > > > >> > >> > > > > > >>> -field
>> > > > >>> > > > >> > >> > > > > > >>> 'name="tmax";'
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> DEBUG 1: Reading data file:
>> > > > >>> > > > >> /scratch/halstead/y/yoo108/ND_
>> > > > >>> > > > >> > >> > > > > grided_obs/
>> > > > >>> > > > >> > >> > > > > > >>> sample_tmax.nc
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> ERROR : process_data_file()
->
>> > > > >>> > > > >> > >> "/scratch/halstead/y/yoo108/ND
>> > > > >>> > > > >> > >> > > > > > >>> _grided_obs/
>> > > > >>> > > > >> > >> > > > > > >>> sample_tmax.nc" not a valid
data
>> file
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> I wonder which part of the
input
>> file
>> > > does
>> > > > >>> not
>> > > > >>> > > > satisfy
>> > > > >>> > > > >> the
>> > > > >>> > > > >> > >> > MET's
>> > > > >>> > > > >> > >> > > > > "valid
>> > > > >>> > > > >> > >> > > > > > >>> file" criteria.
>> > > > >>> > > > >> > >> > > > > > >>> ncdump output of the input
file
>> looks
>> > as
>> > > > >>> below:
>> > > > >>> > > > >> > >> > > > > > >>> Input file was originally
generated
>> by
>> > > VIC
>> > > > >>> model
>> > > > >>> > > and
>> > > > >>> > > > >> > >> converted
>> > > > >>> > > > >> > >> > > into
>> > > > >>> > > > >> > >> > > > > cf
>> > > > >>> > > > >> > >> > > > > > >>> netcdf format.
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> Thank you in advance.
>> > > > >>> > > > >> > >> > > > > > >>> Regards,
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> Jinwoong
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> yoo108 at halstead-
fe00:*/scratch
>> > > > >>> > > > >> > /halstead/y/yoo108/ND_grided_
>> > > > >>> > > > >> > >> > obs*
>> > > > >>> > > > >> > >> > > $
>> > > > >>> > > > >> > >> > > > > > >>> ncdump -h
>> > > > >>> > > > >> > >> > > > > > >>> sample_tmax.nc
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> netcdf sample_tmax {
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> dimensions:
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> T = 1 ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> X = 55 ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> Y = 65 ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> variables:
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> double T(T) ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> T:units = "days since 1915-
01-01" ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> T:long_name = "Time" ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> double X(X) ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> X:units = "degrees_east" ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> X:long_name = "Longitude" ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> double Y(Y) ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> Y:units = "degrees_north" ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> Y:long_name = "Latitude" ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> double tmax(T, Y, X) ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> tmax:units = "degC" ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> tmax:long_name = "tmax
calculated by
>> > > VIC" ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> tmax:missing_value = -9999.f
;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> // global attributes:
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>> :production = "VIC output" ;
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>>
>> > > > >>> > > > >> > >> > > > > > >>
>> > > > >>> > > > >> > >> > > > > > >
>> > > > >>> > > > >> > >> > > > > >
>> > > > >>> > > > >> > >> > > > > >
>> > > > >>> > > > >> > >> > > > >
>> > > > >>> > > > >> > >> > > > >
>> > > > >>> > > > >> > >> > > >
>> > > > >>> > > > >> > >> > > >
>> > > > >>> > > > >> > >> > >
>> > > > >>> > > > >> > >> > >
>> > > > >>> > > > >> > >> >
>> > > > >>> > > > >> > >> >
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >>
>> > > > >>> > > > >> > >
>> > > > >>> > > > >> >
>> > > > >>> > > > >> >
>> > > > >>> > > > >>
>> > > > >>> > > > >>
>> > > > >>> > > > >
>> > > > >>> > > >
>> > > > >>> > > >
>> > > > >>> > >
>> > > > >>> > >
>> > > > >>> >
>> > > > >>> >
>> > > > >>>
>> > > > >>>
>> > > > >>
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: John Halley Gotway
Time: Fri Jul 14 09:49:51 2017
Jinwoong,
I'd like to make sure I'm testing with the exact same file you're
using.
Could you please post this file to our anonymous ftp site:
/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
00.nc
Following these instructions:
http://www.dtcenter.org/met/users/support/met_help.php#ftp
Once I get it, I'll plot it just like you did and then try to run it
through Grid-Stat.
Thanks,
John
On Thu, Jul 13, 2017 at 11:35 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>
> Hi John,
>
> I wonder if you had a chance to take a look at the issue regarding
how to
> make grid_stat read in netcdf file that has WRF coordinate grid
info?
> Please let me know.
> Thank you.
>
> Regards,
>
> Jinwoong
>
> On Wed, Jul 12, 2017 at 3:05 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> wrote:
>
> > Hi John,
> > As I noted in the previous messages,
> > I was able to plot netcdf files by copying global attributes from
WRF
> > output to the netcdf files in the same coordinate grids.
> >
> > yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal* $
> > ~/met-6.0_bugfix/bin/plot_data_plane
/scratch/halstead/y/yoo108/NCA
> > R_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc
> met_em.d03.2005-12-31_18:00:
> > 00.ps 'name="TT";level="(0,0,*,*)";file_type = NETCDF_PINT;'
> >
> > DEBUG 1: Opening data file: /scratch/halstead/y/yoo108/NCA
> > R_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc
> >
> > DEBUG 1: Creating postscript file: met_em.d03.2005-12-
31_18:00:00.ps
> >
> > However, when 'file_typ=NETCDF_PINT;' was not provided in the
> > plot_data_plane command, it failed.
> >
> > yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal* $
> > ~/met-6.0_bugfix/bin/plot_data_plane
/scratch/halstead/y/yoo108/NCA
> > R_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc
> met_em.d03.2005-12-31_18:00:
> > 00.ps 'name="TT";level="(0,0,*,*)";'
> >
> > DEBUG 1: Opening data file: /scratch/halstead/y/yoo108/NCA
> > R_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc
> >
> > ERROR : plot_data_plane -> file "/scratch/halstead/y/yoo108/NC
> > AR_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc" not a valid data
file
> >
> > Thing is that I don't know where to put the argument (
> > 'file_typ=NETCDF_PINT;') in the grid_stat.
> >
> > I tried both in config file and command line but both failed.
> >
> >
> > Thank you.
> >
> >
> > Regards,
> >
> >
> > Jinwoong
> >
> >
> >
> > On Wed, Jul 12, 2017 at 2:59 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Jinwoong,
> >>
> >> OK, sorry for the confusion. Honestly, I don't know how you're
getting
> >> plot_data_plane to work at all. When I run it using the sample
data
> file
> >> you sent me (met_em.d03.2005-01-01_00:00:00.nc), it doesn't work:
> >>
> >> met-6.0/bin/plot_data_plane met_em.d03.2005-01-01_00:00:00.nc
test.ps \
> >> 'name="TT"; level="(0,0,*,*)"; file_type = NETCDF_PINT;'
> >> DEBUG 1: Opening data file: met_em.d03.2005-01-01_00:00:00.nc
> >> ERROR :
> >> ERROR : MetNcPinterpDataFile::open(const char *) -> unable to
open
> >> NetCDF
> >> file "met_em.d03.2005-01-01_00:00:00.nc"
> >> ERROR :
> >> ERROR :
> >> ERROR : Met2dDataFileFactory::new_met_2d_data_file() -> error
opening
> >> file
> >> "met_em.d03.2005-01-01_00:00:00.nc"
> >> ERROR :
> >>
> >> There must be something different between the sample file you
sent and
> the
> >> one you're actually using:
> >> /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> 2005-12-31_18:00:
> >> 00.nc
> >>
> >> John
> >>
> >> On Wed, Jul 12, 2017 at 12:46 PM, Jinwoong Yoo via RT <
> met_help at ucar.edu>
> >> wrote:
> >>
> >> >
> >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >> >
> >> > Hi John,
> >> >
> >> > I am still experiencing troubles to read in netcdf files for
grid_stat
> >> > command.
> >> > Please read the last two previous emails that I sent.
> >> > Thank you very much.
> >> >
> >> > Regards,
> >> >
> >> > Jinwoong
> >> >
> >> > On Wed, Jul 12, 2017 at 1:44 PM, John Halley Gotway via RT <
> >> > met_help at ucar.edu> wrote:
> >> >
> >> > > Great, glad you were able to get it working.
> >> > >
> >> > > Thanks,
> >> > > John
> >> > >
> >> > > On Tue, Jul 11, 2017 at 9:44 AM, Jinwoong Yoo via RT <
> >> met_help at ucar.edu>
> >> > > wrote:
> >> > >
> >> > > >
> >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >> > > >
> >> > > > Hi John,
> >> > > >
> >> > > > Even with the plot_data_plane command,
> >> > > > I noticed that "file_type = NETCDF_PINT;" argument should
be
> >> provided
> >> > in
> >> > > > the command line.
> >> > > > Otherwise, it fails. Please see below.
> >> > > >
> >> > > > yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis
> >> /METanal*
> >> > $
> >> > > > ~/met-6.0_bugfix/bin/plot_data_plane
> >> > > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-
> >> 12-31_18:00:
> >> > > > 00.nc
> >> > > > met_em.d03.2005-12-31_18:00:00.ps
'name="TT";level="(0,0,*,*)";'
> >> > > >
> >> > > > DEBUG 1: Opening data file:
> >> > > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-
> >> 12-31_18:00:
> >> > > > 00.nc
> >> > > >
> >> > > > ERROR : plot_data_plane -> file
> >> > > > "/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> >> > 2005-12-31_18:00:
> >> > > > 00.nc"
> >> > > > not a valid data file
> >> > > >
> >> > > >
> >> > > >
> >> > > > yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis
> >> /METanal*
> >> > $
> >> > > > ~/met-6.0_bugfix/bin/plot_data_plane
> >> > > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-
> >> 12-31_18:00:
> >> > > > 00.nc
> >> > > > met_em.d03.2005-12-31_18:00:00.ps
'name="TT";level="(0,0,*,*)";
> >> > file_type
> >> > > =
> >> > > > NETCDF_PINT;'
> >> > > >
> >> > > > DEBUG 1: Opening data file:
> >> > > > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-
> >> 12-31_18:00:
> >> > > > 00.nc
> >> > > >
> >> > > > DEBUG 1: Creating postscript file: met_em.d03.2005-12-
31_18:00:00
> >> .ps
> >> > > >
> >> > > >
> >> > > >
> >> > > > Thank you.
> >> > > >
> >> > > > Regards,
> >> > > >
> >> > > >
> >> > > > Jinwoong
> >> > > >
> >> > > >
> >> > > > On Tue, Jul 11, 2017 at 11:12 AM, Jinwoong Yoo <
> >> jinwoong.yoo at gmail.com
> >> > >
> >> > > > wrote:
> >> > > >
> >> > > > > Hi John,
> >> > > > >
> >> > > > > Now I am trying to execute grid_stat against these netcdf
files
> >> that
> >> > > have
> >> > > > > been patted with the WRF global attributes.
> >> > > > >
> >> > > > > I tried to include 'file_type = NETCDF_PINT;' argument
both in
> its
> >> > > > > configuration file and in the command line.
> >> > > > > However, both failed to run (Please see below).
> >> > > > >
> >> > > > > Could you please guide me how to specify the netcdf file
type in
> >> the
> >> > > > > grid_stat application?
> >> > > > > Thank you.
> >> > > > >
> >> > > > > Regards,
> >> > > > >
> >> > > > > Jinwoong
> >> > > > >
> >> > > > >
> >> > > > > 1.
> >> > > > >
> >> > > > > .......
> >> > > > >
> >> > > > > obs = {
> >> > > > >
> >> > > > >
> >> > > > > field = [
> >> > > > >
> >> > > > > {
> >> > > > >
> >> > > > > name = "TT";
> >> > > > >
> >> > > > > level = [ "(0,0,*,*)" ];
> >> > > > >
> >> > > > > file_type = NETCDF_PINT;
> >> > > > >
> >> > > > > cat_thresh = [];
> >> > > > >
> >> > > > > }
> >> > > > >
> >> > > > > .......
> >> > > > >
> >> > > > > DEBUG 1: Default Config File: /home/yoo108/met-
6.0_bugfix/
> >> > > > > share/met/config/GridStatConfig_default
> >> > > > >
> >> > > > > DEBUG 1: User Config File: /scratch/halstead/y/yoo108/
> >> > > > wrfAnalysis/METanal/
> >> > > > > GridStatConfig_met_em
> >> > > > >
> >> > > > > DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() ->
> created
> >> new
> >> > > > > Met2dDataFile object of type "FileType_Gb2".
> >> > > > >
> >> > > > > DEBUG 4: Switching the GRIB2 radius of the earth value of
> 6371.23
> >> km
> >> > to
> >> > > > > 6371.2 km for internal consistency.
> >> > > > >
> >> > > > > DEBUG 4:
> >> > > > >
> >> > > > > DEBUG 4: Lambert Conformal Grid Data:
> >> > > > >
> >> > > > > DEBUG 4: scale_lat_1: 48
> >> > > > >
> >> > > > > DEBUG 4: scale_lat_2: 32
> >> > > > >
> >> > > > > DEBUG 4: lat_pin: 36.9132
> >> > > > >
> >> > > > > DEBUG 4: lon_pin: 92.0748
> >> > > > >
> >> > > > > DEBUG 4: x_pin: 0
> >> > > > >
> >> > > > > DEBUG 4: y_pin: 0
> >> > > > >
> >> > > > > DEBUG 4: lon_orient: 97
> >> > > > >
> >> > > > > DEBUG 4: d_km: 4
> >> > > > >
> >> > > > > DEBUG 4: r_km: 6371.2
> >> > > > >
> >> > > > > DEBUG 4: nx: 189
> >> > > > >
> >> > > > > DEBUG 4: ny: 270
> >> > > > >
> >> > > > > DEBUG 4:
> >> > > > >
> >> > > > > DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() ->
> created
> >> new
> >> > > > > Met2dDataFile object of type "FileType_None".
> >> > > > >
> >> > > > > ERROR :
> >> > > > >
> >> > > > > ERROR : Trouble reading observation file
> >> > "/scratch/halstead/y/yoo108/
> >> > > > > NCAR_BC_met_em/met_em.d03.1980-01-01_00:00:00.nc"
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > 2.
> >> > > > >
> >> > > > > /home/yoo108/met-6.0_bugfix/bin/grid_stat
> >> > > $dir_data/$yyyy/$yyyy$nummon/$
> >> > > > > grib_date1 $dir_data2/$met_em_date1
$analDir/$GridStatConfig
> >> > > 'file_type =
> >> > > > > NETCDF_PINT;' -outdir $workDir -v 4
> >> > > > >
> >> > > > > *** Model Evaluation Tools (METV6.0) ***
> >> > > > >
> >> > > > >
> >> > > > > Usage: grid_stat
> >> > > > >
> >> > > > > fcst_file
> >> > > > >
> >> > > > > obs_file
> >> > > > >
> >> > > > > config_file
> >> > > > >
> >> > > > > [-outdir path]
> >> > > > >
> >> > > > > [-log file]
> >> > > > >
> >> > > > > [-v level]
> >> > > > >
> >> > > > > [-compress level]
> >> > > > >
> >> > > > >
> >> > > > > where "fcst_file" is a gridded forecast file containing
the
> >> field(s)
> >> > to
> >> > > > > be verified (required).
> >> > > > >
> >> > > > > "obs_file" is a gridded observation file containing the
> verifying
> >> > > > field(s)
> >> > > > > (required).
> >> > > > >
> >> > > > > "config_file" is a GridStatConfig file containing the
desired
> >> > > > > configuration settings (required).
> >> > > > >
> >> > > > > "-outdir path" overrides the default output directory
> >> > > > >
(/scratch/halstead/y/yoo108/wrfAnalysis/METanal/wrf2met_em)
> >> > > (optional).
> >> > > > >
> >> > > > > "-log file" outputs log messages to the specified file
> (optional).
> >> > > > >
> >> > > > > "-v level" overrides the default level of logging (4)
> (optional).
> >> > > > >
> >> > > > > "-compress level" overrides the compression level of
NetCDF
> >> variable
> >> > > (0)
> >> > > > > (optional).
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > On Mon, Jul 10, 2017 at 4:53 PM, Jinwoong Yoo <
> >> > jinwoong.yoo at gmail.com>
> >> > > > > wrote:
> >> > > > >
> >> > > > >> Hi John,
> >> > > > >>
> >> > > > >> I was able to open netcdf files that share the same
coordinates
> >> with
> >> > > WRF
> >> > > > >> output by copying the global attribute of the WRF output
to
> these
> >> > > netcdf
> >> > > > >> files:
> >> > > > >>
> >> > > > >> ncks -A -x wrfout.nc target.nc
> >> > > > >>
> >> > > > >> This enabled me to open netcdf files in MET using
> >> > > > >> 'name="TT";level="(0,0,*,*)";file_type = NETCDF_PINT;'
> argument.
> >> > > > >>
> >> > > > >> Thank you very much!
> >> > > > >> Regards,
> >> > > > >>
> >> > > > >> Jinwoong
> >> > > > >>
> >> > > > >> On Mon, Jul 10, 2017 at 3:04 PM, John Halley Gotway via
RT <
> >> > > > >> met_help at ucar.edu> wrote:
> >> > > > >>
> >> > > > >>> Jinwoong,
> >> > > > >>>
> >> > > > >>> I tried running the sample file
(daily_T2m_maxminmean_1981.nc)
> >> > > through
> >> > > > >>> plot_data_plane and saw the same behavior you did.
Looking
> >> closely
> >> > > at
> >> > > > >>> that
> >> > > > >>> file I see that is not the NetCDF output generated by
WRF.
> The
> >> > > history
> >> > > > >>> attribute indicates that it was created by the "ncks"
utility:
> >> > > > >>>
> >> > > > >>> :history = "Sun Jul 2 15:47:18 2017: ncks -d days,0,0
> >> > > > >>>
/scratch/halstead/k/khoogewi/CCRC_wrf/analysis/T2m/daily_T2m_
> >> > > > >>> maxminmean_1981.nc
> >> > > > >>>
/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_maxminm
> >> > > > >>> ean_19810101.nc"
> >> > > > >>>
> >> > > > >>>
> >> > > > >>> This is not a CF-compliant NetCDF file and it does not
look
> like
> >> > the
> >> > > > >>> output
> >> > > > >>> from WRF. Another alternative is making it look like
the
> NetCDF
> >> > file
> >> > > > >>> format used by the MET tools themselves.
> >> > > > >>>
> >> > > > >>> I ran the following command to add global attributes to
define
> >> the
> >> > > grid
> >> > > > >>> spec for MET:
> >> > > > >>>
> >> > > > >>> ncatted \
> >> > > > >>> -a MET_version,global,o,c,"V6.0" \
> >> > > > >>> -a Projection,global,o,c,"Lambert Conformal" \
> >> > > > >>> -a scale_lat_1,global,o,c,"48" \
> >> > > > >>> -a scale_lat_2,global,o,c,"32" \
> >> > > > >>> -a lat_pin,global,o,c,"48" \
> >> > > > >>> -a lon_pin,global,o,c,"-97" \
> >> > > > >>> -a x_pin,global,o,c,"0" \
> >> > > > >>> -a y_pin,global,o,c,"0" \
> >> > > > >>> -a lon_orient,global,o,c,"-97" \
> >> > > > >>> -a d_km,global,o,c,"3" \
> >> > > > >>> -a r_km,global,o,c,"6371.2" \
> >> > > > >>> -a nx,global,o,c,"189" \
> >> > > > >>> -a ny,global,o,c,"270" \
> >> > > > >>> daily_T2m_maxminmean_1976.nc -o
daily_T2m_maxminmean_1976_MET.
> >> nc
> >> > > > >>>
> >> > > > >>> However, I don't think these are all correct.
Specifically, I
> >> > don't
> >> > > > know
> >> > > > >>> how the "lon_orient" should be set. So I set it to the
> >> longitude
> >> > of
> >> > > > the
> >> > > > >>> lower-left corner. Also, I don't know how the d_km
should be
> >> set.
> >> > > > >>> That's
> >> > > > >>> the grid spacing in km. So I just guess with a value
of 3.
> >> > > > >>>
> >> > > > >>> This enables MET to plot the result, but you should
work on
> >> making
> >> > > the
> >> > > > >>> grid
> >> > > > >>> info correct:
> >> > > > >>> met-6.0/bin/plot_data_plane \
> >> > > > >>> daily_T2m_maxminmean_1976_MET.nc \
> >> > > > >>> daily_T2m_maxminmean_1976_MET.ps \
> >> > > > >>> 'name="T2m_max"; level="(10,*,*)";' -v 4
> >> > > > >>>
> >> > > > >>> Thanks,
> >> > > > >>> John
> >> > > > >>>
> >> > > > >>>
> >> > > > >>>
> >> > > > >>> On Fri, Jul 7, 2017 at 5:06 PM, Jinwoong Yoo via RT <
> >> > > met_help at ucar.edu
> >> > > > >
> >> > > > >>> wrote:
> >> > > > >>>
> >> > > > >>> >
> >> > > > >>> > <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=81063
> >> >
> >> > > > >>> >
> >> > > > >>> > Hi John,
> >> > > > >>> >
> >> > > > >>> > Thank you for your comment.
> >> > > > >>> > I tried it but it failed.
> >> > > > >>> > Please see below.
> >> > > > >>> >
> >> > > > >>> > yoo108 at halstead-fe03:*/scratch/halstead/y/yoo108/
> >> > > > wrfAnalysis/METanal*
> >> > > > >>> $
> >> > > > >>> > ~/met-6.0_bugfix/bin/plot_data_plane
> >> > > > >>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> >> > > > >>> > maxminmean_20051231.nc
> >> > > > >>> > wrfDaily_T2m_maxminmean_20051231.ps
> >> > > > >>> > 'name="T2m_max";level="(0,*,*)";file_type =
NETCDF_PINT;'
> >> > > > >>> >
> >> > > > >>> > DEBUG 1: Opening data file:
> >> > > > >>> > /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> >> > > > >>> > maxminmean_20051231.nc
> >> > > > >>> >
> >> > > > >>> > ERROR : MetNcPinterpDataFile::open(const char *) ->
unable
> >> to
> >> > > open
> >> > > > >>> NetCDF
> >> > > > >>> > file
> >> > > > >>> >
"/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> >> > > > >>> > maxminmean_20051231.nc"
> >> > > > >>> >
> >> > > > >>> > ERROR : Met2dDataFileFactory::new_met_2d_data_file()
->
> >> error
> >> > > > opening
> >> > > > >>> > file
> >> > > > >>> >
"/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> >> > > > >>> > maxminmean_20051231.nc"
> >> > > > >>> >
> >> > > > >>> >
> >> > > > >>> >
> >> > > > >>> > One sample file (wrfDaily_T2m_maxminmean_19810101.nc)
is
> also
> >> > > > >>> included in
> >> > > > >>> > the Yoo_data4.tar file that I uploaded previously.
> >> > > > >>> > Thank you.
> >> > > > >>> > Haver a nice weekend.
> >> > > > >>> >
> >> > > > >>> > Regards,
> >> > > > >>> >
> >> > > > >>> > Jinwoong
> >> > > > >>> >
> >> > > > >>> >
> >> > > > >>> >
> >> > > > >>> > On Fri, Jul 7, 2017 at 6:04 PM, John Halley Gotway
via RT <
> >> > > > >>> > met_help at ucar.edu
> >> > > > >>> > > wrote:
> >> > > > >>> >
> >> > > > >>> > > Jinwoong,
> >> > > > >>> > >
> >> > > > >>> > > If they really are output from WRF, one simple
thing to
> try
> >> is
> >> > > > >>> telling
> >> > > > >>> > MET
> >> > > > >>> > > to interpret them as the NetCDF output of the
wrf_interp
> >> > utility
> >> > > > >>> > > :
> >> > > > >>> > > file_type = NETCDF_PINT;
> >> > > > >>> > >
> >> > > > >>> > > "PINT" stands for "pressure interpolated"...
pinterp was
> the
> >> > > > >>> precursor to
> >> > > > >>> > > the current wrf_interp tool.
> >> > > > >>> > >
> >> > > > >>> > > If that doesn't work, I'll need to see a sample
file
> before
> >> > > making
> >> > > > >>> any
> >> > > > >>> > > other suggestions.
> >> > > > >>> > >
> >> > > > >>> > > Thanks,
> >> > > > >>> > > John
> >> > > > >>> > >
> >> > > > >>> > >
> >> > > > >>> > >
> >> > > > >>> > > On Fri, Jul 7, 2017 at 3:36 PM, Jinwoong Yoo via RT
<
> >> > > > >>> met_help at ucar.edu>
> >> > > > >>> > > wrote:
> >> > > > >>> > >
> >> > > > >>> > > >
> >> > > > >>> > > > <URL: https://rt.rap.ucar.edu/rt/
> >> > Ticket/Display.html?id=81063
> >> > > >
> >> > > > >>> > > >
> >> > > > >>> > > > Hi John,
> >> > > > >>> > > >
> >> > > > >>> > > > I was able to read in a "home brew" netcdf data
file
> using
> >> > > > >>> > > plot_data_plane.
> >> > > > >>> > > >
> >> > > > >>> > > > Then, I went ahead and tried another netcdf file
in
> >> > curvilinear
> >> > > > >>> > > coordinate
> >> > > > >>> > > > which is in the same coordinate grid as my WRF
output.
> >> But it
> >> > > > >>> failed.
> >> > > > >>> > > >
> >> > > > >>> > > > I have many netcdf climatology files from the WRF
> >> simulation
> >> > > such
> >> > > > >>> as
> >> > > > >>> > > daily,
> >> > > > >>> > > > monthly, and annual, etc. Therefore, they are all
in
> >> > > curvilinear
> >> > > > >>> > > coordinate
> >> > > > >>> > > > (Lambert).
> >> > > > >>> > > >
> >> > > > >>> > > > I wonder if there is any work around so that I
can feed
> >> these
> >> > > > files
> >> > > > >>> > into
> >> > > > >>> > > > MET?
> >> > > > >>> > > > Or should I regrid them all into lat lon
coordinate
> files
> >> > > first?
> >> > > > >>> > > >
> >> > > > >>> > > > Thank you, John.
> >> > > > >>> > > >
> >> > > > >>> > > > Regards,
> >> > > > >>> > > >
> >> > > > >>> > > > Jinwoong Yoo
> >> > > > >>> > > >
> >> > > > >>> > > >
> >> > > > >>> > > > On Fri, Jul 7, 2017 at 3:01 PM, Jinwoong Yoo <
> >> > > > >>> jinwoong.yoo at gmail.com>
> >> > > > >>> > > > wrote:
> >> > > > >>> > > >
> >> > > > >>> > > > > Hi John,
> >> > > > >>> > > > >
> >> > > > >>> > > > > Thank you very much.
> >> > > > >>> > > > > Let me try and let you know how it goes.
> >> > > > >>> > > > > Thank you.
> >> > > > >>> > > > > Regards,
> >> > > > >>> > > > >
> >> > > > >>> > > > > Jinwoong
> >> > > > >>> > > > >
> >> > > > >>> > > > > On Fri, Jul 7, 2017 at 2:59 PM, John Halley
Gotway via
> >> RT <
> >> > > > >>> > > > > met_help at ucar.edu> wrote:
> >> > > > >>> > > > >
> >> > > > >>> > > > >> Jinwoong,
> >> > > > >>> > > > >>
> >> > > > >>> > > > >> Yes, you can give it a try. The closer you
can make
> >> the
> >> > > > NetCDF
> >> > > > >>> > files
> >> > > > >>> > > to
> >> > > > >>> > > > >> the CF-convention, the more likely MET will be
able
> to
> >> > read
> >> > > > it.
> >> > > > >>> > > > >>
> >> > > > >>> > > > >> The reason that's its able to read the TRMM
data are
> >> that
> >> > > the
> >> > > > >>> > lat/lon
> >> > > > >>> > > > >> values are equally spaced. Non-equally spaced
> lat/lon
> >> > > values
> >> > > > >>> on a
> >> > > > >>> > map
> >> > > > >>> > > > >> projection require that the map projection
> information
> >> be
> >> > > > >>> specified.
> >> > > > >>> > > > >> Unfortunately, specifying map projection
information
> in
> >> > > > >>> CF-compliant
> >> > > > >>> > > > >> NetCDF
> >> > > > >>> > > > >> files is not as easy as I think it should be!
> >> > > > >>> > > > >>
> >> > > > >>> > > > >> Hope it works out ok for you.
> >> > > > >>> > > > >>
> >> > > > >>> > > > >> Thanks,
> >> > > > >>> > > > >> John
> >> > > > >>> > > > >>
> >> > > > >>> > > > >> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong Yoo
via RT
> <
> >> > > > >>> > > met_help at ucar.edu
> >> > > > >>> > > > >
> >> > > > >>> > > > >> wrote:
> >> > > > >>> > > > >>
> >> > > > >>> > > > >> >
> >> > > > >>> > > > >> > <URL: https://rt.rap.ucar.edu/rt/
> >> > > > Ticket/Display.html?id=81063
> >> > > > >>> >
> >> > > > >>> > > > >> >
> >> > > > >>> > > > >> > investigating not investing :)
> >> > > > >>> > > > >> >
> >> > > > >>> > > > >> > Thanks!
> >> > > > >>> > > > >> > Regards,
> >> > > > >>> > > > >> >
> >> > > > >>> > > > >> > Jinwoong
> >> > > > >>> > > > >> >
> >> > > > >>> > > > >> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong Yoo
<
> >> > > > >>> > > jinwoong.yoo at gmail.com>
> >> > > > >>> > > > >> > wrote:
> >> > > > >>> > > > >> >
> >> > > > >>> > > > >> > > Hi John,
> >> > > > >>> > > > >> > >
> >> > > > >>> > > > >> > > Thank you very much for your time
investing the
> >> issue.
> >> > > > >>> > > > >> > > I am glad to hear that there is a trick to
work
> >> around
> >> > > the
> >> > > > >>> issue
> >> > > > >>> > > to
> >> > > > >>> > > > >> read
> >> > > > >>> > > > >> > > in TRMM data in netcdf format.
> >> > > > >>> > > > >> > > I wonder if I can apply the same trick (
> >> > > > >>> file_type=NETCDF_NCCF;)
> >> > > > >>> > > to
> >> > > > >>> > > > >> read
> >> > > > >>> > > > >> > > in any other observation files in netcdf
format?
> >> > > > >>> > > > >> > > In fact, I would like to read in "home
brew"
> netcdf
> >> > > > dataset
> >> > > > >>> > files
> >> > > > >>> > > > into
> >> > > > >>> > > > >> > > MET.
> >> > > > >>> > > > >> > > One sample file of them was included in
the
> >> uploaded
> >> > > data
> >> > > > >>> > folder (
> >> > > > >>> > > > >> > > sample_tmax.nc).
> >> > > > >>> > > > >> > > The data in this sample file was
originally
> >> generated
> >> > by
> >> > > > VIC
> >> > > > >>> > > model.
> >> > > > >>> > > > >> > > Then the file format was converted into a
generic
> >> > netcdf
> >> > > > >>> file
> >> > > > >>> > > format
> >> > > > >>> > > > >> > > although the dimension names are T, X, Y
not
> time,
> >> > lat,
> >> > > > lon.
> >> > > > >>> > > > >> > > But their coordinates have units in
> "degrees_east"
> >> or
> >> > > > >>> > > > "degrees_north"
> >> > > > >>> > > > >> as
> >> > > > >>> > > > >> > > well as their long_name as "Longitude" and
> >> "Latitude",
> >> > > > >>> > > respectively.
> >> > > > >>> > > > >> > >
> >> > > > >>> > > > >> > > Of course, I will try to read those in for
> >> Grid-stat
> >> > > > today.
> >> > > > >>> > > > >> > > But I would like to hear from you if the
trick (
> >> > > > >>> > > > >> file_type=NETCDF_NCCF;)
> >> > > > >>> > > > >> > > can be applied generally, which I wish
very much.
> >> > > > >>> > > > >> > >
> >> > > > >>> > > > >> > > Thank you so much, John.
> >> > > > >>> > > > >> > >
> >> > > > >>> > > > >> > > Regards,
> >> > > > >>> > > > >> > >
> >> > > > >>> > > > >> > > Jinwoong Yoo
> >> > > > >>> > > > >> > >
> >> > > > >>> > > > >> > >
> >> > > > >>> > > > >> > > On Fri, Jul 7, 2017 at 1:16 PM, John
Halley
> Gotway
> >> via
> >> > > RT
> >> > > > <
> >> > > > >>> > > > >> > > met_help at ucar.edu> wrote:
> >> > > > >>> > > > >> > >
> >> > > > >>> > > > >> > >> Jinwoong,
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >> Thanks for sending your sample data and
for your
> >> > > patience
> >> > > > >>> > while I
> >> > > > >>> > > > was
> >> > > > >>> > > > >> > out
> >> > > > >>> > > > >> > >> of town.
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >> Using met-6.0, I'm able to process the
TRMM
> NetCDF
> >> > file
> >> > > > you
> >> > > > >>> > sent.
> >> > > > >>> > > > >> The
> >> > > > >>> > > > >> > >> trick is that I had to tell it which
NetCDF file
> >> type
> >> > > > >>> should be
> >> > > > >>> > > > used
> >> > > > >>> > > > >> to
> >> > > > >>> > > > >> > >> interpret the data. Using "file_type =
> >> NETCDF_NCCF;"
> >> > > I'm
> >> > > > >>> > telling
> >> > > > >>> > > > >> MET to
> >> > > > >>> > > > >> > >> interpret it as if it were a CF-compliant
NetCDF
> >> > file:
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >> met-6.0/bin/plot_data_plane \
> >> > > > >>> > > > >> > >> trmm_daily.20051231.7.nc
> trmm_daily.20051231.7.ps
> >> \
> >> > > > >>> > > > >> > >> 'name="precipitation"; level="(*,*)";
> >> > > > >>> file_type=NETCDF_NCCF;'
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >> DEBUG 1: Opening data file:
> >> trmm_daily.20051231.7.nc
> >> > > > >>> > > > >> > >> WARNING: NcCfFile::open() -> could not
determine
> >> the
> >> > > > valid
> >> > > > >>> > time,
> >> > > > >>> > > > >> using
> >> > > > >>> > > > >> > 0.
> >> > > > >>> > > > >> > >> WARNING: NcCfFile::open() -> could not
determine
> >> the
> >> > > > valid
> >> > > > >>> > time,
> >> > > > >>> > > > >> using
> >> > > > >>> > > > >> > 0.
> >> > > > >>> > > > >> > >> DEBUG 1: Creating postscript file:
> >> > > > >>> trmm_daily.20051231.7.ps
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >> The plot_data_plane tool is able to read
the
> data,
> >> > and
> >> > > > I've
> >> > > > >>> > > > attached
> >> > > > >>> > > > >> the
> >> > > > >>> > > > >> > >> resulting image. However, notice the
warning
> >> > messages
> >> > > > >>> about
> >> > > > >>> > the
> >> > > > >>> > > > >> valid
> >> > > > >>> > > > >> > >> time.
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >> Using ncdump to see that file attributes,
I see
> >> this
> >> > > > timing
> >> > > > >>> > > > >> information:
> >> > > > >>> > > > >> > >> :HDF5_GLOBAL.BeginDate =
> >> > "2005-12-31" ;
> >> > > > >>> > > > >> > >> :HDF5_GLOBAL.BeginTime =
> >> > > "01:30:00.000Z"
> >> > > > ;
> >> > > > >>> > > > >> > >> :HDF5_GLOBAL.EndDate =
> >> "2006-01-01" ;
> >> > > > >>> > > > >> > >> :HDF5_GLOBAL.EndTime =
> >> > "01:29:59.999Z"
> >> > > ;
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >> However that is not the CF-compliant way
of
> >> > specifying
> >> > > > >>> timing
> >> > > > >>> > > info.
> >> > > > >>> > > > >> So
> >> > > > >>> > > > >> > >> while MET will be able to read the data,
the
> >> timing
> >> > > info
> >> > > > >>> won't
> >> > > > >>> > be
> >> > > > >>> > > > >> > accurate
> >> > > > >>> > > > >> > >> in the MET output files. Instead, you'll
see
> >> > > "19700101"
> >> > > > >>> which
> >> > > > >>> > is
> >> > > > >>> > > > >> > unixtime
> >> > > > >>> > > > >> > >> = 0.
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >> Another option would be pulling the
binary TRMM
> >> data
> >> > > and
> >> > > > >>> using
> >> > > > >>> > > this
> >> > > > >>> > > > >> > >> Rscript
> >> > > > >>> > > > >> > >> to convert the binary to NetCDF:
> >> > > > >>> > > > >> > >> http://www.dtcenter.org/met/
> >> > > users/downloads/Rscripts/
> >> > > > >>> > > > trmmbin2nc.R
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >> However, I haven't done this in a while
and am
> not
> >> > sure
> >> > > > if
> >> > > > >>> > you'll
> >> > > > >>> > > > run
> >> > > > >>> > > > >> > into
> >> > > > >>> > > > >> > >> any issues.
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >> Hope that helps.
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >> Thanks,
> >> > > > >>> > > > >> > >> John
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >> On Thu, Jul 6, 2017 at 7:33 PM, Jinwoong
Yoo via
> >> RT <
> >> > > > >>> > > > >> met_help at ucar.edu>
> >> > > > >>> > > > >> > >> wrote:
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >> >
> >> > > > >>> > > > >> > >> > <URL: https://rt.rap.ucar.edu/rt/
> >> > > > >>> > Ticket/Display.html?id=81063
> >> > > > >>> > > >
> >> > > > >>> > > > >> > >> >
> >> > > > >>> > > > >> > >> > Hi John,
> >> > > > >>> > > > >> > >> >
> >> > > > >>> > > > >> > >> > Thank you very much.
> >> > > > >>> > > > >> > >> > Regards,
> >> > > > >>> > > > >> > >> >
> >> > > > >>> > > > >> > >> > Jinwoong
> >> > > > >>> > > > >> > >> >
> >> > > > >>> > > > >> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John
Halley
> >> Gotway
> >> > > via
> >> > > > >>> RT <
> >> > > > >>> > > > >> > >> > met_help at ucar.edu> wrote:
> >> > > > >>> > > > >> > >> >
> >> > > > >>> > > > >> > >> > > Jinwoong,
> >> > > > >>> > > > >> > >> > >
> >> > > > >>> > > > >> > >> > > I'm out of the office today but will
take a
> >> > closer
> >> > > > look
> >> > > > >>> > > > tomorrow.
> >> > > > >>> > > > >> > >> > >
> >> > > > >>> > > > >> > >> > > Thanks
> >> > > > >>> > > > >> > >> > > John
> >> > > > >>> > > > >> > >> > >
> >> > > > >>> > > > >> > >> > > On Mon, Jul 3, 2017 at 12:20 PM
Jinwoong Yoo
> >> via
> >> > > RT <
> >> > > > >>> > > > >> > >> met_help at ucar.edu>
> >> > > > >>> > > > >> > >> > > wrote:
> >> > > > >>> > > > >> > >> > >
> >> > > > >>> > > > >> > >> > > >
> >> > > > >>> > > > >> > >> > > > <URL: https://rt.rap.ucar.edu/rt/
> >> > > > >>> > > > Ticket/Display.html?id=81063
> >> > > > >>> > > > >> >
> >> > > > >>> > > > >> > >> > > >
> >> > > > >>> > > > >> > >> > > > Hi John,
> >> > > > >>> > > > >> > >> > > >
> >> > > > >>> > > > >> > >> > > > Thank you for your reply.
> >> > > > >>> > > > >> > >> > > > I uploaded my data as in
Yoo_data4.tar on
> >> the
> >> > ftp
> >> > > > >>> site.
> >> > > > >>> > > > >> > >> > > > I included several files for the
message
> of
> >> ID
> >> > > of [
> >> > > > >>> > > > >> > rt.rap.ucar.edu
> >> > > > >>> > > > >> > >> > > #81074]
> >> > > > >>> > > > >> > >> > > > as well.
> >> > > > >>> > > > >> > >> > > > Thank you.
> >> > > > >>> > > > >> > >> > > > Regards,
> >> > > > >>> > > > >> > >> > > >
> >> > > > >>> > > > >> > >> > > > Jinwoong
> >> > > > >>> > > > >> > >> > > >
> >> > > > >>> > > > >> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM,
John
> Halley
> >> > > Gotway
> >> > > > >>> via
> >> > > > >>> > RT
> >> > > > >>> > > <
> >> > > > >>> > > > >> > >> > > > met_help at ucar.edu> wrote:
> >> > > > >>> > > > >> > >> > > >
> >> > > > >>> > > > >> > >> > > > > Jinwoong,
> >> > > > >>> > > > >> > >> > > > >
> >> > > > >>> > > > >> > >> > > > > I see that you're having trouble
> reading a
> >> > TRMM
> >> > > > >>> NetCDF
> >> > > > >>> > > file
> >> > > > >>> > > > >> into
> >> > > > >>> > > > >> > >> MET.
> >> > > > >>> > > > >> > >> > > > Can
> >> > > > >>> > > > >> > >> > > > > you please post the problematic
file to
> >> our
> >> > > > >>> anonymous
> >> > > > >>> > ftp
> >> > > > >>> > > > >> site
> >> > > > >>> > > > >> > so
> >> > > > >>> > > > >> > >> I
> >> > > > >>> > > > >> > >> > can
> >> > > > >>> > > > >> > >> > > > > take a look?
> >> > > > >>> > > > >> > >> > > > >
> >> > > > >>> > > > >> > >> > > > > http://www.dtcenter.org/met/
> >> > > > >>> > > users/support/met_help.php#ftp
> >> > > > >>> > > > >> > >> > > > >
> >> > > > >>> > > > >> > >> > > > > Thanks,
> >> > > > >>> > > > >> > >> > > > > John Halley Gotway
> >> > > > >>> > > > >> > >> > > > >
> >> > > > >>> > > > >> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM,
Jinwoong
> >> Yoo
> >> > > via
> >> > > > >>> RT <
> >> > > > >>> > > > >> > >> > met_help at ucar.edu
> >> > > > >>> > > > >> > >> > > >
> >> > > > >>> > > > >> > >> > > > > wrote:
> >> > > > >>> > > > >> > >> > > > >
> >> > > > >>> > > > >> > >> > > > > >
> >> > > > >>> > > > >> > >> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Tic
> >> > > > >>> > > > >> ket/Display.html?id=81063
> >> > > > >>> > > > >> > >
> >> > > > >>> > > > >> > >> > > > > >
> >> > > > >>> > > > >> > >> > > > > > Hi,
> >> > > > >>> > > > >> > >> > > > > >
> >> > > > >>> > > > >> > >> > > > > > TRMM data comes in as netCDF-4
classic
> >> > model.
> >> > > > >>> > > > >> > >> > > > > > I changed it to netCDF classic
and run
> >> the
> >> > > same
> >> > > > >>> > command
> >> > > > >>> > > > >> for a
> >> > > > >>> > > > >> > >> test.
> >> > > > >>> > > > >> > >> > > > > > But I got the same error as
below.
> >> > > > >>> > > > >> > >> > > > > >
> >> > > > >>> > > > >> > >> > > > > > yoo108 at halstead-fe00:*/scratch
> >> > > > >>> /halstead/y/yoo108/
> >> > > > >>> > TRMM*
> >> > > > >>> > > $
> >> > > > >>> > > > >> > >> > > > > > ~/met-6.0_bugfix/bin/regrid_
> data_plane
> >> > > > >>> > > > >> > >> /scratch/halstead/y/yoo108/
> >> > > > >>> > > > >> > >> > > TRMM/
> >> > > > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> >> > > > >>> > > > >> > >> > > > > > /scratch/halstead/y/yoo108/ND_
> >> > > > >>> grided_obs/daily_T2m_
> >> > > > >>> > > > >> > >> > > maxminmean_1976.nc
> >> > > > >>> > > > >> > >> > > > > >
/scratch/halstead/y/yoo108/TRMM/
> >> > > > >>> > regrid_trmm_sample.nc
> >> > > > >>> > > > >> -field
> >> > > > >>> > > > >> > >> > > > > > 'name="precipitation";'
> >> > > > >>> > > > >> > >> > > > > >
> >> > > > >>> > > > >> > >> > > > > > DEBUG 1: Reading data file:
> >> > > > >>> > > > /scratch/halstead/y/yoo108/TRM
> >> > > > >>> > > > >> M/
> >> > > > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> >> > > > >>> > > > >> > >> > > > > >
> >> > > > >>> > > > >> > >> > > > > > ERROR :
> >> > > > >>> > > > >> > >> > > > > >
> >> > > > >>> > > > >> > >> > > > > > ERROR : process_data_file() ->
> >> > > > >>> > > > >> "/scratch/halstead/y/yoo108/TR
> >> > > > >>> > > > >> > >> MM/
> >> > > > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc"
not a
> >> valid
> >> > > data
> >> > > > >>> file
> >> > > > >>> > > > >> > >> > > > > >
> >> > > > >>> > > > >> > >> > > > > > Thank you.
> >> > > > >>> > > > >> > >> > > > > >
> >> > > > >>> > > > >> > >> > > > > > Regards,
> >> > > > >>> > > > >> > >> > > > > >
> >> > > > >>> > > > >> > >> > > > > >
> >> > > > >>> > > > >> > >> > > > > > Jinwoong
> >> > > > >>> > > > >> > >> > > > > >
> >> > > > >>> > > > >> > >> > > > > > On Mon, Jul 3, 2017 at 11:41
AM,
> >> Jinwoong
> >> > > Yoo <
> >> > > > >>> > > > >> > >> > > jinwoong.yoo at gmail.com>
> >> > > > >>> > > > >> > >> > > > > > wrote:
> >> > > > >>> > > > >> > >> > > > > >
> >> > > > >>> > > > >> > >> > > > > > > Hi,
> >> > > > >>> > > > >> > >> > > > > > >
> >> > > > >>> > > > >> > >> > > > > > > I noticed that TRMM data
dimension
> was
> >> > > (lon,
> >> > > > >>> lat).
> >> > > > >>> > > > >> > >> > > > > > > So I switched their order to
(lat,
> >> lon)
> >> > and
> >> > > > >>> ran the
> >> > > > >>> > > > >> command
> >> > > > >>> > > > >> > >> > again.
> >> > > > >>> > > > >> > >> > > > > > > However, I got the same error
> message
> >> as
> >> > > > below.
> >> > > > >>> > > > >> > >> > > > > > >
> >> > > > >>> > > > >> > >> > > > > > > yoo108 at halstead-
fe00:*/scratch
> >> > > > >>> /halstead/y/yoo108/
> >> > > > >>> > > TRMM*
> >> > > > >>> > > > $
> >> > > > >>> > > > >> > >> > > > > > > ~/met-
6.0_bugfix/bin/regrid_da
> >> ta_plane
> >> > > > >>> > > > >> > >> > /scratch/halstead/y/yoo108/
> >> > > > >>> > > > >> > >> > > > > TRMM/
> >> > > > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> >> > > > >>> > > > /scratch/halstead/y/yoo108/ND_
> >> > > > >>> > > > >> > >> > > > > > >
grided_obs/daily_T2m_maxminmea
> >> n_1976.nc
> >> > > > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> >> > > > >>> > > > >> > >> > > > > TRMM/
> >> > > > >>> > > > >> > >> > > > > > > regrid_trmm_sample.nc -field
> >> > > > >>> > 'name="precipitation";'
> >> > > > >>> > > > >> > >> > > > > > >
> >> > > > >>> > > > >> > >> > > > > > > DEBUG 1: Reading data file:
> >> > > > >>> > > > >> /scratch/halstead/y/yoo108/TRM
> >> > > > >>> > > > >> > M/
> >> > > > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> >> > > > >>> > > > >> > >> > > > > > >
> >> > > > >>> > > > >> > >> > > > > > > ERROR :
> >> > > > >>> > > > >> > >> > > > > > >
> >> > > > >>> > > > >> > >> > > > > > > ERROR : process_data_file()
->
> >> > > > >>> > > > >> > "/scratch/halstead/y/yoo108/TR
> >> > > > >>> > > > >> > >> > MM/
> >> > > > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc" not
a
> valid
> >> > data
> >> > > > >>> file
> >> > > > >>> > > > >> > >> > > > > > >
> >> > > > >>> > > > >> > >> > > > > > >
> >> > > > >>> > > > >> > >> > > > > > > Thank you.
> >> > > > >>> > > > >> > >> > > > > > >
> >> > > > >>> > > > >> > >> > > > > > > Regards,
> >> > > > >>> > > > >> > >> > > > > > >
> >> > > > >>> > > > >> > >> > > > > > >
> >> > > > >>> > > > >> > >> > > > > > > Jinwoong
> >> > > > >>> > > > >> > >> > > > > > >
> >> > > > >>> > > > >> > >> > > > > > >
> >> > > > >>> > > > >> > >> > > > > > >
> >> > > > >>> > > > >> > >> > > > > > > On Thu, Jun 29, 2017 at 4:36
PM,
> >> Jinwoong
> >> > > > Yoo <
> >> > > > >>> > > > >> > >> > > > jinwoong.yoo at gmail.com>
> >> > > > >>> > > > >> > >> > > > > > > wrote:
> >> > > > >>> > > > >> > >> > > > > > >
> >> > > > >>> > > > >> > >> > > > > > >> Hi,
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> I got a similar result with
a TRMM
> >> data.
> >> > > > >>> > > > >> > >> > > > > > >> Please see below:
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> yoo108 at halstead-
fe01:*/scratch
> >> > > > >>> /halstead/y/yoo108/
> >> > > > >>> > > > TRMM*
> >> > > > >>> > > > >> $
> >> > > > >>> > > > >> > >> > > > > > >> ~/met-
6.0_bugfix/bin/regrid_da
> >> ta_plane
> >> > > > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> >> > > > >>> > > > >> > >> > > > > TRMM/
> >> > > > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> >> > > > >>> > > > >> /scratch/halstead/y/yoo108/ND_
> >> > > > >>> > > > >> > >> > > > > > >>
grided_obs/daily_T2m_maxminmea
> >> n_1976.nc
> >> > > > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> >> > > > >>> > > > >> > >> > > > > > TRMM/
> >> > > > >>> > > > >> > >> > > > > > >> regrid_trmm_sample.nc -field
> >> > > > >>> > > 'name="precipitation";'
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> DEBUG 1: Reading data file:
> >> > > > >>> > > > >> /scratch/halstead/y/yoo108/TRM
> >> > > > >>> > > > >> > M/
> >> > > > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> ERROR : process_data_file()
->
> >> > > > >>> > > > >> > >> "/scratch/halstead/y/yoo108/TR
> >> > > > >>> > > > >> > >> > MM/
> >> > > > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc"
not a
> >> valid
> >> > > > data
> >> > > > >>> file
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> A part of ncdump output for
the
> TRMM
> >> > data
> >> > > is
> >> > > > >>> > pasted
> >> > > > >>> > > > >> below:
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> yoo108 at halstead-
fe01:*/scratch
> >> > > > >>> /halstead/y/yoo108/
> >> > > > >>> > > > TRMM*
> >> > > > >>> > > > >> $
> >> > > > >>> > > > >> > >> ncdump
> >> > > > >>> > > > >> > >> > > -h
> >> > > > >>> > > > >> > >> > > > > > >> subset_200003-200512/3B42RT_
> >> > > > >>> > > Daily.20051231.7.nc4.nc4
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> netcdf
> \3B42RT_Daily.20051231.7.nc4 {
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> dimensions:
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> lon = 59 ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> lat = 58 ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> variables:
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> short precipitation_cnt(lon,
lat) ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> precipitation_cnt:units =
"count" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> precipitation_cnt:long_name
=
> "Count
> >> of
> >> > > > valid
> >> > > > >>> 3-hr
> >> > > > >>> > > > >> > >> precipitation
> >> > > > >>> > > > >> > >> > > > > > >> retrievals for the day" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>
precipitation_cnt:coordinates =
> "lat
> >> > lon"
> >> > > ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> precipitation_cnt:origname =
> >> > > > >>> "precipitation_cnt" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>
precipitation_cnt:fullnamepath =
> >> > > > >>> > > "/precipitation_cnt"
> >> > > > >>> > > > ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> float
uncal_precipitation(lon,
> lat) ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation:units =
"mm" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation:long_name =
> >> "Daily
> >> > > > >>> accumulated
> >> > > > >>> > > > >> > >> uncalibrated
> >> > > > >>> > > > >> > >> > > > > > >> precipitation" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation:coordinates =
> >> "lat
> >> > > > lon" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation:_FillValue =
> >> > -9999.9f
> >> > > ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation:origname
=
> >> > > > >>> > > "uncal_precipitation" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation:fullnamepath =
> >> > > > >>> > > > >> "/uncal_precipitation"
> >> > > > >>> > > > >> > ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> short
uncal_precipitation_cnt(lon,
> >> lat)
> >> > ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:units =
> >> "count"
> >> > ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:long_name
> =
> >> > > "Count
> >> > > > of
> >> > > > >>> > valid
> >> > > > >>> > > > >> 3-hr
> >> > > > >>> > > > >> > >> uncal
> >> > > > >>> > > > >> > >> > > > > > >> precipitation retrievals for
the
> >> day" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:
> coordinates
> >> =
> >> > > "lat
> >> > > > >>> lon" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:origname =
> >> > > > >>> > > > >> > >> "uncal_precipitation_cnt" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:
> fullnamepath
> >> =
> >> > > > >>> > > > >> > >> > > "/uncal_precipitation_cnt" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> float precipitation(lon,
lat) ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> precipitation:units = "mm" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> precipitation:long_name =
"Daily
> >> > > accumulated
> >> > > > >>> > > > >> precipitation
> >> > > > >>> > > > >> > >> > > (combined
> >> > > > >>> > > > >> > >> > > > > > >> microwave-IR) estimate" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> precipitation:coordinates =
"lat
> >> lon" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> precipitation:_FillValue =
> -9999.9f ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> precipitation:origname =
> >> > "precipitation" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> precipitation:fullnamepath =
> >> > > > "/precipitation"
> >> > > > >>> ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> short randomError_cnt(lon,
lat) ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:units =
"count" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:long_name =
"Count
> of
> >> > > > >>> randomError
> >> > > > >>> > > for
> >> > > > >>> > > > >> the
> >> > > > >>> > > > >> > >> day" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:coordinates
= "lat
> >> lon"
> >> > ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:origname =
> >> > > > "randomError_cnt" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:fullnamepath
=
> >> > > > >>> "/randomError_cnt"
> >> > > > >>> > ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> float randomError(lon, lat)
;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> randomError:units = "mm" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> randomError:long_name =
"Daily
> total
> >> > error
> >> > > > of
> >> > > > >>> > > combined
> >> > > > >>> > > > >> > >> > > microwave-IR
> >> > > > >>> > > > >> > >> > > > > > >> precipitation estimate" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> randomError:_FillValue =
-9999.9f ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> randomError:origname =
> "randomError"
> >> ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> randomError:fullnamepath =
> >> > "/randomError"
> >> > > ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> float lat(lat) ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> lat:units = "degrees_north"
;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> lat:long_name = "Latitude" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> lat:origname = "lat" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> lat:fullnamepath = "/lat" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> float lon(lon) ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> lon:units = "degrees_east" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> lon:long_name = "Longitude"
;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> lon:origname = "lon" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> lon:fullnamepath = "/lon" ;
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> Thank you.
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> Regards,
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> Jinwoong
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >> On Thu, Jun 29, 2017 at 3:11
PM,
> >> > > > >>> > met_help at ucar.edu
> >> > > > >>> > > > via
> >> > > > >>> > > > >> RT
> >> > > > >>> > > > >> > <
> >> > > > >>> > > > >> > >> > > > > > >> met_help at ucar.edu> wrote:
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >>> NOTE: THE MET TEAM HAS
LIMITED
> >> > > AVAILABILITY
> >> > > > >>> > BETWEEN
> >> > > > >>> > > > >> > 5/23/17
> >> > > > >>> > > > >> > >> AND
> >> > > > >>> > > > >> > >> > > > > > >>> 5/30/17. RESPONSES MAY BE
> DELAYED.
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> Greetings,
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> This message has been
> automatically
> >> > > > >>> generated in
> >> > > > >>> > > > >> response
> >> > > > >>> > > > >> > to
> >> > > > >>> > > > >> > >> > the
> >> > > > >>> > > > >> > >> > > > > > >>> creation of a trouble
ticket
> >> regarding:
> >> > > > >>> > > > >> > >> > > > > > >>> "regrid_data_plane:
not a
> >> valid
> >> > > > data
> >> > > > >>> > file",
> >> > > > >>> > > > >> > >> > > > > > >>> a summary of which appears
below.
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> There is no need to reply
to this
> >> > message
> >> > > > >>> right
> >> > > > >>> > > now.
> >> > > > >>> > > > >> Your
> >> > > > >>> > > > >> > >> > ticket
> >> > > > >>> > > > >> > >> > > > has
> >> > > > >>> > > > >> > >> > > > > > >>> been
> >> > > > >>> > > > >> > >> > > > > > >>> assigned an ID of [
> rt.rap.ucar.edu
> >> > > > #81063].
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> Please include the string:
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> [rt.rap.ucar.edu
#81063]
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> in the subject line of all
future
> >> > > > >>> correspondence
> >> > > > >>> > > > about
> >> > > > >>> > > > >> > this
> >> > > > >>> > > > >> > >> > > issue.
> >> > > > >>> > > > >> > >> > > > To
> >> > > > >>> > > > >> > >> > > > > > do
> >> > > > >>> > > > >> > >> > > > > > >>> so,
> >> > > > >>> > > > >> > >> > > > > > >>> you may reply to this
message.
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>>
Thank you,
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > met_help at ucar.edu
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>>
------------------------------
> >> > > > >>> > > > >> > >> ------------------------------
> >> > > > >>> > > > >> > >> > > > > > >>> -------------
> >> > > > >>> > > > >> > >> > > > > > >>> Hi,
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> I am trying to regrid one
of my
> >> > > observation
> >> > > > >>> files
> >> > > > >>> > > in
> >> > > > >>> > > > >> lat
> >> > > > >>> > > > >> > lon
> >> > > > >>> > > > >> > >> > > > > coordinate
> >> > > > >>> > > > >> > >> > > > > > >>> grid to WRF curvilinear
grid.
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> I ran bin/regrid_data_plane
using
> a
> >> > > sample
> >> > > > >>> lat
> >> > > > >>> > lon
> >> > > > >>> > > > grid
> >> > > > >>> > > > >> > file
> >> > > > >>> > > > >> > >> > and
> >> > > > >>> > > > >> > >> > > a
> >> > > > >>> > > > >> > >> > > > > file
> >> > > > >>> > > > >> > >> > > > > > >>> in
> >> > > > >>> > > > >> > >> > > > > > >>> the WRF grid. But I got
error as
> >> shown
> >> > > > below:
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> yoo108 at halstead-
fe00:*/scratch
> >> > > > >>> > > > >> > /halstead/y/yoo108/ND_grided_
> >> > > > >>> > > > >> > >> > obs*
> >> > > > >>> > > > >> > >> > > $
> >> > > > >>> > > > >> > >> > > > > > >>> ~/met-
6.0_bugfix/bin/regrid_da
> >> ta_plane
> >> > > > >>> > > > >> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_
> >> > > grided_obs/
> >> > > > >>> > > > >> sample_tmax.nc
> >> > > > >>> > > > >> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_
> >> > > > >>> > > grided_obs/daily_T2m_
> >> > > > >>> > > > >> > >> > > > > maxminmean_1976.nc
> >> > > > >>> > > > >> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_
> >> > > > >>> > > > >> > >> grided_obs/NDtoWRFgrid_sample_
> >> > > > >>> > > > >> > >> > > > tmax.nc
> >> > > > >>> > > > >> > >> > > > > > >>> -field
> >> > > > >>> > > > >> > >> > > > > > >>> 'name="tmax";'
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> DEBUG 1: Reading data file:
> >> > > > >>> > > > >> /scratch/halstead/y/yoo108/ND_
> >> > > > >>> > > > >> > >> > > > > grided_obs/
> >> > > > >>> > > > >> > >> > > > > > >>> sample_tmax.nc
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> ERROR :
process_data_file() ->
> >> > > > >>> > > > >> > >> "/scratch/halstead/y/yoo108/ND
> >> > > > >>> > > > >> > >> > > > > > >>> _grided_obs/
> >> > > > >>> > > > >> > >> > > > > > >>> sample_tmax.nc" not a valid
data
> >> file
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> I wonder which part of the
input
> >> file
> >> > > does
> >> > > > >>> not
> >> > > > >>> > > > satisfy
> >> > > > >>> > > > >> the
> >> > > > >>> > > > >> > >> > MET's
> >> > > > >>> > > > >> > >> > > > > "valid
> >> > > > >>> > > > >> > >> > > > > > >>> file" criteria.
> >> > > > >>> > > > >> > >> > > > > > >>> ncdump output of the input
file
> >> looks
> >> > as
> >> > > > >>> below:
> >> > > > >>> > > > >> > >> > > > > > >>> Input file was originally
> generated
> >> by
> >> > > VIC
> >> > > > >>> model
> >> > > > >>> > > and
> >> > > > >>> > > > >> > >> converted
> >> > > > >>> > > > >> > >> > > into
> >> > > > >>> > > > >> > >> > > > > cf
> >> > > > >>> > > > >> > >> > > > > > >>> netcdf format.
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> Thank you in advance.
> >> > > > >>> > > > >> > >> > > > > > >>> Regards,
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> Jinwoong
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> yoo108 at halstead-
fe00:*/scratch
> >> > > > >>> > > > >> > /halstead/y/yoo108/ND_grided_
> >> > > > >>> > > > >> > >> > obs*
> >> > > > >>> > > > >> > >> > > $
> >> > > > >>> > > > >> > >> > > > > > >>> ncdump -h
> >> > > > >>> > > > >> > >> > > > > > >>> sample_tmax.nc
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> netcdf sample_tmax {
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> dimensions:
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> T = 1 ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> X = 55 ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> Y = 65 ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> variables:
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> double T(T) ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> T:units = "days since 1915-
01-01"
> ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> T:long_name = "Time" ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> double X(X) ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> X:units = "degrees_east" ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> X:long_name = "Longitude" ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> double Y(Y) ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> Y:units = "degrees_north" ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> Y:long_name = "Latitude" ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> double tmax(T, Y, X) ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> tmax:units = "degC" ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> tmax:long_name = "tmax
calculated
> by
> >> > > VIC" ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> tmax:missing_value =
-9999.f ;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> // global attributes:
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>> :production = "VIC output"
;
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>>
> >> > > > >>> > > > >> > >> > > > > > >>
> >> > > > >>> > > > >> > >> > > > > > >
> >> > > > >>> > > > >> > >> > > > > >
> >> > > > >>> > > > >> > >> > > > > >
> >> > > > >>> > > > >> > >> > > > >
> >> > > > >>> > > > >> > >> > > > >
> >> > > > >>> > > > >> > >> > > >
> >> > > > >>> > > > >> > >> > > >
> >> > > > >>> > > > >> > >> > >
> >> > > > >>> > > > >> > >> > >
> >> > > > >>> > > > >> > >> >
> >> > > > >>> > > > >> > >> >
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >>
> >> > > > >>> > > > >> > >
> >> > > > >>> > > > >> >
> >> > > > >>> > > > >> >
> >> > > > >>> > > > >>
> >> > > > >>> > > > >>
> >> > > > >>> > > > >
> >> > > > >>> > > >
> >> > > > >>> > > >
> >> > > > >>> > >
> >> > > > >>> > >
> >> > > > >>> >
> >> > > > >>> >
> >> > > > >>>
> >> > > > >>>
> >> > > > >>
> >> > > > >
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Fri Jul 14 10:43:15 2017
Hi John,
Thank you for your kind message.
I have uploaded met_em file as in met_em.tar through the ftp.
Thank you very much in advance.
Regards,
Jinwoong
On Fri, Jul 14, 2017 at 11:49 AM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Jinwoong,
>
> I'd like to make sure I'm testing with the exact same file you're
using.
>
> Could you please post this file to our anonymous ftp site:
> /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-12-
31_18:00:
> 00.nc
>
> Following these instructions:
> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>
> Once I get it, I'll plot it just like you did and then try to run it
> through Grid-Stat.
>
> Thanks,
> John
>
> On Thu, Jul 13, 2017 at 11:35 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >
> > Hi John,
> >
> > I wonder if you had a chance to take a look at the issue regarding
how to
> > make grid_stat read in netcdf file that has WRF coordinate grid
info?
> > Please let me know.
> > Thank you.
> >
> > Regards,
> >
> > Jinwoong
> >
> > On Wed, Jul 12, 2017 at 3:05 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > wrote:
> >
> > > Hi John,
> > > As I noted in the previous messages,
> > > I was able to plot netcdf files by copying global attributes
from WRF
> > > output to the netcdf files in the same coordinate grids.
> > >
> > > yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal*
> $
> > > ~/met-6.0_bugfix/bin/plot_data_plane
/scratch/halstead/y/yoo108/NCA
> > > R_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc
> > met_em.d03.2005-12-31_18:00:
> > > 00.ps 'name="TT";level="(0,0,*,*)";file_type = NETCDF_PINT;'
> > >
> > > DEBUG 1: Opening data file: /scratch/halstead/y/yoo108/NCA
> > > R_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc
> > >
> > > DEBUG 1: Creating postscript file: met_em.d03.2005-12-
31_18:00:00.ps
> > >
> > > However, when 'file_typ=NETCDF_PINT;' was not provided in the
> > > plot_data_plane command, it failed.
> > >
> > > yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis/METanal*
> $
> > > ~/met-6.0_bugfix/bin/plot_data_plane
/scratch/halstead/y/yoo108/NCA
> > > R_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc
> > met_em.d03.2005-12-31_18:00:
> > > 00.ps 'name="TT";level="(0,0,*,*)";'
> > >
> > > DEBUG 1: Opening data file: /scratch/halstead/y/yoo108/NCA
> > > R_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc
> > >
> > > ERROR : plot_data_plane -> file "/scratch/halstead/y/yoo108/NC
> > > AR_BC_met_em/met_em.d03.2005-12-31_18:00:00.nc" not a valid data
file
> > >
> > > Thing is that I don't know where to put the argument (
> > > 'file_typ=NETCDF_PINT;') in the grid_stat.
> > >
> > > I tried both in config file and command line but both failed.
> > >
> > >
> > > Thank you.
> > >
> > >
> > > Regards,
> > >
> > >
> > > Jinwoong
> > >
> > >
> > >
> > > On Wed, Jul 12, 2017 at 2:59 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >> Jinwoong,
> > >>
> > >> OK, sorry for the confusion. Honestly, I don't know how you're
> getting
> > >> plot_data_plane to work at all. When I run it using the sample
data
> > file
> > >> you sent me (met_em.d03.2005-01-01_00:00:00.nc), it doesn't
work:
> > >>
> > >> met-6.0/bin/plot_data_plane met_em.d03.2005-01-01_00:00:00.nc
test.ps
> \
> > >> 'name="TT"; level="(0,0,*,*)"; file_type = NETCDF_PINT;'
> > >> DEBUG 1: Opening data file: met_em.d03.2005-01-01_00:00:00.nc
> > >> ERROR :
> > >> ERROR : MetNcPinterpDataFile::open(const char *) -> unable to
open
> > >> NetCDF
> > >> file "met_em.d03.2005-01-01_00:00:00.nc"
> > >> ERROR :
> > >> ERROR :
> > >> ERROR : Met2dDataFileFactory::new_met_2d_data_file() -> error
> opening
> > >> file
> > >> "met_em.d03.2005-01-01_00:00:00.nc"
> > >> ERROR :
> > >>
> > >> There must be something different between the sample file you
sent and
> > the
> > >> one you're actually using:
> > >> /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> > 2005-12-31_18:00:
> > >> 00.nc
> > >>
> > >> John
> > >>
> > >> On Wed, Jul 12, 2017 at 12:46 PM, Jinwoong Yoo via RT <
> > met_help at ucar.edu>
> > >> wrote:
> > >>
> > >> >
> > >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
> > >> >
> > >> > Hi John,
> > >> >
> > >> > I am still experiencing troubles to read in netcdf files for
> grid_stat
> > >> > command.
> > >> > Please read the last two previous emails that I sent.
> > >> > Thank you very much.
> > >> >
> > >> > Regards,
> > >> >
> > >> > Jinwoong
> > >> >
> > >> > On Wed, Jul 12, 2017 at 1:44 PM, John Halley Gotway via RT <
> > >> > met_help at ucar.edu> wrote:
> > >> >
> > >> > > Great, glad you were able to get it working.
> > >> > >
> > >> > > Thanks,
> > >> > > John
> > >> > >
> > >> > > On Tue, Jul 11, 2017 at 9:44 AM, Jinwoong Yoo via RT <
> > >> met_help at ucar.edu>
> > >> > > wrote:
> > >> > >
> > >> > > >
> > >> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > >> > > >
> > >> > > > Hi John,
> > >> > > >
> > >> > > > Even with the plot_data_plane command,
> > >> > > > I noticed that "file_type = NETCDF_PINT;" argument should
be
> > >> provided
> > >> > in
> > >> > > > the command line.
> > >> > > > Otherwise, it fails. Please see below.
> > >> > > >
> > >> > > > yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis
> > >> /METanal*
> > >> > $
> > >> > > > ~/met-6.0_bugfix/bin/plot_data_plane
> > >> > > >
/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-
> > >> 12-31_18:00:
> > >> > > > 00.nc
> > >> > > > met_em.d03.2005-12-31_18:00:00.ps
> 'name="TT";level="(0,0,*,*)";'
> > >> > > >
> > >> > > > DEBUG 1: Opening data file:
> > >> > > >
/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-
> > >> 12-31_18:00:
> > >> > > > 00.nc
> > >> > > >
> > >> > > > ERROR : plot_data_plane -> file
> > >> > > > "/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> > >> > 2005-12-31_18:00:
> > >> > > > 00.nc"
> > >> > > > not a valid data file
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > yoo108 at halstead-
fe01:*/scratch/halstead/y/yoo108/wrfAnalysis
> > >> /METanal*
> > >> > $
> > >> > > > ~/met-6.0_bugfix/bin/plot_data_plane
> > >> > > >
/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-
> > >> 12-31_18:00:
> > >> > > > 00.nc
> > >> > > > met_em.d03.2005-12-31_18:00:00.ps
'name="TT";level="(0,0,*,*)";
> > >> > file_type
> > >> > > =
> > >> > > > NETCDF_PINT;'
> > >> > > >
> > >> > > > DEBUG 1: Opening data file:
> > >> > > >
/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.2005-
> > >> 12-31_18:00:
> > >> > > > 00.nc
> > >> > > >
> > >> > > > DEBUG 1: Creating postscript file:
> met_em.d03.2005-12-31_18:00:00
> > >> .ps
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > Thank you.
> > >> > > >
> > >> > > > Regards,
> > >> > > >
> > >> > > >
> > >> > > > Jinwoong
> > >> > > >
> > >> > > >
> > >> > > > On Tue, Jul 11, 2017 at 11:12 AM, Jinwoong Yoo <
> > >> jinwoong.yoo at gmail.com
> > >> > >
> > >> > > > wrote:
> > >> > > >
> > >> > > > > Hi John,
> > >> > > > >
> > >> > > > > Now I am trying to execute grid_stat against these
netcdf
> files
> > >> that
> > >> > > have
> > >> > > > > been patted with the WRF global attributes.
> > >> > > > >
> > >> > > > > I tried to include 'file_type = NETCDF_PINT;' argument
both in
> > its
> > >> > > > > configuration file and in the command line.
> > >> > > > > However, both failed to run (Please see below).
> > >> > > > >
> > >> > > > > Could you please guide me how to specify the netcdf
file type
> in
> > >> the
> > >> > > > > grid_stat application?
> > >> > > > > Thank you.
> > >> > > > >
> > >> > > > > Regards,
> > >> > > > >
> > >> > > > > Jinwoong
> > >> > > > >
> > >> > > > >
> > >> > > > > 1.
> > >> > > > >
> > >> > > > > .......
> > >> > > > >
> > >> > > > > obs = {
> > >> > > > >
> > >> > > > >
> > >> > > > > field = [
> > >> > > > >
> > >> > > > > {
> > >> > > > >
> > >> > > > > name = "TT";
> > >> > > > >
> > >> > > > > level = [ "(0,0,*,*)" ];
> > >> > > > >
> > >> > > > > file_type = NETCDF_PINT;
> > >> > > > >
> > >> > > > > cat_thresh = [];
> > >> > > > >
> > >> > > > > }
> > >> > > > >
> > >> > > > > .......
> > >> > > > >
> > >> > > > > DEBUG 1: Default Config File: /home/yoo108/met-
6.0_bugfix/
> > >> > > > > share/met/config/GridStatConfig_default
> > >> > > > >
> > >> > > > > DEBUG 1: User Config File: /scratch/halstead/y/yoo108/
> > >> > > > wrfAnalysis/METanal/
> > >> > > > > GridStatConfig_met_em
> > >> > > > >
> > >> > > > > DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file()
->
> > created
> > >> new
> > >> > > > > Met2dDataFile object of type "FileType_Gb2".
> > >> > > > >
> > >> > > > > DEBUG 4: Switching the GRIB2 radius of the earth value
of
> > 6371.23
> > >> km
> > >> > to
> > >> > > > > 6371.2 km for internal consistency.
> > >> > > > >
> > >> > > > > DEBUG 4:
> > >> > > > >
> > >> > > > > DEBUG 4: Lambert Conformal Grid Data:
> > >> > > > >
> > >> > > > > DEBUG 4: scale_lat_1: 48
> > >> > > > >
> > >> > > > > DEBUG 4: scale_lat_2: 32
> > >> > > > >
> > >> > > > > DEBUG 4: lat_pin: 36.9132
> > >> > > > >
> > >> > > > > DEBUG 4: lon_pin: 92.0748
> > >> > > > >
> > >> > > > > DEBUG 4: x_pin: 0
> > >> > > > >
> > >> > > > > DEBUG 4: y_pin: 0
> > >> > > > >
> > >> > > > > DEBUG 4: lon_orient: 97
> > >> > > > >
> > >> > > > > DEBUG 4: d_km: 4
> > >> > > > >
> > >> > > > > DEBUG 4: r_km: 6371.2
> > >> > > > >
> > >> > > > > DEBUG 4: nx: 189
> > >> > > > >
> > >> > > > > DEBUG 4: ny: 270
> > >> > > > >
> > >> > > > > DEBUG 4:
> > >> > > > >
> > >> > > > > DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file()
->
> > created
> > >> new
> > >> > > > > Met2dDataFile object of type "FileType_None".
> > >> > > > >
> > >> > > > > ERROR :
> > >> > > > >
> > >> > > > > ERROR : Trouble reading observation file
> > >> > "/scratch/halstead/y/yoo108/
> > >> > > > > NCAR_BC_met_em/met_em.d03.1980-01-01_00:00:00.nc"
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > 2.
> > >> > > > >
> > >> > > > > /home/yoo108/met-6.0_bugfix/bin/grid_stat
> > >> > > $dir_data/$yyyy/$yyyy$nummon/$
> > >> > > > > grib_date1 $dir_data2/$met_em_date1
$analDir/$GridStatConfig
> > >> > > 'file_type =
> > >> > > > > NETCDF_PINT;' -outdir $workDir -v 4
> > >> > > > >
> > >> > > > > *** Model Evaluation Tools (METV6.0) ***
> > >> > > > >
> > >> > > > >
> > >> > > > > Usage: grid_stat
> > >> > > > >
> > >> > > > > fcst_file
> > >> > > > >
> > >> > > > > obs_file
> > >> > > > >
> > >> > > > > config_file
> > >> > > > >
> > >> > > > > [-outdir path]
> > >> > > > >
> > >> > > > > [-log file]
> > >> > > > >
> > >> > > > > [-v level]
> > >> > > > >
> > >> > > > > [-compress level]
> > >> > > > >
> > >> > > > >
> > >> > > > > where "fcst_file" is a gridded forecast file containing
the
> > >> field(s)
> > >> > to
> > >> > > > > be verified (required).
> > >> > > > >
> > >> > > > > "obs_file" is a gridded observation file containing the
> > verifying
> > >> > > > field(s)
> > >> > > > > (required).
> > >> > > > >
> > >> > > > > "config_file" is a GridStatConfig file containing the
desired
> > >> > > > > configuration settings (required).
> > >> > > > >
> > >> > > > > "-outdir path" overrides the default output directory
> > >> > > > >
(/scratch/halstead/y/yoo108/wrfAnalysis/METanal/wrf2met_em)
> > >> > > (optional).
> > >> > > > >
> > >> > > > > "-log file" outputs log messages to the specified file
> > (optional).
> > >> > > > >
> > >> > > > > "-v level" overrides the default level of logging (4)
> > (optional).
> > >> > > > >
> > >> > > > > "-compress level" overrides the compression level of
NetCDF
> > >> variable
> > >> > > (0)
> > >> > > > > (optional).
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > On Mon, Jul 10, 2017 at 4:53 PM, Jinwoong Yoo <
> > >> > jinwoong.yoo at gmail.com>
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > >> Hi John,
> > >> > > > >>
> > >> > > > >> I was able to open netcdf files that share the same
> coordinates
> > >> with
> > >> > > WRF
> > >> > > > >> output by copying the global attribute of the WRF
output to
> > these
> > >> > > netcdf
> > >> > > > >> files:
> > >> > > > >>
> > >> > > > >> ncks -A -x wrfout.nc target.nc
> > >> > > > >>
> > >> > > > >> This enabled me to open netcdf files in MET using
> > >> > > > >> 'name="TT";level="(0,0,*,*)";file_type = NETCDF_PINT;'
> > argument.
> > >> > > > >>
> > >> > > > >> Thank you very much!
> > >> > > > >> Regards,
> > >> > > > >>
> > >> > > > >> Jinwoong
> > >> > > > >>
> > >> > > > >> On Mon, Jul 10, 2017 at 3:04 PM, John Halley Gotway
via RT <
> > >> > > > >> met_help at ucar.edu> wrote:
> > >> > > > >>
> > >> > > > >>> Jinwoong,
> > >> > > > >>>
> > >> > > > >>> I tried running the sample file
> (daily_T2m_maxminmean_1981.nc)
> > >> > > through
> > >> > > > >>> plot_data_plane and saw the same behavior you did.
Looking
> > >> closely
> > >> > > at
> > >> > > > >>> that
> > >> > > > >>> file I see that is not the NetCDF output generated by
WRF.
> > The
> > >> > > history
> > >> > > > >>> attribute indicates that it was created by the "ncks"
> utility:
> > >> > > > >>>
> > >> > > > >>> :history = "Sun Jul 2 15:47:18 2017: ncks -d
days,0,0
> > >> > > > >>>
/scratch/halstead/k/khoogewi/CCRC_wrf/analysis/T2m/daily_
> T2m_
> > >> > > > >>> maxminmean_1981.nc
> > >> > > > >>> /scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> maxminm
> > >> > > > >>> ean_19810101.nc"
> > >> > > > >>>
> > >> > > > >>>
> > >> > > > >>> This is not a CF-compliant NetCDF file and it does
not look
> > like
> > >> > the
> > >> > > > >>> output
> > >> > > > >>> from WRF. Another alternative is making it look like
the
> > NetCDF
> > >> > file
> > >> > > > >>> format used by the MET tools themselves.
> > >> > > > >>>
> > >> > > > >>> I ran the following command to add global attributes
to
> define
> > >> the
> > >> > > grid
> > >> > > > >>> spec for MET:
> > >> > > > >>>
> > >> > > > >>> ncatted \
> > >> > > > >>> -a MET_version,global,o,c,"V6.0" \
> > >> > > > >>> -a Projection,global,o,c,"Lambert Conformal" \
> > >> > > > >>> -a scale_lat_1,global,o,c,"48" \
> > >> > > > >>> -a scale_lat_2,global,o,c,"32" \
> > >> > > > >>> -a lat_pin,global,o,c,"48" \
> > >> > > > >>> -a lon_pin,global,o,c,"-97" \
> > >> > > > >>> -a x_pin,global,o,c,"0" \
> > >> > > > >>> -a y_pin,global,o,c,"0" \
> > >> > > > >>> -a lon_orient,global,o,c,"-97" \
> > >> > > > >>> -a d_km,global,o,c,"3" \
> > >> > > > >>> -a r_km,global,o,c,"6371.2" \
> > >> > > > >>> -a nx,global,o,c,"189" \
> > >> > > > >>> -a ny,global,o,c,"270" \
> > >> > > > >>> daily_T2m_maxminmean_1976.nc -o
> daily_T2m_maxminmean_1976_MET.
> > >> nc
> > >> > > > >>>
> > >> > > > >>> However, I don't think these are all correct.
> Specifically, I
> > >> > don't
> > >> > > > know
> > >> > > > >>> how the "lon_orient" should be set. So I set it to
the
> > >> longitude
> > >> > of
> > >> > > > the
> > >> > > > >>> lower-left corner. Also, I don't know how the d_km
should
> be
> > >> set.
> > >> > > > >>> That's
> > >> > > > >>> the grid spacing in km. So I just guess with a value
of 3.
> > >> > > > >>>
> > >> > > > >>> This enables MET to plot the result, but you should
work on
> > >> making
> > >> > > the
> > >> > > > >>> grid
> > >> > > > >>> info correct:
> > >> > > > >>> met-6.0/bin/plot_data_plane \
> > >> > > > >>> daily_T2m_maxminmean_1976_MET.nc \
> > >> > > > >>> daily_T2m_maxminmean_1976_MET.ps \
> > >> > > > >>> 'name="T2m_max"; level="(10,*,*)";' -v 4
> > >> > > > >>>
> > >> > > > >>> Thanks,
> > >> > > > >>> John
> > >> > > > >>>
> > >> > > > >>>
> > >> > > > >>>
> > >> > > > >>> On Fri, Jul 7, 2017 at 5:06 PM, Jinwoong Yoo via RT <
> > >> > > met_help at ucar.edu
> > >> > > > >
> > >> > > > >>> wrote:
> > >> > > > >>>
> > >> > > > >>> >
> > >> > > > >>> > <URL: https://rt.rap.ucar.edu/rt/
> > Ticket/Display.html?id=81063
> > >> >
> > >> > > > >>> >
> > >> > > > >>> > Hi John,
> > >> > > > >>> >
> > >> > > > >>> > Thank you for your comment.
> > >> > > > >>> > I tried it but it failed.
> > >> > > > >>> > Please see below.
> > >> > > > >>> >
> > >> > > > >>> > yoo108 at halstead-fe03:*/scratch/halstead/y/yoo108/
> > >> > > > wrfAnalysis/METanal*
> > >> > > > >>> $
> > >> > > > >>> > ~/met-6.0_bugfix/bin/plot_data_plane
> > >> > > > >>> >
/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > >> > > > >>> > maxminmean_20051231.nc
> > >> > > > >>> > wrfDaily_T2m_maxminmean_20051231.ps
> > >> > > > >>> > 'name="T2m_max";level="(0,*,*)";file_type =
NETCDF_PINT;'
> > >> > > > >>> >
> > >> > > > >>> > DEBUG 1: Opening data file:
> > >> > > > >>> >
/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > >> > > > >>> > maxminmean_20051231.nc
> > >> > > > >>> >
> > >> > > > >>> > ERROR : MetNcPinterpDataFile::open(const char *)
->
> unable
> > >> to
> > >> > > open
> > >> > > > >>> NetCDF
> > >> > > > >>> > file
> > >> > > > >>> >
"/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > >> > > > >>> > maxminmean_20051231.nc"
> > >> > > > >>> >
> > >> > > > >>> > ERROR :
Met2dDataFileFactory::new_met_2d_data_file() ->
> > >> error
> > >> > > > opening
> > >> > > > >>> > file
> > >> > > > >>> >
"/scratch/halstead/y/yoo108/WRFdaily/T2m/wrfDaily_T2m_
> > >> > > > >>> > maxminmean_20051231.nc"
> > >> > > > >>> >
> > >> > > > >>> >
> > >> > > > >>> >
> > >> > > > >>> > One sample file
(wrfDaily_T2m_maxminmean_19810101.nc) is
> > also
> > >> > > > >>> included in
> > >> > > > >>> > the Yoo_data4.tar file that I uploaded previously.
> > >> > > > >>> > Thank you.
> > >> > > > >>> > Haver a nice weekend.
> > >> > > > >>> >
> > >> > > > >>> > Regards,
> > >> > > > >>> >
> > >> > > > >>> > Jinwoong
> > >> > > > >>> >
> > >> > > > >>> >
> > >> > > > >>> >
> > >> > > > >>> > On Fri, Jul 7, 2017 at 6:04 PM, John Halley Gotway
via RT
> <
> > >> > > > >>> > met_help at ucar.edu
> > >> > > > >>> > > wrote:
> > >> > > > >>> >
> > >> > > > >>> > > Jinwoong,
> > >> > > > >>> > >
> > >> > > > >>> > > If they really are output from WRF, one simple
thing to
> > try
> > >> is
> > >> > > > >>> telling
> > >> > > > >>> > MET
> > >> > > > >>> > > to interpret them as the NetCDF output of the
wrf_interp
> > >> > utility
> > >> > > > >>> > > :
> > >> > > > >>> > > file_type = NETCDF_PINT;
> > >> > > > >>> > >
> > >> > > > >>> > > "PINT" stands for "pressure interpolated"...
pinterp was
> > the
> > >> > > > >>> precursor to
> > >> > > > >>> > > the current wrf_interp tool.
> > >> > > > >>> > >
> > >> > > > >>> > > If that doesn't work, I'll need to see a sample
file
> > before
> > >> > > making
> > >> > > > >>> any
> > >> > > > >>> > > other suggestions.
> > >> > > > >>> > >
> > >> > > > >>> > > Thanks,
> > >> > > > >>> > > John
> > >> > > > >>> > >
> > >> > > > >>> > >
> > >> > > > >>> > >
> > >> > > > >>> > > On Fri, Jul 7, 2017 at 3:36 PM, Jinwoong Yoo via
RT <
> > >> > > > >>> met_help at ucar.edu>
> > >> > > > >>> > > wrote:
> > >> > > > >>> > >
> > >> > > > >>> > > >
> > >> > > > >>> > > > <URL: https://rt.rap.ucar.edu/rt/
> > >> > Ticket/Display.html?id=81063
> > >> > > >
> > >> > > > >>> > > >
> > >> > > > >>> > > > Hi John,
> > >> > > > >>> > > >
> > >> > > > >>> > > > I was able to read in a "home brew" netcdf data
file
> > using
> > >> > > > >>> > > plot_data_plane.
> > >> > > > >>> > > >
> > >> > > > >>> > > > Then, I went ahead and tried another netcdf
file in
> > >> > curvilinear
> > >> > > > >>> > > coordinate
> > >> > > > >>> > > > which is in the same coordinate grid as my WRF
output.
> > >> But it
> > >> > > > >>> failed.
> > >> > > > >>> > > >
> > >> > > > >>> > > > I have many netcdf climatology files from the
WRF
> > >> simulation
> > >> > > such
> > >> > > > >>> as
> > >> > > > >>> > > daily,
> > >> > > > >>> > > > monthly, and annual, etc. Therefore, they are
all in
> > >> > > curvilinear
> > >> > > > >>> > > coordinate
> > >> > > > >>> > > > (Lambert).
> > >> > > > >>> > > >
> > >> > > > >>> > > > I wonder if there is any work around so that I
can
> feed
> > >> these
> > >> > > > files
> > >> > > > >>> > into
> > >> > > > >>> > > > MET?
> > >> > > > >>> > > > Or should I regrid them all into lat lon
coordinate
> > files
> > >> > > first?
> > >> > > > >>> > > >
> > >> > > > >>> > > > Thank you, John.
> > >> > > > >>> > > >
> > >> > > > >>> > > > Regards,
> > >> > > > >>> > > >
> > >> > > > >>> > > > Jinwoong Yoo
> > >> > > > >>> > > >
> > >> > > > >>> > > >
> > >> > > > >>> > > > On Fri, Jul 7, 2017 at 3:01 PM, Jinwoong Yoo <
> > >> > > > >>> jinwoong.yoo at gmail.com>
> > >> > > > >>> > > > wrote:
> > >> > > > >>> > > >
> > >> > > > >>> > > > > Hi John,
> > >> > > > >>> > > > >
> > >> > > > >>> > > > > Thank you very much.
> > >> > > > >>> > > > > Let me try and let you know how it goes.
> > >> > > > >>> > > > > Thank you.
> > >> > > > >>> > > > > Regards,
> > >> > > > >>> > > > >
> > >> > > > >>> > > > > Jinwoong
> > >> > > > >>> > > > >
> > >> > > > >>> > > > > On Fri, Jul 7, 2017 at 2:59 PM, John Halley
Gotway
> via
> > >> RT <
> > >> > > > >>> > > > > met_help at ucar.edu> wrote:
> > >> > > > >>> > > > >
> > >> > > > >>> > > > >> Jinwoong,
> > >> > > > >>> > > > >>
> > >> > > > >>> > > > >> Yes, you can give it a try. The closer you
can
> make
> > >> the
> > >> > > > NetCDF
> > >> > > > >>> > files
> > >> > > > >>> > > to
> > >> > > > >>> > > > >> the CF-convention, the more likely MET will
be able
> > to
> > >> > read
> > >> > > > it.
> > >> > > > >>> > > > >>
> > >> > > > >>> > > > >> The reason that's its able to read the TRMM
data
> are
> > >> that
> > >> > > the
> > >> > > > >>> > lat/lon
> > >> > > > >>> > > > >> values are equally spaced. Non-equally
spaced
> > lat/lon
> > >> > > values
> > >> > > > >>> on a
> > >> > > > >>> > map
> > >> > > > >>> > > > >> projection require that the map projection
> > information
> > >> be
> > >> > > > >>> specified.
> > >> > > > >>> > > > >> Unfortunately, specifying map projection
> information
> > in
> > >> > > > >>> CF-compliant
> > >> > > > >>> > > > >> NetCDF
> > >> > > > >>> > > > >> files is not as easy as I think it should
be!
> > >> > > > >>> > > > >>
> > >> > > > >>> > > > >> Hope it works out ok for you.
> > >> > > > >>> > > > >>
> > >> > > > >>> > > > >> Thanks,
> > >> > > > >>> > > > >> John
> > >> > > > >>> > > > >>
> > >> > > > >>> > > > >> On Fri, Jul 7, 2017 at 12:11 PM, Jinwoong
Yoo via
> RT
> > <
> > >> > > > >>> > > met_help at ucar.edu
> > >> > > > >>> > > > >
> > >> > > > >>> > > > >> wrote:
> > >> > > > >>> > > > >>
> > >> > > > >>> > > > >> >
> > >> > > > >>> > > > >> > <URL: https://rt.rap.ucar.edu/rt/
> > >> > > > Ticket/Display.html?id=81063
> > >> > > > >>> >
> > >> > > > >>> > > > >> >
> > >> > > > >>> > > > >> > investigating not investing :)
> > >> > > > >>> > > > >> >
> > >> > > > >>> > > > >> > Thanks!
> > >> > > > >>> > > > >> > Regards,
> > >> > > > >>> > > > >> >
> > >> > > > >>> > > > >> > Jinwoong
> > >> > > > >>> > > > >> >
> > >> > > > >>> > > > >> > On Fri, Jul 7, 2017 at 2:10 PM, Jinwoong
Yoo <
> > >> > > > >>> > > jinwoong.yoo at gmail.com>
> > >> > > > >>> > > > >> > wrote:
> > >> > > > >>> > > > >> >
> > >> > > > >>> > > > >> > > Hi John,
> > >> > > > >>> > > > >> > >
> > >> > > > >>> > > > >> > > Thank you very much for your time
investing the
> > >> issue.
> > >> > > > >>> > > > >> > > I am glad to hear that there is a trick
to work
> > >> around
> > >> > > the
> > >> > > > >>> issue
> > >> > > > >>> > > to
> > >> > > > >>> > > > >> read
> > >> > > > >>> > > > >> > > in TRMM data in netcdf format.
> > >> > > > >>> > > > >> > > I wonder if I can apply the same trick (
> > >> > > > >>> file_type=NETCDF_NCCF;)
> > >> > > > >>> > > to
> > >> > > > >>> > > > >> read
> > >> > > > >>> > > > >> > > in any other observation files in netcdf
> format?
> > >> > > > >>> > > > >> > > In fact, I would like to read in "home
brew"
> > netcdf
> > >> > > > dataset
> > >> > > > >>> > files
> > >> > > > >>> > > > into
> > >> > > > >>> > > > >> > > MET.
> > >> > > > >>> > > > >> > > One sample file of them was included in
the
> > >> uploaded
> > >> > > data
> > >> > > > >>> > folder (
> > >> > > > >>> > > > >> > > sample_tmax.nc).
> > >> > > > >>> > > > >> > > The data in this sample file was
originally
> > >> generated
> > >> > by
> > >> > > > VIC
> > >> > > > >>> > > model.
> > >> > > > >>> > > > >> > > Then the file format was converted into
a
> generic
> > >> > netcdf
> > >> > > > >>> file
> > >> > > > >>> > > format
> > >> > > > >>> > > > >> > > although the dimension names are T, X, Y
not
> > time,
> > >> > lat,
> > >> > > > lon.
> > >> > > > >>> > > > >> > > But their coordinates have units in
> > "degrees_east"
> > >> or
> > >> > > > >>> > > > "degrees_north"
> > >> > > > >>> > > > >> as
> > >> > > > >>> > > > >> > > well as their long_name as "Longitude"
and
> > >> "Latitude",
> > >> > > > >>> > > respectively.
> > >> > > > >>> > > > >> > >
> > >> > > > >>> > > > >> > > Of course, I will try to read those in
for
> > >> Grid-stat
> > >> > > > today.
> > >> > > > >>> > > > >> > > But I would like to hear from you if the
trick
> (
> > >> > > > >>> > > > >> file_type=NETCDF_NCCF;)
> > >> > > > >>> > > > >> > > can be applied generally, which I wish
very
> much.
> > >> > > > >>> > > > >> > >
> > >> > > > >>> > > > >> > > Thank you so much, John.
> > >> > > > >>> > > > >> > >
> > >> > > > >>> > > > >> > > Regards,
> > >> > > > >>> > > > >> > >
> > >> > > > >>> > > > >> > > Jinwoong Yoo
> > >> > > > >>> > > > >> > >
> > >> > > > >>> > > > >> > >
> > >> > > > >>> > > > >> > > On Fri, Jul 7, 2017 at 1:16 PM, John
Halley
> > Gotway
> > >> via
> > >> > > RT
> > >> > > > <
> > >> > > > >>> > > > >> > > met_help at ucar.edu> wrote:
> > >> > > > >>> > > > >> > >
> > >> > > > >>> > > > >> > >> Jinwoong,
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >> Thanks for sending your sample data and
for
> your
> > >> > > patience
> > >> > > > >>> > while I
> > >> > > > >>> > > > was
> > >> > > > >>> > > > >> > out
> > >> > > > >>> > > > >> > >> of town.
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >> Using met-6.0, I'm able to process the
TRMM
> > NetCDF
> > >> > file
> > >> > > > you
> > >> > > > >>> > sent.
> > >> > > > >>> > > > >> The
> > >> > > > >>> > > > >> > >> trick is that I had to tell it which
NetCDF
> file
> > >> type
> > >> > > > >>> should be
> > >> > > > >>> > > > used
> > >> > > > >>> > > > >> to
> > >> > > > >>> > > > >> > >> interpret the data. Using "file_type =
> > >> NETCDF_NCCF;"
> > >> > > I'm
> > >> > > > >>> > telling
> > >> > > > >>> > > > >> MET to
> > >> > > > >>> > > > >> > >> interpret it as if it were a CF-
compliant
> NetCDF
> > >> > file:
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >> met-6.0/bin/plot_data_plane \
> > >> > > > >>> > > > >> > >> trmm_daily.20051231.7.nc
> > trmm_daily.20051231.7.ps
> > >> \
> > >> > > > >>> > > > >> > >> 'name="precipitation"; level="(*,*)";
> > >> > > > >>> file_type=NETCDF_NCCF;'
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >> DEBUG 1: Opening data file:
> > >> trmm_daily.20051231.7.nc
> > >> > > > >>> > > > >> > >> WARNING: NcCfFile::open() -> could not
> determine
> > >> the
> > >> > > > valid
> > >> > > > >>> > time,
> > >> > > > >>> > > > >> using
> > >> > > > >>> > > > >> > 0.
> > >> > > > >>> > > > >> > >> WARNING: NcCfFile::open() -> could not
> determine
> > >> the
> > >> > > > valid
> > >> > > > >>> > time,
> > >> > > > >>> > > > >> using
> > >> > > > >>> > > > >> > 0.
> > >> > > > >>> > > > >> > >> DEBUG 1: Creating postscript file:
> > >> > > > >>> trmm_daily.20051231.7.ps
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >> The plot_data_plane tool is able to
read the
> > data,
> > >> > and
> > >> > > > I've
> > >> > > > >>> > > > attached
> > >> > > > >>> > > > >> the
> > >> > > > >>> > > > >> > >> resulting image. However, notice the
warning
> > >> > messages
> > >> > > > >>> about
> > >> > > > >>> > the
> > >> > > > >>> > > > >> valid
> > >> > > > >>> > > > >> > >> time.
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >> Using ncdump to see that file
attributes, I
> see
> > >> this
> > >> > > > timing
> > >> > > > >>> > > > >> information:
> > >> > > > >>> > > > >> > >> :HDF5_GLOBAL.BeginDate
=
> > >> > "2005-12-31" ;
> > >> > > > >>> > > > >> > >> :HDF5_GLOBAL.BeginTime
=
> > >> > > "01:30:00.000Z"
> > >> > > > ;
> > >> > > > >>> > > > >> > >> :HDF5_GLOBAL.EndDate =
> > >> "2006-01-01" ;
> > >> > > > >>> > > > >> > >> :HDF5_GLOBAL.EndTime =
> > >> > "01:29:59.999Z"
> > >> > > ;
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >> However that is not the CF-compliant
way of
> > >> > specifying
> > >> > > > >>> timing
> > >> > > > >>> > > info.
> > >> > > > >>> > > > >> So
> > >> > > > >>> > > > >> > >> while MET will be able to read the
data, the
> > >> timing
> > >> > > info
> > >> > > > >>> won't
> > >> > > > >>> > be
> > >> > > > >>> > > > >> > accurate
> > >> > > > >>> > > > >> > >> in the MET output files. Instead,
you'll see
> > >> > > "19700101"
> > >> > > > >>> which
> > >> > > > >>> > is
> > >> > > > >>> > > > >> > unixtime
> > >> > > > >>> > > > >> > >> = 0.
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >> Another option would be pulling the
binary
> TRMM
> > >> data
> > >> > > and
> > >> > > > >>> using
> > >> > > > >>> > > this
> > >> > > > >>> > > > >> > >> Rscript
> > >> > > > >>> > > > >> > >> to convert the binary to NetCDF:
> > >> > > > >>> > > > >> > >> http://www.dtcenter.org/met/
> > >> > > users/downloads/Rscripts/
> > >> > > > >>> > > > trmmbin2nc.R
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >> However, I haven't done this in a while
and am
> > not
> > >> > sure
> > >> > > > if
> > >> > > > >>> > you'll
> > >> > > > >>> > > > run
> > >> > > > >>> > > > >> > into
> > >> > > > >>> > > > >> > >> any issues.
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >> Hope that helps.
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >> Thanks,
> > >> > > > >>> > > > >> > >> John
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >> On Thu, Jul 6, 2017 at 7:33 PM,
Jinwoong Yoo
> via
> > >> RT <
> > >> > > > >>> > > > >> met_help at ucar.edu>
> > >> > > > >>> > > > >> > >> wrote:
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >> >
> > >> > > > >>> > > > >> > >> > <URL: https://rt.rap.ucar.edu/rt/
> > >> > > > >>> > Ticket/Display.html?id=81063
> > >> > > > >>> > > >
> > >> > > > >>> > > > >> > >> >
> > >> > > > >>> > > > >> > >> > Hi John,
> > >> > > > >>> > > > >> > >> >
> > >> > > > >>> > > > >> > >> > Thank you very much.
> > >> > > > >>> > > > >> > >> > Regards,
> > >> > > > >>> > > > >> > >> >
> > >> > > > >>> > > > >> > >> > Jinwoong
> > >> > > > >>> > > > >> > >> >
> > >> > > > >>> > > > >> > >> > On Thu, Jul 6, 2017 at 10:41 AM, John
Halley
> > >> Gotway
> > >> > > via
> > >> > > > >>> RT <
> > >> > > > >>> > > > >> > >> > met_help at ucar.edu> wrote:
> > >> > > > >>> > > > >> > >> >
> > >> > > > >>> > > > >> > >> > > Jinwoong,
> > >> > > > >>> > > > >> > >> > >
> > >> > > > >>> > > > >> > >> > > I'm out of the office today but
will take
> a
> > >> > closer
> > >> > > > look
> > >> > > > >>> > > > tomorrow.
> > >> > > > >>> > > > >> > >> > >
> > >> > > > >>> > > > >> > >> > > Thanks
> > >> > > > >>> > > > >> > >> > > John
> > >> > > > >>> > > > >> > >> > >
> > >> > > > >>> > > > >> > >> > > On Mon, Jul 3, 2017 at 12:20 PM
Jinwoong
> Yoo
> > >> via
> > >> > > RT <
> > >> > > > >>> > > > >> > >> met_help at ucar.edu>
> > >> > > > >>> > > > >> > >> > > wrote:
> > >> > > > >>> > > > >> > >> > >
> > >> > > > >>> > > > >> > >> > > >
> > >> > > > >>> > > > >> > >> > > > <URL: https://rt.rap.ucar.edu/rt/
> > >> > > > >>> > > > Ticket/Display.html?id=81063
> > >> > > > >>> > > > >> >
> > >> > > > >>> > > > >> > >> > > >
> > >> > > > >>> > > > >> > >> > > > Hi John,
> > >> > > > >>> > > > >> > >> > > >
> > >> > > > >>> > > > >> > >> > > > Thank you for your reply.
> > >> > > > >>> > > > >> > >> > > > I uploaded my data as in
Yoo_data4.tar
> on
> > >> the
> > >> > ftp
> > >> > > > >>> site.
> > >> > > > >>> > > > >> > >> > > > I included several files for the
message
> > of
> > >> ID
> > >> > > of [
> > >> > > > >>> > > > >> > rt.rap.ucar.edu
> > >> > > > >>> > > > >> > >> > > #81074]
> > >> > > > >>> > > > >> > >> > > > as well.
> > >> > > > >>> > > > >> > >> > > > Thank you.
> > >> > > > >>> > > > >> > >> > > > Regards,
> > >> > > > >>> > > > >> > >> > > >
> > >> > > > >>> > > > >> > >> > > > Jinwoong
> > >> > > > >>> > > > >> > >> > > >
> > >> > > > >>> > > > >> > >> > > > On Mon, Jul 3, 2017 at 12:46 PM,
John
> > Halley
> > >> > > Gotway
> > >> > > > >>> via
> > >> > > > >>> > RT
> > >> > > > >>> > > <
> > >> > > > >>> > > > >> > >> > > > met_help at ucar.edu> wrote:
> > >> > > > >>> > > > >> > >> > > >
> > >> > > > >>> > > > >> > >> > > > > Jinwoong,
> > >> > > > >>> > > > >> > >> > > > >
> > >> > > > >>> > > > >> > >> > > > > I see that you're having
trouble
> > reading a
> > >> > TRMM
> > >> > > > >>> NetCDF
> > >> > > > >>> > > file
> > >> > > > >>> > > > >> into
> > >> > > > >>> > > > >> > >> MET.
> > >> > > > >>> > > > >> > >> > > > Can
> > >> > > > >>> > > > >> > >> > > > > you please post the problematic
file
> to
> > >> our
> > >> > > > >>> anonymous
> > >> > > > >>> > ftp
> > >> > > > >>> > > > >> site
> > >> > > > >>> > > > >> > so
> > >> > > > >>> > > > >> > >> I
> > >> > > > >>> > > > >> > >> > can
> > >> > > > >>> > > > >> > >> > > > > take a look?
> > >> > > > >>> > > > >> > >> > > > >
> > >> > > > >>> > > > >> > >> > > > > http://www.dtcenter.org/met/
> > >> > > > >>> > > users/support/met_help.php#ftp
> > >> > > > >>> > > > >> > >> > > > >
> > >> > > > >>> > > > >> > >> > > > > Thanks,
> > >> > > > >>> > > > >> > >> > > > > John Halley Gotway
> > >> > > > >>> > > > >> > >> > > > >
> > >> > > > >>> > > > >> > >> > > > > On Mon, Jul 3, 2017 at 9:56 AM,
> Jinwoong
> > >> Yoo
> > >> > > via
> > >> > > > >>> RT <
> > >> > > > >>> > > > >> > >> > met_help at ucar.edu
> > >> > > > >>> > > > >> > >> > > >
> > >> > > > >>> > > > >> > >> > > > > wrote:
> > >> > > > >>> > > > >> > >> > > > >
> > >> > > > >>> > > > >> > >> > > > > >
> > >> > > > >>> > > > >> > >> > > > > > <URL:
> https://rt.rap.ucar.edu/rt/Tic
> > >> > > > >>> > > > >> ket/Display.html?id=81063
> > >> > > > >>> > > > >> > >
> > >> > > > >>> > > > >> > >> > > > > >
> > >> > > > >>> > > > >> > >> > > > > > Hi,
> > >> > > > >>> > > > >> > >> > > > > >
> > >> > > > >>> > > > >> > >> > > > > > TRMM data comes in as netCDF-
4
> classic
> > >> > model.
> > >> > > > >>> > > > >> > >> > > > > > I changed it to netCDF
classic and
> run
> > >> the
> > >> > > same
> > >> > > > >>> > command
> > >> > > > >>> > > > >> for a
> > >> > > > >>> > > > >> > >> test.
> > >> > > > >>> > > > >> > >> > > > > > But I got the same error as
below.
> > >> > > > >>> > > > >> > >> > > > > >
> > >> > > > >>> > > > >> > >> > > > > > yoo108 at halstead-
fe00:*/scratch
> > >> > > > >>> /halstead/y/yoo108/
> > >> > > > >>> > TRMM*
> > >> > > > >>> > > $
> > >> > > > >>> > > > >> > >> > > > > > ~/met-6.0_bugfix/bin/regrid_
> > data_plane
> > >> > > > >>> > > > >> > >> /scratch/halstead/y/yoo108/
> > >> > > > >>> > > > >> > >> > > TRMM/
> > >> > > > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > >> > > > >>> > > > >> > >> > > > > >
/scratch/halstead/y/yoo108/ND_
> > >> > > > >>> grided_obs/daily_T2m_
> > >> > > > >>> > > > >> > >> > > maxminmean_1976.nc
> > >> > > > >>> > > > >> > >> > > > > >
/scratch/halstead/y/yoo108/TRMM/
> > >> > > > >>> > regrid_trmm_sample.nc
> > >> > > > >>> > > > >> -field
> > >> > > > >>> > > > >> > >> > > > > > 'name="precipitation";'
> > >> > > > >>> > > > >> > >> > > > > >
> > >> > > > >>> > > > >> > >> > > > > > DEBUG 1: Reading data file:
> > >> > > > >>> > > > /scratch/halstead/y/yoo108/TRM
> > >> > > > >>> > > > >> M/
> > >> > > > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc
> > >> > > > >>> > > > >> > >> > > > > >
> > >> > > > >>> > > > >> > >> > > > > > ERROR :
> > >> > > > >>> > > > >> > >> > > > > >
> > >> > > > >>> > > > >> > >> > > > > > ERROR : process_data_file()
->
> > >> > > > >>> > > > >> "/scratch/halstead/y/yoo108/TR
> > >> > > > >>> > > > >> > >> MM/
> > >> > > > >>> > > > >> > >> > > > > > trmm_daily_nc3.20051231.7.nc"
not a
> > >> valid
> > >> > > data
> > >> > > > >>> file
> > >> > > > >>> > > > >> > >> > > > > >
> > >> > > > >>> > > > >> > >> > > > > > Thank you.
> > >> > > > >>> > > > >> > >> > > > > >
> > >> > > > >>> > > > >> > >> > > > > > Regards,
> > >> > > > >>> > > > >> > >> > > > > >
> > >> > > > >>> > > > >> > >> > > > > >
> > >> > > > >>> > > > >> > >> > > > > > Jinwoong
> > >> > > > >>> > > > >> > >> > > > > >
> > >> > > > >>> > > > >> > >> > > > > > On Mon, Jul 3, 2017 at 11:41
AM,
> > >> Jinwoong
> > >> > > Yoo <
> > >> > > > >>> > > > >> > >> > > jinwoong.yoo at gmail.com>
> > >> > > > >>> > > > >> > >> > > > > > wrote:
> > >> > > > >>> > > > >> > >> > > > > >
> > >> > > > >>> > > > >> > >> > > > > > > Hi,
> > >> > > > >>> > > > >> > >> > > > > > >
> > >> > > > >>> > > > >> > >> > > > > > > I noticed that TRMM data
dimension
> > was
> > >> > > (lon,
> > >> > > > >>> lat).
> > >> > > > >>> > > > >> > >> > > > > > > So I switched their order
to (lat,
> > >> lon)
> > >> > and
> > >> > > > >>> ran the
> > >> > > > >>> > > > >> command
> > >> > > > >>> > > > >> > >> > again.
> > >> > > > >>> > > > >> > >> > > > > > > However, I got the same
error
> > message
> > >> as
> > >> > > > below.
> > >> > > > >>> > > > >> > >> > > > > > >
> > >> > > > >>> > > > >> > >> > > > > > > yoo108 at halstead-
fe00:*/scratch
> > >> > > > >>> /halstead/y/yoo108/
> > >> > > > >>> > > TRMM*
> > >> > > > >>> > > > $
> > >> > > > >>> > > > >> > >> > > > > > > ~/met-
6.0_bugfix/bin/regrid_da
> > >> ta_plane
> > >> > > > >>> > > > >> > >> > /scratch/halstead/y/yoo108/
> > >> > > > >>> > > > >> > >> > > > > TRMM/
> > >> > > > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > >> > > > >>> > > > /scratch/halstead/y/yoo108/ND_
> > >> > > > >>> > > > >> > >> > > > > > >
grided_obs/daily_T2m_maxminmea
> > >> n_1976.nc
> > >> > > > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > >> > > > >>> > > > >> > >> > > > > TRMM/
> > >> > > > >>> > > > >> > >> > > > > > > regrid_trmm_sample.nc
-field
> > >> > > > >>> > 'name="precipitation";'
> > >> > > > >>> > > > >> > >> > > > > > >
> > >> > > > >>> > > > >> > >> > > > > > > DEBUG 1: Reading data file:
> > >> > > > >>> > > > >> /scratch/halstead/y/yoo108/TRM
> > >> > > > >>> > > > >> > M/
> > >> > > > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc
> > >> > > > >>> > > > >> > >> > > > > > >
> > >> > > > >>> > > > >> > >> > > > > > > ERROR :
> > >> > > > >>> > > > >> > >> > > > > > >
> > >> > > > >>> > > > >> > >> > > > > > > ERROR :
process_data_file() ->
> > >> > > > >>> > > > >> > "/scratch/halstead/y/yoo108/TR
> > >> > > > >>> > > > >> > >> > MM/
> > >> > > > >>> > > > >> > >> > > > > > > trmm_daily.20051231.7.nc"
not a
> > valid
> > >> > data
> > >> > > > >>> file
> > >> > > > >>> > > > >> > >> > > > > > >
> > >> > > > >>> > > > >> > >> > > > > > >
> > >> > > > >>> > > > >> > >> > > > > > > Thank you.
> > >> > > > >>> > > > >> > >> > > > > > >
> > >> > > > >>> > > > >> > >> > > > > > > Regards,
> > >> > > > >>> > > > >> > >> > > > > > >
> > >> > > > >>> > > > >> > >> > > > > > >
> > >> > > > >>> > > > >> > >> > > > > > > Jinwoong
> > >> > > > >>> > > > >> > >> > > > > > >
> > >> > > > >>> > > > >> > >> > > > > > >
> > >> > > > >>> > > > >> > >> > > > > > >
> > >> > > > >>> > > > >> > >> > > > > > > On Thu, Jun 29, 2017 at
4:36 PM,
> > >> Jinwoong
> > >> > > > Yoo <
> > >> > > > >>> > > > >> > >> > > > jinwoong.yoo at gmail.com>
> > >> > > > >>> > > > >> > >> > > > > > > wrote:
> > >> > > > >>> > > > >> > >> > > > > > >
> > >> > > > >>> > > > >> > >> > > > > > >> Hi,
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> I got a similar result
with a
> TRMM
> > >> data.
> > >> > > > >>> > > > >> > >> > > > > > >> Please see below:
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> yoo108 at halstead-
fe01:*/scratch
> > >> > > > >>> /halstead/y/yoo108/
> > >> > > > >>> > > > TRMM*
> > >> > > > >>> > > > >> $
> > >> > > > >>> > > > >> > >> > > > > > >> ~/met-
6.0_bugfix/bin/regrid_da
> > >> ta_plane
> > >> > > > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > >> > > > >>> > > > >> > >> > > > > TRMM/
> > >> > > > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > >> > > > >>> > > > >> /scratch/halstead/y/yoo108/ND_
> > >> > > > >>> > > > >> > >> > > > > > >>
grided_obs/daily_T2m_maxminmea
> > >> n_1976.nc
> > >> > > > >>> > > > >> > >> > > /scratch/halstead/y/yoo108/
> > >> > > > >>> > > > >> > >> > > > > > TRMM/
> > >> > > > >>> > > > >> > >> > > > > > >> regrid_trmm_sample.nc
-field
> > >> > > > >>> > > 'name="precipitation";'
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> DEBUG 1: Reading data
file:
> > >> > > > >>> > > > >> /scratch/halstead/y/yoo108/TRM
> > >> > > > >>> > > > >> > M/
> > >> > > > >>> > > > >> > >> > > > > > >> 3B42RT_Daily.20051231.7.nc
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> ERROR :
process_data_file() ->
> > >> > > > >>> > > > >> > >> "/scratch/halstead/y/yoo108/TR
> > >> > > > >>> > > > >> > >> > MM/
> > >> > > > >>> > > > >> > >> > > > > > >>
3B42RT_Daily.20051231.7.nc" not
> a
> > >> valid
> > >> > > > data
> > >> > > > >>> file
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> A part of ncdump output
for the
> > TRMM
> > >> > data
> > >> > > is
> > >> > > > >>> > pasted
> > >> > > > >>> > > > >> below:
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> yoo108 at halstead-
fe01:*/scratch
> > >> > > > >>> /halstead/y/yoo108/
> > >> > > > >>> > > > TRMM*
> > >> > > > >>> > > > >> $
> > >> > > > >>> > > > >> > >> ncdump
> > >> > > > >>> > > > >> > >> > > -h
> > >> > > > >>> > > > >> > >> > > > > > >> subset_200003-
200512/3B42RT_
> > >> > > > >>> > > Daily.20051231.7.nc4.nc4
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> netcdf
> > \3B42RT_Daily.20051231.7.nc4 {
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> dimensions:
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> lon = 59 ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> lat = 58 ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> variables:
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> short
precipitation_cnt(lon,
> lat) ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> precipitation_cnt:units =
> "count" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
precipitation_cnt:long_name =
> > "Count
> > >> of
> > >> > > > valid
> > >> > > > >>> 3-hr
> > >> > > > >>> > > > >> > >> precipitation
> > >> > > > >>> > > > >> > >> > > > > > >> retrievals for the day" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
precipitation_cnt:coordinates =
> > "lat
> > >> > lon"
> > >> > > ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> precipitation_cnt:origname
=
> > >> > > > >>> "precipitation_cnt" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
precipitation_cnt:fullnamepath =
> > >> > > > >>> > > "/precipitation_cnt"
> > >> > > > >>> > > > ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> float
uncal_precipitation(lon,
> > lat) ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation:units
= "mm"
> ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation:long_name =
> > >> "Daily
> > >> > > > >>> accumulated
> > >> > > > >>> > > > >> > >> uncalibrated
> > >> > > > >>> > > > >> > >> > > > > > >> precipitation" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation:coordinates
> =
> > >> "lat
> > >> > > > lon" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation:_FillValue =
> > >> > -9999.9f
> > >> > > ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation:origname =
> > >> > > > >>> > > "uncal_precipitation" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation:fullnamepath
> =
> > >> > > > >>> > > > >> "/uncal_precipitation"
> > >> > > > >>> > > > >> > ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> short
> uncal_precipitation_cnt(lon,
> > >> lat)
> > >> > ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:units =
> > >> "count"
> > >> > ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:long_
> name
> > =
> > >> > > "Count
> > >> > > > of
> > >> > > > >>> > valid
> > >> > > > >>> > > > >> 3-hr
> > >> > > > >>> > > > >> > >> uncal
> > >> > > > >>> > > > >> > >> > > > > > >> precipitation retrievals
for the
> > >> day" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:
> > coordinates
> > >> =
> > >> > > "lat
> > >> > > > >>> lon" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
uncal_precipitation_cnt:origname
> =
> > >> > > > >>> > > > >> > >> "uncal_precipitation_cnt" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> uncal_precipitation_cnt:
> > fullnamepath
> > >> =
> > >> > > > >>> > > > >> > >> > > "/uncal_precipitation_cnt" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> float precipitation(lon,
lat) ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> precipitation:units = "mm"
;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> precipitation:long_name =
"Daily
> > >> > > accumulated
> > >> > > > >>> > > > >> precipitation
> > >> > > > >>> > > > >> > >> > > (combined
> > >> > > > >>> > > > >> > >> > > > > > >> microwave-IR) estimate" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> precipitation:coordinates
= "lat
> > >> lon" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> precipitation:_FillValue =
> > -9999.9f ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> precipitation:origname =
> > >> > "precipitation" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> precipitation:fullnamepath
=
> > >> > > > "/precipitation"
> > >> > > > >>> ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> short randomError_cnt(lon,
lat) ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:units =
"count" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:long_name
=
> "Count
> > of
> > >> > > > >>> randomError
> > >> > > > >>> > > for
> > >> > > > >>> > > > >> the
> > >> > > > >>> > > > >> > >> day" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
randomError_cnt:coordinates =
> "lat
> > >> lon"
> > >> > ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> randomError_cnt:origname =
> > >> > > > "randomError_cnt" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
randomError_cnt:fullnamepath =
> > >> > > > >>> "/randomError_cnt"
> > >> > > > >>> > ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> float randomError(lon,
lat) ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> randomError:units = "mm" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> randomError:long_name =
"Daily
> > total
> > >> > error
> > >> > > > of
> > >> > > > >>> > > combined
> > >> > > > >>> > > > >> > >> > > microwave-IR
> > >> > > > >>> > > > >> > >> > > > > > >> precipitation estimate" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> randomError:_FillValue =
> -9999.9f ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> randomError:origname =
> > "randomError"
> > >> ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> randomError:fullnamepath =
> > >> > "/randomError"
> > >> > > ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> float lat(lat) ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> lat:units =
"degrees_north" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> lat:long_name = "Latitude"
;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> lat:origname = "lat" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> lat:fullnamepath = "/lat"
;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> float lon(lon) ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> lon:units = "degrees_east"
;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> lon:long_name =
"Longitude" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> lon:origname = "lon" ;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> lon:fullnamepath = "/lon"
;
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> Thank you.
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> Regards,
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> Jinwoong
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >> On Thu, Jun 29, 2017 at
3:11 PM,
> > >> > > > >>> > met_help at ucar.edu
> > >> > > > >>> > > > via
> > >> > > > >>> > > > >> RT
> > >> > > > >>> > > > >> > <
> > >> > > > >>> > > > >> > >> > > > > > >> met_help at ucar.edu> wrote:
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >>> NOTE: THE MET TEAM HAS
LIMITED
> > >> > > AVAILABILITY
> > >> > > > >>> > BETWEEN
> > >> > > > >>> > > > >> > 5/23/17
> > >> > > > >>> > > > >> > >> AND
> > >> > > > >>> > > > >> > >> > > > > > >>> 5/30/17. RESPONSES MAY
BE
> > DELAYED.
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> Greetings,
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> This message has been
> > automatically
> > >> > > > >>> generated in
> > >> > > > >>> > > > >> response
> > >> > > > >>> > > > >> > to
> > >> > > > >>> > > > >> > >> > the
> > >> > > > >>> > > > >> > >> > > > > > >>> creation of a trouble
ticket
> > >> regarding:
> > >> > > > >>> > > > >> > >> > > > > > >>>
"regrid_data_plane: not
> a
> > >> valid
> > >> > > > data
> > >> > > > >>> > file",
> > >> > > > >>> > > > >> > >> > > > > > >>> a summary of which
appears
> below.
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> There is no need to reply
to
> this
> > >> > message
> > >> > > > >>> right
> > >> > > > >>> > > now.
> > >> > > > >>> > > > >> Your
> > >> > > > >>> > > > >> > >> > ticket
> > >> > > > >>> > > > >> > >> > > > has
> > >> > > > >>> > > > >> > >> > > > > > >>> been
> > >> > > > >>> > > > >> > >> > > > > > >>> assigned an ID of [
> > rt.rap.ucar.edu
> > >> > > > #81063].
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> Please include the
string:
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> [rt.rap.ucar.edu
> #81063]
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> in the subject line of
all
> future
> > >> > > > >>> correspondence
> > >> > > > >>> > > > about
> > >> > > > >>> > > > >> > this
> > >> > > > >>> > > > >> > >> > > issue.
> > >> > > > >>> > > > >> > >> > > > To
> > >> > > > >>> > > > >> > >> > > > > > do
> > >> > > > >>> > > > >> > >> > > > > > >>> so,
> > >> > > > >>> > > > >> > >> > > > > > >>> you may reply to this
message.
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>>
Thank
> you,
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > met_help at ucar.edu
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>>
------------------------------
> > >> > > > >>> > > > >> > >> ------------------------------
> > >> > > > >>> > > > >> > >> > > > > > >>> -------------
> > >> > > > >>> > > > >> > >> > > > > > >>> Hi,
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> I am trying to regrid one
of my
> > >> > > observation
> > >> > > > >>> files
> > >> > > > >>> > > in
> > >> > > > >>> > > > >> lat
> > >> > > > >>> > > > >> > lon
> > >> > > > >>> > > > >> > >> > > > > coordinate
> > >> > > > >>> > > > >> > >> > > > > > >>> grid to WRF curvilinear
grid.
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> I ran
bin/regrid_data_plane
> using
> > a
> > >> > > sample
> > >> > > > >>> lat
> > >> > > > >>> > lon
> > >> > > > >>> > > > grid
> > >> > > > >>> > > > >> > file
> > >> > > > >>> > > > >> > >> > and
> > >> > > > >>> > > > >> > >> > > a
> > >> > > > >>> > > > >> > >> > > > > file
> > >> > > > >>> > > > >> > >> > > > > > >>> in
> > >> > > > >>> > > > >> > >> > > > > > >>> the WRF grid. But I got
error as
> > >> shown
> > >> > > > below:
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> yoo108 at halstead-
fe00:*/scratch
> > >> > > > >>> > > > >> > /halstead/y/yoo108/ND_grided_
> > >> > > > >>> > > > >> > >> > obs*
> > >> > > > >>> > > > >> > >> > > $
> > >> > > > >>> > > > >> > >> > > > > > >>> ~/met-
6.0_bugfix/bin/regrid_da
> > >> ta_plane
> > >> > > > >>> > > > >> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_
> > >> > > grided_obs/
> > >> > > > >>> > > > >> sample_tmax.nc
> > >> > > > >>> > > > >> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_
> > >> > > > >>> > > grided_obs/daily_T2m_
> > >> > > > >>> > > > >> > >> > > > > maxminmean_1976.nc
> > >> > > > >>> > > > >> > >> > > > > > >>>
/scratch/halstead/y/yoo108/ND_
> > >> > > > >>> > > > >> > >> grided_obs/NDtoWRFgrid_sample_
> > >> > > > >>> > > > >> > >> > > > tmax.nc
> > >> > > > >>> > > > >> > >> > > > > > >>> -field
> > >> > > > >>> > > > >> > >> > > > > > >>> 'name="tmax";'
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> DEBUG 1: Reading data
file:
> > >> > > > >>> > > > >> /scratch/halstead/y/yoo108/ND_
> > >> > > > >>> > > > >> > >> > > > > grided_obs/
> > >> > > > >>> > > > >> > >> > > > > > >>> sample_tmax.nc
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> ERROR :
process_data_file() ->
> > >> > > > >>> > > > >> > >> "/scratch/halstead/y/yoo108/ND
> > >> > > > >>> > > > >> > >> > > > > > >>> _grided_obs/
> > >> > > > >>> > > > >> > >> > > > > > >>> sample_tmax.nc" not a
valid
> data
> > >> file
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> I wonder which part of
the input
> > >> file
> > >> > > does
> > >> > > > >>> not
> > >> > > > >>> > > > satisfy
> > >> > > > >>> > > > >> the
> > >> > > > >>> > > > >> > >> > MET's
> > >> > > > >>> > > > >> > >> > > > > "valid
> > >> > > > >>> > > > >> > >> > > > > > >>> file" criteria.
> > >> > > > >>> > > > >> > >> > > > > > >>> ncdump output of the
input file
> > >> looks
> > >> > as
> > >> > > > >>> below:
> > >> > > > >>> > > > >> > >> > > > > > >>> Input file was originally
> > generated
> > >> by
> > >> > > VIC
> > >> > > > >>> model
> > >> > > > >>> > > and
> > >> > > > >>> > > > >> > >> converted
> > >> > > > >>> > > > >> > >> > > into
> > >> > > > >>> > > > >> > >> > > > > cf
> > >> > > > >>> > > > >> > >> > > > > > >>> netcdf format.
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> Thank you in advance.
> > >> > > > >>> > > > >> > >> > > > > > >>> Regards,
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> Jinwoong
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> yoo108 at halstead-
fe00:*/scratch
> > >> > > > >>> > > > >> > /halstead/y/yoo108/ND_grided_
> > >> > > > >>> > > > >> > >> > obs*
> > >> > > > >>> > > > >> > >> > > $
> > >> > > > >>> > > > >> > >> > > > > > >>> ncdump -h
> > >> > > > >>> > > > >> > >> > > > > > >>> sample_tmax.nc
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> netcdf sample_tmax {
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> dimensions:
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> T = 1 ;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> X = 55 ;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> Y = 65 ;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> variables:
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> double T(T) ;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> T:units = "days since
> 1915-01-01"
> > ;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> T:long_name = "Time" ;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> double X(X) ;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> X:units = "degrees_east"
;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> X:long_name = "Longitude"
;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> double Y(Y) ;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> Y:units = "degrees_north"
;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> Y:long_name = "Latitude"
;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> double tmax(T, Y, X) ;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> tmax:units = "degC" ;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> tmax:long_name = "tmax
> calculated
> > by
> > >> > > VIC" ;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> tmax:missing_value =
-9999.f ;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> // global attributes:
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>> :production = "VIC
output" ;
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>>
> > >> > > > >>> > > > >> > >> > > > > > >>
> > >> > > > >>> > > > >> > >> > > > > > >
> > >> > > > >>> > > > >> > >> > > > > >
> > >> > > > >>> > > > >> > >> > > > > >
> > >> > > > >>> > > > >> > >> > > > >
> > >> > > > >>> > > > >> > >> > > > >
> > >> > > > >>> > > > >> > >> > > >
> > >> > > > >>> > > > >> > >> > > >
> > >> > > > >>> > > > >> > >> > >
> > >> > > > >>> > > > >> > >> > >
> > >> > > > >>> > > > >> > >> >
> > >> > > > >>> > > > >> > >> >
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >>
> > >> > > > >>> > > > >> > >
> > >> > > > >>> > > > >> >
> > >> > > > >>> > > > >> >
> > >> > > > >>> > > > >>
> > >> > > > >>> > > > >>
> > >> > > > >>> > > > >
> > >> > > > >>> > > >
> > >> > > > >>> > > >
> > >> > > > >>> > >
> > >> > > > >>> > >
> > >> > > > >>> >
> > >> > > > >>> >
> > >> > > > >>>
> > >> > > > >>>
> > >> > > > >>
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >>
> > >>
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: John Halley Gotway
Time: Fri Jul 14 15:05:13 2017
Jinwoong,
I'm sorry this took so long, but the good news is that it's an easy
fix.
The "file_type" setting needs to be defined at one higher level of
context,
like this:
fcst = {
file_type = NETCDF_PINT;
field = [
{
name = "TT";
level = [ "(0,0,*,*)" ];
cat_thresh = [];
}
];
}
The "fcst" section defines information about the input forecast file,
and
the "obs" section defines information about the input observation
file.
The "file_type" setting defines how to interpret these input files.
So the
code parses it from inside the "fcst" and "obs" dictionaries... not
separately for each entry in the "field" array.
Here's the note in the file met-6.0/data/config/README about this:
// - The "file_type" entry specifies the input file type rather than
letting
// the code determine it itself. For valid file_type values, see
"File
types"
// in the data/config/ConfigConstants file.
That obviously doesn't explain it well enough. For the next release,
I'll
update it to read:
// - The "file_type" entry specifies the input file type rather than
letting
// the code determine it itself. For valid file_type values, see
"File
types"
// in the data/config/ConfigConstants file. This entry should be
defined within
// the "fcst" or "obs" dictionaries.
// e.g.
// fcst = {
// file_type = NETCDF_NCCF;
// ...
// }
Thanks,
John
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Fri Jul 14 15:15:29 2017
Hi John,
Thank you very much for your time and your kindness.
Let me apply this to my application.
I will let you know how it goes.
Thank you.
Have a nice weekend.
Regards,
Jinwoong
On Fri, Jul 14, 2017 at 5:05 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Jinwoong,
>
> I'm sorry this took so long, but the good news is that it's an easy
fix.
>
> The "file_type" setting needs to be defined at one higher level of
context,
> like this:
>
> fcst = {
>
> file_type = NETCDF_PINT;
>
> field = [
> {
> name = "TT";
> level = [ "(0,0,*,*)" ];
> cat_thresh = [];
> }
> ];
>
> }
>
> The "fcst" section defines information about the input forecast
file, and
> the "obs" section defines information about the input observation
file.
>
> The "file_type" setting defines how to interpret these input files.
So the
> code parses it from inside the "fcst" and "obs" dictionaries... not
> separately for each entry in the "field" array.
>
> Here's the note in the file met-6.0/data/config/README about this:
>
> // - The "file_type" entry specifies the input file type rather
than
> letting
> // the code determine it itself. For valid file_type values,
see "File
> types"
> // in the data/config/ConfigConstants file.
>
> That obviously doesn't explain it well enough. For the next
release, I'll
> update it to read:
>
> // - The "file_type" entry specifies the input file type rather
than
> letting
> // the code determine it itself. For valid file_type values,
see "File
> types"
> // in the data/config/ConfigConstants file. This entry should
be
> defined within
> // the "fcst" or "obs" dictionaries.
> // e.g.
> // fcst = {
> // file_type = NETCDF_NCCF;
> // ...
> // }
>
> Thanks,
> John
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Fri Jul 28 12:46:52 2017
Hi John,
Inserting the "file_type = NETCDF_PINT;" above the field list line
seems to
work.
In this way I was able to process my met_em files against WRF grib2
files.
However, only TT and GHT variables were taken by the Gridstat.
It couldn't digest UU and VV variables in the met_em files.
Regarding the issue, I got WARNING and ERROR messages as below:
WARNING: process_scores() -> UU(0,0,*,*) not found in file:
/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.1976-01-
01_00:00:00.nc
ERROR : PinterpFile::data(NcVar *, const LongArray &, DataPlane &,
double
&) const -> can't find needed dimensions(s) for variable "UU" ... one
of
the dimensions may be staggered.
In fact, I confirmed that U-wind and V-wind variables are staggered in
the
met_em grid for the WRF processing.
Do you know how I can proceed?
Thank you.
Regards,
Jinwoong
On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo <jinwoong.yoo at gmail.com>
wrote:
> Hi John,
>
> Thank you very much for your time and your kindness.
> Let me apply this to my application.
> I will let you know how it goes.
> Thank you.
> Have a nice weekend.
>
> Regards,
>
> Jinwoong
>
> On Fri, Jul 14, 2017 at 5:05 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Jinwoong,
>>
>> I'm sorry this took so long, but the good news is that it's an easy
fix.
>>
>> The "file_type" setting needs to be defined at one higher level of
>> context,
>> like this:
>>
>> fcst = {
>>
>> file_type = NETCDF_PINT;
>>
>> field = [
>> {
>> name = "TT";
>> level = [ "(0,0,*,*)" ];
>> cat_thresh = [];
>> }
>> ];
>>
>> }
>>
>> The "fcst" section defines information about the input forecast
file, and
>> the "obs" section defines information about the input observation
file.
>>
>> The "file_type" setting defines how to interpret these input files.
So
>> the
>> code parses it from inside the "fcst" and "obs" dictionaries... not
>> separately for each entry in the "field" array.
>>
>> Here's the note in the file met-6.0/data/config/README about this:
>>
>> // - The "file_type" entry specifies the input file type rather
than
>> letting
>> // the code determine it itself. For valid file_type values,
see
>> "File
>> types"
>> // in the data/config/ConfigConstants file.
>>
>> That obviously doesn't explain it well enough. For the next
release, I'll
>> update it to read:
>>
>> // - The "file_type" entry specifies the input file type rather
than
>> letting
>> // the code determine it itself. For valid file_type values,
see
>> "File
>> types"
>> // in the data/config/ConfigConstants file. This entry should
be
>> defined within
>> // the "fcst" or "obs" dictionaries.
>> // e.g.
>> // fcst = {
>> // file_type = NETCDF_NCCF;
>> // ...
>> // }
>>
>> Thanks,
>> John
>>
>>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: John Halley Gotway
Time: Tue Aug 01 13:18:19 2017
Jinwoong,
Yes, that is a severe limitation when MET reads the NetCDF output from
WRF. It does not read variables defined on the staggered dimensions.
So
it only reads variables from mass points, not velocity points.
We recommend using the Unified Post Processor (UPP) software to
postprocess
the output of WRF. One of the things it does is interpolate data from
the
staggered dimensions to a regular grid. It writes output in GRIB1 or
GRIB2
format which MET handles nicely.
Thanks,
John
On Fri, Jul 28, 2017 at 12:46 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>
> Hi John,
>
> Inserting the "file_type = NETCDF_PINT;" above the field list line
seems to
> work.
> In this way I was able to process my met_em files against WRF grib2
files.
>
> However, only TT and GHT variables were taken by the Gridstat.
> It couldn't digest UU and VV variables in the met_em files.
> Regarding the issue, I got WARNING and ERROR messages as below:
>
> WARNING: process_scores() -> UU(0,0,*,*) not found in file:
> /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.1976-01-
01_00:00:
> 00.nc
>
> ERROR : PinterpFile::data(NcVar *, const LongArray &, DataPlane &,
double
> &) const -> can't find needed dimensions(s) for variable "UU" ...
one of
> the dimensions may be staggered.
> In fact, I confirmed that U-wind and V-wind variables are staggered
in the
> met_em grid for the WRF processing.
> Do you know how I can proceed?
> Thank you.
> Regards,
>
> Jinwoong
>
> On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> wrote:
>
> > Hi John,
> >
> > Thank you very much for your time and your kindness.
> > Let me apply this to my application.
> > I will let you know how it goes.
> > Thank you.
> > Have a nice weekend.
> >
> > Regards,
> >
> > Jinwoong
> >
> > On Fri, Jul 14, 2017 at 5:05 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Jinwoong,
> >>
> >> I'm sorry this took so long, but the good news is that it's an
easy fix.
> >>
> >> The "file_type" setting needs to be defined at one higher level
of
> >> context,
> >> like this:
> >>
> >> fcst = {
> >>
> >> file_type = NETCDF_PINT;
> >>
> >> field = [
> >> {
> >> name = "TT";
> >> level = [ "(0,0,*,*)" ];
> >> cat_thresh = [];
> >> }
> >> ];
> >>
> >> }
> >>
> >> The "fcst" section defines information about the input forecast
file,
> and
> >> the "obs" section defines information about the input observation
file.
> >>
> >> The "file_type" setting defines how to interpret these input
files. So
> >> the
> >> code parses it from inside the "fcst" and "obs" dictionaries...
not
> >> separately for each entry in the "field" array.
> >>
> >> Here's the note in the file met-6.0/data/config/README about
this:
> >>
> >> // - The "file_type" entry specifies the input file type rather
than
> >> letting
> >> // the code determine it itself. For valid file_type values,
see
> >> "File
> >> types"
> >> // in the data/config/ConfigConstants file.
> >>
> >> That obviously doesn't explain it well enough. For the next
release,
> I'll
> >> update it to read:
> >>
> >> // - The "file_type" entry specifies the input file type rather
than
> >> letting
> >> // the code determine it itself. For valid file_type values,
see
> >> "File
> >> types"
> >> // in the data/config/ConfigConstants file. This entry
should be
> >> defined within
> >> // the "fcst" or "obs" dictionaries.
> >> // e.g.
> >> // fcst = {
> >> // file_type = NETCDF_NCCF;
> >> // ...
> >> // }
> >>
> >> Thanks,
> >> John
> >>
> >>
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Tue Aug 01 13:26:11 2017
Hi John,
I see.
Thank you very much for your thoughts.
Regards,
Jinwoong
On Tue, Aug 1, 2017 at 3:18 PM, John Halley Gotway via RT
<met_help at ucar.edu
> wrote:
> Jinwoong,
>
> Yes, that is a severe limitation when MET reads the NetCDF output
from
> WRF. It does not read variables defined on the staggered
dimensions. So
> it only reads variables from mass points, not velocity points.
>
> We recommend using the Unified Post Processor (UPP) software to
postprocess
> the output of WRF. One of the things it does is interpolate data
from the
> staggered dimensions to a regular grid. It writes output in GRIB1
or GRIB2
> format which MET handles nicely.
>
> Thanks,
> John
>
> On Fri, Jul 28, 2017 at 12:46 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >
> > Hi John,
> >
> > Inserting the "file_type = NETCDF_PINT;" above the field list line
seems
> to
> > work.
> > In this way I was able to process my met_em files against WRF
grib2
> files.
> >
> > However, only TT and GHT variables were taken by the Gridstat.
> > It couldn't digest UU and VV variables in the met_em files.
> > Regarding the issue, I got WARNING and ERROR messages as below:
> >
> > WARNING: process_scores() -> UU(0,0,*,*) not found in file:
> > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.1976-01-
01_00:00:
> > 00.nc
> >
> > ERROR : PinterpFile::data(NcVar *, const LongArray &, DataPlane
&,
> double
> > &) const -> can't find needed dimensions(s) for variable "UU" ...
one of
> > the dimensions may be staggered.
> > In fact, I confirmed that U-wind and V-wind variables are
staggered in
> the
> > met_em grid for the WRF processing.
> > Do you know how I can proceed?
> > Thank you.
> > Regards,
> >
> > Jinwoong
> >
> > On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > wrote:
> >
> > > Hi John,
> > >
> > > Thank you very much for your time and your kindness.
> > > Let me apply this to my application.
> > > I will let you know how it goes.
> > > Thank you.
> > > Have a nice weekend.
> > >
> > > Regards,
> > >
> > > Jinwoong
> > >
> > > On Fri, Jul 14, 2017 at 5:05 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >> Jinwoong,
> > >>
> > >> I'm sorry this took so long, but the good news is that it's an
easy
> fix.
> > >>
> > >> The "file_type" setting needs to be defined at one higher level
of
> > >> context,
> > >> like this:
> > >>
> > >> fcst = {
> > >>
> > >> file_type = NETCDF_PINT;
> > >>
> > >> field = [
> > >> {
> > >> name = "TT";
> > >> level = [ "(0,0,*,*)" ];
> > >> cat_thresh = [];
> > >> }
> > >> ];
> > >>
> > >> }
> > >>
> > >> The "fcst" section defines information about the input forecast
file,
> > and
> > >> the "obs" section defines information about the input
observation
> file.
> > >>
> > >> The "file_type" setting defines how to interpret these input
files.
> So
> > >> the
> > >> code parses it from inside the "fcst" and "obs" dictionaries...
not
> > >> separately for each entry in the "field" array.
> > >>
> > >> Here's the note in the file met-6.0/data/config/README about
this:
> > >>
> > >> // - The "file_type" entry specifies the input file type
rather than
> > >> letting
> > >> // the code determine it itself. For valid file_type
values, see
> > >> "File
> > >> types"
> > >> // in the data/config/ConfigConstants file.
> > >>
> > >> That obviously doesn't explain it well enough. For the next
release,
> > I'll
> > >> update it to read:
> > >>
> > >> // - The "file_type" entry specifies the input file type
rather than
> > >> letting
> > >> // the code determine it itself. For valid file_type
values, see
> > >> "File
> > >> types"
> > >> // in the data/config/ConfigConstants file. This entry
should be
> > >> defined within
> > >> // the "fcst" or "obs" dictionaries.
> > >> // e.g.
> > >> // fcst = {
> > >> // file_type = NETCDF_NCCF;
> > >> // ...
> > >> // }
> > >>
> > >> Thanks,
> > >> John
> > >>
> > >>
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Tue Aug 08 11:59:32 2017
Hi John,
I know surface variables use "Z" and pressure level variables use "P".
How can I correctly specify the level for the below ground variables
such
as soil moisture?
Can I use "Z", "G", "L", or something else?
It is hard to find it from the Users' Guide.
I have four layers of soil moisture at the NARR data set.
Thank you very much.
Regards,
Jinwoong
On Tue, Aug 1, 2017 at 3:26 PM, Jinwoong Yoo <jinwoong.yoo at gmail.com>
wrote:
> Hi John,
>
> I see.
> Thank you very much for your thoughts.
> Regards,
>
> Jinwoong
>
> On Tue, Aug 1, 2017 at 3:18 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Jinwoong,
>>
>> Yes, that is a severe limitation when MET reads the NetCDF output
from
>> WRF. It does not read variables defined on the staggered
dimensions. So
>> it only reads variables from mass points, not velocity points.
>>
>> We recommend using the Unified Post Processor (UPP) software to
>> postprocess
>> the output of WRF. One of the things it does is interpolate data
from the
>> staggered dimensions to a regular grid. It writes output in GRIB1
or
>> GRIB2
>> format which MET handles nicely.
>>
>> Thanks,
>> John
>>
>> On Fri, Jul 28, 2017 at 12:46 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
>> wrote:
>>
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>> >
>> > Hi John,
>> >
>> > Inserting the "file_type = NETCDF_PINT;" above the field list
line
>> seems to
>> > work.
>> > In this way I was able to process my met_em files against WRF
grib2
>> files.
>> >
>> > However, only TT and GHT variables were taken by the Gridstat.
>> > It couldn't digest UU and VV variables in the met_em files.
>> > Regarding the issue, I got WARNING and ERROR messages as below:
>> >
>> > WARNING: process_scores() -> UU(0,0,*,*) not found in file:
>> > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.1976-01-
01_00:00:
>> > 00.nc
>> >
>> > ERROR : PinterpFile::data(NcVar *, const LongArray &, DataPlane
&,
>> double
>> > &) const -> can't find needed dimensions(s) for variable "UU" ...
one of
>> > the dimensions may be staggered.
>> > In fact, I confirmed that U-wind and V-wind variables are
staggered in
>> the
>> > met_em grid for the WRF processing.
>> > Do you know how I can proceed?
>> > Thank you.
>> > Regards,
>> >
>> > Jinwoong
>> >
>> > On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
>> > wrote:
>> >
>> > > Hi John,
>> > >
>> > > Thank you very much for your time and your kindness.
>> > > Let me apply this to my application.
>> > > I will let you know how it goes.
>> > > Thank you.
>> > > Have a nice weekend.
>> > >
>> > > Regards,
>> > >
>> > > Jinwoong
>> > >
>> > > On Fri, Jul 14, 2017 at 5:05 PM, John Halley Gotway via RT <
>> > > met_help at ucar.edu> wrote:
>> > >
>> > >> Jinwoong,
>> > >>
>> > >> I'm sorry this took so long, but the good news is that it's an
easy
>> fix.
>> > >>
>> > >> The "file_type" setting needs to be defined at one higher
level of
>> > >> context,
>> > >> like this:
>> > >>
>> > >> fcst = {
>> > >>
>> > >> file_type = NETCDF_PINT;
>> > >>
>> > >> field = [
>> > >> {
>> > >> name = "TT";
>> > >> level = [ "(0,0,*,*)" ];
>> > >> cat_thresh = [];
>> > >> }
>> > >> ];
>> > >>
>> > >> }
>> > >>
>> > >> The "fcst" section defines information about the input
forecast file,
>> > and
>> > >> the "obs" section defines information about the input
observation
>> file.
>> > >>
>> > >> The "file_type" setting defines how to interpret these input
files.
>> So
>> > >> the
>> > >> code parses it from inside the "fcst" and "obs"
dictionaries... not
>> > >> separately for each entry in the "field" array.
>> > >>
>> > >> Here's the note in the file met-6.0/data/config/README about
this:
>> > >>
>> > >> // - The "file_type" entry specifies the input file type
rather
>> than
>> > >> letting
>> > >> // the code determine it itself. For valid file_type
values, see
>> > >> "File
>> > >> types"
>> > >> // in the data/config/ConfigConstants file.
>> > >>
>> > >> That obviously doesn't explain it well enough. For the next
release,
>> > I'll
>> > >> update it to read:
>> > >>
>> > >> // - The "file_type" entry specifies the input file type
rather
>> than
>> > >> letting
>> > >> // the code determine it itself. For valid file_type
values, see
>> > >> "File
>> > >> types"
>> > >> // in the data/config/ConfigConstants file. This entry
should be
>> > >> defined within
>> > >> // the "fcst" or "obs" dictionaries.
>> > >> // e.g.
>> > >> // fcst = {
>> > >> // file_type = NETCDF_NCCF;
>> > >> // ...
>> > >> // }
>> > >>
>> > >> Thanks,
>> > >> John
>> > >>
>> > >>
>> > >
>> >
>> >
>>
>>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Minna Win
Time: Tue Aug 08 12:09:01 2017
Hi Jinwoong,
This is Minna, another developer on the MET team. I have experienced
the
same issue, especially with uncommon data sets. John showed me how to
use
MET's plot_data_plane to test whether to use 'Z', 'G', or 'L':
Try running plot_data_plane in the following manner, but replace
$MET_BIN
for the location of your MET binaries, replace <grib_file> for the
full
path to your grib1 or grib2 data file, replace <output_ps> for the
name of
the output plot, and replace "TMP" with your variable of interest:
$MET_BIN/plot_data_plane \
<grib file> \
<output ps file> \
'name="TMP"; level="Z0";' \
-v 4
If the correct level descriptor works, then the log (output to stdout)
will
indicate that a match has been found with the record number. I hope
this
helps.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Tue, Aug 8, 2017 at 5:59 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>
> Hi John,
>
>
> I know surface variables use "Z" and pressure level variables use
"P".
> How can I correctly specify the level for the below ground variables
such
> as soil moisture?
>
> Can I use "Z", "G", "L", or something else?
> It is hard to find it from the Users' Guide.
> I have four layers of soil moisture at the NARR data set.
>
> Thank you very much.
> Regards,
>
> Jinwoong
>
> On Tue, Aug 1, 2017 at 3:26 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> wrote:
>
> > Hi John,
> >
> > I see.
> > Thank you very much for your thoughts.
> > Regards,
> >
> > Jinwoong
> >
> > On Tue, Aug 1, 2017 at 3:18 PM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> >> Jinwoong,
> >>
> >> Yes, that is a severe limitation when MET reads the NetCDF output
from
> >> WRF. It does not read variables defined on the staggered
dimensions.
> So
> >> it only reads variables from mass points, not velocity points.
> >>
> >> We recommend using the Unified Post Processor (UPP) software to
> >> postprocess
> >> the output of WRF. One of the things it does is interpolate data
from
> the
> >> staggered dimensions to a regular grid. It writes output in
GRIB1 or
> >> GRIB2
> >> format which MET handles nicely.
> >>
> >> Thanks,
> >> John
> >>
> >> On Fri, Jul 28, 2017 at 12:46 PM, Jinwoong Yoo via RT <
> met_help at ucar.edu>
> >> wrote:
> >>
> >> >
> >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >> >
> >> > Hi John,
> >> >
> >> > Inserting the "file_type = NETCDF_PINT;" above the field list
line
> >> seems to
> >> > work.
> >> > In this way I was able to process my met_em files against WRF
grib2
> >> files.
> >> >
> >> > However, only TT and GHT variables were taken by the Gridstat.
> >> > It couldn't digest UU and VV variables in the met_em files.
> >> > Regarding the issue, I got WARNING and ERROR messages as below:
> >> >
> >> > WARNING: process_scores() -> UU(0,0,*,*) not found in file:
> >> > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> 1976-01-01_00:00:
> >> > 00.nc
> >> >
> >> > ERROR : PinterpFile::data(NcVar *, const LongArray &,
DataPlane &,
> >> double
> >> > &) const -> can't find needed dimensions(s) for variable "UU"
... one
> of
> >> > the dimensions may be staggered.
> >> > In fact, I confirmed that U-wind and V-wind variables are
staggered in
> >> the
> >> > met_em grid for the WRF processing.
> >> > Do you know how I can proceed?
> >> > Thank you.
> >> > Regards,
> >> >
> >> > Jinwoong
> >> >
> >> > On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com
> >
> >> > wrote:
> >> >
> >> > > Hi John,
> >> > >
> >> > > Thank you very much for your time and your kindness.
> >> > > Let me apply this to my application.
> >> > > I will let you know how it goes.
> >> > > Thank you.
> >> > > Have a nice weekend.
> >> > >
> >> > > Regards,
> >> > >
> >> > > Jinwoong
> >> > >
> >> > > On Fri, Jul 14, 2017 at 5:05 PM, John Halley Gotway via RT <
> >> > > met_help at ucar.edu> wrote:
> >> > >
> >> > >> Jinwoong,
> >> > >>
> >> > >> I'm sorry this took so long, but the good news is that it's
an easy
> >> fix.
> >> > >>
> >> > >> The "file_type" setting needs to be defined at one higher
level of
> >> > >> context,
> >> > >> like this:
> >> > >>
> >> > >> fcst = {
> >> > >>
> >> > >> file_type = NETCDF_PINT;
> >> > >>
> >> > >> field = [
> >> > >> {
> >> > >> name = "TT";
> >> > >> level = [ "(0,0,*,*)" ];
> >> > >> cat_thresh = [];
> >> > >> }
> >> > >> ];
> >> > >>
> >> > >> }
> >> > >>
> >> > >> The "fcst" section defines information about the input
forecast
> file,
> >> > and
> >> > >> the "obs" section defines information about the input
observation
> >> file.
> >> > >>
> >> > >> The "file_type" setting defines how to interpret these input
files.
> >> So
> >> > >> the
> >> > >> code parses it from inside the "fcst" and "obs"
dictionaries... not
> >> > >> separately for each entry in the "field" array.
> >> > >>
> >> > >> Here's the note in the file met-6.0/data/config/README about
this:
> >> > >>
> >> > >> // - The "file_type" entry specifies the input file type
rather
> >> than
> >> > >> letting
> >> > >> // the code determine it itself. For valid file_type
values,
> see
> >> > >> "File
> >> > >> types"
> >> > >> // in the data/config/ConfigConstants file.
> >> > >>
> >> > >> That obviously doesn't explain it well enough. For the next
> release,
> >> > I'll
> >> > >> update it to read:
> >> > >>
> >> > >> // - The "file_type" entry specifies the input file type
rather
> >> than
> >> > >> letting
> >> > >> // the code determine it itself. For valid file_type
values,
> see
> >> > >> "File
> >> > >> types"
> >> > >> // in the data/config/ConfigConstants file. This entry
should
> be
> >> > >> defined within
> >> > >> // the "fcst" or "obs" dictionaries.
> >> > >> // e.g.
> >> > >> // fcst = {
> >> > >> // file_type = NETCDF_NCCF;
> >> > >> // ...
> >> > >> // }
> >> > >>
> >> > >> Thanks,
> >> > >> John
> >> > >>
> >> > >>
> >> > >
> >> >
> >> >
> >>
> >>
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Tue Aug 08 12:36:17 2017
Hi Minna,
Thank you very much for your note.
Then, isn't there any letter specifically designated for below ground
levels?
Let me try with "Z" (i.g., "Z1", "Z2", "Z3", and "Z4") first.
Thank you.
Regards,
Jinwoong
On Tue, Aug 8, 2017 at 2:09 PM, Minna Win via RT <met_help at ucar.edu>
wrote:
> Hi Jinwoong,
>
> This is Minna, another developer on the MET team. I have
experienced the
> same issue, especially with uncommon data sets. John showed me how
to use
> MET's plot_data_plane to test whether to use 'Z', 'G', or 'L':
> Try running plot_data_plane in the following manner, but replace
$MET_BIN
> for the location of your MET binaries, replace <grib_file> for the
full
> path to your grib1 or grib2 data file, replace <output_ps> for the
name of
> the output plot, and replace "TMP" with your variable of interest:
>
> $MET_BIN/plot_data_plane \
> <grib file> \
> <output ps file> \
> 'name="TMP"; level="Z0";' \
> -v 4
>
> If the correct level descriptor works, then the log (output to
stdout) will
> indicate that a match has been found with the record number. I hope
this
> helps.
>
> Regards,
> Minna
>
> ---------------
> Minna Win
> NCAR
> Research Applications Lab
> Phone: 303-497-8423
> Fax: 302-497-8401
>
>
> On Tue, Aug 8, 2017 at 5:59 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >
> > Hi John,
> >
> >
> > I know surface variables use "Z" and pressure level variables use
"P".
> > How can I correctly specify the level for the below ground
variables such
> > as soil moisture?
> >
> > Can I use "Z", "G", "L", or something else?
> > It is hard to find it from the Users' Guide.
> > I have four layers of soil moisture at the NARR data set.
> >
> > Thank you very much.
> > Regards,
> >
> > Jinwoong
> >
> > On Tue, Aug 1, 2017 at 3:26 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > wrote:
> >
> > > Hi John,
> > >
> > > I see.
> > > Thank you very much for your thoughts.
> > > Regards,
> > >
> > > Jinwoong
> > >
> > > On Tue, Aug 1, 2017 at 3:18 PM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >> Jinwoong,
> > >>
> > >> Yes, that is a severe limitation when MET reads the NetCDF
output from
> > >> WRF. It does not read variables defined on the staggered
dimensions.
> > So
> > >> it only reads variables from mass points, not velocity points.
> > >>
> > >> We recommend using the Unified Post Processor (UPP) software to
> > >> postprocess
> > >> the output of WRF. One of the things it does is interpolate
data from
> > the
> > >> staggered dimensions to a regular grid. It writes output in
GRIB1 or
> > >> GRIB2
> > >> format which MET handles nicely.
> > >>
> > >> Thanks,
> > >> John
> > >>
> > >> On Fri, Jul 28, 2017 at 12:46 PM, Jinwoong Yoo via RT <
> > met_help at ucar.edu>
> > >> wrote:
> > >>
> > >> >
> > >> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
> > >> >
> > >> > Hi John,
> > >> >
> > >> > Inserting the "file_type = NETCDF_PINT;" above the field list
line
> > >> seems to
> > >> > work.
> > >> > In this way I was able to process my met_em files against WRF
grib2
> > >> files.
> > >> >
> > >> > However, only TT and GHT variables were taken by the
Gridstat.
> > >> > It couldn't digest UU and VV variables in the met_em files.
> > >> > Regarding the issue, I got WARNING and ERROR messages as
below:
> > >> >
> > >> > WARNING: process_scores() -> UU(0,0,*,*) not found in file:
> > >> > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> > 1976-01-01_00:00:
> > >> > 00.nc
> > >> >
> > >> > ERROR : PinterpFile::data(NcVar *, const LongArray &,
DataPlane &,
> > >> double
> > >> > &) const -> can't find needed dimensions(s) for variable "UU"
...
> one
> > of
> > >> > the dimensions may be staggered.
> > >> > In fact, I confirmed that U-wind and V-wind variables are
staggered
> in
> > >> the
> > >> > met_em grid for the WRF processing.
> > >> > Do you know how I can proceed?
> > >> > Thank you.
> > >> > Regards,
> > >> >
> > >> > Jinwoong
> > >> >
> > >> > On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo <
> jinwoong.yoo at gmail.com
> > >
> > >> > wrote:
> > >> >
> > >> > > Hi John,
> > >> > >
> > >> > > Thank you very much for your time and your kindness.
> > >> > > Let me apply this to my application.
> > >> > > I will let you know how it goes.
> > >> > > Thank you.
> > >> > > Have a nice weekend.
> > >> > >
> > >> > > Regards,
> > >> > >
> > >> > > Jinwoong
> > >> > >
> > >> > > On Fri, Jul 14, 2017 at 5:05 PM, John Halley Gotway via RT
<
> > >> > > met_help at ucar.edu> wrote:
> > >> > >
> > >> > >> Jinwoong,
> > >> > >>
> > >> > >> I'm sorry this took so long, but the good news is that
it's an
> easy
> > >> fix.
> > >> > >>
> > >> > >> The "file_type" setting needs to be defined at one higher
level
> of
> > >> > >> context,
> > >> > >> like this:
> > >> > >>
> > >> > >> fcst = {
> > >> > >>
> > >> > >> file_type = NETCDF_PINT;
> > >> > >>
> > >> > >> field = [
> > >> > >> {
> > >> > >> name = "TT";
> > >> > >> level = [ "(0,0,*,*)" ];
> > >> > >> cat_thresh = [];
> > >> > >> }
> > >> > >> ];
> > >> > >>
> > >> > >> }
> > >> > >>
> > >> > >> The "fcst" section defines information about the input
forecast
> > file,
> > >> > and
> > >> > >> the "obs" section defines information about the input
observation
> > >> file.
> > >> > >>
> > >> > >> The "file_type" setting defines how to interpret these
input
> files.
> > >> So
> > >> > >> the
> > >> > >> code parses it from inside the "fcst" and "obs"
dictionaries...
> not
> > >> > >> separately for each entry in the "field" array.
> > >> > >>
> > >> > >> Here's the note in the file met-6.0/data/config/README
about
> this:
> > >> > >>
> > >> > >> // - The "file_type" entry specifies the input file type
rather
> > >> than
> > >> > >> letting
> > >> > >> // the code determine it itself. For valid file_type
values,
> > see
> > >> > >> "File
> > >> > >> types"
> > >> > >> // in the data/config/ConfigConstants file.
> > >> > >>
> > >> > >> That obviously doesn't explain it well enough. For the
next
> > release,
> > >> > I'll
> > >> > >> update it to read:
> > >> > >>
> > >> > >> // - The "file_type" entry specifies the input file type
rather
> > >> than
> > >> > >> letting
> > >> > >> // the code determine it itself. For valid file_type
values,
> > see
> > >> > >> "File
> > >> > >> types"
> > >> > >> // in the data/config/ConfigConstants file. This
entry
> should
> > be
> > >> > >> defined within
> > >> > >> // the "fcst" or "obs" dictionaries.
> > >> > >> // e.g.
> > >> > >> // fcst = {
> > >> > >> // file_type = NETCDF_NCCF;
> > >> > >> // ...
> > >> > >> // }
> > >> > >>
> > >> > >> Thanks,
> > >> > >> John
> > >> > >>
> > >> > >>
> > >> > >
> > >> >
> > >> >
> > >>
> > >>
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Tue Aug 08 13:06:23 2017
Hi Minna,
I tried all of them but in vain.
Interestingly, ground levels are specified as a range (e.g.,
levels=(0,200)
for 0-2m level) in the NARR grib file.
But I don't know how to put it in the command line or in the config
file.
Any idea?
Thank you.
Regards,
Jinwoong
On Tue, Aug 8, 2017 at 2:36 PM, Jinwoong Yoo <jinwoong.yoo at gmail.com>
wrote:
> Hi Minna,
>
> Thank you very much for your note.
> Then, isn't there any letter specifically designated for below
ground
> levels?
> Let me try with "Z" (i.g., "Z1", "Z2", "Z3", and "Z4") first.
> Thank you.
>
> Regards,
>
> Jinwoong
>
>
>
> On Tue, Aug 8, 2017 at 2:09 PM, Minna Win via RT <met_help at ucar.edu>
> wrote:
>
>> Hi Jinwoong,
>>
>> This is Minna, another developer on the MET team. I have
experienced the
>> same issue, especially with uncommon data sets. John showed me how
to use
>> MET's plot_data_plane to test whether to use 'Z', 'G', or 'L':
>> Try running plot_data_plane in the following manner, but replace
$MET_BIN
>> for the location of your MET binaries, replace <grib_file> for the
full
>> path to your grib1 or grib2 data file, replace <output_ps> for the
name of
>> the output plot, and replace "TMP" with your variable of interest:
>>
>> $MET_BIN/plot_data_plane \
>> <grib file> \
>> <output ps file> \
>> 'name="TMP"; level="Z0";' \
>> -v 4
>>
>> If the correct level descriptor works, then the log (output to
stdout)
>> will
>> indicate that a match has been found with the record number. I
hope this
>> helps.
>>
>> Regards,
>> Minna
>>
>> ---------------
>> Minna Win
>> NCAR
>> Research Applications Lab
>> Phone: 303-497-8423
>> Fax: 302-497-8401
>>
>>
>> On Tue, Aug 8, 2017 at 5:59 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
>> wrote:
>>
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>> >
>> > Hi John,
>> >
>> >
>> > I know surface variables use "Z" and pressure level variables use
"P".
>> > How can I correctly specify the level for the below ground
variables
>> such
>> > as soil moisture?
>> >
>> > Can I use "Z", "G", "L", or something else?
>> > It is hard to find it from the Users' Guide.
>> > I have four layers of soil moisture at the NARR data set.
>> >
>> > Thank you very much.
>> > Regards,
>> >
>> > Jinwoong
>> >
>> > On Tue, Aug 1, 2017 at 3:26 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
>> > wrote:
>> >
>> > > Hi John,
>> > >
>> > > I see.
>> > > Thank you very much for your thoughts.
>> > > Regards,
>> > >
>> > > Jinwoong
>> > >
>> > > On Tue, Aug 1, 2017 at 3:18 PM, John Halley Gotway via RT <
>> > > met_help at ucar.edu> wrote:
>> > >
>> > >> Jinwoong,
>> > >>
>> > >> Yes, that is a severe limitation when MET reads the NetCDF
output
>> from
>> > >> WRF. It does not read variables defined on the staggered
dimensions.
>> > So
>> > >> it only reads variables from mass points, not velocity points.
>> > >>
>> > >> We recommend using the Unified Post Processor (UPP) software
to
>> > >> postprocess
>> > >> the output of WRF. One of the things it does is interpolate
data
>> from
>> > the
>> > >> staggered dimensions to a regular grid. It writes output in
GRIB1 or
>> > >> GRIB2
>> > >> format which MET handles nicely.
>> > >>
>> > >> Thanks,
>> > >> John
>> > >>
>> > >> On Fri, Jul 28, 2017 at 12:46 PM, Jinwoong Yoo via RT <
>> > met_help at ucar.edu>
>> > >> wrote:
>> > >>
>> > >> >
>> > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>> > >> >
>> > >> > Hi John,
>> > >> >
>> > >> > Inserting the "file_type = NETCDF_PINT;" above the field
list line
>> > >> seems to
>> > >> > work.
>> > >> > In this way I was able to process my met_em files against
WRF grib2
>> > >> files.
>> > >> >
>> > >> > However, only TT and GHT variables were taken by the
Gridstat.
>> > >> > It couldn't digest UU and VV variables in the met_em files.
>> > >> > Regarding the issue, I got WARNING and ERROR messages as
below:
>> > >> >
>> > >> > WARNING: process_scores() -> UU(0,0,*,*) not found in file:
>> > >> > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
>> > 1976-01-01_00:00:
>> > >> > 00.nc
>> > >> >
>> > >> > ERROR : PinterpFile::data(NcVar *, const LongArray &,
DataPlane &,
>> > >> double
>> > >> > &) const -> can't find needed dimensions(s) for variable
"UU" ...
>> one
>> > of
>> > >> > the dimensions may be staggered.
>> > >> > In fact, I confirmed that U-wind and V-wind variables are
>> staggered in
>> > >> the
>> > >> > met_em grid for the WRF processing.
>> > >> > Do you know how I can proceed?
>> > >> > Thank you.
>> > >> > Regards,
>> > >> >
>> > >> > Jinwoong
>> > >> >
>> > >> > On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo <
>> jinwoong.yoo at gmail.com
>> > >
>> > >> > wrote:
>> > >> >
>> > >> > > Hi John,
>> > >> > >
>> > >> > > Thank you very much for your time and your kindness.
>> > >> > > Let me apply this to my application.
>> > >> > > I will let you know how it goes.
>> > >> > > Thank you.
>> > >> > > Have a nice weekend.
>> > >> > >
>> > >> > > Regards,
>> > >> > >
>> > >> > > Jinwoong
>> > >> > >
>> > >> > > On Fri, Jul 14, 2017 at 5:05 PM, John Halley Gotway via RT
<
>> > >> > > met_help at ucar.edu> wrote:
>> > >> > >
>> > >> > >> Jinwoong,
>> > >> > >>
>> > >> > >> I'm sorry this took so long, but the good news is that
it's an
>> easy
>> > >> fix.
>> > >> > >>
>> > >> > >> The "file_type" setting needs to be defined at one higher
level
>> of
>> > >> > >> context,
>> > >> > >> like this:
>> > >> > >>
>> > >> > >> fcst = {
>> > >> > >>
>> > >> > >> file_type = NETCDF_PINT;
>> > >> > >>
>> > >> > >> field = [
>> > >> > >> {
>> > >> > >> name = "TT";
>> > >> > >> level = [ "(0,0,*,*)" ];
>> > >> > >> cat_thresh = [];
>> > >> > >> }
>> > >> > >> ];
>> > >> > >>
>> > >> > >> }
>> > >> > >>
>> > >> > >> The "fcst" section defines information about the input
forecast
>> > file,
>> > >> > and
>> > >> > >> the "obs" section defines information about the input
>> observation
>> > >> file.
>> > >> > >>
>> > >> > >> The "file_type" setting defines how to interpret these
input
>> files.
>> > >> So
>> > >> > >> the
>> > >> > >> code parses it from inside the "fcst" and "obs"
dictionaries...
>> not
>> > >> > >> separately for each entry in the "field" array.
>> > >> > >>
>> > >> > >> Here's the note in the file met-6.0/data/config/README
about
>> this:
>> > >> > >>
>> > >> > >> // - The "file_type" entry specifies the input file
type
>> rather
>> > >> than
>> > >> > >> letting
>> > >> > >> // the code determine it itself. For valid file_type
>> values,
>> > see
>> > >> > >> "File
>> > >> > >> types"
>> > >> > >> // in the data/config/ConfigConstants file.
>> > >> > >>
>> > >> > >> That obviously doesn't explain it well enough. For the
next
>> > release,
>> > >> > I'll
>> > >> > >> update it to read:
>> > >> > >>
>> > >> > >> // - The "file_type" entry specifies the input file
type
>> rather
>> > >> than
>> > >> > >> letting
>> > >> > >> // the code determine it itself. For valid file_type
>> values,
>> > see
>> > >> > >> "File
>> > >> > >> types"
>> > >> > >> // in the data/config/ConfigConstants file. This
entry
>> should
>> > be
>> > >> > >> defined within
>> > >> > >> // the "fcst" or "obs" dictionaries.
>> > >> > >> // e.g.
>> > >> > >> // fcst = {
>> > >> > >> // file_type = NETCDF_NCCF;
>> > >> > >> // ...
>> > >> > >> // }
>> > >> > >>
>> > >> > >> Thanks,
>> > >> > >> John
>> > >> > >>
>> > >> > >>
>> > >> > >
>> > >> >
>> > >> >
>> > >>
>> > >>
>> > >
>> >
>> >
>>
>>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Minna Win
Time: Tue Aug 08 13:25:43 2017
Hi Jinwoong,
I had to deal with uncommon levels for a recent project (ie freezing
level,
max wind speed, tropopause). MET has support for such instances in
the
form of:
$MET_BIN/plot_data_plane \
<grib data file> \
<output ps file >\
'name="<variable>"; GRIB_lvl_typ=<type>; GRIB_lvl_val1=<value> \
-v 4
For my data, I had to look up the values for GRIB_lvl_typ using the
following GRIB1 and GRIB2 tables:
GRIB2:
http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table4-5.shtml
GRIB1:
http://www.nco.ncep.noaa.gov/pmb/docs/on388/table3.html#TABLE3A
You can use wgrib or wgrib2 to see whether your variable of interest
has
information about the level:
e.g.
For grib2 data
wgrib2 GALWEM_20170602_CY00_FH06.GR2 | grep PRES
which gives:
519:658332188:d=2017060200 <%28201%29%20706-0200>:PRES:max wind:6 hour
fcst:
559:694572877:d=2017060200 <%28201%29%20706-0200>:PRES:surface:6 hour
fcst:
567:704111051:d=2017060200 <%28201%29%20706-0200>:PRES:tropopause:6
hour
fcst:
I then used the descriptions of 'max wind' and 'tropopause' to look up
the
'code figure' column value in the GRIB2 table 4-5
For example, if your data is in GRIB2, set GRIB_lvl_typ to the 'code
figure' value from table 4.5. Following the example from above, for
'tropopause' you would set GRIB_lvl_typ=7 and GRIB_lvl_val1=0.
Likewise
for GRIB1 data, except you would refer to ON388 TABLE 3A and set the
GRIB_lvl_typ to the value under the "Value" column.
What data are you using, and what variable and level do you need to
access? Please let us know if you need additional clarification.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Tue, Aug 8, 2017 at 6:36 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>
> Hi Minna,
>
> Thank you very much for your note.
> Then, isn't there any letter specifically designated for below
ground
> levels?
> Let me try with "Z" (i.g., "Z1", "Z2", "Z3", and "Z4") first.
> Thank you.
>
> Regards,
>
> Jinwoong
>
>
>
> On Tue, Aug 8, 2017 at 2:09 PM, Minna Win via RT <met_help at ucar.edu>
> wrote:
>
> > Hi Jinwoong,
> >
> > This is Minna, another developer on the MET team. I have
experienced the
> > same issue, especially with uncommon data sets. John showed me
how to
> use
> > MET's plot_data_plane to test whether to use 'Z', 'G', or 'L':
> > Try running plot_data_plane in the following manner, but replace
$MET_BIN
> > for the location of your MET binaries, replace <grib_file> for the
full
> > path to your grib1 or grib2 data file, replace <output_ps> for the
name
> of
> > the output plot, and replace "TMP" with your variable of
interest:
> >
> > $MET_BIN/plot_data_plane \
> > <grib file> \
> > <output ps file> \
> > 'name="TMP"; level="Z0";' \
> > -v 4
> >
> > If the correct level descriptor works, then the log (output to
stdout)
> will
> > indicate that a match has been found with the record number. I
hope this
> > helps.
> >
> > Regards,
> > Minna
> >
> > ---------------
> > Minna Win
> > NCAR
> > Research Applications Lab
> > Phone: 303-497-8423
> > Fax: 302-497-8401
> >
> >
> > On Tue, Aug 8, 2017 at 5:59 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > >
> > > Hi John,
> > >
> > >
> > > I know surface variables use "Z" and pressure level variables
use "P".
> > > How can I correctly specify the level for the below ground
variables
> such
> > > as soil moisture?
> > >
> > > Can I use "Z", "G", "L", or something else?
> > > It is hard to find it from the Users' Guide.
> > > I have four layers of soil moisture at the NARR data set.
> > >
> > > Thank you very much.
> > > Regards,
> > >
> > > Jinwoong
> > >
> > > On Tue, Aug 1, 2017 at 3:26 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > > wrote:
> > >
> > > > Hi John,
> > > >
> > > > I see.
> > > > Thank you very much for your thoughts.
> > > > Regards,
> > > >
> > > > Jinwoong
> > > >
> > > > On Tue, Aug 1, 2017 at 3:18 PM, John Halley Gotway via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > >> Jinwoong,
> > > >>
> > > >> Yes, that is a severe limitation when MET reads the NetCDF
output
> from
> > > >> WRF. It does not read variables defined on the staggered
> dimensions.
> > > So
> > > >> it only reads variables from mass points, not velocity
points.
> > > >>
> > > >> We recommend using the Unified Post Processor (UPP) software
to
> > > >> postprocess
> > > >> the output of WRF. One of the things it does is interpolate
data
> from
> > > the
> > > >> staggered dimensions to a regular grid. It writes output in
GRIB1
> or
> > > >> GRIB2
> > > >> format which MET handles nicely.
> > > >>
> > > >> Thanks,
> > > >> John
> > > >>
> > > >> On Fri, Jul 28, 2017 at 12:46 PM, Jinwoong Yoo via RT <
> > > met_help at ucar.edu>
> > > >> wrote:
> > > >>
> > > >> >
> > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > > >> >
> > > >> > Hi John,
> > > >> >
> > > >> > Inserting the "file_type = NETCDF_PINT;" above the field
list line
> > > >> seems to
> > > >> > work.
> > > >> > In this way I was able to process my met_em files against
WRF
> grib2
> > > >> files.
> > > >> >
> > > >> > However, only TT and GHT variables were taken by the
Gridstat.
> > > >> > It couldn't digest UU and VV variables in the met_em files.
> > > >> > Regarding the issue, I got WARNING and ERROR messages as
below:
> > > >> >
> > > >> > WARNING: process_scores() -> UU(0,0,*,*) not found in file:
> > > >> > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> > > 1976-01-01_00:00:
> > > >> > 00.nc
> > > >> >
> > > >> > ERROR : PinterpFile::data(NcVar *, const LongArray &,
DataPlane
> &,
> > > >> double
> > > >> > &) const -> can't find needed dimensions(s) for variable
"UU" ...
> > one
> > > of
> > > >> > the dimensions may be staggered.
> > > >> > In fact, I confirmed that U-wind and V-wind variables are
> staggered
> > in
> > > >> the
> > > >> > met_em grid for the WRF processing.
> > > >> > Do you know how I can proceed?
> > > >> > Thank you.
> > > >> > Regards,
> > > >> >
> > > >> > Jinwoong
> > > >> >
> > > >> > On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo <
> > jinwoong.yoo at gmail.com
> > > >
> > > >> > wrote:
> > > >> >
> > > >> > > Hi John,
> > > >> > >
> > > >> > > Thank you very much for your time and your kindness.
> > > >> > > Let me apply this to my application.
> > > >> > > I will let you know how it goes.
> > > >> > > Thank you.
> > > >> > > Have a nice weekend.
> > > >> > >
> > > >> > > Regards,
> > > >> > >
> > > >> > > Jinwoong
> > > >> > >
> > > >> > > On Fri, Jul 14, 2017 at 5:05 PM, John Halley Gotway via
RT <
> > > >> > > met_help at ucar.edu> wrote:
> > > >> > >
> > > >> > >> Jinwoong,
> > > >> > >>
> > > >> > >> I'm sorry this took so long, but the good news is that
it's an
> > easy
> > > >> fix.
> > > >> > >>
> > > >> > >> The "file_type" setting needs to be defined at one
higher level
> > of
> > > >> > >> context,
> > > >> > >> like this:
> > > >> > >>
> > > >> > >> fcst = {
> > > >> > >>
> > > >> > >> file_type = NETCDF_PINT;
> > > >> > >>
> > > >> > >> field = [
> > > >> > >> {
> > > >> > >> name = "TT";
> > > >> > >> level = [ "(0,0,*,*)" ];
> > > >> > >> cat_thresh = [];
> > > >> > >> }
> > > >> > >> ];
> > > >> > >>
> > > >> > >> }
> > > >> > >>
> > > >> > >> The "fcst" section defines information about the input
forecast
> > > file,
> > > >> > and
> > > >> > >> the "obs" section defines information about the input
> observation
> > > >> file.
> > > >> > >>
> > > >> > >> The "file_type" setting defines how to interpret these
input
> > files.
> > > >> So
> > > >> > >> the
> > > >> > >> code parses it from inside the "fcst" and "obs"
dictionaries...
> > not
> > > >> > >> separately for each entry in the "field" array.
> > > >> > >>
> > > >> > >> Here's the note in the file met-6.0/data/config/README
about
> > this:
> > > >> > >>
> > > >> > >> // - The "file_type" entry specifies the input file
type
> rather
> > > >> than
> > > >> > >> letting
> > > >> > >> // the code determine it itself. For valid
file_type
> values,
> > > see
> > > >> > >> "File
> > > >> > >> types"
> > > >> > >> // in the data/config/ConfigConstants file.
> > > >> > >>
> > > >> > >> That obviously doesn't explain it well enough. For the
next
> > > release,
> > > >> > I'll
> > > >> > >> update it to read:
> > > >> > >>
> > > >> > >> // - The "file_type" entry specifies the input file
type
> rather
> > > >> than
> > > >> > >> letting
> > > >> > >> // the code determine it itself. For valid
file_type
> values,
> > > see
> > > >> > >> "File
> > > >> > >> types"
> > > >> > >> // in the data/config/ConfigConstants file. This
entry
> > should
> > > be
> > > >> > >> defined within
> > > >> > >> // the "fcst" or "obs" dictionaries.
> > > >> > >> // e.g.
> > > >> > >> // fcst = {
> > > >> > >> // file_type = NETCDF_NCCF;
> > > >> > >> // ...
> > > >> > >> // }
> > > >> > >>
> > > >> > >> Thanks,
> > > >> > >> John
> > > >> > >>
> > > >> > >>
> > > >> > >
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Tue Aug 08 13:34:46 2017
Hi Minna,
I am using the NARR grib1 data along with WRF UPP output grib2 data.
I would like to retrieve SOILM variable for the level of 0-200 cm down
from
both of the datasets.
Below is the print out of the variable from the NARR data.
ec 283:37526500:date 2005123121 SOILM kpds5=86 kpds6=112 kpds7=200
levels=(0,200) grid=221 0-200 cm down anl: bitmap: 68650 undef
SOILM=Soil moisture content [kg/m^2]
timerange 0 P1 0 P2 0 TimeU 1 nx 349 ny 277 GDS grid 3 num_in_ave 0
missing 0
center 7 subcenter 15 process 140 Table 131 scan: WE:SN winds(N/S)
Lambert Conf: Lat1 1.000000 Lon1 -145.500000 Lov -107.000000
Latin1 50.000000 Latin2 50.000000 LatSP 0.000000 LonSP 0.000000
North Pole (349 x 277) Dx 32.463000 Dy 32.463000 scan 64 mode 0
min/max data 57.0137 936.014 num bits 14 BDS_Ref 570.137 DecScale
1
BinScale 0
Thank you.
Regards,
Jinwoong
On Tue, Aug 8, 2017 at 3:25 PM, Minna Win via RT <met_help at ucar.edu>
wrote:
> Hi Jinwoong,
>
> I had to deal with uncommon levels for a recent project (ie freezing
level,
> max wind speed, tropopause). MET has support for such instances in
the
> form of:
>
> $MET_BIN/plot_data_plane \
> <grib data file> \
> <output ps file >\
> 'name="<variable>"; GRIB_lvl_typ=<type>; GRIB_lvl_val1=<value> \
> -v 4
>
> For my data, I had to look up the values for GRIB_lvl_typ using the
> following GRIB1 and GRIB2 tables:
>
> GRIB2:
> http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table4-5.shtml
>
> GRIB1:
> http://www.nco.ncep.noaa.gov/pmb/docs/on388/table3.html#TABLE3A
>
> You can use wgrib or wgrib2 to see whether your variable of interest
has
> information about the level:
> e.g.
> For grib2 data
> wgrib2 GALWEM_20170602_CY00_FH06.GR2 | grep PRES
>
> which gives:
> 519:658332188:d=2017060200 <%28201%29%20706-0200>:PRES:max wind:6
hour
> fcst:
> 559:694572877:d=2017060200 <%28201%29%20706-0200>:PRES:surface:6
hour
> fcst:
> 567:704111051:d=2017060200 <%28201%29%20706-0200>:PRES:tropopause:6
hour
> fcst:
>
> I then used the descriptions of 'max wind' and 'tropopause' to look
up the
> 'code figure' column value in the GRIB2 table 4-5
>
>
> For example, if your data is in GRIB2, set GRIB_lvl_typ to the 'code
> figure' value from table 4.5. Following the example from above, for
> 'tropopause' you would set GRIB_lvl_typ=7 and GRIB_lvl_val1=0.
Likewise
> for GRIB1 data, except you would refer to ON388 TABLE 3A and set
the
> GRIB_lvl_typ to the value under the "Value" column.
>
> What data are you using, and what variable and level do you need to
> access? Please let us know if you need additional clarification.
>
> Regards,
> Minna
>
>
>
> ---------------
> Minna Win
> NCAR
> Research Applications Lab
> Phone: 303-497-8423
> Fax: 302-497-8401
>
>
> On Tue, Aug 8, 2017 at 6:36 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >
> > Hi Minna,
> >
> > Thank you very much for your note.
> > Then, isn't there any letter specifically designated for below
ground
> > levels?
> > Let me try with "Z" (i.g., "Z1", "Z2", "Z3", and "Z4") first.
> > Thank you.
> >
> > Regards,
> >
> > Jinwoong
> >
> >
> >
> > On Tue, Aug 8, 2017 at 2:09 PM, Minna Win via RT
<met_help at ucar.edu>
> > wrote:
> >
> > > Hi Jinwoong,
> > >
> > > This is Minna, another developer on the MET team. I have
experienced
> the
> > > same issue, especially with uncommon data sets. John showed me
how to
> > use
> > > MET's plot_data_plane to test whether to use 'Z', 'G', or 'L':
> > > Try running plot_data_plane in the following manner, but replace
> $MET_BIN
> > > for the location of your MET binaries, replace <grib_file> for
the full
> > > path to your grib1 or grib2 data file, replace <output_ps> for
the name
> > of
> > > the output plot, and replace "TMP" with your variable of
interest:
> > >
> > > $MET_BIN/plot_data_plane \
> > > <grib file> \
> > > <output ps file> \
> > > 'name="TMP"; level="Z0";' \
> > > -v 4
> > >
> > > If the correct level descriptor works, then the log (output to
stdout)
> > will
> > > indicate that a match has been found with the record number. I
hope
> this
> > > helps.
> > >
> > > Regards,
> > > Minna
> > >
> > > ---------------
> > > Minna Win
> > > NCAR
> > > Research Applications Lab
> > > Phone: 303-497-8423
> > > Fax: 302-497-8401
> > >
> > >
> > > On Tue, Aug 8, 2017 at 5:59 PM, Jinwoong Yoo via RT
<met_help at ucar.edu
> >
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
> > > >
> > > > Hi John,
> > > >
> > > >
> > > > I know surface variables use "Z" and pressure level variables
use
> "P".
> > > > How can I correctly specify the level for the below ground
variables
> > such
> > > > as soil moisture?
> > > >
> > > > Can I use "Z", "G", "L", or something else?
> > > > It is hard to find it from the Users' Guide.
> > > > I have four layers of soil moisture at the NARR data set.
> > > >
> > > > Thank you very much.
> > > > Regards,
> > > >
> > > > Jinwoong
> > > >
> > > > On Tue, Aug 1, 2017 at 3:26 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com
> >
> > > > wrote:
> > > >
> > > > > Hi John,
> > > > >
> > > > > I see.
> > > > > Thank you very much for your thoughts.
> > > > > Regards,
> > > > >
> > > > > Jinwoong
> > > > >
> > > > > On Tue, Aug 1, 2017 at 3:18 PM, John Halley Gotway via RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > >> Jinwoong,
> > > > >>
> > > > >> Yes, that is a severe limitation when MET reads the NetCDF
output
> > from
> > > > >> WRF. It does not read variables defined on the staggered
> > dimensions.
> > > > So
> > > > >> it only reads variables from mass points, not velocity
points.
> > > > >>
> > > > >> We recommend using the Unified Post Processor (UPP)
software to
> > > > >> postprocess
> > > > >> the output of WRF. One of the things it does is
interpolate data
> > from
> > > > the
> > > > >> staggered dimensions to a regular grid. It writes output
in GRIB1
> > or
> > > > >> GRIB2
> > > > >> format which MET handles nicely.
> > > > >>
> > > > >> Thanks,
> > > > >> John
> > > > >>
> > > > >> On Fri, Jul 28, 2017 at 12:46 PM, Jinwoong Yoo via RT <
> > > > met_help at ucar.edu>
> > > > >> wrote:
> > > > >>
> > > > >> >
> > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > > > >> >
> > > > >> > Hi John,
> > > > >> >
> > > > >> > Inserting the "file_type = NETCDF_PINT;" above the field
list
> line
> > > > >> seems to
> > > > >> > work.
> > > > >> > In this way I was able to process my met_em files against
WRF
> > grib2
> > > > >> files.
> > > > >> >
> > > > >> > However, only TT and GHT variables were taken by the
Gridstat.
> > > > >> > It couldn't digest UU and VV variables in the met_em
files.
> > > > >> > Regarding the issue, I got WARNING and ERROR messages as
below:
> > > > >> >
> > > > >> > WARNING: process_scores() -> UU(0,0,*,*) not found in
file:
> > > > >> > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> > > > 1976-01-01_00:00:
> > > > >> > 00.nc
> > > > >> >
> > > > >> > ERROR : PinterpFile::data(NcVar *, const LongArray &,
DataPlane
> > &,
> > > > >> double
> > > > >> > &) const -> can't find needed dimensions(s) for variable
"UU"
> ...
> > > one
> > > > of
> > > > >> > the dimensions may be staggered.
> > > > >> > In fact, I confirmed that U-wind and V-wind variables are
> > staggered
> > > in
> > > > >> the
> > > > >> > met_em grid for the WRF processing.
> > > > >> > Do you know how I can proceed?
> > > > >> > Thank you.
> > > > >> > Regards,
> > > > >> >
> > > > >> > Jinwoong
> > > > >> >
> > > > >> > On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo <
> > > jinwoong.yoo at gmail.com
> > > > >
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Hi John,
> > > > >> > >
> > > > >> > > Thank you very much for your time and your kindness.
> > > > >> > > Let me apply this to my application.
> > > > >> > > I will let you know how it goes.
> > > > >> > > Thank you.
> > > > >> > > Have a nice weekend.
> > > > >> > >
> > > > >> > > Regards,
> > > > >> > >
> > > > >> > > Jinwoong
> > > > >> > >
> > > > >> > > On Fri, Jul 14, 2017 at 5:05 PM, John Halley Gotway via
RT <
> > > > >> > > met_help at ucar.edu> wrote:
> > > > >> > >
> > > > >> > >> Jinwoong,
> > > > >> > >>
> > > > >> > >> I'm sorry this took so long, but the good news is that
it's
> an
> > > easy
> > > > >> fix.
> > > > >> > >>
> > > > >> > >> The "file_type" setting needs to be defined at one
higher
> level
> > > of
> > > > >> > >> context,
> > > > >> > >> like this:
> > > > >> > >>
> > > > >> > >> fcst = {
> > > > >> > >>
> > > > >> > >> file_type = NETCDF_PINT;
> > > > >> > >>
> > > > >> > >> field = [
> > > > >> > >> {
> > > > >> > >> name = "TT";
> > > > >> > >> level = [ "(0,0,*,*)" ];
> > > > >> > >> cat_thresh = [];
> > > > >> > >> }
> > > > >> > >> ];
> > > > >> > >>
> > > > >> > >> }
> > > > >> > >>
> > > > >> > >> The "fcst" section defines information about the input
> forecast
> > > > file,
> > > > >> > and
> > > > >> > >> the "obs" section defines information about the input
> > observation
> > > > >> file.
> > > > >> > >>
> > > > >> > >> The "file_type" setting defines how to interpret these
input
> > > files.
> > > > >> So
> > > > >> > >> the
> > > > >> > >> code parses it from inside the "fcst" and "obs"
> dictionaries...
> > > not
> > > > >> > >> separately for each entry in the "field" array.
> > > > >> > >>
> > > > >> > >> Here's the note in the file met-6.0/data/config/README
about
> > > this:
> > > > >> > >>
> > > > >> > >> // - The "file_type" entry specifies the input file
type
> > rather
> > > > >> than
> > > > >> > >> letting
> > > > >> > >> // the code determine it itself. For valid
file_type
> > values,
> > > > see
> > > > >> > >> "File
> > > > >> > >> types"
> > > > >> > >> // in the data/config/ConfigConstants file.
> > > > >> > >>
> > > > >> > >> That obviously doesn't explain it well enough. For
the next
> > > > release,
> > > > >> > I'll
> > > > >> > >> update it to read:
> > > > >> > >>
> > > > >> > >> // - The "file_type" entry specifies the input file
type
> > rather
> > > > >> than
> > > > >> > >> letting
> > > > >> > >> // the code determine it itself. For valid
file_type
> > values,
> > > > see
> > > > >> > >> "File
> > > > >> > >> types"
> > > > >> > >> // in the data/config/ConfigConstants file. This
entry
> > > should
> > > > be
> > > > >> > >> defined within
> > > > >> > >> // the "fcst" or "obs" dictionaries.
> > > > >> > >> // e.g.
> > > > >> > >> // fcst = {
> > > > >> > >> // file_type = NETCDF_NCCF;
> > > > >> > >> // ...
> > > > >> > >> // }
> > > > >> > >>
> > > > >> > >> Thanks,
> > > > >> > >> John
> > > > >> > >>
> > > > >> > >>
> > > > >> > >
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Minna Win
Time: Tue Aug 08 13:51:26 2017
Hi Jinwoong,
Given your GRIB1 output from wgrib, you might want to try the
following:
$MET_BIN/plot_data_plane \
<grib data> \
<output ps file> \
'name="SOILM"; GRIB_lvl_typ=112; GRIB_lvl_val1=0;' -v 4
I forgot to mention that for GRIB1, you can also look at the wgrib
output
and set GRIB_lvl_typ to the kpds6 value, in this case it is 112
(useful if
there isn't a description for you to look up and match to the "Value"
column in the ON388 table).
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Tue, Aug 8, 2017 at 7:34 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>
> Hi Minna,
>
> I am using the NARR grib1 data along with WRF UPP output grib2 data.
> I would like to retrieve SOILM variable for the level of 0-200 cm
down from
> both of the datasets.
> Below is the print out of the variable from the NARR data.
>
> ec 283:37526500:date 2005123121 SOILM kpds5=86 kpds6=112 kpds7=200
> levels=(0,200) grid=221 0-200 cm down anl: bitmap: 68650 undef
>
> SOILM=Soil moisture content [kg/m^2]
>
> timerange 0 P1 0 P2 0 TimeU 1 nx 349 ny 277 GDS grid 3 num_in_ave
0
> missing 0
>
> center 7 subcenter 15 process 140 Table 131 scan: WE:SN winds(N/S)
>
> Lambert Conf: Lat1 1.000000 Lon1 -145.500000 Lov -107.000000
>
> Latin1 50.000000 Latin2 50.000000 LatSP 0.000000 LonSP
0.000000
>
> North Pole (349 x 277) Dx 32.463000 Dy 32.463000 scan 64 mode
0
>
> min/max data 57.0137 936.014 num bits 14 BDS_Ref 570.137
DecScale 1
> BinScale 0
>
>
>
> Thank you.
> Regards,
>
> Jinwoong
>
> On Tue, Aug 8, 2017 at 3:25 PM, Minna Win via RT <met_help at ucar.edu>
> wrote:
>
> > Hi Jinwoong,
> >
> > I had to deal with uncommon levels for a recent project (ie
freezing
> level,
> > max wind speed, tropopause). MET has support for such instances
in the
> > form of:
> >
> > $MET_BIN/plot_data_plane \
> > <grib data file> \
> > <output ps file >\
> > 'name="<variable>"; GRIB_lvl_typ=<type>; GRIB_lvl_val1=<value> \
> > -v 4
> >
> > For my data, I had to look up the values for GRIB_lvl_typ using
the
> > following GRIB1 and GRIB2 tables:
> >
> > GRIB2:
> > http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table4-5.shtml
> >
> > GRIB1:
> > http://www.nco.ncep.noaa.gov/pmb/docs/on388/table3.html#TABLE3A
> >
> > You can use wgrib or wgrib2 to see whether your variable of
interest has
> > information about the level:
> > e.g.
> > For grib2 data
> > wgrib2 GALWEM_20170602_CY00_FH06.GR2 | grep PRES
> >
> > which gives:
> > 519:658332188:d=2017060200 <%28201%29%20706-0200>:PRES:max wind:6
hour
> > fcst:
> > 559:694572877:d=2017060200 <%28201%29%20706-0200>:PRES:surface:6
hour
> > fcst:
> > 567:704111051:d=2017060200 <%28201%29%20706-
0200>:PRES:tropopause:6 hour
> > fcst:
> >
> > I then used the descriptions of 'max wind' and 'tropopause' to
look up
> the
> > 'code figure' column value in the GRIB2 table 4-5
> >
> >
> > For example, if your data is in GRIB2, set GRIB_lvl_typ to the
'code
> > figure' value from table 4.5. Following the example from above,
for
> > 'tropopause' you would set GRIB_lvl_typ=7 and GRIB_lvl_val1=0.
Likewise
> > for GRIB1 data, except you would refer to ON388 TABLE 3A and set
the
> > GRIB_lvl_typ to the value under the "Value" column.
> >
> > What data are you using, and what variable and level do you need
to
> > access? Please let us know if you need additional clarification.
> >
> > Regards,
> > Minna
> >
> >
> >
> > ---------------
> > Minna Win
> > NCAR
> > Research Applications Lab
> > Phone: 303-497-8423
> > Fax: 302-497-8401
> >
> >
> > On Tue, Aug 8, 2017 at 6:36 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > >
> > > Hi Minna,
> > >
> > > Thank you very much for your note.
> > > Then, isn't there any letter specifically designated for below
ground
> > > levels?
> > > Let me try with "Z" (i.g., "Z1", "Z2", "Z3", and "Z4") first.
> > > Thank you.
> > >
> > > Regards,
> > >
> > > Jinwoong
> > >
> > >
> > >
> > > On Tue, Aug 8, 2017 at 2:09 PM, Minna Win via RT
<met_help at ucar.edu>
> > > wrote:
> > >
> > > > Hi Jinwoong,
> > > >
> > > > This is Minna, another developer on the MET team. I have
experienced
> > the
> > > > same issue, especially with uncommon data sets. John showed
me how
> to
> > > use
> > > > MET's plot_data_plane to test whether to use 'Z', 'G', or 'L':
> > > > Try running plot_data_plane in the following manner, but
replace
> > $MET_BIN
> > > > for the location of your MET binaries, replace <grib_file> for
the
> full
> > > > path to your grib1 or grib2 data file, replace <output_ps> for
the
> name
> > > of
> > > > the output plot, and replace "TMP" with your variable of
interest:
> > > >
> > > > $MET_BIN/plot_data_plane \
> > > > <grib file> \
> > > > <output ps file> \
> > > > 'name="TMP"; level="Z0";' \
> > > > -v 4
> > > >
> > > > If the correct level descriptor works, then the log (output to
> stdout)
> > > will
> > > > indicate that a match has been found with the record number.
I hope
> > this
> > > > helps.
> > > >
> > > > Regards,
> > > > Minna
> > > >
> > > > ---------------
> > > > Minna Win
> > > > NCAR
> > > > Research Applications Lab
> > > > Phone: 303-497-8423
> > > > Fax: 302-497-8401
> > > >
> > > >
> > > > On Tue, Aug 8, 2017 at 5:59 PM, Jinwoong Yoo via RT <
> met_help at ucar.edu
> > >
> > > > wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > > > >
> > > > > Hi John,
> > > > >
> > > > >
> > > > > I know surface variables use "Z" and pressure level
variables use
> > "P".
> > > > > How can I correctly specify the level for the below ground
> variables
> > > such
> > > > > as soil moisture?
> > > > >
> > > > > Can I use "Z", "G", "L", or something else?
> > > > > It is hard to find it from the Users' Guide.
> > > > > I have four layers of soil moisture at the NARR data set.
> > > > >
> > > > > Thank you very much.
> > > > > Regards,
> > > > >
> > > > > Jinwoong
> > > > >
> > > > > On Tue, Aug 1, 2017 at 3:26 PM, Jinwoong Yoo <
> jinwoong.yoo at gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Hi John,
> > > > > >
> > > > > > I see.
> > > > > > Thank you very much for your thoughts.
> > > > > > Regards,
> > > > > >
> > > > > > Jinwoong
> > > > > >
> > > > > > On Tue, Aug 1, 2017 at 3:18 PM, John Halley Gotway via RT
<
> > > > > > met_help at ucar.edu> wrote:
> > > > > >
> > > > > >> Jinwoong,
> > > > > >>
> > > > > >> Yes, that is a severe limitation when MET reads the
NetCDF
> output
> > > from
> > > > > >> WRF. It does not read variables defined on the staggered
> > > dimensions.
> > > > > So
> > > > > >> it only reads variables from mass points, not velocity
points.
> > > > > >>
> > > > > >> We recommend using the Unified Post Processor (UPP)
software to
> > > > > >> postprocess
> > > > > >> the output of WRF. One of the things it does is
interpolate
> data
> > > from
> > > > > the
> > > > > >> staggered dimensions to a regular grid. It writes output
in
> GRIB1
> > > or
> > > > > >> GRIB2
> > > > > >> format which MET handles nicely.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> John
> > > > > >>
> > > > > >> On Fri, Jul 28, 2017 at 12:46 PM, Jinwoong Yoo via RT <
> > > > > met_help at ucar.edu>
> > > > > >> wrote:
> > > > > >>
> > > > > >> >
> > > > > >> > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
> >
> > > > > >> >
> > > > > >> > Hi John,
> > > > > >> >
> > > > > >> > Inserting the "file_type = NETCDF_PINT;" above the
field list
> > line
> > > > > >> seems to
> > > > > >> > work.
> > > > > >> > In this way I was able to process my met_em files
against WRF
> > > grib2
> > > > > >> files.
> > > > > >> >
> > > > > >> > However, only TT and GHT variables were taken by the
Gridstat.
> > > > > >> > It couldn't digest UU and VV variables in the met_em
files.
> > > > > >> > Regarding the issue, I got WARNING and ERROR messages
as
> below:
> > > > > >> >
> > > > > >> > WARNING: process_scores() -> UU(0,0,*,*) not found in
file:
> > > > > >> > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> > > > > 1976-01-01_00:00:
> > > > > >> > 00.nc
> > > > > >> >
> > > > > >> > ERROR : PinterpFile::data(NcVar *, const LongArray &,
> DataPlane
> > > &,
> > > > > >> double
> > > > > >> > &) const -> can't find needed dimensions(s) for
variable "UU"
> > ...
> > > > one
> > > > > of
> > > > > >> > the dimensions may be staggered.
> > > > > >> > In fact, I confirmed that U-wind and V-wind variables
are
> > > staggered
> > > > in
> > > > > >> the
> > > > > >> > met_em grid for the WRF processing.
> > > > > >> > Do you know how I can proceed?
> > > > > >> > Thank you.
> > > > > >> > Regards,
> > > > > >> >
> > > > > >> > Jinwoong
> > > > > >> >
> > > > > >> > On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo <
> > > > jinwoong.yoo at gmail.com
> > > > > >
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> > > Hi John,
> > > > > >> > >
> > > > > >> > > Thank you very much for your time and your kindness.
> > > > > >> > > Let me apply this to my application.
> > > > > >> > > I will let you know how it goes.
> > > > > >> > > Thank you.
> > > > > >> > > Have a nice weekend.
> > > > > >> > >
> > > > > >> > > Regards,
> > > > > >> > >
> > > > > >> > > Jinwoong
> > > > > >> > >
> > > > > >> > > On Fri, Jul 14, 2017 at 5:05 PM, John Halley Gotway
via RT <
> > > > > >> > > met_help at ucar.edu> wrote:
> > > > > >> > >
> > > > > >> > >> Jinwoong,
> > > > > >> > >>
> > > > > >> > >> I'm sorry this took so long, but the good news is
that it's
> > an
> > > > easy
> > > > > >> fix.
> > > > > >> > >>
> > > > > >> > >> The "file_type" setting needs to be defined at one
higher
> > level
> > > > of
> > > > > >> > >> context,
> > > > > >> > >> like this:
> > > > > >> > >>
> > > > > >> > >> fcst = {
> > > > > >> > >>
> > > > > >> > >> file_type = NETCDF_PINT;
> > > > > >> > >>
> > > > > >> > >> field = [
> > > > > >> > >> {
> > > > > >> > >> name = "TT";
> > > > > >> > >> level = [ "(0,0,*,*)" ];
> > > > > >> > >> cat_thresh = [];
> > > > > >> > >> }
> > > > > >> > >> ];
> > > > > >> > >>
> > > > > >> > >> }
> > > > > >> > >>
> > > > > >> > >> The "fcst" section defines information about the
input
> > forecast
> > > > > file,
> > > > > >> > and
> > > > > >> > >> the "obs" section defines information about the
input
> > > observation
> > > > > >> file.
> > > > > >> > >>
> > > > > >> > >> The "file_type" setting defines how to interpret
these
> input
> > > > files.
> > > > > >> So
> > > > > >> > >> the
> > > > > >> > >> code parses it from inside the "fcst" and "obs"
> > dictionaries...
> > > > not
> > > > > >> > >> separately for each entry in the "field" array.
> > > > > >> > >>
> > > > > >> > >> Here's the note in the file met-
6.0/data/config/README
> about
> > > > this:
> > > > > >> > >>
> > > > > >> > >> // - The "file_type" entry specifies the input
file type
> > > rather
> > > > > >> than
> > > > > >> > >> letting
> > > > > >> > >> // the code determine it itself. For valid
file_type
> > > values,
> > > > > see
> > > > > >> > >> "File
> > > > > >> > >> types"
> > > > > >> > >> // in the data/config/ConfigConstants file.
> > > > > >> > >>
> > > > > >> > >> That obviously doesn't explain it well enough. For
the
> next
> > > > > release,
> > > > > >> > I'll
> > > > > >> > >> update it to read:
> > > > > >> > >>
> > > > > >> > >> // - The "file_type" entry specifies the input
file type
> > > rather
> > > > > >> than
> > > > > >> > >> letting
> > > > > >> > >> // the code determine it itself. For valid
file_type
> > > values,
> > > > > see
> > > > > >> > >> "File
> > > > > >> > >> types"
> > > > > >> > >> // in the data/config/ConfigConstants file.
This entry
> > > > should
> > > > > be
> > > > > >> > >> defined within
> > > > > >> > >> // the "fcst" or "obs" dictionaries.
> > > > > >> > >> // e.g.
> > > > > >> > >> // fcst = {
> > > > > >> > >> // file_type = NETCDF_NCCF;
> > > > > >> > >> // ...
> > > > > >> > >> // }
> > > > > >> > >>
> > > > > >> > >> Thanks,
> > > > > >> > >> John
> > > > > >> > >>
> > > > > >> > >>
> > > > > >> > >
> > > > > >> >
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Tue Aug 08 14:42:56 2017
Hi Minna,
I was able to run the command by setting as
'name="SOILM";GRIB_lvl_typ=112; GRIB_lvl_val1=0;GRIB_lvl_val2=200;'
As it is, I had to set both GRIB_lvl_val1=0 and GRIB_lvl_val2=200 to
specify the range.
Then, how can I set it in config file for GridStat?
Can I set as below?
{
name = "SOILM";
GRIB_lvl_typ="112";
GRIB_lvl_val1="0";
GRIB_lvl_val2="200";
cat_thresh = [];
}
Thank you.
Regards,
Jinwoong
On Tue, Aug 8, 2017 at 3:51 PM, Minna Win via RT <met_help at ucar.edu>
wrote:
> Hi Jinwoong,
>
> Given your GRIB1 output from wgrib, you might want to try the
following:
>
> $MET_BIN/plot_data_plane \
> <grib data> \
> <output ps file> \
> 'name="SOILM"; GRIB_lvl_typ=112; GRIB_lvl_val1=0;' -v 4
>
>
>
> I forgot to mention that for GRIB1, you can also look at the wgrib
output
> and set GRIB_lvl_typ to the kpds6 value, in this case it is 112
(useful if
> there isn't a description for you to look up and match to the
"Value"
> column in the ON388 table).
>
> Regards,
> Minna
>
> ---------------
> Minna Win
> NCAR
> Research Applications Lab
> Phone: 303-497-8423
> Fax: 302-497-8401
>
>
> On Tue, Aug 8, 2017 at 7:34 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >
> > Hi Minna,
> >
> > I am using the NARR grib1 data along with WRF UPP output grib2
data.
> > I would like to retrieve SOILM variable for the level of 0-200 cm
down
> from
> > both of the datasets.
> > Below is the print out of the variable from the NARR data.
> >
> > ec 283:37526500:date 2005123121 SOILM kpds5=86 kpds6=112 kpds7=200
> > levels=(0,200) grid=221 0-200 cm down anl: bitmap: 68650 undef
> >
> > SOILM=Soil moisture content [kg/m^2]
> >
> > timerange 0 P1 0 P2 0 TimeU 1 nx 349 ny 277 GDS grid 3
num_in_ave 0
> > missing 0
> >
> > center 7 subcenter 15 process 140 Table 131 scan: WE:SN
winds(N/S)
> >
> > Lambert Conf: Lat1 1.000000 Lon1 -145.500000 Lov -107.000000
> >
> > Latin1 50.000000 Latin2 50.000000 LatSP 0.000000 LonSP
0.000000
> >
> > North Pole (349 x 277) Dx 32.463000 Dy 32.463000 scan 64
mode 0
> >
> > min/max data 57.0137 936.014 num bits 14 BDS_Ref 570.137
DecScale 1
> > BinScale 0
> >
> >
> >
> > Thank you.
> > Regards,
> >
> > Jinwoong
> >
> > On Tue, Aug 8, 2017 at 3:25 PM, Minna Win via RT
<met_help at ucar.edu>
> > wrote:
> >
> > > Hi Jinwoong,
> > >
> > > I had to deal with uncommon levels for a recent project (ie
freezing
> > level,
> > > max wind speed, tropopause). MET has support for such instances
in the
> > > form of:
> > >
> > > $MET_BIN/plot_data_plane \
> > > <grib data file> \
> > > <output ps file >\
> > > 'name="<variable>"; GRIB_lvl_typ=<type>; GRIB_lvl_val1=<value> \
> > > -v 4
> > >
> > > For my data, I had to look up the values for GRIB_lvl_typ using
the
> > > following GRIB1 and GRIB2 tables:
> > >
> > > GRIB2:
> > > http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table4-5.shtml
> > >
> > > GRIB1:
> > > http://www.nco.ncep.noaa.gov/pmb/docs/on388/table3.html#TABLE3A
> > >
> > > You can use wgrib or wgrib2 to see whether your variable of
interest
> has
> > > information about the level:
> > > e.g.
> > > For grib2 data
> > > wgrib2 GALWEM_20170602_CY00_FH06.GR2 | grep PRES
> > >
> > > which gives:
> > > 519:658332188:d=2017060200 <%28201%29%20706-0200>:PRES:max
wind:6 hour
> > > fcst:
> > > 559:694572877:d=2017060200 <%28201%29%20706-0200>:PRES:surface:6
hour
> > > fcst:
> > > 567:704111051:d=2017060200 <%28201%29%20706-
0200>:PRES:tropopause:6
> hour
> > > fcst:
> > >
> > > I then used the descriptions of 'max wind' and 'tropopause' to
look up
> > the
> > > 'code figure' column value in the GRIB2 table 4-5
> > >
> > >
> > > For example, if your data is in GRIB2, set GRIB_lvl_typ to the
'code
> > > figure' value from table 4.5. Following the example from above,
for
> > > 'tropopause' you would set GRIB_lvl_typ=7 and GRIB_lvl_val1=0.
> Likewise
> > > for GRIB1 data, except you would refer to ON388 TABLE 3A and
set the
> > > GRIB_lvl_typ to the value under the "Value" column.
> > >
> > > What data are you using, and what variable and level do you need
to
> > > access? Please let us know if you need additional
clarification.
> > >
> > > Regards,
> > > Minna
> > >
> > >
> > >
> > > ---------------
> > > Minna Win
> > > NCAR
> > > Research Applications Lab
> > > Phone: 303-497-8423
> > > Fax: 302-497-8401
> > >
> > >
> > > On Tue, Aug 8, 2017 at 6:36 PM, Jinwoong Yoo via RT
<met_help at ucar.edu
> >
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
> > > >
> > > > Hi Minna,
> > > >
> > > > Thank you very much for your note.
> > > > Then, isn't there any letter specifically designated for below
ground
> > > > levels?
> > > > Let me try with "Z" (i.g., "Z1", "Z2", "Z3", and "Z4") first.
> > > > Thank you.
> > > >
> > > > Regards,
> > > >
> > > > Jinwoong
> > > >
> > > >
> > > >
> > > > On Tue, Aug 8, 2017 at 2:09 PM, Minna Win via RT
<met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > > Hi Jinwoong,
> > > > >
> > > > > This is Minna, another developer on the MET team. I have
> experienced
> > > the
> > > > > same issue, especially with uncommon data sets. John showed
me how
> > to
> > > > use
> > > > > MET's plot_data_plane to test whether to use 'Z', 'G', or
'L':
> > > > > Try running plot_data_plane in the following manner, but
replace
> > > $MET_BIN
> > > > > for the location of your MET binaries, replace <grib_file>
for the
> > full
> > > > > path to your grib1 or grib2 data file, replace <output_ps>
for the
> > name
> > > > of
> > > > > the output plot, and replace "TMP" with your variable of
interest:
> > > > >
> > > > > $MET_BIN/plot_data_plane \
> > > > > <grib file> \
> > > > > <output ps file> \
> > > > > 'name="TMP"; level="Z0";' \
> > > > > -v 4
> > > > >
> > > > > If the correct level descriptor works, then the log (output
to
> > stdout)
> > > > will
> > > > > indicate that a match has been found with the record number.
I
> hope
> > > this
> > > > > helps.
> > > > >
> > > > > Regards,
> > > > > Minna
> > > > >
> > > > > ---------------
> > > > > Minna Win
> > > > > NCAR
> > > > > Research Applications Lab
> > > > > Phone: 303-497-8423
> > > > > Fax: 302-497-8401
> > > > >
> > > > >
> > > > > On Tue, Aug 8, 2017 at 5:59 PM, Jinwoong Yoo via RT <
> > met_help at ucar.edu
> > > >
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > > > > >
> > > > > > Hi John,
> > > > > >
> > > > > >
> > > > > > I know surface variables use "Z" and pressure level
variables use
> > > "P".
> > > > > > How can I correctly specify the level for the below ground
> > variables
> > > > such
> > > > > > as soil moisture?
> > > > > >
> > > > > > Can I use "Z", "G", "L", or something else?
> > > > > > It is hard to find it from the Users' Guide.
> > > > > > I have four layers of soil moisture at the NARR data set.
> > > > > >
> > > > > > Thank you very much.
> > > > > > Regards,
> > > > > >
> > > > > > Jinwoong
> > > > > >
> > > > > > On Tue, Aug 1, 2017 at 3:26 PM, Jinwoong Yoo <
> > jinwoong.yoo at gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi John,
> > > > > > >
> > > > > > > I see.
> > > > > > > Thank you very much for your thoughts.
> > > > > > > Regards,
> > > > > > >
> > > > > > > Jinwoong
> > > > > > >
> > > > > > > On Tue, Aug 1, 2017 at 3:18 PM, John Halley Gotway via
RT <
> > > > > > > met_help at ucar.edu> wrote:
> > > > > > >
> > > > > > >> Jinwoong,
> > > > > > >>
> > > > > > >> Yes, that is a severe limitation when MET reads the
NetCDF
> > output
> > > > from
> > > > > > >> WRF. It does not read variables defined on the
staggered
> > > > dimensions.
> > > > > > So
> > > > > > >> it only reads variables from mass points, not velocity
points.
> > > > > > >>
> > > > > > >> We recommend using the Unified Post Processor (UPP)
software
> to
> > > > > > >> postprocess
> > > > > > >> the output of WRF. One of the things it does is
interpolate
> > data
> > > > from
> > > > > > the
> > > > > > >> staggered dimensions to a regular grid. It writes
output in
> > GRIB1
> > > > or
> > > > > > >> GRIB2
> > > > > > >> format which MET handles nicely.
> > > > > > >>
> > > > > > >> Thanks,
> > > > > > >> John
> > > > > > >>
> > > > > > >> On Fri, Jul 28, 2017 at 12:46 PM, Jinwoong Yoo via RT <
> > > > > > met_help at ucar.edu>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> >
> > > > > > >> > <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=81063
> > >
> > > > > > >> >
> > > > > > >> > Hi John,
> > > > > > >> >
> > > > > > >> > Inserting the "file_type = NETCDF_PINT;" above the
field
> list
> > > line
> > > > > > >> seems to
> > > > > > >> > work.
> > > > > > >> > In this way I was able to process my met_em files
against
> WRF
> > > > grib2
> > > > > > >> files.
> > > > > > >> >
> > > > > > >> > However, only TT and GHT variables were taken by the
> Gridstat.
> > > > > > >> > It couldn't digest UU and VV variables in the met_em
files.
> > > > > > >> > Regarding the issue, I got WARNING and ERROR messages
as
> > below:
> > > > > > >> >
> > > > > > >> > WARNING: process_scores() -> UU(0,0,*,*) not found in
file:
> > > > > > >> > /scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> > > > > > 1976-01-01_00:00:
> > > > > > >> > 00.nc
> > > > > > >> >
> > > > > > >> > ERROR : PinterpFile::data(NcVar *, const LongArray
&,
> > DataPlane
> > > > &,
> > > > > > >> double
> > > > > > >> > &) const -> can't find needed dimensions(s) for
variable
> "UU"
> > > ...
> > > > > one
> > > > > > of
> > > > > > >> > the dimensions may be staggered.
> > > > > > >> > In fact, I confirmed that U-wind and V-wind variables
are
> > > > staggered
> > > > > in
> > > > > > >> the
> > > > > > >> > met_em grid for the WRF processing.
> > > > > > >> > Do you know how I can proceed?
> > > > > > >> > Thank you.
> > > > > > >> > Regards,
> > > > > > >> >
> > > > > > >> > Jinwoong
> > > > > > >> >
> > > > > > >> > On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo <
> > > > > jinwoong.yoo at gmail.com
> > > > > > >
> > > > > > >> > wrote:
> > > > > > >> >
> > > > > > >> > > Hi John,
> > > > > > >> > >
> > > > > > >> > > Thank you very much for your time and your
kindness.
> > > > > > >> > > Let me apply this to my application.
> > > > > > >> > > I will let you know how it goes.
> > > > > > >> > > Thank you.
> > > > > > >> > > Have a nice weekend.
> > > > > > >> > >
> > > > > > >> > > Regards,
> > > > > > >> > >
> > > > > > >> > > Jinwoong
> > > > > > >> > >
> > > > > > >> > > On Fri, Jul 14, 2017 at 5:05 PM, John Halley Gotway
via
> RT <
> > > > > > >> > > met_help at ucar.edu> wrote:
> > > > > > >> > >
> > > > > > >> > >> Jinwoong,
> > > > > > >> > >>
> > > > > > >> > >> I'm sorry this took so long, but the good news is
that
> it's
> > > an
> > > > > easy
> > > > > > >> fix.
> > > > > > >> > >>
> > > > > > >> > >> The "file_type" setting needs to be defined at one
higher
> > > level
> > > > > of
> > > > > > >> > >> context,
> > > > > > >> > >> like this:
> > > > > > >> > >>
> > > > > > >> > >> fcst = {
> > > > > > >> > >>
> > > > > > >> > >> file_type = NETCDF_PINT;
> > > > > > >> > >>
> > > > > > >> > >> field = [
> > > > > > >> > >> {
> > > > > > >> > >> name = "TT";
> > > > > > >> > >> level = [ "(0,0,*,*)" ];
> > > > > > >> > >> cat_thresh = [];
> > > > > > >> > >> }
> > > > > > >> > >> ];
> > > > > > >> > >>
> > > > > > >> > >> }
> > > > > > >> > >>
> > > > > > >> > >> The "fcst" section defines information about the
input
> > > forecast
> > > > > > file,
> > > > > > >> > and
> > > > > > >> > >> the "obs" section defines information about the
input
> > > > observation
> > > > > > >> file.
> > > > > > >> > >>
> > > > > > >> > >> The "file_type" setting defines how to interpret
these
> > input
> > > > > files.
> > > > > > >> So
> > > > > > >> > >> the
> > > > > > >> > >> code parses it from inside the "fcst" and "obs"
> > > dictionaries...
> > > > > not
> > > > > > >> > >> separately for each entry in the "field" array.
> > > > > > >> > >>
> > > > > > >> > >> Here's the note in the file met-
6.0/data/config/README
> > about
> > > > > this:
> > > > > > >> > >>
> > > > > > >> > >> // - The "file_type" entry specifies the input
file
> type
> > > > rather
> > > > > > >> than
> > > > > > >> > >> letting
> > > > > > >> > >> // the code determine it itself. For valid
file_type
> > > > values,
> > > > > > see
> > > > > > >> > >> "File
> > > > > > >> > >> types"
> > > > > > >> > >> // in the data/config/ConfigConstants file.
> > > > > > >> > >>
> > > > > > >> > >> That obviously doesn't explain it well enough.
For the
> > next
> > > > > > release,
> > > > > > >> > I'll
> > > > > > >> > >> update it to read:
> > > > > > >> > >>
> > > > > > >> > >> // - The "file_type" entry specifies the input
file
> type
> > > > rather
> > > > > > >> than
> > > > > > >> > >> letting
> > > > > > >> > >> // the code determine it itself. For valid
file_type
> > > > values,
> > > > > > see
> > > > > > >> > >> "File
> > > > > > >> > >> types"
> > > > > > >> > >> // in the data/config/ConfigConstants file.
This
> entry
> > > > > should
> > > > > > be
> > > > > > >> > >> defined within
> > > > > > >> > >> // the "fcst" or "obs" dictionaries.
> > > > > > >> > >> // e.g.
> > > > > > >> > >> // fcst = {
> > > > > > >> > >> // file_type = NETCDF_NCCF;
> > > > > > >> > >> // ...
> > > > > > >> > >> // }
> > > > > > >> > >>
> > > > > > >> > >> Thanks,
> > > > > > >> > >> John
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >> > >
> > > > > > >> >
> > > > > > >> >
> > > > > > >>
> > > > > > >>
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Minna Win
Time: Tue Aug 08 15:46:30 2017
Hi Jinwoon,
Yes, that is correct. The GRIB_lvl_typ and
GRIB_lvl_val1/GRIB_lvl_val2 are
supported for all the MET applications that need to have a level
specified. My apologies for forgetting to indicate that. Hopefully,
you
can continue to use plot_data_plane to test out your levels and then
use
those values in the grid-stat and other config files. Please let me
know
if that doesn't work for you.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Tue, Aug 8, 2017 at 8:42 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>
> Hi Minna,
>
> I was able to run the command by setting as
>
> 'name="SOILM";GRIB_lvl_typ=112; GRIB_lvl_val1=0;GRIB_lvl_val2=200;'
>
> As it is, I had to set both GRIB_lvl_val1=0 and GRIB_lvl_val2=200
to
> specify the range.
>
> Then, how can I set it in config file for GridStat?
>
> Can I set as below?
>
> {
>
> name = "SOILM";
>
> GRIB_lvl_typ="112";
>
> GRIB_lvl_val1="0";
>
> GRIB_lvl_val2="200";
>
> cat_thresh = [];
>
> }
>
> Thank you.
>
> Regards,
>
>
> Jinwoong
>
>
>
>
> On Tue, Aug 8, 2017 at 3:51 PM, Minna Win via RT <met_help at ucar.edu>
> wrote:
>
> > Hi Jinwoong,
> >
> > Given your GRIB1 output from wgrib, you might want to try the
following:
> >
> > $MET_BIN/plot_data_plane \
> > <grib data> \
> > <output ps file> \
> > 'name="SOILM"; GRIB_lvl_typ=112; GRIB_lvl_val1=0;' -v 4
> >
> >
> >
> > I forgot to mention that for GRIB1, you can also look at the wgrib
output
> > and set GRIB_lvl_typ to the kpds6 value, in this case it is 112
(useful
> if
> > there isn't a description for you to look up and match to the
"Value"
> > column in the ON388 table).
> >
> > Regards,
> > Minna
> >
> > ---------------
> > Minna Win
> > NCAR
> > Research Applications Lab
> > Phone: 303-497-8423
> > Fax: 302-497-8401
> >
> >
> > On Tue, Aug 8, 2017 at 7:34 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > >
> > > Hi Minna,
> > >
> > > I am using the NARR grib1 data along with WRF UPP output grib2
data.
> > > I would like to retrieve SOILM variable for the level of 0-200
cm down
> > from
> > > both of the datasets.
> > > Below is the print out of the variable from the NARR data.
> > >
> > > ec 283:37526500:date 2005123121 SOILM kpds5=86 kpds6=112
kpds7=200
> > > levels=(0,200) grid=221 0-200 cm down anl: bitmap: 68650 undef
> > >
> > > SOILM=Soil moisture content [kg/m^2]
> > >
> > > timerange 0 P1 0 P2 0 TimeU 1 nx 349 ny 277 GDS grid 3
num_in_ave 0
> > > missing 0
> > >
> > > center 7 subcenter 15 process 140 Table 131 scan: WE:SN
winds(N/S)
> > >
> > > Lambert Conf: Lat1 1.000000 Lon1 -145.500000 Lov -107.000000
> > >
> > > Latin1 50.000000 Latin2 50.000000 LatSP 0.000000 LonSP
0.000000
> > >
> > > North Pole (349 x 277) Dx 32.463000 Dy 32.463000 scan 64
mode 0
> > >
> > > min/max data 57.0137 936.014 num bits 14 BDS_Ref 570.137
DecScale
> 1
> > > BinScale 0
> > >
> > >
> > >
> > > Thank you.
> > > Regards,
> > >
> > > Jinwoong
> > >
> > > On Tue, Aug 8, 2017 at 3:25 PM, Minna Win via RT
<met_help at ucar.edu>
> > > wrote:
> > >
> > > > Hi Jinwoong,
> > > >
> > > > I had to deal with uncommon levels for a recent project (ie
freezing
> > > level,
> > > > max wind speed, tropopause). MET has support for such
instances in
> the
> > > > form of:
> > > >
> > > > $MET_BIN/plot_data_plane \
> > > > <grib data file> \
> > > > <output ps file >\
> > > > 'name="<variable>"; GRIB_lvl_typ=<type>; GRIB_lvl_val1=<value>
\
> > > > -v 4
> > > >
> > > > For my data, I had to look up the values for GRIB_lvl_typ
using the
> > > > following GRIB1 and GRIB2 tables:
> > > >
> > > > GRIB2:
> > > > http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table4-
5.shtml
> > > >
> > > > GRIB1:
> > > >
http://www.nco.ncep.noaa.gov/pmb/docs/on388/table3.html#TABLE3A
> > > >
> > > > You can use wgrib or wgrib2 to see whether your variable of
interest
> > has
> > > > information about the level:
> > > > e.g.
> > > > For grib2 data
> > > > wgrib2 GALWEM_20170602_CY00_FH06.GR2 | grep PRES
> > > >
> > > > which gives:
> > > > 519:658332188:d=2017060200 <%28201%29%20706-0200>:PRES:max
wind:6
> hour
> > > > fcst:
> > > > 559:694572877:d=2017060200 <%28201%29%20706-
0200>:PRES:surface:6
> hour
> > > > fcst:
> > > > 567:704111051:d=2017060200 <%28201%29%20706-
0200>:PRES:tropopause:6
> > hour
> > > > fcst:
> > > >
> > > > I then used the descriptions of 'max wind' and 'tropopause' to
look
> up
> > > the
> > > > 'code figure' column value in the GRIB2 table 4-5
> > > >
> > > >
> > > > For example, if your data is in GRIB2, set GRIB_lvl_typ to the
'code
> > > > figure' value from table 4.5. Following the example from
above, for
> > > > 'tropopause' you would set GRIB_lvl_typ=7 and
GRIB_lvl_val1=0.
> > Likewise
> > > > for GRIB1 data, except you would refer to ON388 TABLE 3A and
set the
> > > > GRIB_lvl_typ to the value under the "Value" column.
> > > >
> > > > What data are you using, and what variable and level do you
need to
> > > > access? Please let us know if you need additional
clarification.
> > > >
> > > > Regards,
> > > > Minna
> > > >
> > > >
> > > >
> > > > ---------------
> > > > Minna Win
> > > > NCAR
> > > > Research Applications Lab
> > > > Phone: 303-497-8423
> > > > Fax: 302-497-8401
> > > >
> > > >
> > > > On Tue, Aug 8, 2017 at 6:36 PM, Jinwoong Yoo via RT <
> met_help at ucar.edu
> > >
> > > > wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > > > >
> > > > > Hi Minna,
> > > > >
> > > > > Thank you very much for your note.
> > > > > Then, isn't there any letter specifically designated for
below
> ground
> > > > > levels?
> > > > > Let me try with "Z" (i.g., "Z1", "Z2", "Z3", and "Z4")
first.
> > > > > Thank you.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Jinwoong
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Aug 8, 2017 at 2:09 PM, Minna Win via RT <
> met_help at ucar.edu>
> > > > > wrote:
> > > > >
> > > > > > Hi Jinwoong,
> > > > > >
> > > > > > This is Minna, another developer on the MET team. I have
> > experienced
> > > > the
> > > > > > same issue, especially with uncommon data sets. John
showed me
> how
> > > to
> > > > > use
> > > > > > MET's plot_data_plane to test whether to use 'Z', 'G', or
'L':
> > > > > > Try running plot_data_plane in the following manner, but
replace
> > > > $MET_BIN
> > > > > > for the location of your MET binaries, replace <grib_file>
for
> the
> > > full
> > > > > > path to your grib1 or grib2 data file, replace <output_ps>
for
> the
> > > name
> > > > > of
> > > > > > the output plot, and replace "TMP" with your variable of
> interest:
> > > > > >
> > > > > > $MET_BIN/plot_data_plane \
> > > > > > <grib file> \
> > > > > > <output ps file> \
> > > > > > 'name="TMP"; level="Z0";' \
> > > > > > -v 4
> > > > > >
> > > > > > If the correct level descriptor works, then the log
(output to
> > > stdout)
> > > > > will
> > > > > > indicate that a match has been found with the record
number. I
> > hope
> > > > this
> > > > > > helps.
> > > > > >
> > > > > > Regards,
> > > > > > Minna
> > > > > >
> > > > > > ---------------
> > > > > > Minna Win
> > > > > > NCAR
> > > > > > Research Applications Lab
> > > > > > Phone: 303-497-8423
> > > > > > Fax: 302-497-8401
> > > > > >
> > > > > >
> > > > > > On Tue, Aug 8, 2017 at 5:59 PM, Jinwoong Yoo via RT <
> > > met_help at ucar.edu
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
> >
> > > > > > >
> > > > > > > Hi John,
> > > > > > >
> > > > > > >
> > > > > > > I know surface variables use "Z" and pressure level
variables
> use
> > > > "P".
> > > > > > > How can I correctly specify the level for the below
ground
> > > variables
> > > > > such
> > > > > > > as soil moisture?
> > > > > > >
> > > > > > > Can I use "Z", "G", "L", or something else?
> > > > > > > It is hard to find it from the Users' Guide.
> > > > > > > I have four layers of soil moisture at the NARR data
set.
> > > > > > >
> > > > > > > Thank you very much.
> > > > > > > Regards,
> > > > > > >
> > > > > > > Jinwoong
> > > > > > >
> > > > > > > On Tue, Aug 1, 2017 at 3:26 PM, Jinwoong Yoo <
> > > jinwoong.yoo at gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi John,
> > > > > > > >
> > > > > > > > I see.
> > > > > > > > Thank you very much for your thoughts.
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Jinwoong
> > > > > > > >
> > > > > > > > On Tue, Aug 1, 2017 at 3:18 PM, John Halley Gotway via
RT <
> > > > > > > > met_help at ucar.edu> wrote:
> > > > > > > >
> > > > > > > >> Jinwoong,
> > > > > > > >>
> > > > > > > >> Yes, that is a severe limitation when MET reads the
NetCDF
> > > output
> > > > > from
> > > > > > > >> WRF. It does not read variables defined on the
staggered
> > > > > dimensions.
> > > > > > > So
> > > > > > > >> it only reads variables from mass points, not
velocity
> points.
> > > > > > > >>
> > > > > > > >> We recommend using the Unified Post Processor (UPP)
software
> > to
> > > > > > > >> postprocess
> > > > > > > >> the output of WRF. One of the things it does is
interpolate
> > > data
> > > > > from
> > > > > > > the
> > > > > > > >> staggered dimensions to a regular grid. It writes
output in
> > > GRIB1
> > > > > or
> > > > > > > >> GRIB2
> > > > > > > >> format which MET handles nicely.
> > > > > > > >>
> > > > > > > >> Thanks,
> > > > > > > >> John
> > > > > > > >>
> > > > > > > >> On Fri, Jul 28, 2017 at 12:46 PM, Jinwoong Yoo via RT
<
> > > > > > > met_help at ucar.edu>
> > > > > > > >> wrote:
> > > > > > > >>
> > > > > > > >> >
> > > > > > > >> > <URL: https://rt.rap.ucar.edu/rt/
> > Ticket/Display.html?id=81063
> > > >
> > > > > > > >> >
> > > > > > > >> > Hi John,
> > > > > > > >> >
> > > > > > > >> > Inserting the "file_type = NETCDF_PINT;" above the
field
> > list
> > > > line
> > > > > > > >> seems to
> > > > > > > >> > work.
> > > > > > > >> > In this way I was able to process my met_em files
against
> > WRF
> > > > > grib2
> > > > > > > >> files.
> > > > > > > >> >
> > > > > > > >> > However, only TT and GHT variables were taken by
the
> > Gridstat.
> > > > > > > >> > It couldn't digest UU and VV variables in the
met_em
> files.
> > > > > > > >> > Regarding the issue, I got WARNING and ERROR
messages as
> > > below:
> > > > > > > >> >
> > > > > > > >> > WARNING: process_scores() -> UU(0,0,*,*) not found
in
> file:
> > > > > > > >> >
/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> > > > > > > 1976-01-01_00:00:
> > > > > > > >> > 00.nc
> > > > > > > >> >
> > > > > > > >> > ERROR : PinterpFile::data(NcVar *, const LongArray
&,
> > > DataPlane
> > > > > &,
> > > > > > > >> double
> > > > > > > >> > &) const -> can't find needed dimensions(s) for
variable
> > "UU"
> > > > ...
> > > > > > one
> > > > > > > of
> > > > > > > >> > the dimensions may be staggered.
> > > > > > > >> > In fact, I confirmed that U-wind and V-wind
variables are
> > > > > staggered
> > > > > > in
> > > > > > > >> the
> > > > > > > >> > met_em grid for the WRF processing.
> > > > > > > >> > Do you know how I can proceed?
> > > > > > > >> > Thank you.
> > > > > > > >> > Regards,
> > > > > > > >> >
> > > > > > > >> > Jinwoong
> > > > > > > >> >
> > > > > > > >> > On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo <
> > > > > > jinwoong.yoo at gmail.com
> > > > > > > >
> > > > > > > >> > wrote:
> > > > > > > >> >
> > > > > > > >> > > Hi John,
> > > > > > > >> > >
> > > > > > > >> > > Thank you very much for your time and your
kindness.
> > > > > > > >> > > Let me apply this to my application.
> > > > > > > >> > > I will let you know how it goes.
> > > > > > > >> > > Thank you.
> > > > > > > >> > > Have a nice weekend.
> > > > > > > >> > >
> > > > > > > >> > > Regards,
> > > > > > > >> > >
> > > > > > > >> > > Jinwoong
> > > > > > > >> > >
> > > > > > > >> > > On Fri, Jul 14, 2017 at 5:05 PM, John Halley
Gotway via
> > RT <
> > > > > > > >> > > met_help at ucar.edu> wrote:
> > > > > > > >> > >
> > > > > > > >> > >> Jinwoong,
> > > > > > > >> > >>
> > > > > > > >> > >> I'm sorry this took so long, but the good news
is that
> > it's
> > > > an
> > > > > > easy
> > > > > > > >> fix.
> > > > > > > >> > >>
> > > > > > > >> > >> The "file_type" setting needs to be defined at
one
> higher
> > > > level
> > > > > > of
> > > > > > > >> > >> context,
> > > > > > > >> > >> like this:
> > > > > > > >> > >>
> > > > > > > >> > >> fcst = {
> > > > > > > >> > >>
> > > > > > > >> > >> file_type = NETCDF_PINT;
> > > > > > > >> > >>
> > > > > > > >> > >> field = [
> > > > > > > >> > >> {
> > > > > > > >> > >> name = "TT";
> > > > > > > >> > >> level = [ "(0,0,*,*)" ];
> > > > > > > >> > >> cat_thresh = [];
> > > > > > > >> > >> }
> > > > > > > >> > >> ];
> > > > > > > >> > >>
> > > > > > > >> > >> }
> > > > > > > >> > >>
> > > > > > > >> > >> The "fcst" section defines information about the
input
> > > > forecast
> > > > > > > file,
> > > > > > > >> > and
> > > > > > > >> > >> the "obs" section defines information about the
input
> > > > > observation
> > > > > > > >> file.
> > > > > > > >> > >>
> > > > > > > >> > >> The "file_type" setting defines how to interpret
these
> > > input
> > > > > > files.
> > > > > > > >> So
> > > > > > > >> > >> the
> > > > > > > >> > >> code parses it from inside the "fcst" and "obs"
> > > > dictionaries...
> > > > > > not
> > > > > > > >> > >> separately for each entry in the "field" array.
> > > > > > > >> > >>
> > > > > > > >> > >> Here's the note in the file met-
6.0/data/config/README
> > > about
> > > > > > this:
> > > > > > > >> > >>
> > > > > > > >> > >> // - The "file_type" entry specifies the input
file
> > type
> > > > > rather
> > > > > > > >> than
> > > > > > > >> > >> letting
> > > > > > > >> > >> // the code determine it itself. For valid
> file_type
> > > > > values,
> > > > > > > see
> > > > > > > >> > >> "File
> > > > > > > >> > >> types"
> > > > > > > >> > >> // in the data/config/ConfigConstants file.
> > > > > > > >> > >>
> > > > > > > >> > >> That obviously doesn't explain it well enough.
For the
> > > next
> > > > > > > release,
> > > > > > > >> > I'll
> > > > > > > >> > >> update it to read:
> > > > > > > >> > >>
> > > > > > > >> > >> // - The "file_type" entry specifies the input
file
> > type
> > > > > rather
> > > > > > > >> than
> > > > > > > >> > >> letting
> > > > > > > >> > >> // the code determine it itself. For valid
> file_type
> > > > > values,
> > > > > > > see
> > > > > > > >> > >> "File
> > > > > > > >> > >> types"
> > > > > > > >> > >> // in the data/config/ConfigConstants file.
This
> > entry
> > > > > > should
> > > > > > > be
> > > > > > > >> > >> defined within
> > > > > > > >> > >> // the "fcst" or "obs" dictionaries.
> > > > > > > >> > >> // e.g.
> > > > > > > >> > >> // fcst = {
> > > > > > > >> > >> // file_type = NETCDF_NCCF;
> > > > > > > >> > >> // ...
> > > > > > > >> > >> // }
> > > > > > > >> > >>
> > > > > > > >> > >> Thanks,
> > > > > > > >> > >> John
> > > > > > > >> > >>
> > > > > > > >> > >>
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Tue Aug 08 16:23:32 2017
Hi Minna,
Thank you for your clarification.
Regards,
Jinwoong
On Tue, Aug 8, 2017 at 5:46 PM, Minna Win via RT <met_help at ucar.edu>
wrote:
> Hi Jinwoon,
>
> Yes, that is correct. The GRIB_lvl_typ and
GRIB_lvl_val1/GRIB_lvl_val2 are
> supported for all the MET applications that need to have a level
> specified. My apologies for forgetting to indicate that.
Hopefully, you
> can continue to use plot_data_plane to test out your levels and then
use
> those values in the grid-stat and other config files. Please let me
know
> if that doesn't work for you.
>
> Regards,
> Minna
>
> ---------------
> Minna Win
> NCAR
> Research Applications Lab
> Phone: 303-497-8423
> Fax: 302-497-8401
>
>
> On Tue, Aug 8, 2017 at 8:42 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >
> > Hi Minna,
> >
> > I was able to run the command by setting as
> >
> > 'name="SOILM";GRIB_lvl_typ=112;
GRIB_lvl_val1=0;GRIB_lvl_val2=200;'
> >
> > As it is, I had to set both GRIB_lvl_val1=0 and GRIB_lvl_val2=200
to
> > specify the range.
> >
> > Then, how can I set it in config file for GridStat?
> >
> > Can I set as below?
> >
> > {
> >
> > name = "SOILM";
> >
> > GRIB_lvl_typ="112";
> >
> > GRIB_lvl_val1="0";
> >
> > GRIB_lvl_val2="200";
> >
> > cat_thresh = [];
> >
> > }
> >
> > Thank you.
> >
> > Regards,
> >
> >
> > Jinwoong
> >
> >
> >
> >
> > On Tue, Aug 8, 2017 at 3:51 PM, Minna Win via RT
<met_help at ucar.edu>
> > wrote:
> >
> > > Hi Jinwoong,
> > >
> > > Given your GRIB1 output from wgrib, you might want to try the
> following:
> > >
> > > $MET_BIN/plot_data_plane \
> > > <grib data> \
> > > <output ps file> \
> > > 'name="SOILM"; GRIB_lvl_typ=112; GRIB_lvl_val1=0;' -v 4
> > >
> > >
> > >
> > > I forgot to mention that for GRIB1, you can also look at the
wgrib
> output
> > > and set GRIB_lvl_typ to the kpds6 value, in this case it is 112
(useful
> > if
> > > there isn't a description for you to look up and match to the
"Value"
> > > column in the ON388 table).
> > >
> > > Regards,
> > > Minna
> > >
> > > ---------------
> > > Minna Win
> > > NCAR
> > > Research Applications Lab
> > > Phone: 303-497-8423
> > > Fax: 302-497-8401
> > >
> > >
> > > On Tue, Aug 8, 2017 at 7:34 PM, Jinwoong Yoo via RT
<met_help at ucar.edu
> >
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
> > > >
> > > > Hi Minna,
> > > >
> > > > I am using the NARR grib1 data along with WRF UPP output grib2
data.
> > > > I would like to retrieve SOILM variable for the level of 0-200
cm
> down
> > > from
> > > > both of the datasets.
> > > > Below is the print out of the variable from the NARR data.
> > > >
> > > > ec 283:37526500:date 2005123121 SOILM kpds5=86 kpds6=112
kpds7=200
> > > > levels=(0,200) grid=221 0-200 cm down anl: bitmap: 68650 undef
> > > >
> > > > SOILM=Soil moisture content [kg/m^2]
> > > >
> > > > timerange 0 P1 0 P2 0 TimeU 1 nx 349 ny 277 GDS grid 3
num_in_ave
> 0
> > > > missing 0
> > > >
> > > > center 7 subcenter 15 process 140 Table 131 scan: WE:SN
winds(N/S)
> > > >
> > > > Lambert Conf: Lat1 1.000000 Lon1 -145.500000 Lov -107.000000
> > > >
> > > > Latin1 50.000000 Latin2 50.000000 LatSP 0.000000 LonSP
0.000000
> > > >
> > > > North Pole (349 x 277) Dx 32.463000 Dy 32.463000 scan 64
mode 0
> > > >
> > > > min/max data 57.0137 936.014 num bits 14 BDS_Ref 570.137
> DecScale
> > 1
> > > > BinScale 0
> > > >
> > > >
> > > >
> > > > Thank you.
> > > > Regards,
> > > >
> > > > Jinwoong
> > > >
> > > > On Tue, Aug 8, 2017 at 3:25 PM, Minna Win via RT
<met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > > Hi Jinwoong,
> > > > >
> > > > > I had to deal with uncommon levels for a recent project (ie
> freezing
> > > > level,
> > > > > max wind speed, tropopause). MET has support for such
instances in
> > the
> > > > > form of:
> > > > >
> > > > > $MET_BIN/plot_data_plane \
> > > > > <grib data file> \
> > > > > <output ps file >\
> > > > > 'name="<variable>"; GRIB_lvl_typ=<type>;
GRIB_lvl_val1=<value> \
> > > > > -v 4
> > > > >
> > > > > For my data, I had to look up the values for GRIB_lvl_typ
using the
> > > > > following GRIB1 and GRIB2 tables:
> > > > >
> > > > > GRIB2:
> > > > > http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table4-
5.shtml
> > > > >
> > > > > GRIB1:
> > > > >
http://www.nco.ncep.noaa.gov/pmb/docs/on388/table3.html#TABLE3A
> > > > >
> > > > > You can use wgrib or wgrib2 to see whether your variable of
> interest
> > > has
> > > > > information about the level:
> > > > > e.g.
> > > > > For grib2 data
> > > > > wgrib2 GALWEM_20170602_CY00_FH06.GR2 | grep PRES
> > > > >
> > > > > which gives:
> > > > > 519:658332188:d=2017060200 <%28201%29%20706-0200>:PRES:max
wind:6
> > hour
> > > > > fcst:
> > > > > 559:694572877:d=2017060200 <%28201%29%20706-
0200>:PRES:surface:6
> > hour
> > > > > fcst:
> > > > > 567:704111051:d=2017060200 <%28201%29%20706-0200>:PRES:
> tropopause:6
> > > hour
> > > > > fcst:
> > > > >
> > > > > I then used the descriptions of 'max wind' and 'tropopause'
to look
> > up
> > > > the
> > > > > 'code figure' column value in the GRIB2 table 4-5
> > > > >
> > > > >
> > > > > For example, if your data is in GRIB2, set GRIB_lvl_typ to
the
> 'code
> > > > > figure' value from table 4.5. Following the example from
above,
> for
> > > > > 'tropopause' you would set GRIB_lvl_typ=7 and
GRIB_lvl_val1=0.
> > > Likewise
> > > > > for GRIB1 data, except you would refer to ON388 TABLE 3A
and set
> the
> > > > > GRIB_lvl_typ to the value under the "Value" column.
> > > > >
> > > > > What data are you using, and what variable and level do you
need to
> > > > > access? Please let us know if you need additional
clarification.
> > > > >
> > > > > Regards,
> > > > > Minna
> > > > >
> > > > >
> > > > >
> > > > > ---------------
> > > > > Minna Win
> > > > > NCAR
> > > > > Research Applications Lab
> > > > > Phone: 303-497-8423
> > > > > Fax: 302-497-8401
> > > > >
> > > > >
> > > > > On Tue, Aug 8, 2017 at 6:36 PM, Jinwoong Yoo via RT <
> > met_help at ucar.edu
> > > >
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> > > > > >
> > > > > > Hi Minna,
> > > > > >
> > > > > > Thank you very much for your note.
> > > > > > Then, isn't there any letter specifically designated for
below
> > ground
> > > > > > levels?
> > > > > > Let me try with "Z" (i.g., "Z1", "Z2", "Z3", and "Z4")
first.
> > > > > > Thank you.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Jinwoong
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Aug 8, 2017 at 2:09 PM, Minna Win via RT <
> > met_help at ucar.edu>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Jinwoong,
> > > > > > >
> > > > > > > This is Minna, another developer on the MET team. I
have
> > > experienced
> > > > > the
> > > > > > > same issue, especially with uncommon data sets. John
showed me
> > how
> > > > to
> > > > > > use
> > > > > > > MET's plot_data_plane to test whether to use 'Z', 'G',
or 'L':
> > > > > > > Try running plot_data_plane in the following manner, but
> replace
> > > > > $MET_BIN
> > > > > > > for the location of your MET binaries, replace
<grib_file> for
> > the
> > > > full
> > > > > > > path to your grib1 or grib2 data file, replace
<output_ps> for
> > the
> > > > name
> > > > > > of
> > > > > > > the output plot, and replace "TMP" with your variable
of
> > interest:
> > > > > > >
> > > > > > > $MET_BIN/plot_data_plane \
> > > > > > > <grib file> \
> > > > > > > <output ps file> \
> > > > > > > 'name="TMP"; level="Z0";' \
> > > > > > > -v 4
> > > > > > >
> > > > > > > If the correct level descriptor works, then the log
(output to
> > > > stdout)
> > > > > > will
> > > > > > > indicate that a match has been found with the record
number. I
> > > hope
> > > > > this
> > > > > > > helps.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Minna
> > > > > > >
> > > > > > > ---------------
> > > > > > > Minna Win
> > > > > > > NCAR
> > > > > > > Research Applications Lab
> > > > > > > Phone: 303-497-8423
> > > > > > > Fax: 302-497-8401
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Aug 8, 2017 at 5:59 PM, Jinwoong Yoo via RT <
> > > > met_help at ucar.edu
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=81063
> > >
> > > > > > > >
> > > > > > > > Hi John,
> > > > > > > >
> > > > > > > >
> > > > > > > > I know surface variables use "Z" and pressure level
variables
> > use
> > > > > "P".
> > > > > > > > How can I correctly specify the level for the below
ground
> > > > variables
> > > > > > such
> > > > > > > > as soil moisture?
> > > > > > > >
> > > > > > > > Can I use "Z", "G", "L", or something else?
> > > > > > > > It is hard to find it from the Users' Guide.
> > > > > > > > I have four layers of soil moisture at the NARR data
set.
> > > > > > > >
> > > > > > > > Thank you very much.
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Jinwoong
> > > > > > > >
> > > > > > > > On Tue, Aug 1, 2017 at 3:26 PM, Jinwoong Yoo <
> > > > jinwoong.yoo at gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi John,
> > > > > > > > >
> > > > > > > > > I see.
> > > > > > > > > Thank you very much for your thoughts.
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > > Jinwoong
> > > > > > > > >
> > > > > > > > > On Tue, Aug 1, 2017 at 3:18 PM, John Halley Gotway
via RT <
> > > > > > > > > met_help at ucar.edu> wrote:
> > > > > > > > >
> > > > > > > > >> Jinwoong,
> > > > > > > > >>
> > > > > > > > >> Yes, that is a severe limitation when MET reads the
NetCDF
> > > > output
> > > > > > from
> > > > > > > > >> WRF. It does not read variables defined on the
staggered
> > > > > > dimensions.
> > > > > > > > So
> > > > > > > > >> it only reads variables from mass points, not
velocity
> > points.
> > > > > > > > >>
> > > > > > > > >> We recommend using the Unified Post Processor (UPP)
> software
> > > to
> > > > > > > > >> postprocess
> > > > > > > > >> the output of WRF. One of the things it does is
> interpolate
> > > > data
> > > > > > from
> > > > > > > > the
> > > > > > > > >> staggered dimensions to a regular grid. It writes
output
> in
> > > > GRIB1
> > > > > > or
> > > > > > > > >> GRIB2
> > > > > > > > >> format which MET handles nicely.
> > > > > > > > >>
> > > > > > > > >> Thanks,
> > > > > > > > >> John
> > > > > > > > >>
> > > > > > > > >> On Fri, Jul 28, 2017 at 12:46 PM, Jinwoong Yoo via
RT <
> > > > > > > > met_help at ucar.edu>
> > > > > > > > >> wrote:
> > > > > > > > >>
> > > > > > > > >> >
> > > > > > > > >> > <URL: https://rt.rap.ucar.edu/rt/
> > > Ticket/Display.html?id=81063
> > > > >
> > > > > > > > >> >
> > > > > > > > >> > Hi John,
> > > > > > > > >> >
> > > > > > > > >> > Inserting the "file_type = NETCDF_PINT;" above
the field
> > > list
> > > > > line
> > > > > > > > >> seems to
> > > > > > > > >> > work.
> > > > > > > > >> > In this way I was able to process my met_em files
> against
> > > WRF
> > > > > > grib2
> > > > > > > > >> files.
> > > > > > > > >> >
> > > > > > > > >> > However, only TT and GHT variables were taken by
the
> > > Gridstat.
> > > > > > > > >> > It couldn't digest UU and VV variables in the
met_em
> > files.
> > > > > > > > >> > Regarding the issue, I got WARNING and ERROR
messages as
> > > > below:
> > > > > > > > >> >
> > > > > > > > >> > WARNING: process_scores() -> UU(0,0,*,*) not
found in
> > file:
> > > > > > > > >> >
/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
> > > > > > > > 1976-01-01_00:00:
> > > > > > > > >> > 00.nc
> > > > > > > > >> >
> > > > > > > > >> > ERROR : PinterpFile::data(NcVar *, const
LongArray &,
> > > > DataPlane
> > > > > > &,
> > > > > > > > >> double
> > > > > > > > >> > &) const -> can't find needed dimensions(s) for
variable
> > > "UU"
> > > > > ...
> > > > > > > one
> > > > > > > > of
> > > > > > > > >> > the dimensions may be staggered.
> > > > > > > > >> > In fact, I confirmed that U-wind and V-wind
variables
> are
> > > > > > staggered
> > > > > > > in
> > > > > > > > >> the
> > > > > > > > >> > met_em grid for the WRF processing.
> > > > > > > > >> > Do you know how I can proceed?
> > > > > > > > >> > Thank you.
> > > > > > > > >> > Regards,
> > > > > > > > >> >
> > > > > > > > >> > Jinwoong
> > > > > > > > >> >
> > > > > > > > >> > On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo <
> > > > > > > jinwoong.yoo at gmail.com
> > > > > > > > >
> > > > > > > > >> > wrote:
> > > > > > > > >> >
> > > > > > > > >> > > Hi John,
> > > > > > > > >> > >
> > > > > > > > >> > > Thank you very much for your time and your
kindness.
> > > > > > > > >> > > Let me apply this to my application.
> > > > > > > > >> > > I will let you know how it goes.
> > > > > > > > >> > > Thank you.
> > > > > > > > >> > > Have a nice weekend.
> > > > > > > > >> > >
> > > > > > > > >> > > Regards,
> > > > > > > > >> > >
> > > > > > > > >> > > Jinwoong
> > > > > > > > >> > >
> > > > > > > > >> > > On Fri, Jul 14, 2017 at 5:05 PM, John Halley
Gotway
> via
> > > RT <
> > > > > > > > >> > > met_help at ucar.edu> wrote:
> > > > > > > > >> > >
> > > > > > > > >> > >> Jinwoong,
> > > > > > > > >> > >>
> > > > > > > > >> > >> I'm sorry this took so long, but the good news
is
> that
> > > it's
> > > > > an
> > > > > > > easy
> > > > > > > > >> fix.
> > > > > > > > >> > >>
> > > > > > > > >> > >> The "file_type" setting needs to be defined at
one
> > higher
> > > > > level
> > > > > > > of
> > > > > > > > >> > >> context,
> > > > > > > > >> > >> like this:
> > > > > > > > >> > >>
> > > > > > > > >> > >> fcst = {
> > > > > > > > >> > >>
> > > > > > > > >> > >> file_type = NETCDF_PINT;
> > > > > > > > >> > >>
> > > > > > > > >> > >> field = [
> > > > > > > > >> > >> {
> > > > > > > > >> > >> name = "TT";
> > > > > > > > >> > >> level = [ "(0,0,*,*)" ];
> > > > > > > > >> > >> cat_thresh = [];
> > > > > > > > >> > >> }
> > > > > > > > >> > >> ];
> > > > > > > > >> > >>
> > > > > > > > >> > >> }
> > > > > > > > >> > >>
> > > > > > > > >> > >> The "fcst" section defines information about
the
> input
> > > > > forecast
> > > > > > > > file,
> > > > > > > > >> > and
> > > > > > > > >> > >> the "obs" section defines information about
the input
> > > > > > observation
> > > > > > > > >> file.
> > > > > > > > >> > >>
> > > > > > > > >> > >> The "file_type" setting defines how to
interpret
> these
> > > > input
> > > > > > > files.
> > > > > > > > >> So
> > > > > > > > >> > >> the
> > > > > > > > >> > >> code parses it from inside the "fcst" and
"obs"
> > > > > dictionaries...
> > > > > > > not
> > > > > > > > >> > >> separately for each entry in the "field"
array.
> > > > > > > > >> > >>
> > > > > > > > >> > >> Here's the note in the file
> met-6.0/data/config/README
> > > > about
> > > > > > > this:
> > > > > > > > >> > >>
> > > > > > > > >> > >> // - The "file_type" entry specifies the
input file
> > > type
> > > > > > rather
> > > > > > > > >> than
> > > > > > > > >> > >> letting
> > > > > > > > >> > >> // the code determine it itself. For
valid
> > file_type
> > > > > > values,
> > > > > > > > see
> > > > > > > > >> > >> "File
> > > > > > > > >> > >> types"
> > > > > > > > >> > >> // in the data/config/ConfigConstants
file.
> > > > > > > > >> > >>
> > > > > > > > >> > >> That obviously doesn't explain it well enough.
For
> the
> > > > next
> > > > > > > > release,
> > > > > > > > >> > I'll
> > > > > > > > >> > >> update it to read:
> > > > > > > > >> > >>
> > > > > > > > >> > >> // - The "file_type" entry specifies the
input file
> > > type
> > > > > > rather
> > > > > > > > >> than
> > > > > > > > >> > >> letting
> > > > > > > > >> > >> // the code determine it itself. For
valid
> > file_type
> > > > > > values,
> > > > > > > > see
> > > > > > > > >> > >> "File
> > > > > > > > >> > >> types"
> > > > > > > > >> > >> // in the data/config/ConfigConstants
file. This
> > > entry
> > > > > > > should
> > > > > > > > be
> > > > > > > > >> > >> defined within
> > > > > > > > >> > >> // the "fcst" or "obs" dictionaries.
> > > > > > > > >> > >> // e.g.
> > > > > > > > >> > >> // fcst = {
> > > > > > > > >> > >> // file_type = NETCDF_NCCF;
> > > > > > > > >> > >> // ...
> > > > > > > > >> > >> // }
> > > > > > > > >> > >>
> > > > > > > > >> > >> Thanks,
> > > > > > > > >> > >> John
> > > > > > > > >> > >>
> > > > > > > > >> > >>
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Tue Aug 08 17:53:51 2017
Hi Minna,
I set field in config file as below but I got errors and gridstat
didn't
produce any output.
{
name = "SHTFL";
level = [ "Z0" ];
cat_thresh = [];
},
{
name = "LHTFL";
level = [ "Z0" ];
cat_thresh = [];
},
{
name = "DSWRF";
level = [ "Z0" ];
cat_thresh = [];
},
{
name = "DLWRF";
level = [ "Z0" ];
cat_thresh = [];
},
{
name = "USWRF";
level = [ "Z0" ];
cat_thresh = [];
},
{
name = "ULWRF";
level = [ "Z0" ];
cat_thresh = [];
},
{
name = "SOILM";
GRIB_lvl_typ="112";
GRIB_lvl_val1="0";
GRIB_lvl_val2="200";
// level = [ "Z0" ];
cat_thresh = [];
}
Error log looks as below.
ERROR : VarInfo::set_level_info_grib() - either level or
GRIB_lvl_typ,
GRIB_lvl_val1 and GRIB_lvl_val2 (if necessary) must be specified in
field
information
Can't I mix level = [ "Z0" ]; and GRIB_lvl_*
in
one config file?
When I tested them separately for plot_data_plane, they both worked.
Thank you.
Regards,
Jinwoong
On Tue, Aug 8, 2017 at 6:23 PM, Jinwoong Yoo <jinwoong.yoo at gmail.com>
wrote:
> Hi Minna,
> Thank you for your clarification.
> Regards,
>
> Jinwoong
>
> On Tue, Aug 8, 2017 at 5:46 PM, Minna Win via RT <met_help at ucar.edu>
> wrote:
>
>> Hi Jinwoon,
>>
>> Yes, that is correct. The GRIB_lvl_typ and
GRIB_lvl_val1/GRIB_lvl_val2
>> are
>> supported for all the MET applications that need to have a level
>> specified. My apologies for forgetting to indicate that.
Hopefully, you
>> can continue to use plot_data_plane to test out your levels and
then use
>> those values in the grid-stat and other config files. Please let
me know
>> if that doesn't work for you.
>>
>> Regards,
>> Minna
>>
>> ---------------
>> Minna Win
>> NCAR
>> Research Applications Lab
>> Phone: 303-497-8423
>> Fax: 302-497-8401
>>
>>
>> On Tue, Aug 8, 2017 at 8:42 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
>> wrote:
>>
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>> >
>> > Hi Minna,
>> >
>> > I was able to run the command by setting as
>> >
>> > 'name="SOILM";GRIB_lvl_typ=112;
GRIB_lvl_val1=0;GRIB_lvl_val2=200;'
>> >
>> > As it is, I had to set both GRIB_lvl_val1=0 and
GRIB_lvl_val2=200 to
>> > specify the range.
>> >
>> > Then, how can I set it in config file for GridStat?
>> >
>> > Can I set as below?
>> >
>> > {
>> >
>> > name = "SOILM";
>> >
>> > GRIB_lvl_typ="112";
>> >
>> > GRIB_lvl_val1="0";
>> >
>> > GRIB_lvl_val2="200";
>> >
>> > cat_thresh = [];
>> >
>> > }
>> >
>> > Thank you.
>> >
>> > Regards,
>> >
>> >
>> > Jinwoong
>> >
>> >
>> >
>> >
>> > On Tue, Aug 8, 2017 at 3:51 PM, Minna Win via RT
<met_help at ucar.edu>
>> > wrote:
>> >
>> > > Hi Jinwoong,
>> > >
>> > > Given your GRIB1 output from wgrib, you might want to try the
>> following:
>> > >
>> > > $MET_BIN/plot_data_plane \
>> > > <grib data> \
>> > > <output ps file> \
>> > > 'name="SOILM"; GRIB_lvl_typ=112; GRIB_lvl_val1=0;' -v 4
>> > >
>> > >
>> > >
>> > > I forgot to mention that for GRIB1, you can also look at the
wgrib
>> output
>> > > and set GRIB_lvl_typ to the kpds6 value, in this case it is 112
>> (useful
>> > if
>> > > there isn't a description for you to look up and match to the
"Value"
>> > > column in the ON388 table).
>> > >
>> > > Regards,
>> > > Minna
>> > >
>> > > ---------------
>> > > Minna Win
>> > > NCAR
>> > > Research Applications Lab
>> > > Phone: 303-497-8423
>> > > Fax: 302-497-8401
>> > >
>> > >
>> > > On Tue, Aug 8, 2017 at 7:34 PM, Jinwoong Yoo via RT <
>> met_help at ucar.edu>
>> > > wrote:
>> > >
>> > > >
>> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
>> > > >
>> > > > Hi Minna,
>> > > >
>> > > > I am using the NARR grib1 data along with WRF UPP output
grib2 data.
>> > > > I would like to retrieve SOILM variable for the level of 0-
200 cm
>> down
>> > > from
>> > > > both of the datasets.
>> > > > Below is the print out of the variable from the NARR data.
>> > > >
>> > > > ec 283:37526500:date 2005123121 SOILM kpds5=86 kpds6=112
kpds7=200
>> > > > levels=(0,200) grid=221 0-200 cm down anl: bitmap: 68650
undef
>> > > >
>> > > > SOILM=Soil moisture content [kg/m^2]
>> > > >
>> > > > timerange 0 P1 0 P2 0 TimeU 1 nx 349 ny 277 GDS grid 3
>> num_in_ave 0
>> > > > missing 0
>> > > >
>> > > > center 7 subcenter 15 process 140 Table 131 scan: WE:SN
winds(N/S)
>> > > >
>> > > > Lambert Conf: Lat1 1.000000 Lon1 -145.500000 Lov
-107.000000
>> > > >
>> > > > Latin1 50.000000 Latin2 50.000000 LatSP 0.000000 LonSP
>> 0.000000
>> > > >
>> > > > North Pole (349 x 277) Dx 32.463000 Dy 32.463000 scan
64 mode
>> 0
>> > > >
>> > > > min/max data 57.0137 936.014 num bits 14 BDS_Ref 570.137
>> DecScale
>> > 1
>> > > > BinScale 0
>> > > >
>> > > >
>> > > >
>> > > > Thank you.
>> > > > Regards,
>> > > >
>> > > > Jinwoong
>> > > >
>> > > > On Tue, Aug 8, 2017 at 3:25 PM, Minna Win via RT
<met_help at ucar.edu
>> >
>> > > > wrote:
>> > > >
>> > > > > Hi Jinwoong,
>> > > > >
>> > > > > I had to deal with uncommon levels for a recent project (ie
>> freezing
>> > > > level,
>> > > > > max wind speed, tropopause). MET has support for such
instances
>> in
>> > the
>> > > > > form of:
>> > > > >
>> > > > > $MET_BIN/plot_data_plane \
>> > > > > <grib data file> \
>> > > > > <output ps file >\
>> > > > > 'name="<variable>"; GRIB_lvl_typ=<type>;
GRIB_lvl_val1=<value> \
>> > > > > -v 4
>> > > > >
>> > > > > For my data, I had to look up the values for GRIB_lvl_typ
using
>> the
>> > > > > following GRIB1 and GRIB2 tables:
>> > > > >
>> > > > > GRIB2:
>> > > > > http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table4-
5.shtml
>> > > > >
>> > > > > GRIB1:
>> > > > >
http://www.nco.ncep.noaa.gov/pmb/docs/on388/table3.html#TABLE3A
>> > > > >
>> > > > > You can use wgrib or wgrib2 to see whether your variable of
>> interest
>> > > has
>> > > > > information about the level:
>> > > > > e.g.
>> > > > > For grib2 data
>> > > > > wgrib2 GALWEM_20170602_CY00_FH06.GR2 | grep PRES
>> > > > >
>> > > > > which gives:
>> > > > > 519:658332188:d=2017060200 <%28201%29%20706-0200>:PRES:max
wind:6
>> > hour
>> > > > > fcst:
>> > > > > 559:694572877:d=2017060200 <(201)%20706-0200>
>> <%28201%29%20706-0200>:PRES:surface:6
>> > hour
>> > > > > fcst:
>> > > > > 567:704111051:d=2017060200 <(201)%20706-0200>
>> <%28201%29%20706-0200>:PRES:tropopause:6
>> > > hour
>> > > > > fcst:
>> > > > >
>> > > > > I then used the descriptions of 'max wind' and 'tropopause'
to
>> look
>> > up
>> > > > the
>> > > > > 'code figure' column value in the GRIB2 table 4-5
>> > > > >
>> > > > >
>> > > > > For example, if your data is in GRIB2, set GRIB_lvl_typ to
the
>> 'code
>> > > > > figure' value from table 4.5. Following the example from
above,
>> for
>> > > > > 'tropopause' you would set GRIB_lvl_typ=7 and
GRIB_lvl_val1=0.
>> > > Likewise
>> > > > > for GRIB1 data, except you would refer to ON388 TABLE 3A
and set
>> the
>> > > > > GRIB_lvl_typ to the value under the "Value" column.
>> > > > >
>> > > > > What data are you using, and what variable and level do you
need
>> to
>> > > > > access? Please let us know if you need additional
clarification.
>> > > > >
>> > > > > Regards,
>> > > > > Minna
>> > > > >
>> > > > >
>> > > > >
>> > > > > ---------------
>> > > > > Minna Win
>> > > > > NCAR
>> > > > > Research Applications Lab
>> > > > > Phone: 303-497-8423 <(303)%20497-8423>
>> > > > > Fax: 302-497-8401 <(302)%20497-8401>
>> > > > >
>> > > > >
>> > > > > On Tue, Aug 8, 2017 at 6:36 PM, Jinwoong Yoo via RT <
>> > met_help at ucar.edu
>> > > >
>> > > > > wrote:
>> > > > >
>> > > > > >
>> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>> > > > > >
>> > > > > > Hi Minna,
>> > > > > >
>> > > > > > Thank you very much for your note.
>> > > > > > Then, isn't there any letter specifically designated for
below
>> > ground
>> > > > > > levels?
>> > > > > > Let me try with "Z" (i.g., "Z1", "Z2", "Z3", and "Z4")
first.
>> > > > > > Thank you.
>> > > > > >
>> > > > > > Regards,
>> > > > > >
>> > > > > > Jinwoong
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Tue, Aug 8, 2017 at 2:09 PM, Minna Win via RT <
>> > met_help at ucar.edu>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Hi Jinwoong,
>> > > > > > >
>> > > > > > > This is Minna, another developer on the MET team. I
have
>> > > experienced
>> > > > > the
>> > > > > > > same issue, especially with uncommon data sets. John
showed
>> me
>> > how
>> > > > to
>> > > > > > use
>> > > > > > > MET's plot_data_plane to test whether to use 'Z', 'G',
or 'L':
>> > > > > > > Try running plot_data_plane in the following manner,
but
>> replace
>> > > > > $MET_BIN
>> > > > > > > for the location of your MET binaries, replace
<grib_file> for
>> > the
>> > > > full
>> > > > > > > path to your grib1 or grib2 data file, replace
<output_ps> for
>> > the
>> > > > name
>> > > > > > of
>> > > > > > > the output plot, and replace "TMP" with your variable
of
>> > interest:
>> > > > > > >
>> > > > > > > $MET_BIN/plot_data_plane \
>> > > > > > > <grib file> \
>> > > > > > > <output ps file> \
>> > > > > > > 'name="TMP"; level="Z0";' \
>> > > > > > > -v 4
>> > > > > > >
>> > > > > > > If the correct level descriptor works, then the log
(output to
>> > > > stdout)
>> > > > > > will
>> > > > > > > indicate that a match has been found with the record
number.
>> I
>> > > hope
>> > > > > this
>> > > > > > > helps.
>> > > > > > >
>> > > > > > > Regards,
>> > > > > > > Minna
>> > > > > > >
>> > > > > > > ---------------
>> > > > > > > Minna Win
>> > > > > > > NCAR
>> > > > > > > Research Applications Lab
>> > > > > > > Phone: 303-497-8423
>> > > > > > > Fax: 302-497-8401
>> > > > > > >
>> > > > > > >
>> > > > > > > On Tue, Aug 8, 2017 at 5:59 PM, Jinwoong Yoo via RT <
>> > > > met_help at ucar.edu
>> > > > > >
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > >
>> > > > > > > > <URL: https://rt.rap.ucar.edu/rt/Tic
>> ket/Display.html?id=81063
>> > >
>> > > > > > > >
>> > > > > > > > Hi John,
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > I know surface variables use "Z" and pressure level
>> variables
>> > use
>> > > > > "P".
>> > > > > > > > How can I correctly specify the level for the below
ground
>> > > > variables
>> > > > > > such
>> > > > > > > > as soil moisture?
>> > > > > > > >
>> > > > > > > > Can I use "Z", "G", "L", or something else?
>> > > > > > > > It is hard to find it from the Users' Guide.
>> > > > > > > > I have four layers of soil moisture at the NARR data
set.
>> > > > > > > >
>> > > > > > > > Thank you very much.
>> > > > > > > > Regards,
>> > > > > > > >
>> > > > > > > > Jinwoong
>> > > > > > > >
>> > > > > > > > On Tue, Aug 1, 2017 at 3:26 PM, Jinwoong Yoo <
>> > > > jinwoong.yoo at gmail.com
>> > > > > >
>> > > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > > Hi John,
>> > > > > > > > >
>> > > > > > > > > I see.
>> > > > > > > > > Thank you very much for your thoughts.
>> > > > > > > > > Regards,
>> > > > > > > > >
>> > > > > > > > > Jinwoong
>> > > > > > > > >
>> > > > > > > > > On Tue, Aug 1, 2017 at 3:18 PM, John Halley Gotway
via RT
>> <
>> > > > > > > > > met_help at ucar.edu> wrote:
>> > > > > > > > >
>> > > > > > > > >> Jinwoong,
>> > > > > > > > >>
>> > > > > > > > >> Yes, that is a severe limitation when MET reads
the
>> NetCDF
>> > > > output
>> > > > > > from
>> > > > > > > > >> WRF. It does not read variables defined on the
staggered
>> > > > > > dimensions.
>> > > > > > > > So
>> > > > > > > > >> it only reads variables from mass points, not
velocity
>> > points.
>> > > > > > > > >>
>> > > > > > > > >> We recommend using the Unified Post Processor
(UPP)
>> software
>> > > to
>> > > > > > > > >> postprocess
>> > > > > > > > >> the output of WRF. One of the things it does is
>> interpolate
>> > > > data
>> > > > > > from
>> > > > > > > > the
>> > > > > > > > >> staggered dimensions to a regular grid. It writes
>> output in
>> > > > GRIB1
>> > > > > > or
>> > > > > > > > >> GRIB2
>> > > > > > > > >> format which MET handles nicely.
>> > > > > > > > >>
>> > > > > > > > >> Thanks,
>> > > > > > > > >> John
>> > > > > > > > >>
>> > > > > > > > >> On Fri, Jul 28, 2017 at 12:46 PM, Jinwoong Yoo via
RT <
>> > > > > > > > met_help at ucar.edu>
>> > > > > > > > >> wrote:
>> > > > > > > > >>
>> > > > > > > > >> >
>> > > > > > > > >> > <URL: https://rt.rap.ucar.edu/rt/
>> > > Ticket/Display.html?id=81063
>> > > > >
>> > > > > > > > >> >
>> > > > > > > > >> > Hi John,
>> > > > > > > > >> >
>> > > > > > > > >> > Inserting the "file_type = NETCDF_PINT;" above
the
>> field
>> > > list
>> > > > > line
>> > > > > > > > >> seems to
>> > > > > > > > >> > work.
>> > > > > > > > >> > In this way I was able to process my met_em
files
>> against
>> > > WRF
>> > > > > > grib2
>> > > > > > > > >> files.
>> > > > > > > > >> >
>> > > > > > > > >> > However, only TT and GHT variables were taken by
the
>> > > Gridstat.
>> > > > > > > > >> > It couldn't digest UU and VV variables in the
met_em
>> > files.
>> > > > > > > > >> > Regarding the issue, I got WARNING and ERROR
messages
>> as
>> > > > below:
>> > > > > > > > >> >
>> > > > > > > > >> > WARNING: process_scores() -> UU(0,0,*,*) not
found in
>> > file:
>> > > > > > > > >> >
/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
>> > > > > > > > 1976-01-01_00:00:
>> > > > > > > > >> > 00.nc
>> > > > > > > > >> >
>> > > > > > > > >> > ERROR : PinterpFile::data(NcVar *, const
LongArray &,
>> > > > DataPlane
>> > > > > > &,
>> > > > > > > > >> double
>> > > > > > > > >> > &) const -> can't find needed dimensions(s) for
>> variable
>> > > "UU"
>> > > > > ...
>> > > > > > > one
>> > > > > > > > of
>> > > > > > > > >> > the dimensions may be staggered.
>> > > > > > > > >> > In fact, I confirmed that U-wind and V-wind
variables
>> are
>> > > > > > staggered
>> > > > > > > in
>> > > > > > > > >> the
>> > > > > > > > >> > met_em grid for the WRF processing.
>> > > > > > > > >> > Do you know how I can proceed?
>> > > > > > > > >> > Thank you.
>> > > > > > > > >> > Regards,
>> > > > > > > > >> >
>> > > > > > > > >> > Jinwoong
>> > > > > > > > >> >
>> > > > > > > > >> > On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo <
>> > > > > > > jinwoong.yoo at gmail.com
>> > > > > > > > >
>> > > > > > > > >> > wrote:
>> > > > > > > > >> >
>> > > > > > > > >> > > Hi John,
>> > > > > > > > >> > >
>> > > > > > > > >> > > Thank you very much for your time and your
kindness.
>> > > > > > > > >> > > Let me apply this to my application.
>> > > > > > > > >> > > I will let you know how it goes.
>> > > > > > > > >> > > Thank you.
>> > > > > > > > >> > > Have a nice weekend.
>> > > > > > > > >> > >
>> > > > > > > > >> > > Regards,
>> > > > > > > > >> > >
>> > > > > > > > >> > > Jinwoong
>> > > > > > > > >> > >
>> > > > > > > > >> > > On Fri, Jul 14, 2017 at 5:05 PM, John Halley
Gotway
>> via
>> > > RT <
>> > > > > > > > >> > > met_help at ucar.edu> wrote:
>> > > > > > > > >> > >
>> > > > > > > > >> > >> Jinwoong,
>> > > > > > > > >> > >>
>> > > > > > > > >> > >> I'm sorry this took so long, but the good
news is
>> that
>> > > it's
>> > > > > an
>> > > > > > > easy
>> > > > > > > > >> fix.
>> > > > > > > > >> > >>
>> > > > > > > > >> > >> The "file_type" setting needs to be defined
at one
>> > higher
>> > > > > level
>> > > > > > > of
>> > > > > > > > >> > >> context,
>> > > > > > > > >> > >> like this:
>> > > > > > > > >> > >>
>> > > > > > > > >> > >> fcst = {
>> > > > > > > > >> > >>
>> > > > > > > > >> > >> file_type = NETCDF_PINT;
>> > > > > > > > >> > >>
>> > > > > > > > >> > >> field = [
>> > > > > > > > >> > >> {
>> > > > > > > > >> > >> name = "TT";
>> > > > > > > > >> > >> level = [ "(0,0,*,*)" ];
>> > > > > > > > >> > >> cat_thresh = [];
>> > > > > > > > >> > >> }
>> > > > > > > > >> > >> ];
>> > > > > > > > >> > >>
>> > > > > > > > >> > >> }
>> > > > > > > > >> > >>
>> > > > > > > > >> > >> The "fcst" section defines information about
the
>> input
>> > > > > forecast
>> > > > > > > > file,
>> > > > > > > > >> > and
>> > > > > > > > >> > >> the "obs" section defines information about
the
>> input
>> > > > > > observation
>> > > > > > > > >> file.
>> > > > > > > > >> > >>
>> > > > > > > > >> > >> The "file_type" setting defines how to
interpret
>> these
>> > > > input
>> > > > > > > files.
>> > > > > > > > >> So
>> > > > > > > > >> > >> the
>> > > > > > > > >> > >> code parses it from inside the "fcst" and
"obs"
>> > > > > dictionaries...
>> > > > > > > not
>> > > > > > > > >> > >> separately for each entry in the "field"
array.
>> > > > > > > > >> > >>
>> > > > > > > > >> > >> Here's the note in the file
>> met-6.0/data/config/README
>> > > > about
>> > > > > > > this:
>> > > > > > > > >> > >>
>> > > > > > > > >> > >> // - The "file_type" entry specifies the
input
>> file
>> > > type
>> > > > > > rather
>> > > > > > > > >> than
>> > > > > > > > >> > >> letting
>> > > > > > > > >> > >> // the code determine it itself. For
valid
>> > file_type
>> > > > > > values,
>> > > > > > > > see
>> > > > > > > > >> > >> "File
>> > > > > > > > >> > >> types"
>> > > > > > > > >> > >> // in the data/config/ConfigConstants
file.
>> > > > > > > > >> > >>
>> > > > > > > > >> > >> That obviously doesn't explain it well
enough. For
>> the
>> > > > next
>> > > > > > > > release,
>> > > > > > > > >> > I'll
>> > > > > > > > >> > >> update it to read:
>> > > > > > > > >> > >>
>> > > > > > > > >> > >> // - The "file_type" entry specifies the
input
>> file
>> > > type
>> > > > > > rather
>> > > > > > > > >> than
>> > > > > > > > >> > >> letting
>> > > > > > > > >> > >> // the code determine it itself. For
valid
>> > file_type
>> > > > > > values,
>> > > > > > > > see
>> > > > > > > > >> > >> "File
>> > > > > > > > >> > >> types"
>> > > > > > > > >> > >> // in the data/config/ConfigConstants
file.
>> This
>> > > entry
>> > > > > > > should
>> > > > > > > > be
>> > > > > > > > >> > >> defined within
>> > > > > > > > >> > >> // the "fcst" or "obs" dictionaries.
>> > > > > > > > >> > >> // e.g.
>> > > > > > > > >> > >> // fcst = {
>> > > > > > > > >> > >> // file_type = NETCDF_NCCF;
>> > > > > > > > >> > >> // ...
>> > > > > > > > >> > >> // }
>> > > > > > > > >> > >>
>> > > > > > > > >> > >> Thanks,
>> > > > > > > > >> > >> John
>> > > > > > > > >> > >>
>> > > > > > > > >> > >>
>> > > > > > > > >> > >
>> > > > > > > > >> >
>> > > > > > > > >> >
>> > > > > > > > >>
>> > > > > > > > >>
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Jinwoong Yoo
Time: Tue Aug 08 19:11:43 2017
Hi Minna,
I noticed that GridStat runs well without the SOILM variable field in
the
config file.
However, when I ran GridStat only for the SOILM variable, it generated
the
same error.
ERROR : VarInfo::set_level_info_grib() - either level or
GRIB_lvl_typ,
GRIB_lvl_val1 and GRIB_lvl_val2 (if necessary) must be specified in
field
information
Therefore, it seems that GridStat does not like the field statement,
which
worked with plot_data_plane:
{
name = "SOILM";
GRIB_lvl_typ="112";
GRIB_lvl_val1="0";
GRIB_lvl_val2="200";
cat_thresh = [];
}
Any idea?
On Tue, Aug 8, 2017 at 7:53 PM, Jinwoong Yoo <jinwoong.yoo at gmail.com>
wrote:
> Hi Minna,
>
> I set field in config file as below but I got errors and gridstat
didn't
> produce any output.
>
> {
>
> name = "SHTFL";
>
> level = [ "Z0" ];
>
> cat_thresh = [];
>
> },
>
> {
>
> name = "LHTFL";
>
> level = [ "Z0" ];
>
> cat_thresh = [];
>
> },
>
> {
>
> name = "DSWRF";
>
> level = [ "Z0" ];
>
> cat_thresh = [];
>
> },
>
> {
>
> name = "DLWRF";
>
> level = [ "Z0" ];
>
> cat_thresh = [];
>
> },
>
> {
>
> name = "USWRF";
>
> level = [ "Z0" ];
>
> cat_thresh = [];
>
> },
>
> {
>
> name = "ULWRF";
>
> level = [ "Z0" ];
>
> cat_thresh = [];
>
> },
>
> {
>
> name = "SOILM";
>
> GRIB_lvl_typ="112";
>
> GRIB_lvl_val1="0";
>
> GRIB_lvl_val2="200";
>
> // level = [ "Z0" ];
>
> cat_thresh = [];
>
> }
>
> Error log looks as below.
>
> ERROR : VarInfo::set_level_info_grib() - either level or
GRIB_lvl_typ,
> GRIB_lvl_val1 and GRIB_lvl_val2 (if necessary) must be specified in
field
> information
>
>
> Can't I mix level = [ "Z0" ]; and
GRIB_lvl_* in
> one config file?
> When I tested them separately for plot_data_plane, they both worked.
>
> Thank you.
> Regards,
>
> Jinwoong
>
> On Tue, Aug 8, 2017 at 6:23 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> wrote:
>
>> Hi Minna,
>> Thank you for your clarification.
>> Regards,
>>
>> Jinwoong
>>
>> On Tue, Aug 8, 2017 at 5:46 PM, Minna Win via RT
<met_help at ucar.edu>
>> wrote:
>>
>>> Hi Jinwoon,
>>>
>>> Yes, that is correct. The GRIB_lvl_typ and
GRIB_lvl_val1/GRIB_lvl_val2
>>> are
>>> supported for all the MET applications that need to have a level
>>> specified. My apologies for forgetting to indicate that.
Hopefully, you
>>> can continue to use plot_data_plane to test out your levels and
then use
>>> those values in the grid-stat and other config files. Please let
me know
>>> if that doesn't work for you.
>>>
>>> Regards,
>>> Minna
>>>
>>> ---------------
>>> Minna Win
>>> NCAR
>>> Research Applications Lab
>>> Phone: 303-497-8423
>>> Fax: 302-497-8401
>>>
>>>
>>> On Tue, Aug 8, 2017 at 8:42 PM, Jinwoong Yoo via RT
<met_help at ucar.edu>
>>> wrote:
>>>
>>> >
>>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>>> >
>>> > Hi Minna,
>>> >
>>> > I was able to run the command by setting as
>>> >
>>> > 'name="SOILM";GRIB_lvl_typ=112;
GRIB_lvl_val1=0;GRIB_lvl_val2=200;'
>>> >
>>> > As it is, I had to set both GRIB_lvl_val1=0 and
GRIB_lvl_val2=200 to
>>> > specify the range.
>>> >
>>> > Then, how can I set it in config file for GridStat?
>>> >
>>> > Can I set as below?
>>> >
>>> > {
>>> >
>>> > name = "SOILM";
>>> >
>>> > GRIB_lvl_typ="112";
>>> >
>>> > GRIB_lvl_val1="0";
>>> >
>>> > GRIB_lvl_val2="200";
>>> >
>>> > cat_thresh = [];
>>> >
>>> > }
>>> >
>>> > Thank you.
>>> >
>>> > Regards,
>>> >
>>> >
>>> > Jinwoong
>>> >
>>> >
>>> >
>>> >
>>> > On Tue, Aug 8, 2017 at 3:51 PM, Minna Win via RT
<met_help at ucar.edu>
>>> > wrote:
>>> >
>>> > > Hi Jinwoong,
>>> > >
>>> > > Given your GRIB1 output from wgrib, you might want to try the
>>> following:
>>> > >
>>> > > $MET_BIN/plot_data_plane \
>>> > > <grib data> \
>>> > > <output ps file> \
>>> > > 'name="SOILM"; GRIB_lvl_typ=112; GRIB_lvl_val1=0;' -v 4
>>> > >
>>> > >
>>> > >
>>> > > I forgot to mention that for GRIB1, you can also look at the
wgrib
>>> output
>>> > > and set GRIB_lvl_typ to the kpds6 value, in this case it is
112
>>> (useful
>>> > if
>>> > > there isn't a description for you to look up and match to the
"Value"
>>> > > column in the ON388 table).
>>> > >
>>> > > Regards,
>>> > > Minna
>>> > >
>>> > > ---------------
>>> > > Minna Win
>>> > > NCAR
>>> > > Research Applications Lab
>>> > > Phone: 303-497-8423
>>> > > Fax: 302-497-8401
>>> > >
>>> > >
>>> > > On Tue, Aug 8, 2017 at 7:34 PM, Jinwoong Yoo via RT <
>>> met_help at ucar.edu>
>>> > > wrote:
>>> > >
>>> > > >
>>> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>>> > > >
>>> > > > Hi Minna,
>>> > > >
>>> > > > I am using the NARR grib1 data along with WRF UPP output
grib2
>>> data.
>>> > > > I would like to retrieve SOILM variable for the level of 0-
200 cm
>>> down
>>> > > from
>>> > > > both of the datasets.
>>> > > > Below is the print out of the variable from the NARR data.
>>> > > >
>>> > > > ec 283:37526500:date 2005123121 SOILM kpds5=86 kpds6=112
kpds7=200
>>> > > > levels=(0,200) grid=221 0-200 cm down anl: bitmap: 68650
undef
>>> > > >
>>> > > > SOILM=Soil moisture content [kg/m^2]
>>> > > >
>>> > > > timerange 0 P1 0 P2 0 TimeU 1 nx 349 ny 277 GDS grid 3
>>> num_in_ave 0
>>> > > > missing 0
>>> > > >
>>> > > > center 7 subcenter 15 process 140 Table 131 scan: WE:SN
>>> winds(N/S)
>>> > > >
>>> > > > Lambert Conf: Lat1 1.000000 Lon1 -145.500000 Lov
-107.000000
>>> > > >
>>> > > > Latin1 50.000000 Latin2 50.000000 LatSP 0.000000 LonSP
>>> 0.000000
>>> > > >
>>> > > > North Pole (349 x 277) Dx 32.463000 Dy 32.463000 scan
64
>>> mode 0
>>> > > >
>>> > > > min/max data 57.0137 936.014 num bits 14 BDS_Ref 570.137
>>> DecScale
>>> > 1
>>> > > > BinScale 0
>>> > > >
>>> > > >
>>> > > >
>>> > > > Thank you.
>>> > > > Regards,
>>> > > >
>>> > > > Jinwoong
>>> > > >
>>> > > > On Tue, Aug 8, 2017 at 3:25 PM, Minna Win via RT <
>>> met_help at ucar.edu>
>>> > > > wrote:
>>> > > >
>>> > > > > Hi Jinwoong,
>>> > > > >
>>> > > > > I had to deal with uncommon levels for a recent project
(ie
>>> freezing
>>> > > > level,
>>> > > > > max wind speed, tropopause). MET has support for such
instances
>>> in
>>> > the
>>> > > > > form of:
>>> > > > >
>>> > > > > $MET_BIN/plot_data_plane \
>>> > > > > <grib data file> \
>>> > > > > <output ps file >\
>>> > > > > 'name="<variable>"; GRIB_lvl_typ=<type>;
GRIB_lvl_val1=<value> \
>>> > > > > -v 4
>>> > > > >
>>> > > > > For my data, I had to look up the values for GRIB_lvl_typ
using
>>> the
>>> > > > > following GRIB1 and GRIB2 tables:
>>> > > > >
>>> > > > > GRIB2:
>>> > > > > http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table4-
5.shtml
>>> > > > >
>>> > > > > GRIB1:
>>> > > > >
http://www.nco.ncep.noaa.gov/pmb/docs/on388/table3.html#TABLE3A
>>> > > > >
>>> > > > > You can use wgrib or wgrib2 to see whether your variable
of
>>> interest
>>> > > has
>>> > > > > information about the level:
>>> > > > > e.g.
>>> > > > > For grib2 data
>>> > > > > wgrib2 GALWEM_20170602_CY00_FH06.GR2 | grep PRES
>>> > > > >
>>> > > > > which gives:
>>> > > > > 519:658332188:d=2017060200 <%28201%29%20706-0200>:PRES:max
>>> wind:6
>>> > hour
>>> > > > > fcst:
>>> > > > > 559:694572877:d=2017060200 <(201)%20706-0200>
>>> <%28201%29%20706-0200>:PRES:surface:6
>>> > hour
>>> > > > > fcst:
>>> > > > > 567:704111051:d=2017060200 <(201)%20706-0200>
>>> <%28201%29%20706-0200>:PRES:tropopause:6
>>> > > hour
>>> > > > > fcst:
>>> > > > >
>>> > > > > I then used the descriptions of 'max wind' and
'tropopause' to
>>> look
>>> > up
>>> > > > the
>>> > > > > 'code figure' column value in the GRIB2 table 4-5
>>> > > > >
>>> > > > >
>>> > > > > For example, if your data is in GRIB2, set GRIB_lvl_typ to
the
>>> 'code
>>> > > > > figure' value from table 4.5. Following the example from
above,
>>> for
>>> > > > > 'tropopause' you would set GRIB_lvl_typ=7 and
GRIB_lvl_val1=0.
>>> > > Likewise
>>> > > > > for GRIB1 data, except you would refer to ON388 TABLE 3A
and
>>> set the
>>> > > > > GRIB_lvl_typ to the value under the "Value" column.
>>> > > > >
>>> > > > > What data are you using, and what variable and level do
you need
>>> to
>>> > > > > access? Please let us know if you need additional
clarification.
>>> > > > >
>>> > > > > Regards,
>>> > > > > Minna
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > ---------------
>>> > > > > Minna Win
>>> > > > > NCAR
>>> > > > > Research Applications Lab
>>> > > > > Phone: 303-497-8423 <(303)%20497-8423>
>>> > > > > Fax: 302-497-8401 <(302)%20497-8401>
>>> > > > >
>>> > > > >
>>> > > > > On Tue, Aug 8, 2017 at 6:36 PM, Jinwoong Yoo via RT <
>>> > met_help at ucar.edu
>>> > > >
>>> > > > > wrote:
>>> > > > >
>>> > > > > >
>>> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>>> >
>>> > > > > >
>>> > > > > > Hi Minna,
>>> > > > > >
>>> > > > > > Thank you very much for your note.
>>> > > > > > Then, isn't there any letter specifically designated for
below
>>> > ground
>>> > > > > > levels?
>>> > > > > > Let me try with "Z" (i.g., "Z1", "Z2", "Z3", and "Z4")
first.
>>> > > > > > Thank you.
>>> > > > > >
>>> > > > > > Regards,
>>> > > > > >
>>> > > > > > Jinwoong
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > > On Tue, Aug 8, 2017 at 2:09 PM, Minna Win via RT <
>>> > met_help at ucar.edu>
>>> > > > > > wrote:
>>> > > > > >
>>> > > > > > > Hi Jinwoong,
>>> > > > > > >
>>> > > > > > > This is Minna, another developer on the MET team. I
have
>>> > > experienced
>>> > > > > the
>>> > > > > > > same issue, especially with uncommon data sets. John
showed
>>> me
>>> > how
>>> > > > to
>>> > > > > > use
>>> > > > > > > MET's plot_data_plane to test whether to use 'Z', 'G',
or
>>> 'L':
>>> > > > > > > Try running plot_data_plane in the following manner,
but
>>> replace
>>> > > > > $MET_BIN
>>> > > > > > > for the location of your MET binaries, replace
<grib_file>
>>> for
>>> > the
>>> > > > full
>>> > > > > > > path to your grib1 or grib2 data file, replace
<output_ps>
>>> for
>>> > the
>>> > > > name
>>> > > > > > of
>>> > > > > > > the output plot, and replace "TMP" with your variable
of
>>> > interest:
>>> > > > > > >
>>> > > > > > > $MET_BIN/plot_data_plane \
>>> > > > > > > <grib file> \
>>> > > > > > > <output ps file> \
>>> > > > > > > 'name="TMP"; level="Z0";' \
>>> > > > > > > -v 4
>>> > > > > > >
>>> > > > > > > If the correct level descriptor works, then the log
(output
>>> to
>>> > > > stdout)
>>> > > > > > will
>>> > > > > > > indicate that a match has been found with the record
>>> number. I
>>> > > hope
>>> > > > > this
>>> > > > > > > helps.
>>> > > > > > >
>>> > > > > > > Regards,
>>> > > > > > > Minna
>>> > > > > > >
>>> > > > > > > ---------------
>>> > > > > > > Minna Win
>>> > > > > > > NCAR
>>> > > > > > > Research Applications Lab
>>> > > > > > > Phone: 303-497-8423
>>> > > > > > > Fax: 302-497-8401
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > On Tue, Aug 8, 2017 at 5:59 PM, Jinwoong Yoo via RT <
>>> > > > met_help at ucar.edu
>>> > > > > >
>>> > > > > > > wrote:
>>> > > > > > >
>>> > > > > > > >
>>> > > > > > > > <URL: https://rt.rap.ucar.edu/rt/Tic
>>> ket/Display.html?id=81063
>>> > >
>>> > > > > > > >
>>> > > > > > > > Hi John,
>>> > > > > > > >
>>> > > > > > > >
>>> > > > > > > > I know surface variables use "Z" and pressure level
>>> variables
>>> > use
>>> > > > > "P".
>>> > > > > > > > How can I correctly specify the level for the below
ground
>>> > > > variables
>>> > > > > > such
>>> > > > > > > > as soil moisture?
>>> > > > > > > >
>>> > > > > > > > Can I use "Z", "G", "L", or something else?
>>> > > > > > > > It is hard to find it from the Users' Guide.
>>> > > > > > > > I have four layers of soil moisture at the NARR data
set.
>>> > > > > > > >
>>> > > > > > > > Thank you very much.
>>> > > > > > > > Regards,
>>> > > > > > > >
>>> > > > > > > > Jinwoong
>>> > > > > > > >
>>> > > > > > > > On Tue, Aug 1, 2017 at 3:26 PM, Jinwoong Yoo <
>>> > > > jinwoong.yoo at gmail.com
>>> > > > > >
>>> > > > > > > > wrote:
>>> > > > > > > >
>>> > > > > > > > > Hi John,
>>> > > > > > > > >
>>> > > > > > > > > I see.
>>> > > > > > > > > Thank you very much for your thoughts.
>>> > > > > > > > > Regards,
>>> > > > > > > > >
>>> > > > > > > > > Jinwoong
>>> > > > > > > > >
>>> > > > > > > > > On Tue, Aug 1, 2017 at 3:18 PM, John Halley Gotway
via
>>> RT <
>>> > > > > > > > > met_help at ucar.edu> wrote:
>>> > > > > > > > >
>>> > > > > > > > >> Jinwoong,
>>> > > > > > > > >>
>>> > > > > > > > >> Yes, that is a severe limitation when MET reads
the
>>> NetCDF
>>> > > > output
>>> > > > > > from
>>> > > > > > > > >> WRF. It does not read variables defined on the
>>> staggered
>>> > > > > > dimensions.
>>> > > > > > > > So
>>> > > > > > > > >> it only reads variables from mass points, not
velocity
>>> > points.
>>> > > > > > > > >>
>>> > > > > > > > >> We recommend using the Unified Post Processor
(UPP)
>>> software
>>> > > to
>>> > > > > > > > >> postprocess
>>> > > > > > > > >> the output of WRF. One of the things it does is
>>> interpolate
>>> > > > data
>>> > > > > > from
>>> > > > > > > > the
>>> > > > > > > > >> staggered dimensions to a regular grid. It
writes
>>> output in
>>> > > > GRIB1
>>> > > > > > or
>>> > > > > > > > >> GRIB2
>>> > > > > > > > >> format which MET handles nicely.
>>> > > > > > > > >>
>>> > > > > > > > >> Thanks,
>>> > > > > > > > >> John
>>> > > > > > > > >>
>>> > > > > > > > >> On Fri, Jul 28, 2017 at 12:46 PM, Jinwoong Yoo
via RT <
>>> > > > > > > > met_help at ucar.edu>
>>> > > > > > > > >> wrote:
>>> > > > > > > > >>
>>> > > > > > > > >> >
>>> > > > > > > > >> > <URL: https://rt.rap.ucar.edu/rt/
>>> > > Ticket/Display.html?id=81063
>>> > > > >
>>> > > > > > > > >> >
>>> > > > > > > > >> > Hi John,
>>> > > > > > > > >> >
>>> > > > > > > > >> > Inserting the "file_type = NETCDF_PINT;" above
the
>>> field
>>> > > list
>>> > > > > line
>>> > > > > > > > >> seems to
>>> > > > > > > > >> > work.
>>> > > > > > > > >> > In this way I was able to process my met_em
files
>>> against
>>> > > WRF
>>> > > > > > grib2
>>> > > > > > > > >> files.
>>> > > > > > > > >> >
>>> > > > > > > > >> > However, only TT and GHT variables were taken
by the
>>> > > Gridstat.
>>> > > > > > > > >> > It couldn't digest UU and VV variables in the
met_em
>>> > files.
>>> > > > > > > > >> > Regarding the issue, I got WARNING and ERROR
messages
>>> as
>>> > > > below:
>>> > > > > > > > >> >
>>> > > > > > > > >> > WARNING: process_scores() -> UU(0,0,*,*) not
found in
>>> > file:
>>> > > > > > > > >> >
/scratch/halstead/y/yoo108/NCAR_BC_met_em/met_em.d03.
>>> > > > > > > > 1976-01-01_00:00:
>>> > > > > > > > >> > 00.nc
>>> > > > > > > > >> >
>>> > > > > > > > >> > ERROR : PinterpFile::data(NcVar *, const
LongArray &,
>>> > > > DataPlane
>>> > > > > > &,
>>> > > > > > > > >> double
>>> > > > > > > > >> > &) const -> can't find needed dimensions(s) for
>>> variable
>>> > > "UU"
>>> > > > > ...
>>> > > > > > > one
>>> > > > > > > > of
>>> > > > > > > > >> > the dimensions may be staggered.
>>> > > > > > > > >> > In fact, I confirmed that U-wind and V-wind
variables
>>> are
>>> > > > > > staggered
>>> > > > > > > in
>>> > > > > > > > >> the
>>> > > > > > > > >> > met_em grid for the WRF processing.
>>> > > > > > > > >> > Do you know how I can proceed?
>>> > > > > > > > >> > Thank you.
>>> > > > > > > > >> > Regards,
>>> > > > > > > > >> >
>>> > > > > > > > >> > Jinwoong
>>> > > > > > > > >> >
>>> > > > > > > > >> > On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo <
>>> > > > > > > jinwoong.yoo at gmail.com
>>> > > > > > > > >
>>> > > > > > > > >> > wrote:
>>> > > > > > > > >> >
>>> > > > > > > > >> > > Hi John,
>>> > > > > > > > >> > >
>>> > > > > > > > >> > > Thank you very much for your time and your
kindness.
>>> > > > > > > > >> > > Let me apply this to my application.
>>> > > > > > > > >> > > I will let you know how it goes.
>>> > > > > > > > >> > > Thank you.
>>> > > > > > > > >> > > Have a nice weekend.
>>> > > > > > > > >> > >
>>> > > > > > > > >> > > Regards,
>>> > > > > > > > >> > >
>>> > > > > > > > >> > > Jinwoong
>>> > > > > > > > >> > >
>>> > > > > > > > >> > > On Fri, Jul 14, 2017 at 5:05 PM, John Halley
Gotway
>>> via
>>> > > RT <
>>> > > > > > > > >> > > met_help at ucar.edu> wrote:
>>> > > > > > > > >> > >
>>> > > > > > > > >> > >> Jinwoong,
>>> > > > > > > > >> > >>
>>> > > > > > > > >> > >> I'm sorry this took so long, but the good
news is
>>> that
>>> > > it's
>>> > > > > an
>>> > > > > > > easy
>>> > > > > > > > >> fix.
>>> > > > > > > > >> > >>
>>> > > > > > > > >> > >> The "file_type" setting needs to be defined
at one
>>> > higher
>>> > > > > level
>>> > > > > > > of
>>> > > > > > > > >> > >> context,
>>> > > > > > > > >> > >> like this:
>>> > > > > > > > >> > >>
>>> > > > > > > > >> > >> fcst = {
>>> > > > > > > > >> > >>
>>> > > > > > > > >> > >> file_type = NETCDF_PINT;
>>> > > > > > > > >> > >>
>>> > > > > > > > >> > >> field = [
>>> > > > > > > > >> > >> {
>>> > > > > > > > >> > >> name = "TT";
>>> > > > > > > > >> > >> level = [ "(0,0,*,*)" ];
>>> > > > > > > > >> > >> cat_thresh = [];
>>> > > > > > > > >> > >> }
>>> > > > > > > > >> > >> ];
>>> > > > > > > > >> > >>
>>> > > > > > > > >> > >> }
>>> > > > > > > > >> > >>
>>> > > > > > > > >> > >> The "fcst" section defines information about
the
>>> input
>>> > > > > forecast
>>> > > > > > > > file,
>>> > > > > > > > >> > and
>>> > > > > > > > >> > >> the "obs" section defines information about
the
>>> input
>>> > > > > > observation
>>> > > > > > > > >> file.
>>> > > > > > > > >> > >>
>>> > > > > > > > >> > >> The "file_type" setting defines how to
interpret
>>> these
>>> > > > input
>>> > > > > > > files.
>>> > > > > > > > >> So
>>> > > > > > > > >> > >> the
>>> > > > > > > > >> > >> code parses it from inside the "fcst" and
"obs"
>>> > > > > dictionaries...
>>> > > > > > > not
>>> > > > > > > > >> > >> separately for each entry in the "field"
array.
>>> > > > > > > > >> > >>
>>> > > > > > > > >> > >> Here's the note in the file
>>> met-6.0/data/config/README
>>> > > > about
>>> > > > > > > this:
>>> > > > > > > > >> > >>
>>> > > > > > > > >> > >> // - The "file_type" entry specifies the
input
>>> file
>>> > > type
>>> > > > > > rather
>>> > > > > > > > >> than
>>> > > > > > > > >> > >> letting
>>> > > > > > > > >> > >> // the code determine it itself. For
valid
>>> > file_type
>>> > > > > > values,
>>> > > > > > > > see
>>> > > > > > > > >> > >> "File
>>> > > > > > > > >> > >> types"
>>> > > > > > > > >> > >> // in the data/config/ConfigConstants
file.
>>> > > > > > > > >> > >>
>>> > > > > > > > >> > >> That obviously doesn't explain it well
enough.
>>> For the
>>> > > > next
>>> > > > > > > > release,
>>> > > > > > > > >> > I'll
>>> > > > > > > > >> > >> update it to read:
>>> > > > > > > > >> > >>
>>> > > > > > > > >> > >> // - The "file_type" entry specifies the
input
>>> file
>>> > > type
>>> > > > > > rather
>>> > > > > > > > >> than
>>> > > > > > > > >> > >> letting
>>> > > > > > > > >> > >> // the code determine it itself. For
valid
>>> > file_type
>>> > > > > > values,
>>> > > > > > > > see
>>> > > > > > > > >> > >> "File
>>> > > > > > > > >> > >> types"
>>> > > > > > > > >> > >> // in the data/config/ConfigConstants
file.
>>> This
>>> > > entry
>>> > > > > > > should
>>> > > > > > > > be
>>> > > > > > > > >> > >> defined within
>>> > > > > > > > >> > >> // the "fcst" or "obs" dictionaries.
>>> > > > > > > > >> > >> // e.g.
>>> > > > > > > > >> > >> // fcst = {
>>> > > > > > > > >> > >> // file_type = NETCDF_NCCF;
>>> > > > > > > > >> > >> // ...
>>> > > > > > > > >> > >> // }
>>> > > > > > > > >> > >>
>>> > > > > > > > >> > >> Thanks,
>>> > > > > > > > >> > >> John
>>> > > > > > > > >> > >>
>>> > > > > > > > >> > >>
>>> > > > > > > > >> > >
>>> > > > > > > > >> >
>>> > > > > > > > >> >
>>> > > > > > > > >>
>>> > > > > > > > >>
>>> > > > > > > > >
>>> > > > > > > >
>>> > > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>>
>>>
>>
>
------------------------------------------------
Subject: regrid_data_plane: not a valid data file
From: Minna Win
Time: Wed Aug 09 11:31:05 2017
Hi Jinwoong,
Please try the following:
{
name = "SOILM";
GRIB_lvl_typ = 112;
GRIB_lvl_val1 =0;
GRIB_lvl_val2 = 200;
}
Notice that there are no quotation marks for the values GRIB_lvl_typ,
GRIB_lvl_val1, and GRIB_lvl_val2 and remove the level=["Z0"] for
SOILM.
Hopefully that will work.
Regards,
Minna
---------------
Minna Win
NCAR
Research Applications Lab
Phone: 303-497-8423
Fax: 302-497-8401
On Wed, Aug 9, 2017 at 1:11 AM, Jinwoong Yoo via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
>
> Hi Minna,
>
> I noticed that GridStat runs well without the SOILM variable field
in the
> config file.
> However, when I ran GridStat only for the SOILM variable, it
generated the
> same error.
>
> ERROR : VarInfo::set_level_info_grib() - either level or
GRIB_lvl_typ,
> GRIB_lvl_val1 and GRIB_lvl_val2 (if necessary) must be specified in
field
> information
> Therefore, it seems that GridStat does not like the field statement,
which
> worked with plot_data_plane:
>
> {
>
> name = "SOILM";
>
> GRIB_lvl_typ="112";
>
> GRIB_lvl_val1="0";
>
> GRIB_lvl_val2="200";
>
> cat_thresh = [];
>
> }
>
>
> Any idea?
>
> On Tue, Aug 8, 2017 at 7:53 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> wrote:
>
> > Hi Minna,
> >
> > I set field in config file as below but I got errors and gridstat
didn't
> > produce any output.
> >
> > {
> >
> > name = "SHTFL";
> >
> > level = [ "Z0" ];
> >
> > cat_thresh = [];
> >
> > },
> >
> > {
> >
> > name = "LHTFL";
> >
> > level = [ "Z0" ];
> >
> > cat_thresh = [];
> >
> > },
> >
> > {
> >
> > name = "DSWRF";
> >
> > level = [ "Z0" ];
> >
> > cat_thresh = [];
> >
> > },
> >
> > {
> >
> > name = "DLWRF";
> >
> > level = [ "Z0" ];
> >
> > cat_thresh = [];
> >
> > },
> >
> > {
> >
> > name = "USWRF";
> >
> > level = [ "Z0" ];
> >
> > cat_thresh = [];
> >
> > },
> >
> > {
> >
> > name = "ULWRF";
> >
> > level = [ "Z0" ];
> >
> > cat_thresh = [];
> >
> > },
> >
> > {
> >
> > name = "SOILM";
> >
> > GRIB_lvl_typ="112";
> >
> > GRIB_lvl_val1="0";
> >
> > GRIB_lvl_val2="200";
> >
> > // level = [ "Z0" ];
> >
> > cat_thresh = [];
> >
> > }
> >
> > Error log looks as below.
> >
> > ERROR : VarInfo::set_level_info_grib() - either level or
GRIB_lvl_typ,
> > GRIB_lvl_val1 and GRIB_lvl_val2 (if necessary) must be specified
in field
> > information
> >
> >
> > Can't I mix level = [ "Z0" ]; and
GRIB_lvl_* in
> > one config file?
> > When I tested them separately for plot_data_plane, they both
worked.
> >
> > Thank you.
> > Regards,
> >
> > Jinwoong
> >
> > On Tue, Aug 8, 2017 at 6:23 PM, Jinwoong Yoo
<jinwoong.yoo at gmail.com>
> > wrote:
> >
> >> Hi Minna,
> >> Thank you for your clarification.
> >> Regards,
> >>
> >> Jinwoong
> >>
> >> On Tue, Aug 8, 2017 at 5:46 PM, Minna Win via RT
<met_help at ucar.edu>
> >> wrote:
> >>
> >>> Hi Jinwoon,
> >>>
> >>> Yes, that is correct. The GRIB_lvl_typ and
GRIB_lvl_val1/GRIB_lvl_val2
> >>> are
> >>> supported for all the MET applications that need to have a level
> >>> specified. My apologies for forgetting to indicate that.
Hopefully,
> you
> >>> can continue to use plot_data_plane to test out your levels and
then
> use
> >>> those values in the grid-stat and other config files. Please
let me
> know
> >>> if that doesn't work for you.
> >>>
> >>> Regards,
> >>> Minna
> >>>
> >>> ---------------
> >>> Minna Win
> >>> NCAR
> >>> Research Applications Lab
> >>> Phone: 303-497-8423
> >>> Fax: 302-497-8401
> >>>
> >>>
> >>> On Tue, Aug 8, 2017 at 8:42 PM, Jinwoong Yoo via RT
<met_help at ucar.edu
> >
> >>> wrote:
> >>>
> >>> >
> >>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063
>
> >>> >
> >>> > Hi Minna,
> >>> >
> >>> > I was able to run the command by setting as
> >>> >
> >>> > 'name="SOILM";GRIB_lvl_typ=112;
GRIB_lvl_val1=0;GRIB_lvl_val2=200;'
> >>> >
> >>> > As it is, I had to set both GRIB_lvl_val1=0 and
GRIB_lvl_val2=200 to
> >>> > specify the range.
> >>> >
> >>> > Then, how can I set it in config file for GridStat?
> >>> >
> >>> > Can I set as below?
> >>> >
> >>> > {
> >>> >
> >>> > name = "SOILM";
> >>> >
> >>> > GRIB_lvl_typ="112";
> >>> >
> >>> > GRIB_lvl_val1="0";
> >>> >
> >>> > GRIB_lvl_val2="200";
> >>> >
> >>> > cat_thresh = [];
> >>> >
> >>> > }
> >>> >
> >>> > Thank you.
> >>> >
> >>> > Regards,
> >>> >
> >>> >
> >>> > Jinwoong
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On Tue, Aug 8, 2017 at 3:51 PM, Minna Win via RT
<met_help at ucar.edu>
> >>> > wrote:
> >>> >
> >>> > > Hi Jinwoong,
> >>> > >
> >>> > > Given your GRIB1 output from wgrib, you might want to try
the
> >>> following:
> >>> > >
> >>> > > $MET_BIN/plot_data_plane \
> >>> > > <grib data> \
> >>> > > <output ps file> \
> >>> > > 'name="SOILM"; GRIB_lvl_typ=112; GRIB_lvl_val1=0;' -v 4
> >>> > >
> >>> > >
> >>> > >
> >>> > > I forgot to mention that for GRIB1, you can also look at the
wgrib
> >>> output
> >>> > > and set GRIB_lvl_typ to the kpds6 value, in this case it is
112
> >>> (useful
> >>> > if
> >>> > > there isn't a description for you to look up and match to
the
> "Value"
> >>> > > column in the ON388 table).
> >>> > >
> >>> > > Regards,
> >>> > > Minna
> >>> > >
> >>> > > ---------------
> >>> > > Minna Win
> >>> > > NCAR
> >>> > > Research Applications Lab
> >>> > > Phone: 303-497-8423
> >>> > > Fax: 302-497-8401
> >>> > >
> >>> > >
> >>> > > On Tue, Aug 8, 2017 at 7:34 PM, Jinwoong Yoo via RT <
> >>> met_help at ucar.edu>
> >>> > > wrote:
> >>> > >
> >>> > > >
> >>> > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=81063 >
> >>> > > >
> >>> > > > Hi Minna,
> >>> > > >
> >>> > > > I am using the NARR grib1 data along with WRF UPP output
grib2
> >>> data.
> >>> > > > I would like to retrieve SOILM variable for the level of
0-200 cm
> >>> down
> >>> > > from
> >>> > > > both of the datasets.
> >>> > > > Below is the print out of the variable from the NARR data.
> >>> > > >
> >>> > > > ec 283:37526500:date 2005123121 SOILM kpds5=86 kpds6=112
> kpds7=200
> >>> > > > levels=(0,200) grid=221 0-200 cm down anl: bitmap: 68650
undef
> >>> > > >
> >>> > > > SOILM=Soil moisture content [kg/m^2]
> >>> > > >
> >>> > > > timerange 0 P1 0 P2 0 TimeU 1 nx 349 ny 277 GDS grid 3
> >>> num_in_ave 0
> >>> > > > missing 0
> >>> > > >
> >>> > > > center 7 subcenter 15 process 140 Table 131 scan: WE:SN
> >>> winds(N/S)
> >>> > > >
> >>> > > > Lambert Conf: Lat1 1.000000 Lon1 -145.500000 Lov
-107.000000
> >>> > > >
> >>> > > > Latin1 50.000000 Latin2 50.000000 LatSP 0.000000
LonSP
> >>> 0.000000
> >>> > > >
> >>> > > > North Pole (349 x 277) Dx 32.463000 Dy 32.463000
scan 64
> >>> mode 0
> >>> > > >
> >>> > > > min/max data 57.0137 936.014 num bits 14 BDS_Ref
570.137
> >>> DecScale
> >>> > 1
> >>> > > > BinScale 0
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > Thank you.
> >>> > > > Regards,
> >>> > > >
> >>> > > > Jinwoong
> >>> > > >
> >>> > > > On Tue, Aug 8, 2017 at 3:25 PM, Minna Win via RT <
> >>> met_help at ucar.edu>
> >>> > > > wrote:
> >>> > > >
> >>> > > > > Hi Jinwoong,
> >>> > > > >
> >>> > > > > I had to deal with uncommon levels for a recent project
(ie
> >>> freezing
> >>> > > > level,
> >>> > > > > max wind speed, tropopause). MET has support for such
> instances
> >>> in
> >>> > the
> >>> > > > > form of:
> >>> > > > >
> >>> > > > > $MET_BIN/plot_data_plane \
> >>> > > > > <grib data file> \
> >>> > > > > <output ps file >\
> >>> > > > > 'name="<variable>"; GRIB_lvl_typ=<type>;
GRIB_lvl_val1=<value>
> \
> >>> > > > > -v 4
> >>> > > > >
> >>> > > > > For my data, I had to look up the values for
GRIB_lvl_typ using
> >>> the
> >>> > > > > following GRIB1 and GRIB2 tables:
> >>> > > > >
> >>> > > > > GRIB2:
> >>> > > > >
http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table4-5.
> shtml
> >>> > > > >
> >>> > > > > GRIB1:
> >>> > > > > http://www.nco.ncep.noaa.gov/pmb/docs/on388/table3.html#
> TABLE3A
> >>> > > > >
> >>> > > > > You can use wgrib or wgrib2 to see whether your variable
of
> >>> interest
> >>> > > has
> >>> > > > > information about the level:
> >>> > > > > e.g.
> >>> > > > > For grib2 data
> >>> > > > > wgrib2 GALWEM_20170602_CY00_FH06.GR2 | grep PRES
> >>> > > > >
> >>> > > > > which gives:
> >>> > > > > 519:658332188:d=2017060200 <%28201%29%20706-
0200>:PRES:max
> >>> wind:6
> >>> > hour
> >>> > > > > fcst:
> >>> > > > > 559:694572877:d=2017060200 <(201)%20706-0200>
> >>> <%28201%29%20706-0200>:PRES:surface:6
> >>> > hour
> >>> > > > > fcst:
> >>> > > > > 567:704111051:d=2017060200 <(201)%20706-0200>
> >>> <%28201%29%20706-0200>:PRES:tropopause:6
> >>> > > hour
> >>> > > > > fcst:
> >>> > > > >
> >>> > > > > I then used the descriptions of 'max wind' and
'tropopause' to
> >>> look
> >>> > up
> >>> > > > the
> >>> > > > > 'code figure' column value in the GRIB2 table 4-5
> >>> > > > >
> >>> > > > >
> >>> > > > > For example, if your data is in GRIB2, set GRIB_lvl_typ
to the
> >>> 'code
> >>> > > > > figure' value from table 4.5. Following the example
from
> above,
> >>> for
> >>> > > > > 'tropopause' you would set GRIB_lvl_typ=7 and
GRIB_lvl_val1=0.
> >>> > > Likewise
> >>> > > > > for GRIB1 data, except you would refer to ON388 TABLE
3A and
> >>> set the
> >>> > > > > GRIB_lvl_typ to the value under the "Value" column.
> >>> > > > >
> >>> > > > > What data are you using, and what variable and level do
you
> need
> >>> to
> >>> > > > > access? Please let us know if you need additional
> clarification.
> >>> > > > >
> >>> > > > > Regards,
> >>> > > > > Minna
> >>> > > > >
> >>> > > > >
> >>> > > > >
> >>> > > > > ---------------
> >>> > > > > Minna Win
> >>> > > > > NCAR
> >>> > > > > Research Applications Lab
> >>> > > > > Phone: 303-497-8423 <(303)%20497-8423>
> >>> > > > > Fax: 302-497-8401 <(302)%20497-8401>
> >>> > > > >
> >>> > > > >
> >>> > > > > On Tue, Aug 8, 2017 at 6:36 PM, Jinwoong Yoo via RT <
> >>> > met_help at ucar.edu
> >>> > > >
> >>> > > > > wrote:
> >>> > > > >
> >>> > > > > >
> >>> > > > > > <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=81063
> >>> >
> >>> > > > > >
> >>> > > > > > Hi Minna,
> >>> > > > > >
> >>> > > > > > Thank you very much for your note.
> >>> > > > > > Then, isn't there any letter specifically designated
for
> below
> >>> > ground
> >>> > > > > > levels?
> >>> > > > > > Let me try with "Z" (i.g., "Z1", "Z2", "Z3", and
"Z4")
> first.
> >>> > > > > > Thank you.
> >>> > > > > >
> >>> > > > > > Regards,
> >>> > > > > >
> >>> > > > > > Jinwoong
> >>> > > > > >
> >>> > > > > >
> >>> > > > > >
> >>> > > > > > On Tue, Aug 8, 2017 at 2:09 PM, Minna Win via RT <
> >>> > met_help at ucar.edu>
> >>> > > > > > wrote:
> >>> > > > > >
> >>> > > > > > > Hi Jinwoong,
> >>> > > > > > >
> >>> > > > > > > This is Minna, another developer on the MET team. I
have
> >>> > > experienced
> >>> > > > > the
> >>> > > > > > > same issue, especially with uncommon data sets.
John
> showed
> >>> me
> >>> > how
> >>> > > > to
> >>> > > > > > use
> >>> > > > > > > MET's plot_data_plane to test whether to use 'Z',
'G', or
> >>> 'L':
> >>> > > > > > > Try running plot_data_plane in the following manner,
but
> >>> replace
> >>> > > > > $MET_BIN
> >>> > > > > > > for the location of your MET binaries, replace
<grib_file>
> >>> for
> >>> > the
> >>> > > > full
> >>> > > > > > > path to your grib1 or grib2 data file, replace
<output_ps>
> >>> for
> >>> > the
> >>> > > > name
> >>> > > > > > of
> >>> > > > > > > the output plot, and replace "TMP" with your
variable of
> >>> > interest:
> >>> > > > > > >
> >>> > > > > > > $MET_BIN/plot_data_plane \
> >>> > > > > > > <grib file> \
> >>> > > > > > > <output ps file> \
> >>> > > > > > > 'name="TMP"; level="Z0";' \
> >>> > > > > > > -v 4
> >>> > > > > > >
> >>> > > > > > > If the correct level descriptor works, then the log
(output
> >>> to
> >>> > > > stdout)
> >>> > > > > > will
> >>> > > > > > > indicate that a match has been found with the record
> >>> number. I
> >>> > > hope
> >>> > > > > this
> >>> > > > > > > helps.
> >>> > > > > > >
> >>> > > > > > > Regards,
> >>> > > > > > > Minna
> >>> > > > > > >
> >>> > > > > > > ---------------
> >>> > > > > > > Minna Win
> >>> > > > > > > NCAR
> >>> > > > > > > Research Applications Lab
> >>> > > > > > > Phone: 303-497-8423
> >>> > > > > > > Fax: 302-497-8401
> >>> > > > > > >
> >>> > > > > > >
> >>> > > > > > > On Tue, Aug 8, 2017 at 5:59 PM, Jinwoong Yoo via RT
<
> >>> > > > met_help at ucar.edu
> >>> > > > > >
> >>> > > > > > > wrote:
> >>> > > > > > >
> >>> > > > > > > >
> >>> > > > > > > > <URL: https://rt.rap.ucar.edu/rt/Tic
> >>> ket/Display.html?id=81063
> >>> > >
> >>> > > > > > > >
> >>> > > > > > > > Hi John,
> >>> > > > > > > >
> >>> > > > > > > >
> >>> > > > > > > > I know surface variables use "Z" and pressure
level
> >>> variables
> >>> > use
> >>> > > > > "P".
> >>> > > > > > > > How can I correctly specify the level for the
below
> ground
> >>> > > > variables
> >>> > > > > > such
> >>> > > > > > > > as soil moisture?
> >>> > > > > > > >
> >>> > > > > > > > Can I use "Z", "G", "L", or something else?
> >>> > > > > > > > It is hard to find it from the Users' Guide.
> >>> > > > > > > > I have four layers of soil moisture at the NARR
data set.
> >>> > > > > > > >
> >>> > > > > > > > Thank you very much.
> >>> > > > > > > > Regards,
> >>> > > > > > > >
> >>> > > > > > > > Jinwoong
> >>> > > > > > > >
> >>> > > > > > > > On Tue, Aug 1, 2017 at 3:26 PM, Jinwoong Yoo <
> >>> > > > jinwoong.yoo at gmail.com
> >>> > > > > >
> >>> > > > > > > > wrote:
> >>> > > > > > > >
> >>> > > > > > > > > Hi John,
> >>> > > > > > > > >
> >>> > > > > > > > > I see.
> >>> > > > > > > > > Thank you very much for your thoughts.
> >>> > > > > > > > > Regards,
> >>> > > > > > > > >
> >>> > > > > > > > > Jinwoong
> >>> > > > > > > > >
> >>> > > > > > > > > On Tue, Aug 1, 2017 at 3:18 PM, John Halley
Gotway via
> >>> RT <
> >>> > > > > > > > > met_help at ucar.edu> wrote:
> >>> > > > > > > > >
> >>> > > > > > > > >> Jinwoong,
> >>> > > > > > > > >>
> >>> > > > > > > > >> Yes, that is a severe limitation when MET reads
the
> >>> NetCDF
> >>> > > > output
> >>> > > > > > from
> >>> > > > > > > > >> WRF. It does not read variables defined on the
> >>> staggered
> >>> > > > > > dimensions.
> >>> > > > > > > > So
> >>> > > > > > > > >> it only reads variables from mass points, not
velocity
> >>> > points.
> >>> > > > > > > > >>
> >>> > > > > > > > >> We recommend using the Unified Post Processor
(UPP)
> >>> software
> >>> > > to
> >>> > > > > > > > >> postprocess
> >>> > > > > > > > >> the output of WRF. One of the things it does
is
> >>> interpolate
> >>> > > > data
> >>> > > > > > from
> >>> > > > > > > > the
> >>> > > > > > > > >> staggered dimensions to a regular grid. It
writes
> >>> output in
> >>> > > > GRIB1
> >>> > > > > > or
> >>> > > > > > > > >> GRIB2
> >>> > > > > > > > >> format which MET handles nicely.
> >>> > > > > > > > >>
> >>> > > > > > > > >> Thanks,
> >>> > > > > > > > >> John
> >>> > > > > > > > >>
> >>> > > > > > > > >> On Fri, Jul 28, 2017 at 12:46 PM, Jinwoong Yoo
via RT
> <
> >>> > > > > > > > met_help at ucar.edu>
> >>> > > > > > > > >> wrote:
> >>> > > > > > > > >>
> >>> > > > > > > > >> >
> >>> > > > > > > > >> > <URL: https://rt.rap.ucar.edu/rt/
> >>> > > Ticket/Display.html?id=81063
> >>> > > > >
> >>> > > > > > > > >> >
> >>> > > > > > > > >> > Hi John,
> >>> > > > > > > > >> >
> >>> > > > > > > > >> > Inserting the "file_type = NETCDF_PINT;"
above the
> >>> field
> >>> > > list
> >>> > > > > line
> >>> > > > > > > > >> seems to
> >>> > > > > > > > >> > work.
> >>> > > > > > > > >> > In this way I was able to process my met_em
files
> >>> against
> >>> > > WRF
> >>> > > > > > grib2
> >>> > > > > > > > >> files.
> >>> > > > > > > > >> >
> >>> > > > > > > > >> > However, only TT and GHT variables were taken
by the
> >>> > > Gridstat.
> >>> > > > > > > > >> > It couldn't digest UU and VV variables in the
met_em
> >>> > files.
> >>> > > > > > > > >> > Regarding the issue, I got WARNING and ERROR
> messages
> >>> as
> >>> > > > below:
> >>> > > > > > > > >> >
> >>> > > > > > > > >> > WARNING: process_scores() -> UU(0,0,*,*) not
found
> in
> >>> > file:
> >>> > > > > > > > >> > /scratch/halstead/y/yoo108/
> NCAR_BC_met_em/met_em.d03.
> >>> > > > > > > > 1976-01-01_00:00:
> >>> > > > > > > > >> > 00.nc
> >>> > > > > > > > >> >
> >>> > > > > > > > >> > ERROR : PinterpFile::data(NcVar *, const
LongArray
> &,
> >>> > > > DataPlane
> >>> > > > > > &,
> >>> > > > > > > > >> double
> >>> > > > > > > > >> > &) const -> can't find needed dimensions(s)
for
> >>> variable
> >>> > > "UU"
> >>> > > > > ...
> >>> > > > > > > one
> >>> > > > > > > > of
> >>> > > > > > > > >> > the dimensions may be staggered.
> >>> > > > > > > > >> > In fact, I confirmed that U-wind and V-wind
> variables
> >>> are
> >>> > > > > > staggered
> >>> > > > > > > in
> >>> > > > > > > > >> the
> >>> > > > > > > > >> > met_em grid for the WRF processing.
> >>> > > > > > > > >> > Do you know how I can proceed?
> >>> > > > > > > > >> > Thank you.
> >>> > > > > > > > >> > Regards,
> >>> > > > > > > > >> >
> >>> > > > > > > > >> > Jinwoong
> >>> > > > > > > > >> >
> >>> > > > > > > > >> > On Fri, Jul 14, 2017 at 5:15 PM, Jinwoong Yoo
<
> >>> > > > > > > jinwoong.yoo at gmail.com
> >>> > > > > > > > >
> >>> > > > > > > > >> > wrote:
> >>> > > > > > > > >> >
> >>> > > > > > > > >> > > Hi John,
> >>> > > > > > > > >> > >
> >>> > > > > > > > >> > > Thank you very much for your time and your
> kindness.
> >>> > > > > > > > >> > > Let me apply this to my application.
> >>> > > > > > > > >> > > I will let you know how it goes.
> >>> > > > > > > > >> > > Thank you.
> >>> > > > > > > > >> > > Have a nice weekend.
> >>> > > > > > > > >> > >
> >>> > > > > > > > >> > > Regards,
> >>> > > > > > > > >> > >
> >>> > > > > > > > >> > > Jinwoong
> >>> > > > > > > > >> > >
> >>> > > > > > > > >> > > On Fri, Jul 14, 2017 at 5:05 PM, John
Halley
> Gotway
> >>> via
> >>> > > RT <
> >>> > > > > > > > >> > > met_help at ucar.edu> wrote:
> >>> > > > > > > > >> > >
> >>> > > > > > > > >> > >> Jinwoong,
> >>> > > > > > > > >> > >>
> >>> > > > > > > > >> > >> I'm sorry this took so long, but the good
news is
> >>> that
> >>> > > it's
> >>> > > > > an
> >>> > > > > > > easy
> >>> > > > > > > > >> fix.
> >>> > > > > > > > >> > >>
> >>> > > > > > > > >> > >> The "file_type" setting needs to be
defined at
> one
> >>> > higher
> >>> > > > > level
> >>> > > > > > > of
> >>> > > > > > > > >> > >> context,
> >>> > > > > > > > >> > >> like this:
> >>> > > > > > > > >> > >>
> >>> > > > > > > > >> > >> fcst = {
> >>> > > > > > > > >> > >>
> >>> > > > > > > > >> > >> file_type = NETCDF_PINT;
> >>> > > > > > > > >> > >>
> >>> > > > > > > > >> > >> field = [
> >>> > > > > > > > >> > >> {
> >>> > > > > > > > >> > >> name = "TT";
> >>> > > > > > > > >> > >> level = [ "(0,0,*,*)" ];
> >>> > > > > > > > >> > >> cat_thresh = [];
> >>> > > > > > > > >> > >> }
> >>> > > > > > > > >> > >> ];
> >>> > > > > > > > >> > >>
> >>> > > > > > > > >> > >> }
> >>> > > > > > > > >> > >>
> >>> > > > > > > > >> > >> The "fcst" section defines information
about the
> >>> input
> >>> > > > > forecast
> >>> > > > > > > > file,
> >>> > > > > > > > >> > and
> >>> > > > > > > > >> > >> the "obs" section defines information
about the
> >>> input
> >>> > > > > > observation
> >>> > > > > > > > >> file.
> >>> > > > > > > > >> > >>
> >>> > > > > > > > >> > >> The "file_type" setting defines how to
interpret
> >>> these
> >>> > > > input
> >>> > > > > > > files.
> >>> > > > > > > > >> So
> >>> > > > > > > > >> > >> the
> >>> > > > > > > > >> > >> code parses it from inside the "fcst" and
"obs"
> >>> > > > > dictionaries...
> >>> > > > > > > not
> >>> > > > > > > > >> > >> separately for each entry in the "field"
array.
> >>> > > > > > > > >> > >>
> >>> > > > > > > > >> > >> Here's the note in the file
> >>> met-6.0/data/config/README
> >>> > > > about
> >>> > > > > > > this:
> >>> > > > > > > > >> > >>
> >>> > > > > > > > >> > >> // - The "file_type" entry specifies the
input
> >>> file
> >>> > > type
> >>> > > > > > rather
> >>> > > > > > > > >> than
> >>> > > > > > > > >> > >> letting
> >>> > > > > > > > >> > >> // the code determine it itself. For
valid
> >>> > file_type
> >>> > > > > > values,
> >>> > > > > > > > see
> >>> > > > > > > > >> > >> "File
> >>> > > > > > > > >> > >> types"
> >>> > > > > > > > >> > >> // in the data/config/ConfigConstants
file.
> >>> > > > > > > > >> > >>
> >>> > > > > > > > >> > >> That obviously doesn't explain it well
enough.
> >>> For the
> >>> > > > next
> >>> > > > > > > > release,
> >>> > > > > > > > >> > I'll
> >>> > > > > > > > >> > >> update it to read:
> >>> > > > > > > > >> > >>
> >>> > > > > > > > >> > >> // - The "file_type" entry specifies the
input
> >>> file
> >>> > > type
> >>> > > > > > rather
> >>> > > > > > > > >> than
> >>> > > > > > > > >> > >> letting
> >>> > > > > > > > >> > >> // the code determine it itself. For
valid
> >>> > file_type
> >>> > > > > > values,
> >>> > > > > > > > see
> >>> > > > > > > > >> > >> "File
> >>> > > > > > > > >> > >> types"
> >>> > > > > > > > >> > >> // in the data/config/ConfigConstants
file.
> >>> This
> >>> > > entry
> >>> > > > > > > should
> >>> > > > > > > > be
> >>> > > > > > > > >> > >> defined within
> >>> > > > > > > > >> > >> // the "fcst" or "obs" dictionaries.
> >>> > > > > > > > >> > >> // e.g.
> >>> > > > > > > > >> > >> // fcst = {
> >>> > > > > > > > >> > >> // file_type = NETCDF_NCCF;
> >>> > > > > > > > >> > >> // ...
> >>> > > > > > > > >> > >> // }
> >>> > > > > > > > >> > >>
> >>> > > > > > > > >> > >> Thanks,
> >>> > > > > > > > >> > >> John
> >>> > > > > > > > >> > >>
> >>> > > > > > > > >> > >>
> >>> > > > > > > > >> > >
> >>> > > > > > > > >> >
> >>> > > > > > > > >> >
> >>> > > > > > > > >>
> >>> > > > > > > > >>
> >>> > > > > > > > >
> >>> > > > > > > >
> >>> > > > > > > >
> >>> > > > > > >
> >>> > > > > > >
> >>> > > > > >
> >>> > > > > >
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
> >>>
> >>
> >
>
>
------------------------------------------------
More information about the Met_help
mailing list