[Met_help] [rt.rap.ucar.edu #89088] History for CF compliance specifying time data type
Howard Soh via RT
met_help at ucar.edu
Thu May 16 14:12:35 MDT 2019
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi,
We've come across the issue that the code is expecting the time variable to be double. The IMPROVER files seem to have time as int64. We've already had to preprocess the files because MET doesn't support the Lambert Azimuthal Equal Area projection. We can go back and sort out the data type but we've been told the IMPROVER files are CF compliant! We weren't expecting this failure. We are not sure this is a CF compliance issue but could it be that MET is too strict? Not a CF compliance expert....
Regards
Marion
DEBUG 1: Default Config File: /project/ukmo/meteval/met-8.0/share/met/config/SeriesAnalysisConfig_default
DEBUG 1: User Config File: /home/h02/frmm/MET/config/SeriesAnalysisConfig.IMPRO_T2m
DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() -> created new Met2dDataFile object of type "FileType_NcCF".
DEBUG 4: NcCfFile::open() -> parsing units for the time variable "seconds since 1970-01-01 00:00:00"
DEBUG 4: parse_cf_time_string() -> parsed NetCDF CF convention time unit string "seconds since 1970-01-01 00:00:00" as a reference time of 19700101_000000 and 1 second(s) per time step.
ERROR :
ERROR : get_double_var() -> data type mismatch (double vs. "int64").
ERROR : It won't be converted because of dimension issue.
ERROR : Please correct the data type to double for variable "time".
ERROR :
--
Dr Marion Mittermaier Manager: Model diagnostics and novel verification
Met Office FitzRoy Road Exeter EX1 3PB United Kingdom
Tel: +44 (0)1392 884830 / +44 (0) 330 135 1604 Fax: +44 (0)1392 885681
E-mail: marion.mittermaier at metoffice.gov.uk<mailto:marion.mittermaier at metoffice.gov.uk> http://www.metoffice.gov.uk<http://www.metoffice.gov.uk/>
http://www.metoffice.gov.uk/research/people/marion-mittermaier
I am co-chair of the WMO WWRP Joint Working Group on Forecast Verification Research (JWGFVR) http://www.wmo.int/pages/prog/arep/wwrp/new/Forecast_Verification.html
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: CF compliance specifying time data type
From: Howard Soh
Time: Tue Feb 26 09:59:38 2019
Comment internally.
This is not CF issue. Our code expects double type data for time
variable and not accepts int/short type time variable. The similar
issue existed with float data type. But I only corrected for float
type data. I will made the similar changes on reading double values
from int/short data type.
Cheers,
Howard
On Tue Feb 26 09:39:33 2019, marion.mittermaier at metoffice.gov.uk
wrote:
> Hi,
>
> We've come across the issue that the code is expecting the time
> variable to be double. The IMPROVER files seem to have time as
int64.
> We've already had to preprocess the files because MET doesn't
support
> the Lambert Azimuthal Equal Area projection. We can go back and sort
> out the data type but we've been told the IMPROVER files are CF
> compliant! We weren't expecting this failure. We are not sure this
is
> a CF compliance issue but could it be that MET is too strict? Not a
CF
> compliance expert....
>
> Regards
> Marion
>
> DEBUG 1: Default Config File: /project/ukmo/meteval/met-
> 8.0/share/met/config/SeriesAnalysisConfig_default
> DEBUG 1: User Config File:
> /home/h02/frmm/MET/config/SeriesAnalysisConfig.IMPRO_T2m
> DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() -> created new
> Met2dDataFile object of type "FileType_NcCF".
> DEBUG 4: NcCfFile::open() -> parsing units for the time variable
> "seconds since 1970-01-01 00:00:00"
> DEBUG 4: parse_cf_time_string() -> parsed NetCDF CF convention time
> unit string "seconds since 1970-01-01 00:00:00" as a reference time
of
> 19700101_000000 and 1 second(s) per time step.
> ERROR :
> ERROR : get_double_var() -> data type mismatch (double vs.
"int64").
> ERROR : It won't be converted because of dimension issue.
> ERROR : Please correct the data type to double for variable "time".
> ERROR :
>
>
> --
> Dr Marion Mittermaier Manager: Model diagnostics and novel
> verification
>
> Met Office FitzRoy Road Exeter EX1 3PB United Kingdom
> Tel: +44 (0)1392 884830 / +44 (0) 330 135 1604 Fax: +44 (0)1392
> 885681
> E-mail:
>
marion.mittermaier at metoffice.gov.uk<mailto:marion.mittermaier at metoffice.gov.uk>
> http://www.metoffice.gov.uk<http://www.metoffice.gov.uk/>
>
> http://www.metoffice.gov.uk/research/people/marion-mittermaier
>
> I am co-chair of the WMO WWRP Joint Working Group on Forecast
> Verification Research (JWGFVR)
>
http://www.wmo.int/pages/prog/arep/wwrp/new/Forecast_Verification.html
------------------------------------------------
Subject: CF compliance specifying time data type
From: Howard Soh
Time: Wed Feb 27 14:14:54 2019
It's not a CF issue. MET tool is strict on checking the data type of
the variables.
MET tool expects the double type time variable. There is an int64 type
time variable at
20171129T1500Z_PT0024H_20171130T1500Z_temperature_at_screen_level.nc.
The MET code will support int64 type time variable for the next
release.
The quick solution will be changing the data type of time variable to
double:
int64 time ;
time:units = "seconds since 1970-01-01 00:00:00" ;
time:standard_name = "time" ;
time:calendar = "gregorian" ;
==>
double time ;
time:units = "seconds since 1970-01-01 00:00:00" ;
time:standard_name = "time" ;
time:calendar = "gregorian" ;
Cheers,
Howard
On Tue Feb 26 09:39:33 2019, marion.mittermaier at metoffice.gov.uk
wrote:
> Hi,
>
> We've come across the issue that the code is expecting the time
> variable to be double. The IMPROVER files seem to have time as
int64.
> We've already had to preprocess the files because MET doesn't
support
> the Lambert Azimuthal Equal Area projection. We can go back and sort
> out the data type but we've been told the IMPROVER files are CF
> compliant! We weren't expecting this failure. We are not sure this
is
> a CF compliance issue but could it be that MET is too strict? Not a
CF
> compliance expert....
>
> Regards
> Marion
>
> DEBUG 1: Default Config File: /project/ukmo/meteval/met-
> 8.0/share/met/config/SeriesAnalysisConfig_default
> DEBUG 1: User Config File:
> /home/h02/frmm/MET/config/SeriesAnalysisConfig.IMPRO_T2m
> DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() -> created new
> Met2dDataFile object of type "FileType_NcCF".
> DEBUG 4: NcCfFile::open() -> parsing units for the time variable
> "seconds since 1970-01-01 00:00:00"
> DEBUG 4: parse_cf_time_string() -> parsed NetCDF CF convention time
> unit string "seconds since 1970-01-01 00:00:00" as a reference time
of
> 19700101_000000 and 1 second(s) per time step.
> ERROR :
> ERROR : get_double_var() -> data type mismatch (double vs.
"int64").
> ERROR : It won't be converted because of dimension issue.
> ERROR : Please correct the data type to double for variable "time".
> ERROR :
>
>
> --
> Dr Marion Mittermaier Manager: Model diagnostics and novel
> verification
>
> Met Office FitzRoy Road Exeter EX1 3PB United Kingdom
> Tel: +44 (0)1392 884830 / +44 (0) 330 135 1604 Fax: +44 (0)1392
> 885681
> E-mail:
>
marion.mittermaier at metoffice.gov.uk<mailto:marion.mittermaier at metoffice.gov.uk>
> http://www.metoffice.gov.uk<http://www.metoffice.gov.uk/>
>
> http://www.metoffice.gov.uk/research/people/marion-mittermaier
>
> I am co-chair of the WMO WWRP Joint Working Group on Forecast
> Verification Research (JWGFVR)
>
http://www.wmo.int/pages/prog/arep/wwrp/new/Forecast_Verification.html
------------------------------------------------
More information about the Met_help
mailing list