[Met_help] [rt.rap.ucar.edu #84736] History for Possible incorrect NetCDF lat/lon encoding from MET v7.0 docker container regrid_data_plane
John Halley Gotway via RT
met_help at ucar.edu
Fri Apr 13 10:40:19 MDT 2018
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Good morning,
I am currently setting up software to run MET to produce grids to view in a
viewer. I have one set of processing running on WCOSS utilizing MET v6.0
which correctly decodes the NetCDF files produced by regrid_data_plane, but
I'm having troubles reproducing the results using the MET v7.0 docker
container using the same file. The file in question is an NDFD QPF forecast
for 01/10/2018 00z, 6 hour lead time, and is originally in GRIB2 format.
I ran a script through the 7.0 docker container to produce a NetCDF file as
a result of regrid_data_plane. The expected NetCDF file was produced with
the expected dimensions (snippet below). The input file was an NDFD
forecast that I have successfully tested on WCOSS using MET v6.0.
However, it appears that the encoding of the lat/lon points ends 1 value
too early and wraps back around to 1, resulting in 2 longitude values for
the upper left corner point.
Upper left lon at point 1,$max_lat
ncdump -v lon -f f ndfdconc2p518011000qpf06f006 | grep "lon(1,1377)"
-130.1034, // lon(1,1377)
-60.88556; // lon(1,1377)
Also, see part of a longitude dump below (ncdump -v lon -f
ndfdconc2p518011000qpf06f006 )
Trying to pull out the values of the lower-right corner (using max_lon)
yields null values due to lon value 2145 being unavailable. This is causing
me not to be able to correctly pull out the corner points to convert these
grids for viewing. This same processing is running properly on WCOSS using
MET v6.0 (not docker container).
Let me know if there's any more I can provide to assistance in resolving
this.
Thank you for your help!
Dana
--
Dana Strom
Technical Lead, AceInfo Solutions
Meteorological Development Laboratory (NWS)
Phone: 301-427-9451
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Possible incorrect NetCDF lat/lon encoding from MET v7.0 docker container regrid_data_plane
From: dana.strom at noaa.gov
Time: Thu Apr 12 11:39:14 2018
After a little more digging and I think the issue might be the version
of
ncdump that I'm utilizing to decode the netcdf file. I'm currently
using
ncdump v4.3.3.1 on this process that isn't reading the netcdf file
properly.
My processing WCOSS currently utilizes NetCDF 4.2 module
(/usrx/local/NetCDF/4.2/serial/bin/ncdump).
Do you have any thoughts about why ncdump would be interpreting them
differently?
On Thu, Apr 12, 2018 at 11:51 AM, met_help at ucar.edu via RT <
met_help at ucar.edu> wrote:
> THE MET SUPPORT STAFF WILL HAVE LIMITED AVAILABILITY DURING THE
WINTER
> HOLIDAYS FROM 12/18/2017 THROUGH 1/1/2018 AND RESPONSES MAY BE
DELAYED.
>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "Possible incorrect NetCDF lat/lon encoding from MET v7.0
docker
> container regrid_data_plane",
> 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 #84736].
>
> Please include the string:
>
> [rt.rap.ucar.edu #84736]
>
> in the subject line of all future correspondence about this issue.
To do
> so,
> you may reply to this message.
>
> For more information, please see:
>
> MET Online Tutorial:
>
https://www.dtcenter.org/met/users/support/online_tutorial/index.php
>
> MET Users Guide:
> https://www.dtcenter.org/met/users/docs/overview.php
>
> MET FAQs:
> https://www.dtcenter.org/met/users/support/faqs/index.php
>
> MET-Help Email Archive:
> http://mailman.ucar.edu/pipermail/met_help
>
> Thank you,
> met_help at ucar.edu
>
>
-------------------------------------------------------------------------
> Good morning,
>
> I am currently setting up software to run MET to produce grids to
view in a
> viewer. I have one set of processing running on WCOSS utilizing MET
v6.0
> which correctly decodes the NetCDF files produced by
regrid_data_plane, but
> I'm having troubles reproducing the results using the MET v7.0
docker
> container using the same file. The file in question is an NDFD QPF
forecast
> for 01/10/2018 00z, 6 hour lead time, and is originally in GRIB2
format.
>
> I ran a script through the 7.0 docker container to produce a NetCDF
file as
> a result of regrid_data_plane. The expected NetCDF file was produced
with
> the expected dimensions (snippet below). The input file was an NDFD
> forecast that I have successfully tested on WCOSS using MET v6.0.
>
>
>
>
> However, it appears that the encoding of the lat/lon points ends 1
value
> too early and wraps back around to 1, resulting in 2 longitude
values for
> the upper left corner point.
>
> Upper left lon at point 1,$max_lat
> ncdump -v lon -f f ndfdconc2p518011000qpf06f006 | grep "lon(1,1377)"
> -130.1034, // lon(1,1377)
> -60.88556; // lon(1,1377)
>
> Also, see part of a longitude dump below (ncdump -v lon -f
> ndfdconc2p518011000qpf06f006 )
>
>
>
>
> Trying to pull out the values of the lower-right corner (using
max_lon)
> yields null values due to lon value 2145 being unavailable. This is
causing
> me not to be able to correctly pull out the corner points to convert
these
> grids for viewing. This same processing is running properly on WCOSS
using
> MET v6.0 (not docker container).
>
> Let me know if there's any more I can provide to assistance in
resolving
> this.
>
> Thank you for your help!
> Dana
>
> --
> Dana Strom
>
> Technical Lead, AceInfo Solutions
>
> Meteorological Development Laboratory (NWS)
>
> Phone: 301-427-9451
>
>
--
Dana Strom
Technical Lead, AceInfo Solutions
Meteorological Development Laboratory (NWS)
Phone: 301-427-9451
------------------------------------------------
Subject: Possible incorrect NetCDF lat/lon encoding from MET v7.0 docker container regrid_data_plane
From: John Halley Gotway
Time: Fri Apr 13 10:14:40 2018
Hi Dana,
I see that you have some questions about versions of ncdump on WCOSS
and
comparing the output of met-6.0 to Dockerized met-7.0.
I'm having a difficult time following all the details. However, my
colleague, Julie Prestopnik, does have access to WCOSS. Could your
please
clarify your question a bit?
Please send us a list of commands Julie could cut-and-paste on WCOSS
that
demonstrate the discrepancy. Hopefully, once we see exactly what
you're
seeing, we may be able to give some helpful suggestions.
Thanks,
John
On Thu, Apr 12, 2018 at 11:39 AM, dana.strom at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=84736 >
>
> After a little more digging and I think the issue might be the
version of
> ncdump that I'm utilizing to decode the netcdf file. I'm currently
using
> ncdump v4.3.3.1 on this process that isn't reading the netcdf file
> properly.
>
> My processing WCOSS currently utilizes NetCDF 4.2 module
> (/usrx/local/NetCDF/4.2/serial/bin/ncdump).
>
> Do you have any thoughts about why ncdump would be interpreting them
> differently?
>
> On Thu, Apr 12, 2018 at 11:51 AM, met_help at ucar.edu via RT <
> met_help at ucar.edu> wrote:
>
> > THE MET SUPPORT STAFF WILL HAVE LIMITED AVAILABILITY DURING THE
WINTER
> > HOLIDAYS FROM 12/18/2017 THROUGH 1/1/2018 AND RESPONSES MAY BE
DELAYED.
> >
> > Greetings,
> >
> > This message has been automatically generated in response to the
> > creation of a trouble ticket regarding:
> > "Possible incorrect NetCDF lat/lon encoding from MET v7.0
docker
> > container regrid_data_plane",
> > 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 #84736].
> >
> > Please include the string:
> >
> > [rt.rap.ucar.edu #84736]
> >
> > in the subject line of all future correspondence about this issue.
To do
> > so,
> > you may reply to this message.
> >
> > For more information, please see:
> >
> > MET Online Tutorial:
> >
https://www.dtcenter.org/met/users/support/online_tutorial/index.php
> >
> > MET Users Guide:
> > https://www.dtcenter.org/met/users/docs/overview.php
> >
> > MET FAQs:
> > https://www.dtcenter.org/met/users/support/faqs/index.php
> >
> > MET-Help Email Archive:
> > http://mailman.ucar.edu/pipermail/met_help
> >
> > Thank you,
> > met_help at ucar.edu
> >
> > ------------------------------------------------------------
> -------------
> > Good morning,
> >
> > I am currently setting up software to run MET to produce grids to
view
> in a
> > viewer. I have one set of processing running on WCOSS utilizing
MET v6.0
> > which correctly decodes the NetCDF files produced by
regrid_data_plane,
> but
> > I'm having troubles reproducing the results using the MET v7.0
docker
> > container using the same file. The file in question is an NDFD QPF
> forecast
> > for 01/10/2018 00z, 6 hour lead time, and is originally in GRIB2
format.
> >
> > I ran a script through the 7.0 docker container to produce a
NetCDF file
> as
> > a result of regrid_data_plane. The expected NetCDF file was
produced with
> > the expected dimensions (snippet below). The input file was an
NDFD
> > forecast that I have successfully tested on WCOSS using MET v6.0.
> >
> >
> >
> >
> > However, it appears that the encoding of the lat/lon points ends 1
value
> > too early and wraps back around to 1, resulting in 2 longitude
values for
> > the upper left corner point.
> >
> > Upper left lon at point 1,$max_lat
> > ncdump -v lon -f f ndfdconc2p518011000qpf06f006 | grep
"lon(1,1377)"
> > -130.1034, // lon(1,1377)
> > -60.88556; // lon(1,1377)
> >
> > Also, see part of a longitude dump below (ncdump -v lon -f
> > ndfdconc2p518011000qpf06f006 )
> >
> >
> >
> >
> > Trying to pull out the values of the lower-right corner (using
max_lon)
> > yields null values due to lon value 2145 being unavailable. This
is
> causing
> > me not to be able to correctly pull out the corner points to
convert
> these
> > grids for viewing. This same processing is running properly on
WCOSS
> using
> > MET v6.0 (not docker container).
> >
> > Let me know if there's any more I can provide to assistance in
resolving
> > this.
> >
> > Thank you for your help!
> > Dana
> >
> > --
> > Dana Strom
> >
> > Technical Lead, AceInfo Solutions
> >
> > Meteorological Development Laboratory (NWS)
> >
> > Phone: 301-427-9451
> >
> >
>
>
> --
> Dana Strom
>
> Technical Lead, AceInfo Solutions
>
> Meteorological Development Laboratory (NWS)
>
> Phone: 301-427-9451
>
>
------------------------------------------------
Subject: Possible incorrect NetCDF lat/lon encoding from MET v7.0 docker container regrid_data_plane
From: dana.strom at noaa.gov
Time: Fri Apr 13 10:33:38 2018
Hi John,
I apologize for the confusion (I was also very confused as to why this
was
happening). Admittedly I didn't go down the whole far enough to snuff
out
the issue before sending it to you. After some testing, I don't think
the
problem lies in MET. I believe there is a bug in netcdf version
4.3.3.1
(the version of netcdf we have on our platform, outside of the
container)
with how ncdump reads the NetCDF file. I was able to test my script
utilizing the version of ncdump within the 7.0 container (netcdf
library
version 4.4.1.1) and there was no error in reading the same NetCDF
output
file.
I don't believe I have any further questions. Thank you much for your
time!
Have a great weekend,
Dana
On Fri, Apr 13, 2018 at 12:14 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Hi Dana,
>
> I see that you have some questions about versions of ncdump on WCOSS
and
> comparing the output of met-6.0 to Dockerized met-7.0.
>
> I'm having a difficult time following all the details. However, my
> colleague, Julie Prestopnik, does have access to WCOSS. Could your
please
> clarify your question a bit?
>
> Please send us a list of commands Julie could cut-and-paste on WCOSS
that
> demonstrate the discrepancy. Hopefully, once we see exactly what
you're
> seeing, we may be able to give some helpful suggestions.
>
> Thanks,
> John
>
>
>
> On Thu, Apr 12, 2018 at 11:39 AM, dana.strom at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=84736 >
> >
> > After a little more digging and I think the issue might be the
version of
> > ncdump that I'm utilizing to decode the netcdf file. I'm currently
using
> > ncdump v4.3.3.1 on this process that isn't reading the netcdf file
> > properly.
> >
> > My processing WCOSS currently utilizes NetCDF 4.2 module
> > (/usrx/local/NetCDF/4.2/serial/bin/ncdump).
> >
> > Do you have any thoughts about why ncdump would be interpreting
them
> > differently?
> >
> > On Thu, Apr 12, 2018 at 11:51 AM, met_help at ucar.edu via RT <
> > met_help at ucar.edu> wrote:
> >
> > > THE MET SUPPORT STAFF WILL HAVE LIMITED AVAILABILITY DURING THE
WINTER
> > > HOLIDAYS FROM 12/18/2017 THROUGH 1/1/2018 AND RESPONSES MAY BE
DELAYED.
> > >
> > > Greetings,
> > >
> > > This message has been automatically generated in response to the
> > > creation of a trouble ticket regarding:
> > > "Possible incorrect NetCDF lat/lon encoding from MET
v7.0
> docker
> > > container regrid_data_plane",
> > > 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 #84736].
> > >
> > > Please include the string:
> > >
> > > [rt.rap.ucar.edu #84736]
> > >
> > > in the subject line of all future correspondence about this
issue. To
> do
> > > so,
> > > you may reply to this message.
> > >
> > > For more information, please see:
> > >
> > > MET Online Tutorial:
> > > https://www.dtcenter.org/met/users/support/online_tutorial/
> index.php
> > >
> > > MET Users Guide:
> > > https://www.dtcenter.org/met/users/docs/overview.php
> > >
> > > MET FAQs:
> > > https://www.dtcenter.org/met/users/support/faqs/index.php
> > >
> > > MET-Help Email Archive:
> > > http://mailman.ucar.edu/pipermail/met_help
> > >
> > > Thank you,
> > > met_help at ucar.edu
> > >
> > > ------------------------------------------------------------
> > -------------
> > > Good morning,
> > >
> > > I am currently setting up software to run MET to produce grids
to view
> > in a
> > > viewer. I have one set of processing running on WCOSS utilizing
MET
> v6.0
> > > which correctly decodes the NetCDF files produced by
regrid_data_plane,
> > but
> > > I'm having troubles reproducing the results using the MET v7.0
docker
> > > container using the same file. The file in question is an NDFD
QPF
> > forecast
> > > for 01/10/2018 00z, 6 hour lead time, and is originally in GRIB2
> format.
> > >
> > > I ran a script through the 7.0 docker container to produce a
NetCDF
> file
> > as
> > > a result of regrid_data_plane. The expected NetCDF file was
produced
> with
> > > the expected dimensions (snippet below). The input file was an
NDFD
> > > forecast that I have successfully tested on WCOSS using MET
v6.0.
> > >
> > >
> > >
> > >
> > > However, it appears that the encoding of the lat/lon points ends
1
> value
> > > too early and wraps back around to 1, resulting in 2 longitude
values
> for
> > > the upper left corner point.
> > >
> > > Upper left lon at point 1,$max_lat
> > > ncdump -v lon -f f ndfdconc2p518011000qpf06f006 | grep
"lon(1,1377)"
> > > -130.1034, // lon(1,1377)
> > > -60.88556; // lon(1,1377)
> > >
> > > Also, see part of a longitude dump below (ncdump -v lon -f
> > > ndfdconc2p518011000qpf06f006 )
> > >
> > >
> > >
> > >
> > > Trying to pull out the values of the lower-right corner (using
max_lon)
> > > yields null values due to lon value 2145 being unavailable. This
is
> > causing
> > > me not to be able to correctly pull out the corner points to
convert
> > these
> > > grids for viewing. This same processing is running properly on
WCOSS
> > using
> > > MET v6.0 (not docker container).
> > >
> > > Let me know if there's any more I can provide to assistance in
> resolving
> > > this.
> > >
> > > Thank you for your help!
> > > Dana
> > >
> > > --
> > > Dana Strom
> > >
> > > Technical Lead, AceInfo Solutions
> > >
> > > Meteorological Development Laboratory (NWS)
> > >
> > > Phone: 301-427-9451
> > >
> > >
> >
> >
> > --
> > Dana Strom
> >
> > Technical Lead, AceInfo Solutions
> >
> > Meteorological Development Laboratory (NWS)
> >
> > Phone: 301-427-9451
> >
> >
>
>
--
Dana Strom
Technical Lead, AceInfo Solutions
Meteorological Development Laboratory (NWS)
Phone: 301-427-9451
------------------------------------------------
Subject: Possible incorrect NetCDF lat/lon encoding from MET v7.0 docker container regrid_data_plane
From: John Halley Gotway
Time: Fri Apr 13 10:40:05 2018
Dana,
Great, glad you were able to rectify it! I can commiserate though...
while
containers make some things easier... they complicate others. I need
to
keep track of whether I'm inside/outside the container and what
versions of
somewhere I'm using in both places.
I'll go ahead and resolve this ticket. But let us know what other
issues
or questions arise.
Thanks,
John
On Fri, Apr 13, 2018 at 10:33 AM, dana.strom at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=84736 >
>
> Hi John,
>
> I apologize for the confusion (I was also very confused as to why
this was
> happening). Admittedly I didn't go down the whole far enough to
snuff out
> the issue before sending it to you. After some testing, I don't
think the
> problem lies in MET. I believe there is a bug in netcdf version
4.3.3.1
> (the version of netcdf we have on our platform, outside of the
container)
> with how ncdump reads the NetCDF file. I was able to test my script
> utilizing the version of ncdump within the 7.0 container (netcdf
library
> version 4.4.1.1) and there was no error in reading the same NetCDF
output
> file.
>
> I don't believe I have any further questions. Thank you much for
your time!
>
> Have a great weekend,
> Dana
>
>
> On Fri, Apr 13, 2018 at 12:14 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Hi Dana,
> >
> > I see that you have some questions about versions of ncdump on
WCOSS and
> > comparing the output of met-6.0 to Dockerized met-7.0.
> >
> > I'm having a difficult time following all the details. However,
my
> > colleague, Julie Prestopnik, does have access to WCOSS. Could
your
> please
> > clarify your question a bit?
> >
> > Please send us a list of commands Julie could cut-and-paste on
WCOSS that
> > demonstrate the discrepancy. Hopefully, once we see exactly what
you're
> > seeing, we may be able to give some helpful suggestions.
> >
> > Thanks,
> > John
> >
> >
> >
> > On Thu, Apr 12, 2018 at 11:39 AM, dana.strom at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=84736 >
> > >
> > > After a little more digging and I think the issue might be the
version
> of
> > > ncdump that I'm utilizing to decode the netcdf file. I'm
currently
> using
> > > ncdump v4.3.3.1 on this process that isn't reading the netcdf
file
> > > properly.
> > >
> > > My processing WCOSS currently utilizes NetCDF 4.2 module
> > > (/usrx/local/NetCDF/4.2/serial/bin/ncdump).
> > >
> > > Do you have any thoughts about why ncdump would be interpreting
them
> > > differently?
> > >
> > > On Thu, Apr 12, 2018 at 11:51 AM, met_help at ucar.edu via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > THE MET SUPPORT STAFF WILL HAVE LIMITED AVAILABILITY DURING
THE
> WINTER
> > > > HOLIDAYS FROM 12/18/2017 THROUGH 1/1/2018 AND RESPONSES MAY BE
> DELAYED.
> > > >
> > > > Greetings,
> > > >
> > > > This message has been automatically generated in response to
the
> > > > creation of a trouble ticket regarding:
> > > > "Possible incorrect NetCDF lat/lon encoding from MET
v7.0
> > docker
> > > > container regrid_data_plane",
> > > > 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 #84736].
> > > >
> > > > Please include the string:
> > > >
> > > > [rt.rap.ucar.edu #84736]
> > > >
> > > > in the subject line of all future correspondence about this
issue. To
> > do
> > > > so,
> > > > you may reply to this message.
> > > >
> > > > For more information, please see:
> > > >
> > > > MET Online Tutorial:
> > > > https://www.dtcenter.org/met/users/support/online_tutorial/
> > index.php
> > > >
> > > > MET Users Guide:
> > > > https://www.dtcenter.org/met/users/docs/overview.php
> > > >
> > > > MET FAQs:
> > > > https://www.dtcenter.org/met/users/support/faqs/index.php
> > > >
> > > > MET-Help Email Archive:
> > > > http://mailman.ucar.edu/pipermail/met_help
> > > >
> > > > Thank you,
> > > > met_help at ucar.edu
> > > >
> > > > ------------------------------------------------------------
> > > -------------
> > > > Good morning,
> > > >
> > > > I am currently setting up software to run MET to produce grids
to
> view
> > > in a
> > > > viewer. I have one set of processing running on WCOSS
utilizing MET
> > v6.0
> > > > which correctly decodes the NetCDF files produced by
> regrid_data_plane,
> > > but
> > > > I'm having troubles reproducing the results using the MET v7.0
docker
> > > > container using the same file. The file in question is an NDFD
QPF
> > > forecast
> > > > for 01/10/2018 00z, 6 hour lead time, and is originally in
GRIB2
> > format.
> > > >
> > > > I ran a script through the 7.0 docker container to produce a
NetCDF
> > file
> > > as
> > > > a result of regrid_data_plane. The expected NetCDF file was
produced
> > with
> > > > the expected dimensions (snippet below). The input file was an
NDFD
> > > > forecast that I have successfully tested on WCOSS using MET
v6.0.
> > > >
> > > >
> > > >
> > > >
> > > > However, it appears that the encoding of the lat/lon points
ends 1
> > value
> > > > too early and wraps back around to 1, resulting in 2 longitude
values
> > for
> > > > the upper left corner point.
> > > >
> > > > Upper left lon at point 1,$max_lat
> > > > ncdump -v lon -f f ndfdconc2p518011000qpf06f006 | grep
"lon(1,1377)"
> > > > -130.1034, // lon(1,1377)
> > > > -60.88556; // lon(1,1377)
> > > >
> > > > Also, see part of a longitude dump below (ncdump -v lon -f
> > > > ndfdconc2p518011000qpf06f006 )
> > > >
> > > >
> > > >
> > > >
> > > > Trying to pull out the values of the lower-right corner (using
> max_lon)
> > > > yields null values due to lon value 2145 being unavailable.
This is
> > > causing
> > > > me not to be able to correctly pull out the corner points to
convert
> > > these
> > > > grids for viewing. This same processing is running properly on
WCOSS
> > > using
> > > > MET v6.0 (not docker container).
> > > >
> > > > Let me know if there's any more I can provide to assistance in
> > resolving
> > > > this.
> > > >
> > > > Thank you for your help!
> > > > Dana
> > > >
> > > > --
> > > > Dana Strom
> > > >
> > > > Technical Lead, AceInfo Solutions
> > > >
> > > > Meteorological Development Laboratory (NWS)
> > > >
> > > > Phone: 301-427-9451
> > > >
> > > >
> > >
> > >
> > > --
> > > Dana Strom
> > >
> > > Technical Lead, AceInfo Solutions
> > >
> > > Meteorological Development Laboratory (NWS)
> > >
> > > Phone: 301-427-9451
> > >
> > >
> >
> >
>
>
> --
> Dana Strom
>
> Technical Lead, AceInfo Solutions
>
> Meteorological Development Laboratory (NWS)
>
> Phone: 301-427-9451
>
>
------------------------------------------------
More information about the Met_help
mailing list