[Met_help] [rt.rap.ucar.edu #60806] History for (UNCLASSIFIED)
John Halley Gotway via RT
met_help at ucar.edu
Thu Mar 28 15:59:58 MDT 2013
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Classification: UNCLASSIFIED
Caveats: NONE
When using ASCII2NC from MET V4.0, I received the following DEBUG dialog:
"Found 10 col input file format deprecated in MET V4.1 - Consider adding
quality flag value"
What does this mean? Is there a problem with the input text file in 10
column format? If so, what is the specific fix that is required?
Thanks.
R/
John
Mr John W. Raby, Meteorologist
U.S. Army Research Laboratory
White Sands Missile Range, NM 88002
(575) 678-2004 DSN 258-2004
FAX (575) 678-1230 DSN 258-1230
Email: john.w.raby2.civ at mail.mil
Classification: UNCLASSIFIED
Caveats: NONE
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
From: John Halley Gotway
Time: Thu Mar 28 10:23:26 2013
John,
In METv4.0, the NetCDF point observations files used by Point-Stat and
Ensemble-Stat did not contain any quality control information. In
METv4.1, we've added quality control information to those
files so that Point-Stat and Ensemble-Stat can filter by them when
doing verification.
So the ascii2nc, pb2nc, and madis2nc tools have been enhanced for
METv4.1 to write out the qc values they see in the input. So the 10-
column ascii2nc format has changed to an 11-column format - the
extra column being for qc info.
However, the tools are still backward compatible. The METv4.1 version
of ascii2nc will still handle the 10-column format, but it'll just put
missing values for the qc string in the output.
Make sense?
Thanks,
John
On 03/28/2013 08:27 AM, Raby, John W USA CIV via RT wrote:
>
> Thu Mar 28 08:27:01 2013: Request 60806 was acted upon.
> Transaction: Ticket created by john.w.raby2.civ at mail.mil
> Queue: met_help
> Subject: (UNCLASSIFIED)
> Owner: Nobody
> Requestors: john.w.raby2.civ at mail.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> When using ASCII2NC from MET V4.0, I received the following DEBUG
dialog:
>
> "Found 10 col input file format deprecated in MET V4.1 - Consider
adding
> quality flag value"
>
> What does this mean? Is there a problem with the input text file in
10
> column format? If so, what is the specific fix that is required?
>
> Thanks.
>
> R/
> John
>
> Mr John W. Raby, Meteorologist
> U.S. Army Research Laboratory
> White Sands Missile Range, NM 88002
> (575) 678-2004 DSN 258-2004
> FAX (575) 678-1230 DSN 258-1230
> Email: john.w.raby2.civ at mail.mil
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
------------------------------------------------
Subject: (UNCLASSIFIED)
From: Raby, John W USA CIV
Time: Thu Mar 28 10:55:13 2013
Classification: UNCLASSIFIED
Caveats: NONE
John -
Yes. Thanks for the info on that. Before we use ascii2nc to convert
MADIS
ascii files to netCDF, we apply the QC filter of "99" or "Highest
Possible"
when we process the sfcdump.txt files we receive from the MADIS
database. So,
the QC has already been applied before running ascii2nc. Appreciate
the
backward compatibility of these utilities as this saves us from
modifying our
program right now to convert to the 11-col format.
I have not yet investigated how your new utility (madis2nc) might
replace our
MADIS processing program yet. I understand that it converts text files
which
are downloaded from the MADIS database into the required 10-col
format. Does
that utility convert the sfcdump.txt files direct to the required 10-
col
netCDF format?
For PreBUFR data, there is no step that I can see between the
downloading of
the PrepBUFR files from NOAA and the generation of the netCDF files
with pb2nc
where a QC flag would be applied. I can only assume that NOAA has
applied/placed QC flags in the data when they post it on their
download
website. I have recently run pb2nc and I did not see any DEBUG dialog
about
the deprecation. I assume I would have received the same dialog if
there had
not been any QC flags in the data when I ran pb2nc.
Incidentally, we found a workaround for the local network security
blocking of
the NOAA ftp sites for MADIS and PrepBUFR. NOAA has HTTP sites for
both and we
have switched our data collection processes to collect from these
sites. We no
longer use ftp.
R/
John
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Thursday, March 28, 2013 10:23 AM
To: Raby, John W CIV USARMY ARL (US)
Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T CIV
(US)
Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
John,
In METv4.0, the NetCDF point observations files used by Point-Stat and
Ensemble-Stat did not contain any quality control information. In
METv4.1,
we've added quality control information to those files so that Point-
Stat and
Ensemble-Stat can filter by them when doing verification.
So the ascii2nc, pb2nc, and madis2nc tools have been enhanced for
METv4.1 to
write out the qc values they see in the input. So the 10-column
ascii2nc
format has changed to an 11-column format - the extra column being for
qc
info.
However, the tools are still backward compatible. The METv4.1 version
of
ascii2nc will still handle the 10-column format, but it'll just put
missing
values for the qc string in the output.
Make sense?
Thanks,
John
On 03/28/2013 08:27 AM, Raby, John W USA CIV via RT wrote:
>
> Thu Mar 28 08:27:01 2013: Request 60806 was acted upon.
> Transaction: Ticket created by john.w.raby2.civ at mail.mil
> Queue: met_help
> Subject: (UNCLASSIFIED)
> Owner: Nobody
> Requestors: john.w.raby2.civ at mail.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806
> >
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> When using ASCII2NC from MET V4.0, I received the following DEBUG
dialog:
>
> "Found 10 col input file format deprecated in MET V4.1 - Consider
> adding quality flag value"
>
> What does this mean? Is there a problem with the input text file in
10
> column format? If so, what is the specific fix that is required?
>
> Thanks.
>
> R/
> John
>
> Mr John W. Raby, Meteorologist
> U.S. Army Research Laboratory
> White Sands Missile Range, NM 88002
> (575) 678-2004 DSN 258-2004
> FAX (575) 678-1230 DSN 258-1230
> Email: john.w.raby2.civ at mail.mil
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
From: John Halley Gotway
Time: Thu Mar 28 11:10:48 2013
John,
The madis2nc tool processes madis NetCDF files, not ascii ones.
Regarding PREPBUFR, yes, NCEP applies QC to the data and assigns a QC
value for each observation. All PB2NC is doing is passing NCEP's QC
values along to the output file. The METv4.1 version of
PB2NC will now pass along this QC information. However, by default
the QC strings will not be used by Point-Stat and Ensemble-Stat. If
you do want to select a subset of observations by their QC
strings, you'd have to set up the config file to list the ones you
want.
When we do the official release of METv4.1, we'll include a list of
release notes about these sorts of things.
Thanks,
John
On 03/28/2013 10:55 AM, Raby, John W USA CIV via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John -
>
> Yes. Thanks for the info on that. Before we use ascii2nc to convert
MADIS
> ascii files to netCDF, we apply the QC filter of "99" or "Highest
Possible"
> when we process the sfcdump.txt files we receive from the MADIS
database. So,
> the QC has already been applied before running ascii2nc. Appreciate
the
> backward compatibility of these utilities as this saves us from
modifying our
> program right now to convert to the 11-col format.
>
> I have not yet investigated how your new utility (madis2nc) might
replace our
> MADIS processing program yet. I understand that it converts text
files which
> are downloaded from the MADIS database into the required 10-col
format. Does
> that utility convert the sfcdump.txt files direct to the required
10-col
> netCDF format?
>
> For PreBUFR data, there is no step that I can see between the
downloading of
> the PrepBUFR files from NOAA and the generation of the netCDF files
with pb2nc
> where a QC flag would be applied. I can only assume that NOAA has
> applied/placed QC flags in the data when they post it on their
download
> website. I have recently run pb2nc and I did not see any DEBUG
dialog about
> the deprecation. I assume I would have received the same dialog if
there had
> not been any QC flags in the data when I ran pb2nc.
>
> Incidentally, we found a workaround for the local network security
blocking of
> the NOAA ftp sites for MADIS and PrepBUFR. NOAA has HTTP sites for
both and we
> have switched our data collection processes to collect from these
sites. We no
> longer use ftp.
>
> R/
> John
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Thursday, March 28, 2013 10:23 AM
> To: Raby, John W CIV USARMY ARL (US)
> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV (US)
> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>
> John,
>
> In METv4.0, the NetCDF point observations files used by Point-Stat
and
> Ensemble-Stat did not contain any quality control information. In
METv4.1,
> we've added quality control information to those files so that
Point-Stat and
> Ensemble-Stat can filter by them when doing verification.
>
> So the ascii2nc, pb2nc, and madis2nc tools have been enhanced for
METv4.1 to
> write out the qc values they see in the input. So the 10-column
ascii2nc
> format has changed to an 11-column format - the extra column being
for qc
> info.
>
> However, the tools are still backward compatible. The METv4.1
version of
> ascii2nc will still handle the 10-column format, but it'll just put
missing
> values for the qc string in the output.
>
> Make sense?
>
> Thanks,
> John
>
>
>
> On 03/28/2013 08:27 AM, Raby, John W USA CIV via RT wrote:
>>
>> Thu Mar 28 08:27:01 2013: Request 60806 was acted upon.
>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>> Queue: met_help
>> Subject: (UNCLASSIFIED)
>> Owner: Nobody
>> Requestors: john.w.raby2.civ at mail.mil
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> When using ASCII2NC from MET V4.0, I received the following DEBUG
dialog:
>>
>> "Found 10 col input file format deprecated in MET V4.1 - Consider
>> adding quality flag value"
>>
>> What does this mean? Is there a problem with the input text file in
10
>> column format? If so, what is the specific fix that is required?
>>
>> Thanks.
>>
>> R/
>> John
>>
>> Mr John W. Raby, Meteorologist
>> U.S. Army Research Laboratory
>> White Sands Missile Range, NM 88002
>> (575) 678-2004 DSN 258-2004
>> FAX (575) 678-1230 DSN 258-1230
>> Email: john.w.raby2.civ at mail.mil
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
------------------------------------------------
Subject: (UNCLASSIFIED)
From: Raby, John W USA CIV
Time: Thu Mar 28 11:26:44 2013
Classification: UNCLASSIFIED
Caveats: NONE
John -
Thanks for that info. This is always useful to us.
How does madis2nc crop the files to the area of interest? The files we
download from the MADIS database (.gz files) contain data for all of
CONUS! We
have to crop the data for the area of interest before we create the
hourly
text files in 10-col format.
R/
John
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Thursday, March 28, 2013 11:11 AM
To: Raby, John W CIV USARMY ARL (US)
Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T CIV
(US)
Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
John,
The madis2nc tool processes madis NetCDF files, not ascii ones.
Regarding PREPBUFR, yes, NCEP applies QC to the data and assigns a QC
value
for each observation. All PB2NC is doing is passing NCEP's QC values
along to
the output file. The METv4.1 version of PB2NC will now pass along
this QC
information. However, by default the QC strings will not be used by
Point-Stat and Ensemble-Stat. If you do want to select a subset of
observations by their QC strings, you'd have to set up the config file
to list
the ones you want.
When we do the official release of METv4.1, we'll include a list of
release
notes about these sorts of things.
Thanks,
John
On 03/28/2013 10:55 AM, Raby, John W USA CIV via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John -
>
> Yes. Thanks for the info on that. Before we use ascii2nc to convert
> MADIS ascii files to netCDF, we apply the QC filter of "99" or
"Highest
> Possible"
> when we process the sfcdump.txt files we receive from the MADIS
> database. So, the QC has already been applied before running
ascii2nc.
> Appreciate the backward compatibility of these utilities as this
saves
> us from modifying our program right now to convert to the 11-col
format.
>
> I have not yet investigated how your new utility (madis2nc) might
> replace our MADIS processing program yet. I understand that it
> converts text files which are downloaded from the MADIS database
into
> the required 10-col format. Does that utility convert the
sfcdump.txt
> files direct to the required 10-col netCDF format?
>
> For PreBUFR data, there is no step that I can see between the
> downloading of the PrepBUFR files from NOAA and the generation of
the
> netCDF files with pb2nc where a QC flag would be applied. I can only
> assume that NOAA has applied/placed QC flags in the data when they
> post it on their download website. I have recently run pb2nc and I
did
> not see any DEBUG dialog about the deprecation. I assume I would
have
> received the same dialog if there had not been any QC flags in the
data when
> I ran pb2nc.
>
> Incidentally, we found a workaround for the local network security
> blocking of the NOAA ftp sites for MADIS and PrepBUFR. NOAA has HTTP
> sites for both and we have switched our data collection processes to
> collect from these sites. We no longer use ftp.
>
> R/
> John
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Thursday, March 28, 2013 10:23 AM
> To: Raby, John W CIV USARMY ARL (US)
> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV
> (US)
> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>
> John,
>
> In METv4.0, the NetCDF point observations files used by Point-Stat
and
> Ensemble-Stat did not contain any quality control information. In
> METv4.1, we've added quality control information to those files so
> that Point-Stat and Ensemble-Stat can filter by them when doing
> verification.
>
> So the ascii2nc, pb2nc, and madis2nc tools have been enhanced for
> METv4.1 to write out the qc values they see in the input. So the
> 10-column ascii2nc format has changed to an 11-column format - the
> extra column being for qc info.
>
> However, the tools are still backward compatible. The METv4.1
version
> of ascii2nc will still handle the 10-column format, but it'll just
put
> missing values for the qc string in the output.
>
> Make sense?
>
> Thanks,
> John
>
>
>
> On 03/28/2013 08:27 AM, Raby, John W USA CIV via RT wrote:
>>
>> Thu Mar 28 08:27:01 2013: Request 60806 was acted upon.
>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>> Queue: met_help
>> Subject: (UNCLASSIFIED)
>> Owner: Nobody
>> Requestors: john.w.raby2.civ at mail.mil
>> Status: new
>> Ticket <URL:
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> When using ASCII2NC from MET V4.0, I received the following DEBUG
dialog:
>>
>> "Found 10 col input file format deprecated in MET V4.1 - Consider
>> adding quality flag value"
>>
>> What does this mean? Is there a problem with the input text file in
>> 10 column format? If so, what is the specific fix that is required?
>>
>> Thanks.
>>
>> R/
>> John
>>
>> Mr John W. Raby, Meteorologist
>> U.S. Army Research Laboratory
>> White Sands Missile Range, NM 88002
>> (575) 678-2004 DSN 258-2004
>> FAX (575) 678-1230 DSN 258-1230
>> Email: john.w.raby2.civ at mail.mil
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
From: John Halley Gotway
Time: Thu Mar 28 12:35:11 2013
John,
Currently there is no mechanism in place in madis2nc to spatially
subset the observations. However, if that functionality is desired,
it would be pretty straight-forward to add. We could do it by
having the user specify a lat/lon polyline or by specifying a gridded
data file and only keep the obs that fall on that grid.
John
On 03/28/2013 11:26 AM, Raby, John W USA CIV via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John -
>
> Thanks for that info. This is always useful to us.
>
> How does madis2nc crop the files to the area of interest? The files
we
> download from the MADIS database (.gz files) contain data for all of
CONUS! We
> have to crop the data for the area of interest before we create the
hourly
> text files in 10-col format.
>
> R/
> John
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Thursday, March 28, 2013 11:11 AM
> To: Raby, John W CIV USARMY ARL (US)
> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV (US)
> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>
> John,
>
> The madis2nc tool processes madis NetCDF files, not ascii ones.
>
> Regarding PREPBUFR, yes, NCEP applies QC to the data and assigns a
QC value
> for each observation. All PB2NC is doing is passing NCEP's QC
values along to
> the output file. The METv4.1 version of PB2NC will now pass along
this QC
> information. However, by default the QC strings will not be used by
> Point-Stat and Ensemble-Stat. If you do want to select a subset of
> observations by their QC strings, you'd have to set up the config
file to list
> the ones you want.
>
> When we do the official release of METv4.1, we'll include a list of
release
> notes about these sorts of things.
>
> Thanks,
> John
>
>
> On 03/28/2013 10:55 AM, Raby, John W USA CIV via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> John -
>>
>> Yes. Thanks for the info on that. Before we use ascii2nc to convert
>> MADIS ascii files to netCDF, we apply the QC filter of "99" or
"Highest
>> Possible"
>> when we process the sfcdump.txt files we receive from the MADIS
>> database. So, the QC has already been applied before running
ascii2nc.
>> Appreciate the backward compatibility of these utilities as this
saves
>> us from modifying our program right now to convert to the 11-col
format.
>>
>> I have not yet investigated how your new utility (madis2nc) might
>> replace our MADIS processing program yet. I understand that it
>> converts text files which are downloaded from the MADIS database
into
>> the required 10-col format. Does that utility convert the
sfcdump.txt
>> files direct to the required 10-col netCDF format?
>>
>> For PreBUFR data, there is no step that I can see between the
>> downloading of the PrepBUFR files from NOAA and the generation of
the
>> netCDF files with pb2nc where a QC flag would be applied. I can
only
>> assume that NOAA has applied/placed QC flags in the data when they
>> post it on their download website. I have recently run pb2nc and I
did
>> not see any DEBUG dialog about the deprecation. I assume I would
have
>> received the same dialog if there had not been any QC flags in the
data when
>> I ran pb2nc.
>>
>> Incidentally, we found a workaround for the local network security
>> blocking of the NOAA ftp sites for MADIS and PrepBUFR. NOAA has
HTTP
>> sites for both and we have switched our data collection processes
to
>> collect from these sites. We no longer use ftp.
>>
>> R/
>> John
>>
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Thursday, March 28, 2013 10:23 AM
>> To: Raby, John W CIV USARMY ARL (US)
>> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV
>> (US)
>> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>>
>> John,
>>
>> In METv4.0, the NetCDF point observations files used by Point-Stat
and
>> Ensemble-Stat did not contain any quality control information. In
>> METv4.1, we've added quality control information to those files so
>> that Point-Stat and Ensemble-Stat can filter by them when doing
>> verification.
>>
>> So the ascii2nc, pb2nc, and madis2nc tools have been enhanced for
>> METv4.1 to write out the qc values they see in the input. So the
>> 10-column ascii2nc format has changed to an 11-column format - the
>> extra column being for qc info.
>>
>> However, the tools are still backward compatible. The METv4.1
version
>> of ascii2nc will still handle the 10-column format, but it'll just
put
>> missing values for the qc string in the output.
>>
>> Make sense?
>>
>> Thanks,
>> John
>>
>>
>>
>> On 03/28/2013 08:27 AM, Raby, John W USA CIV via RT wrote:
>>>
>>> Thu Mar 28 08:27:01 2013: Request 60806 was acted upon.
>>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>>> Queue: met_help
>>> Subject: (UNCLASSIFIED)
>>> Owner: Nobody
>>> Requestors: john.w.raby2.civ at mail.mil
>>> Status: new
>>> Ticket <URL:
>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806
>>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> When using ASCII2NC from MET V4.0, I received the following DEBUG
dialog:
>>>
>>> "Found 10 col input file format deprecated in MET V4.1 - Consider
>>> adding quality flag value"
>>>
>>> What does this mean? Is there a problem with the input text file
in
>>> 10 column format? If so, what is the specific fix that is
required?
>>>
>>> Thanks.
>>>
>>> R/
>>> John
>>>
>>> Mr John W. Raby, Meteorologist
>>> U.S. Army Research Laboratory
>>> White Sands Missile Range, NM 88002
>>> (575) 678-2004 DSN 258-2004
>>> FAX (575) 678-1230 DSN 258-1230
>>> Email: john.w.raby2.civ at mail.mil
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
------------------------------------------------
Subject: (UNCLASSIFIED)
From: Raby, John W USA CIV
Time: Thu Mar 28 13:43:42 2013
Classification: UNCLASSIFIED
Caveats: NONE
John -
I think your idea of adding a capability to have the user specify the
domain
by lat/long such as the .poly file to define a verification masking
region for
Point-Stat/Grid-Stat would be a nice enhancement. As far as I know,
MADIS does
not provide the capability to use a spatial subset to request their
data in
netCDF format.
I did find a MADIS site https://madis-
data.noaa.gov/public/sfcdumpguest.html
which allows a user to specify a domain and then provides a text file
output
as well as some other familiar formats, but not netCDF. See the
attached text
file I downloaded from that site.
Also having the capability to specify, by way of a given model output
grid,
the grid over which to keep the observations per your other suggestion
would
be very nice. For example, if I am going to use Point-Stat to verify
the WRF
forecast output GRIB1 file (WRFPRS_d01.10), I would want to collect
the
observations for that same gridded area and throw away the rest.
If I had to choose one of those methods I would say go with the use of
the
specified gridded data file such as the WRFPRS file.
Thanks for your help with this.
R/
John
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Thursday, March 28, 2013 12:35 PM
To: Raby, John W CIV USARMY ARL (US)
Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T CIV
(US)
Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
John,
Currently there is no mechanism in place in madis2nc to spatially
subset the
observations. However, if that functionality is desired, it would be
pretty
straight-forward to add. We could do it by having the user specify a
lat/lon
polyline or by specifying a gridded data file and only keep the obs
that fall
on that grid.
John
On 03/28/2013 11:26 AM, Raby, John W USA CIV via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John -
>
> Thanks for that info. This is always useful to us.
>
> How does madis2nc crop the files to the area of interest? The files
we
> download from the MADIS database (.gz files) contain data for all of
> CONUS! We have to crop the data for the area of interest before we
> create the hourly text files in 10-col format.
>
> R/
> John
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Thursday, March 28, 2013 11:11 AM
> To: Raby, John W CIV USARMY ARL (US)
> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV
> (US)
> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>
> John,
>
> The madis2nc tool processes madis NetCDF files, not ascii ones.
>
> Regarding PREPBUFR, yes, NCEP applies QC to the data and assigns a
QC
> value for each observation. All PB2NC is doing is passing NCEP's QC
> values along to the output file. The METv4.1 version of PB2NC will
> now pass along this QC information. However, by default the QC
> strings will not be used by Point-Stat and Ensemble-Stat. If you do
> want to select a subset of observations by their QC strings, you'd
> have to set up the config file to list the ones you want.
>
> When we do the official release of METv4.1, we'll include a list of
> release notes about these sorts of things.
>
> Thanks,
> John
>
>
> On 03/28/2013 10:55 AM, Raby, John W USA CIV via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> John -
>>
>> Yes. Thanks for the info on that. Before we use ascii2nc to convert
>> MADIS ascii files to netCDF, we apply the QC filter of "99" or
>> "Highest Possible"
>> when we process the sfcdump.txt files we receive from the MADIS
>> database. So, the QC has already been applied before running
ascii2nc.
>> Appreciate the backward compatibility of these utilities as this
>> saves us from modifying our program right now to convert to the 11-
col
>> format.
>>
>> I have not yet investigated how your new utility (madis2nc) might
>> replace our MADIS processing program yet. I understand that it
>> converts text files which are downloaded from the MADIS database
into
>> the required 10-col format. Does that utility convert the
sfcdump.txt
>> files direct to the required 10-col netCDF format?
>>
>> For PreBUFR data, there is no step that I can see between the
>> downloading of the PrepBUFR files from NOAA and the generation of
the
>> netCDF files with pb2nc where a QC flag would be applied. I can
only
>> assume that NOAA has applied/placed QC flags in the data when they
>> post it on their download website. I have recently run pb2nc and I
>> did not see any DEBUG dialog about the deprecation. I assume I
would
>> have received the same dialog if there had not been any QC flags in
>> the data when I ran pb2nc.
>>
>> Incidentally, we found a workaround for the local network security
>> blocking of the NOAA ftp sites for MADIS and PrepBUFR. NOAA has
HTTP
>> sites for both and we have switched our data collection processes
to
>> collect from these sites. We no longer use ftp.
>>
>> R/
>> John
>>
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Thursday, March 28, 2013 10:23 AM
>> To: Raby, John W CIV USARMY ARL (US)
>> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV
>> (US)
>> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>>
>> John,
>>
>> In METv4.0, the NetCDF point observations files used by Point-Stat
>> and Ensemble-Stat did not contain any quality control information.
>> In METv4.1, we've added quality control information to those files
so
>> that Point-Stat and Ensemble-Stat can filter by them when doing
>> verification.
>>
>> So the ascii2nc, pb2nc, and madis2nc tools have been enhanced for
>> METv4.1 to write out the qc values they see in the input. So the
>> 10-column ascii2nc format has changed to an 11-column format - the
>> extra column being for qc info.
>>
>> However, the tools are still backward compatible. The METv4.1
>> version of ascii2nc will still handle the 10-column format, but
it'll
>> just put missing values for the qc string in the output.
>>
>> Make sense?
>>
>> Thanks,
>> John
>>
>>
>>
>> On 03/28/2013 08:27 AM, Raby, John W USA CIV via RT wrote:
>>>
>>> Thu Mar 28 08:27:01 2013: Request 60806 was acted upon.
>>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>>> Queue: met_help
>>> Subject: (UNCLASSIFIED)
>>> Owner: Nobody
>>> Requestors: john.w.raby2.civ at mail.mil
>>> Status: new
>>> Ticket <URL:
>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806
>>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> When using ASCII2NC from MET V4.0, I received the following DEBUG
dialog:
>>>
>>> "Found 10 col input file format deprecated in MET V4.1 - Consider
>>> adding quality flag value"
>>>
>>> What does this mean? Is there a problem with the input text file
in
>>> 10 column format? If so, what is the specific fix that is
required?
>>>
>>> Thanks.
>>>
>>> R/
>>> John
>>>
>>> Mr John W. Raby, Meteorologist
>>> U.S. Army Research Laboratory
>>> White Sands Missile Range, NM 88002
>>> (575) 678-2004 DSN 258-2004
>>> FAX (575) 678-1230 DSN 258-1230
>>> Email: john.w.raby2.civ at mail.mil
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
From: John Halley Gotway
Time: Thu Mar 28 15:05:57 2013
John,
Thanks for your feedback on this. I've created a ticket in our
development issue track system for this. We may or may not be able to
include this in METv4.1 - it depends on how the remaining
development tasks shake out. But if not in 4.1, we can add it to the
next release.
Thanks,
John
On 03/28/2013 01:43 PM, Raby, John W USA CIV via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John -
>
> I think your idea of adding a capability to have the user specify
the domain
> by lat/long such as the .poly file to define a verification masking
region for
> Point-Stat/Grid-Stat would be a nice enhancement. As far as I know,
MADIS does
> not provide the capability to use a spatial subset to request their
data in
> netCDF format.
>
> I did find a MADIS site https://madis-
data.noaa.gov/public/sfcdumpguest.html
> which allows a user to specify a domain and then provides a text
file output
> as well as some other familiar formats, but not netCDF. See the
attached text
> file I downloaded from that site.
>
> Also having the capability to specify, by way of a given model
output grid,
> the grid over which to keep the observations per your other
suggestion would
> be very nice. For example, if I am going to use Point-Stat to verify
the WRF
> forecast output GRIB1 file (WRFPRS_d01.10), I would want to collect
the
> observations for that same gridded area and throw away the rest.
>
> If I had to choose one of those methods I would say go with the use
of the
> specified gridded data file such as the WRFPRS file.
>
> Thanks for your help with this.
>
> R/
> John
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Thursday, March 28, 2013 12:35 PM
> To: Raby, John W CIV USARMY ARL (US)
> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV (US)
> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>
> John,
>
> Currently there is no mechanism in place in madis2nc to spatially
subset the
> observations. However, if that functionality is desired, it would
be pretty
> straight-forward to add. We could do it by having the user specify
a lat/lon
> polyline or by specifying a gridded data file and only keep the obs
that fall
> on that grid.
>
> John
>
> On 03/28/2013 11:26 AM, Raby, John W USA CIV via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> John -
>>
>> Thanks for that info. This is always useful to us.
>>
>> How does madis2nc crop the files to the area of interest? The files
we
>> download from the MADIS database (.gz files) contain data for all
of
>> CONUS! We have to crop the data for the area of interest before we
>> create the hourly text files in 10-col format.
>>
>> R/
>> John
>>
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Thursday, March 28, 2013 11:11 AM
>> To: Raby, John W CIV USARMY ARL (US)
>> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV
>> (US)
>> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>>
>> John,
>>
>> The madis2nc tool processes madis NetCDF files, not ascii ones.
>>
>> Regarding PREPBUFR, yes, NCEP applies QC to the data and assigns a
QC
>> value for each observation. All PB2NC is doing is passing NCEP's
QC
>> values along to the output file. The METv4.1 version of PB2NC will
>> now pass along this QC information. However, by default the QC
>> strings will not be used by Point-Stat and Ensemble-Stat. If you
do
>> want to select a subset of observations by their QC strings, you'd
>> have to set up the config file to list the ones you want.
>>
>> When we do the official release of METv4.1, we'll include a list of
>> release notes about these sorts of things.
>>
>> Thanks,
>> John
>>
>>
>> On 03/28/2013 10:55 AM, Raby, John W USA CIV via RT wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> John -
>>>
>>> Yes. Thanks for the info on that. Before we use ascii2nc to
convert
>>> MADIS ascii files to netCDF, we apply the QC filter of "99" or
>>> "Highest Possible"
>>> when we process the sfcdump.txt files we receive from the MADIS
>>> database. So, the QC has already been applied before running
ascii2nc.
>>> Appreciate the backward compatibility of these utilities as this
>>> saves us from modifying our program right now to convert to the
11-col
>>> format.
>>>
>>> I have not yet investigated how your new utility (madis2nc) might
>>> replace our MADIS processing program yet. I understand that it
>>> converts text files which are downloaded from the MADIS database
into
>>> the required 10-col format. Does that utility convert the
sfcdump.txt
>>> files direct to the required 10-col netCDF format?
>>>
>>> For PreBUFR data, there is no step that I can see between the
>>> downloading of the PrepBUFR files from NOAA and the generation of
the
>>> netCDF files with pb2nc where a QC flag would be applied. I can
only
>>> assume that NOAA has applied/placed QC flags in the data when they
>>> post it on their download website. I have recently run pb2nc and I
>>> did not see any DEBUG dialog about the deprecation. I assume I
would
>>> have received the same dialog if there had not been any QC flags
in
>>> the data when I ran pb2nc.
>>>
>>> Incidentally, we found a workaround for the local network security
>>> blocking of the NOAA ftp sites for MADIS and PrepBUFR. NOAA has
HTTP
>>> sites for both and we have switched our data collection processes
to
>>> collect from these sites. We no longer use ftp.
>>>
>>> R/
>>> John
>>>
>>>
>>> -----Original Message-----
>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> Sent: Thursday, March 28, 2013 10:23 AM
>>> To: Raby, John W CIV USARMY ARL (US)
>>> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV
>>> (US)
>>> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>>>
>>> John,
>>>
>>> In METv4.0, the NetCDF point observations files used by Point-Stat
>>> and Ensemble-Stat did not contain any quality control information.
>>> In METv4.1, we've added quality control information to those files
so
>>> that Point-Stat and Ensemble-Stat can filter by them when doing
>>> verification.
>>>
>>> So the ascii2nc, pb2nc, and madis2nc tools have been enhanced for
>>> METv4.1 to write out the qc values they see in the input. So the
>>> 10-column ascii2nc format has changed to an 11-column format - the
>>> extra column being for qc info.
>>>
>>> However, the tools are still backward compatible. The METv4.1
>>> version of ascii2nc will still handle the 10-column format, but
it'll
>>> just put missing values for the qc string in the output.
>>>
>>> Make sense?
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>> On 03/28/2013 08:27 AM, Raby, John W USA CIV via RT wrote:
>>>>
>>>> Thu Mar 28 08:27:01 2013: Request 60806 was acted upon.
>>>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>>>> Queue: met_help
>>>> Subject: (UNCLASSIFIED)
>>>> Owner: Nobody
>>>> Requestors: john.w.raby2.civ at mail.mil
>>>> Status: new
>>>> Ticket <URL:
>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806
>>>>>
>>>>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>> When using ASCII2NC from MET V4.0, I received the following DEBUG
dialog:
>>>>
>>>> "Found 10 col input file format deprecated in MET V4.1 - Consider
>>>> adding quality flag value"
>>>>
>>>> What does this mean? Is there a problem with the input text file
in
>>>> 10 column format? If so, what is the specific fix that is
required?
>>>>
>>>> Thanks.
>>>>
>>>> R/
>>>> John
>>>>
>>>> Mr John W. Raby, Meteorologist
>>>> U.S. Army Research Laboratory
>>>> White Sands Missile Range, NM 88002
>>>> (575) 678-2004 DSN 258-2004
>>>> FAX (575) 678-1230 DSN 258-1230
>>>> Email: john.w.raby2.civ at mail.mil
>>>>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>>
>>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
------------------------------------------------
Subject: (UNCLASSIFIED)
From: Raby, John W USA CIV
Time: Thu Mar 28 15:20:59 2013
Classification: UNCLASSIFIED
Caveats: NONE
John -
I noticed something in the User's Guide for METV4.0.1. On page 3-15 it
gives
an example of the madis2nc usage and it shows the input is a text
file. This
seems to contradict what you were saying earlier about the input file
being a
netCDF file. Is this a typo?
Glad to help out on this new capability. MADIS has a LOT of data
besides just
surface mesonet data. If I had the capability to download the MADIS
netCDF
files containing Sfc METAR/SYNOPTIC, UPPER Air data, profiler data,
AIRCFT
observations, I could use MADIS2NC to format/convert it for immediate
use by
Point-Stat.
If you need some help with testing when the time comes, let me know.
Thanks.
R/
John
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Thursday, March 28, 2013 3:06 PM
To: Raby, John W CIV USARMY ARL (US)
Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T CIV
(US)
Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
John,
Thanks for your feedback on this. I've created a ticket in our
development
issue track system for this. We may or may not be able to include
this in
METv4.1 - it depends on how the remaining development tasks shake out.
But if
not in 4.1, we can add it to the next release.
Thanks,
John
On 03/28/2013 01:43 PM, Raby, John W USA CIV via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John -
>
> I think your idea of adding a capability to have the user specify
the
> domain by lat/long such as the .poly file to define a verification
> masking region for Point-Stat/Grid-Stat would be a nice enhancement.
> As far as I know, MADIS does not provide the capability to use a
> spatial subset to request their data in netCDF format.
>
> I did find a MADIS site
> https://madis-data.noaa.gov/public/sfcdumpguest.html
> which allows a user to specify a domain and then provides a text
file
> output as well as some other familiar formats, but not netCDF. See
the
> attached text file I downloaded from that site.
>
> Also having the capability to specify, by way of a given model
output
> grid, the grid over which to keep the observations per your other
> suggestion would be very nice. For example, if I am going to use
> Point-Stat to verify the WRF forecast output GRIB1 file
> (WRFPRS_d01.10), I would want to collect the observations for that
same
> gridded area and throw away the rest.
>
> If I had to choose one of those methods I would say go with the use
of
> the specified gridded data file such as the WRFPRS file.
>
> Thanks for your help with this.
>
> R/
> John
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Thursday, March 28, 2013 12:35 PM
> To: Raby, John W CIV USARMY ARL (US)
> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV
> (US)
> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>
> John,
>
> Currently there is no mechanism in place in madis2nc to spatially
> subset the observations. However, if that functionality is desired,
> it would be pretty straight-forward to add. We could do it by
having
> the user specify a lat/lon polyline or by specifying a gridded data
> file and only keep the obs that fall on that grid.
>
> John
>
> On 03/28/2013 11:26 AM, Raby, John W USA CIV via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> John -
>>
>> Thanks for that info. This is always useful to us.
>>
>> How does madis2nc crop the files to the area of interest? The files
>> we download from the MADIS database (.gz files) contain data for
all
>> of CONUS! We have to crop the data for the area of interest before
we
>> create the hourly text files in 10-col format.
>>
>> R/
>> John
>>
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Thursday, March 28, 2013 11:11 AM
>> To: Raby, John W CIV USARMY ARL (US)
>> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV
>> (US)
>> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>>
>> John,
>>
>> The madis2nc tool processes madis NetCDF files, not ascii ones.
>>
>> Regarding PREPBUFR, yes, NCEP applies QC to the data and assigns a
QC
>> value for each observation. All PB2NC is doing is passing NCEP's
QC
>> values along to the output file. The METv4.1 version of PB2NC will
>> now pass along this QC information. However, by default the QC
>> strings will not be used by Point-Stat and Ensemble-Stat. If you
do
>> want to select a subset of observations by their QC strings, you'd
>> have to set up the config file to list the ones you want.
>>
>> When we do the official release of METv4.1, we'll include a list of
>> release notes about these sorts of things.
>>
>> Thanks,
>> John
>>
>>
>> On 03/28/2013 10:55 AM, Raby, John W USA CIV via RT wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> John -
>>>
>>> Yes. Thanks for the info on that. Before we use ascii2nc to
convert
>>> MADIS ascii files to netCDF, we apply the QC filter of "99" or
>>> "Highest Possible"
>>> when we process the sfcdump.txt files we receive from the MADIS
>>> database. So, the QC has already been applied before running
ascii2nc.
>>> Appreciate the backward compatibility of these utilities as this
>>> saves us from modifying our program right now to convert to the
>>> 11-col format.
>>>
>>> I have not yet investigated how your new utility (madis2nc) might
>>> replace our MADIS processing program yet. I understand that it
>>> converts text files which are downloaded from the MADIS database
>>> into the required 10-col format. Does that utility convert the
>>> sfcdump.txt files direct to the required 10-col netCDF format?
>>>
>>> For PreBUFR data, there is no step that I can see between the
>>> downloading of the PrepBUFR files from NOAA and the generation of
>>> the netCDF files with pb2nc where a QC flag would be applied. I
can
>>> only assume that NOAA has applied/placed QC flags in the data when
>>> they post it on their download website. I have recently run pb2nc
>>> and I did not see any DEBUG dialog about the deprecation. I assume
I
>>> would have received the same dialog if there had not been any QC
>>> flags in the data when I ran pb2nc.
>>>
>>> Incidentally, we found a workaround for the local network security
>>> blocking of the NOAA ftp sites for MADIS and PrepBUFR. NOAA has
HTTP
>>> sites for both and we have switched our data collection processes
to
>>> collect from these sites. We no longer use ftp.
>>>
>>> R/
>>> John
>>>
>>>
>>> -----Original Message-----
>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> Sent: Thursday, March 28, 2013 10:23 AM
>>> To: Raby, John W CIV USARMY ARL (US)
>>> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
>>> CIV
>>> (US)
>>> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>>>
>>> John,
>>>
>>> In METv4.0, the NetCDF point observations files used by Point-Stat
>>> and Ensemble-Stat did not contain any quality control information.
>>> In METv4.1, we've added quality control information to those files
>>> so that Point-Stat and Ensemble-Stat can filter by them when doing
>>> verification.
>>>
>>> So the ascii2nc, pb2nc, and madis2nc tools have been enhanced for
>>> METv4.1 to write out the qc values they see in the input. So the
>>> 10-column ascii2nc format has changed to an 11-column format - the
>>> extra column being for qc info.
>>>
>>> However, the tools are still backward compatible. The METv4.1
>>> version of ascii2nc will still handle the 10-column format, but
>>> it'll just put missing values for the qc string in the output.
>>>
>>> Make sense?
>>>
>>> Thanks,
>>> John
>>>
>>>
>>>
>>> On 03/28/2013 08:27 AM, Raby, John W USA CIV via RT wrote:
>>>>
>>>> Thu Mar 28 08:27:01 2013: Request 60806 was acted upon.
>>>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>>>> Queue: met_help
>>>> Subject: (UNCLASSIFIED)
>>>> Owner: Nobody
>>>> Requestors: john.w.raby2.civ at mail.mil
>>>> Status: new
>>>> Ticket <URL:
>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806
>>>>>
>>>>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>> When using ASCII2NC from MET V4.0, I received the following DEBUG
dialog:
>>>>
>>>> "Found 10 col input file format deprecated in MET V4.1 - Consider
>>>> adding quality flag value"
>>>>
>>>> What does this mean? Is there a problem with the input text file
in
>>>> 10 column format? If so, what is the specific fix that is
required?
>>>>
>>>> Thanks.
>>>>
>>>> R/
>>>> John
>>>>
>>>> Mr John W. Raby, Meteorologist
>>>> U.S. Army Research Laboratory
>>>> White Sands Missile Range, NM 88002
>>>> (575) 678-2004 DSN 258-2004
>>>> FAX (575) 678-1230 DSN 258-1230
>>>> Email: john.w.raby2.civ at mail.mil
>>>>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>>
>>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
From: John Halley Gotway
Time: Thu Mar 28 15:40:04 2013
John,
Yes, that example on page 3-15 is incorrect. I'll get that fixed for
the next release.
You're right, there are several different "flavors" of madis data.
Currently, we have functionality in the tool to decode the following
types:
metar, raob, profiler or maritime
Support for additional madis types can be added as time/funding allow.
Thanks,
John
On 03/28/2013 03:20 PM, Raby, John W USA CIV via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John -
>
> I noticed something in the User's Guide for METV4.0.1. On page 3-15
it gives
> an example of the madis2nc usage and it shows the input is a text
file. This
> seems to contradict what you were saying earlier about the input
file being a
> netCDF file. Is this a typo?
>
> Glad to help out on this new capability. MADIS has a LOT of data
besides just
> surface mesonet data. If I had the capability to download the MADIS
netCDF
> files containing Sfc METAR/SYNOPTIC, UPPER Air data, profiler data,
AIRCFT
> observations, I could use MADIS2NC to format/convert it for
immediate use by
> Point-Stat.
>
> If you need some help with testing when the time comes, let me know.
>
>
>
> Thanks.
>
> R/
> John
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Thursday, March 28, 2013 3:06 PM
> To: Raby, John W CIV USARMY ARL (US)
> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV (US)
> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>
> John,
>
> Thanks for your feedback on this. I've created a ticket in our
development
> issue track system for this. We may or may not be able to include
this in
> METv4.1 - it depends on how the remaining development tasks shake
out. But if
> not in 4.1, we can add it to the next release.
>
> Thanks,
> John
>
> On 03/28/2013 01:43 PM, Raby, John W USA CIV via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> John -
>>
>> I think your idea of adding a capability to have the user specify
the
>> domain by lat/long such as the .poly file to define a verification
>> masking region for Point-Stat/Grid-Stat would be a nice
enhancement.
>> As far as I know, MADIS does not provide the capability to use a
>> spatial subset to request their data in netCDF format.
>>
>> I did find a MADIS site
>> https://madis-data.noaa.gov/public/sfcdumpguest.html
>> which allows a user to specify a domain and then provides a text
file
>> output as well as some other familiar formats, but not netCDF. See
the
>> attached text file I downloaded from that site.
>>
>> Also having the capability to specify, by way of a given model
output
>> grid, the grid over which to keep the observations per your other
>> suggestion would be very nice. For example, if I am going to use
>> Point-Stat to verify the WRF forecast output GRIB1 file
>> (WRFPRS_d01.10), I would want to collect the observations for that
same
>> gridded area and throw away the rest.
>>
>> If I had to choose one of those methods I would say go with the use
of
>> the specified gridded data file such as the WRFPRS file.
>>
>> Thanks for your help with this.
>>
>> R/
>> John
>>
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Thursday, March 28, 2013 12:35 PM
>> To: Raby, John W CIV USARMY ARL (US)
>> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV
>> (US)
>> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>>
>> John,
>>
>> Currently there is no mechanism in place in madis2nc to spatially
>> subset the observations. However, if that functionality is
desired,
>> it would be pretty straight-forward to add. We could do it by
having
>> the user specify a lat/lon polyline or by specifying a gridded data
>> file and only keep the obs that fall on that grid.
>>
>> John
>>
>> On 03/28/2013 11:26 AM, Raby, John W USA CIV via RT wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> John -
>>>
>>> Thanks for that info. This is always useful to us.
>>>
>>> How does madis2nc crop the files to the area of interest? The
files
>>> we download from the MADIS database (.gz files) contain data for
all
>>> of CONUS! We have to crop the data for the area of interest before
we
>>> create the hourly text files in 10-col format.
>>>
>>> R/
>>> John
>>>
>>>
>>> -----Original Message-----
>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> Sent: Thursday, March 28, 2013 11:11 AM
>>> To: Raby, John W CIV USARMY ARL (US)
>>> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV
>>> (US)
>>> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>>>
>>> John,
>>>
>>> The madis2nc tool processes madis NetCDF files, not ascii ones.
>>>
>>> Regarding PREPBUFR, yes, NCEP applies QC to the data and assigns a
QC
>>> value for each observation. All PB2NC is doing is passing NCEP's
QC
>>> values along to the output file. The METv4.1 version of PB2NC
will
>>> now pass along this QC information. However, by default the QC
>>> strings will not be used by Point-Stat and Ensemble-Stat. If you
do
>>> want to select a subset of observations by their QC strings, you'd
>>> have to set up the config file to list the ones you want.
>>>
>>> When we do the official release of METv4.1, we'll include a list
of
>>> release notes about these sorts of things.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On 03/28/2013 10:55 AM, Raby, John W USA CIV via RT wrote:
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>> John -
>>>>
>>>> Yes. Thanks for the info on that. Before we use ascii2nc to
convert
>>>> MADIS ascii files to netCDF, we apply the QC filter of "99" or
>>>> "Highest Possible"
>>>> when we process the sfcdump.txt files we receive from the MADIS
>>>> database. So, the QC has already been applied before running
ascii2nc.
>>>> Appreciate the backward compatibility of these utilities as this
>>>> saves us from modifying our program right now to convert to the
>>>> 11-col format.
>>>>
>>>> I have not yet investigated how your new utility (madis2nc) might
>>>> replace our MADIS processing program yet. I understand that it
>>>> converts text files which are downloaded from the MADIS database
>>>> into the required 10-col format. Does that utility convert the
>>>> sfcdump.txt files direct to the required 10-col netCDF format?
>>>>
>>>> For PreBUFR data, there is no step that I can see between the
>>>> downloading of the PrepBUFR files from NOAA and the generation of
>>>> the netCDF files with pb2nc where a QC flag would be applied. I
can
>>>> only assume that NOAA has applied/placed QC flags in the data
when
>>>> they post it on their download website. I have recently run pb2nc
>>>> and I did not see any DEBUG dialog about the deprecation. I
assume I
>>>> would have received the same dialog if there had not been any QC
>>>> flags in the data when I ran pb2nc.
>>>>
>>>> Incidentally, we found a workaround for the local network
security
>>>> blocking of the NOAA ftp sites for MADIS and PrepBUFR. NOAA has
HTTP
>>>> sites for both and we have switched our data collection processes
to
>>>> collect from these sites. We no longer use ftp.
>>>>
>>>> R/
>>>> John
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>>> Sent: Thursday, March 28, 2013 10:23 AM
>>>> To: Raby, John W CIV USARMY ARL (US)
>>>> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
>>>> CIV
>>>> (US)
>>>> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>>>>
>>>> John,
>>>>
>>>> In METv4.0, the NetCDF point observations files used by Point-
Stat
>>>> and Ensemble-Stat did not contain any quality control
information.
>>>> In METv4.1, we've added quality control information to those
files
>>>> so that Point-Stat and Ensemble-Stat can filter by them when
doing
>>>> verification.
>>>>
>>>> So the ascii2nc, pb2nc, and madis2nc tools have been enhanced for
>>>> METv4.1 to write out the qc values they see in the input. So the
>>>> 10-column ascii2nc format has changed to an 11-column format -
the
>>>> extra column being for qc info.
>>>>
>>>> However, the tools are still backward compatible. The METv4.1
>>>> version of ascii2nc will still handle the 10-column format, but
>>>> it'll just put missing values for the qc string in the output.
>>>>
>>>> Make sense?
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>>
>>>> On 03/28/2013 08:27 AM, Raby, John W USA CIV via RT wrote:
>>>>>
>>>>> Thu Mar 28 08:27:01 2013: Request 60806 was acted upon.
>>>>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>>>>> Queue: met_help
>>>>> Subject: (UNCLASSIFIED)
>>>>> Owner: Nobody
>>>>> Requestors: john.w.raby2.civ at mail.mil
>>>>> Status: new
>>>>> Ticket <URL:
>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806
>>>>>>
>>>>>
>>>>>
>>>>> Classification: UNCLASSIFIED
>>>>> Caveats: NONE
>>>>>
>>>>> When using ASCII2NC from MET V4.0, I received the following
DEBUG dialog:
>>>>>
>>>>> "Found 10 col input file format deprecated in MET V4.1 -
Consider
>>>>> adding quality flag value"
>>>>>
>>>>> What does this mean? Is there a problem with the input text file
in
>>>>> 10 column format? If so, what is the specific fix that is
required?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> R/
>>>>> John
>>>>>
>>>>> Mr John W. Raby, Meteorologist
>>>>> U.S. Army Research Laboratory
>>>>> White Sands Missile Range, NM 88002
>>>>> (575) 678-2004 DSN 258-2004
>>>>> FAX (575) 678-1230 DSN 258-1230
>>>>> Email: john.w.raby2.civ at mail.mil
>>>>>
>>>>>
>>>>> Classification: UNCLASSIFIED
>>>>> Caveats: NONE
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>>
>>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
------------------------------------------------
Subject: (UNCLASSIFIED)
From: Raby, John W USA CIV
Time: Thu Mar 28 15:56:45 2013
Classification: UNCLASSIFIED
Caveats: NONE
John -
Thanks for all the great feedback and your support for future
capabilities.
Let me know if I can help in any way.
Happy Easter!
R/
John
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Thursday, March 28, 2013 3:40 PM
To: Raby, John W CIV USARMY ARL (US)
Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T CIV
(US)
Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
John,
Yes, that example on page 3-15 is incorrect. I'll get that fixed for
the next
release.
You're right, there are several different "flavors" of madis data.
Currently,
we have functionality in the tool to decode the following types:
metar, raob, profiler or maritime
Support for additional madis types can be added as time/funding allow.
Thanks,
John
On 03/28/2013 03:20 PM, Raby, John W USA CIV via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John -
>
> I noticed something in the User's Guide for METV4.0.1. On page 3-15
it
> gives an example of the madis2nc usage and it shows the input is a
> text file. This seems to contradict what you were saying earlier
about
> the input file being a netCDF file. Is this a typo?
>
> Glad to help out on this new capability. MADIS has a LOT of data
> besides just surface mesonet data. If I had the capability to
download
> the MADIS netCDF files containing Sfc METAR/SYNOPTIC, UPPER Air
data,
> profiler data, AIRCFT observations, I could use MADIS2NC to
> format/convert it for immediate use by Point-Stat.
>
> If you need some help with testing when the time comes, let me know.
>
>
>
> Thanks.
>
> R/
> John
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Thursday, March 28, 2013 3:06 PM
> To: Raby, John W CIV USARMY ARL (US)
> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV
> (US)
> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>
> John,
>
> Thanks for your feedback on this. I've created a ticket in our
> development issue track system for this. We may or may not be able
to
> include this in
> METv4.1 - it depends on how the remaining development tasks shake
out.
> But if not in 4.1, we can add it to the next release.
>
> Thanks,
> John
>
> On 03/28/2013 01:43 PM, Raby, John W USA CIV via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> John -
>>
>> I think your idea of adding a capability to have the user specify
the
>> domain by lat/long such as the .poly file to define a verification
>> masking region for Point-Stat/Grid-Stat would be a nice
enhancement.
>> As far as I know, MADIS does not provide the capability to use a
>> spatial subset to request their data in netCDF format.
>>
>> I did find a MADIS site
>> https://madis-data.noaa.gov/public/sfcdumpguest.html
>> which allows a user to specify a domain and then provides a text
file
>> output as well as some other familiar formats, but not netCDF. See
>> the attached text file I downloaded from that site.
>>
>> Also having the capability to specify, by way of a given model
output
>> grid, the grid over which to keep the observations per your other
>> suggestion would be very nice. For example, if I am going to use
>> Point-Stat to verify the WRF forecast output GRIB1 file
>> (WRFPRS_d01.10), I would want to collect the observations for that
>> same gridded area and throw away the rest.
>>
>> If I had to choose one of those methods I would say go with the use
>> of the specified gridded data file such as the WRFPRS file.
>>
>> Thanks for your help with this.
>>
>> R/
>> John
>>
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Thursday, March 28, 2013 12:35 PM
>> To: Raby, John W CIV USARMY ARL (US)
>> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
CIV
>> (US)
>> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>>
>> John,
>>
>> Currently there is no mechanism in place in madis2nc to spatially
>> subset the observations. However, if that functionality is
desired,
>> it would be pretty straight-forward to add. We could do it by
having
>> the user specify a lat/lon polyline or by specifying a gridded data
>> file and only keep the obs that fall on that grid.
>>
>> John
>>
>> On 03/28/2013 11:26 AM, Raby, John W USA CIV via RT wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> John -
>>>
>>> Thanks for that info. This is always useful to us.
>>>
>>> How does madis2nc crop the files to the area of interest? The
files
>>> we download from the MADIS database (.gz files) contain data for
all
>>> of CONUS! We have to crop the data for the area of interest before
>>> we create the hourly text files in 10-col format.
>>>
>>> R/
>>> John
>>>
>>>
>>> -----Original Message-----
>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> Sent: Thursday, March 28, 2013 11:11 AM
>>> To: Raby, John W CIV USARMY ARL (US)
>>> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
>>> CIV
>>> (US)
>>> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>>>
>>> John,
>>>
>>> The madis2nc tool processes madis NetCDF files, not ascii ones.
>>>
>>> Regarding PREPBUFR, yes, NCEP applies QC to the data and assigns a
>>> QC value for each observation. All PB2NC is doing is passing
NCEP's
>>> QC values along to the output file. The METv4.1 version of PB2NC
>>> will now pass along this QC information. However, by default the
QC
>>> strings will not be used by Point-Stat and Ensemble-Stat. If you
do
>>> want to select a subset of observations by their QC strings, you'd
>>> have to set up the config file to list the ones you want.
>>>
>>> When we do the official release of METv4.1, we'll include a list
of
>>> release notes about these sorts of things.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On 03/28/2013 10:55 AM, Raby, John W USA CIV via RT wrote:
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806 >
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>> John -
>>>>
>>>> Yes. Thanks for the info on that. Before we use ascii2nc to
convert
>>>> MADIS ascii files to netCDF, we apply the QC filter of "99" or
>>>> "Highest Possible"
>>>> when we process the sfcdump.txt files we receive from the MADIS
>>>> database. So, the QC has already been applied before running
ascii2nc.
>>>> Appreciate the backward compatibility of these utilities as this
>>>> saves us from modifying our program right now to convert to the
>>>> 11-col format.
>>>>
>>>> I have not yet investigated how your new utility (madis2nc) might
>>>> replace our MADIS processing program yet. I understand that it
>>>> converts text files which are downloaded from the MADIS database
>>>> into the required 10-col format. Does that utility convert the
>>>> sfcdump.txt files direct to the required 10-col netCDF format?
>>>>
>>>> For PreBUFR data, there is no step that I can see between the
>>>> downloading of the PrepBUFR files from NOAA and the generation of
>>>> the netCDF files with pb2nc where a QC flag would be applied. I
can
>>>> only assume that NOAA has applied/placed QC flags in the data
when
>>>> they post it on their download website. I have recently run pb2nc
>>>> and I did not see any DEBUG dialog about the deprecation. I
assume
>>>> I would have received the same dialog if there had not been any
QC
>>>> flags in the data when I ran pb2nc.
>>>>
>>>> Incidentally, we found a workaround for the local network
security
>>>> blocking of the NOAA ftp sites for MADIS and PrepBUFR. NOAA has
>>>> HTTP sites for both and we have switched our data collection
>>>> processes to collect from these sites. We no longer use ftp.
>>>>
>>>> R/
>>>> John
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>>> Sent: Thursday, March 28, 2013 10:23 AM
>>>> To: Raby, John W CIV USARMY ARL (US)
>>>> Cc: Vaucher, Gail T CIV (US); rflanigan at q.com; Flanigan, Robert T
>>>> CIV
>>>> (US)
>>>> Subject: Re: [rt.rap.ucar.edu #60806] (UNCLASSIFIED)
>>>>
>>>> John,
>>>>
>>>> In METv4.0, the NetCDF point observations files used by Point-
Stat
>>>> and Ensemble-Stat did not contain any quality control
information.
>>>> In METv4.1, we've added quality control information to those
files
>>>> so that Point-Stat and Ensemble-Stat can filter by them when
doing
>>>> verification.
>>>>
>>>> So the ascii2nc, pb2nc, and madis2nc tools have been enhanced for
>>>> METv4.1 to write out the qc values they see in the input. So the
>>>> 10-column ascii2nc format has changed to an 11-column format -
the
>>>> extra column being for qc info.
>>>>
>>>> However, the tools are still backward compatible. The METv4.1
>>>> version of ascii2nc will still handle the 10-column format, but
>>>> it'll just put missing values for the qc string in the output.
>>>>
>>>> Make sense?
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>>
>>>> On 03/28/2013 08:27 AM, Raby, John W USA CIV via RT wrote:
>>>>>
>>>>> Thu Mar 28 08:27:01 2013: Request 60806 was acted upon.
>>>>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>>>>> Queue: met_help
>>>>> Subject: (UNCLASSIFIED)
>>>>> Owner: Nobody
>>>>> Requestors: john.w.raby2.civ at mail.mil
>>>>> Status: new
>>>>> Ticket <URL:
>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=60806
>>>>>>
>>>>>
>>>>>
>>>>> Classification: UNCLASSIFIED
>>>>> Caveats: NONE
>>>>>
>>>>> When using ASCII2NC from MET V4.0, I received the following
DEBUG
>>>>> dialog:
>>>>>
>>>>> "Found 10 col input file format deprecated in MET V4.1 -
Consider
>>>>> adding quality flag value"
>>>>>
>>>>> What does this mean? Is there a problem with the input text file
>>>>> in
>>>>> 10 column format? If so, what is the specific fix that is
required?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> R/
>>>>> John
>>>>>
>>>>> Mr John W. Raby, Meteorologist
>>>>> U.S. Army Research Laboratory
>>>>> White Sands Missile Range, NM 88002
>>>>> (575) 678-2004 DSN 258-2004
>>>>> FAX (575) 678-1230 DSN 258-1230
>>>>> Email: john.w.raby2.civ at mail.mil
>>>>>
>>>>>
>>>>> Classification: UNCLASSIFIED
>>>>> Caveats: NONE
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>>
>>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------
More information about the Met_help
mailing list