[Met_help] [rt.rap.ucar.edu #94683] History for prepbufr dump files being written out
John Halley Gotway via RT
met_help at ucar.edu
Wed Apr 1 11:07:41 MDT 2020
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi, everyone,
At today's METplus call with EMC, I had asked John about the fact that with
the new METv9, that I am seeing prepbufr dump files being written out, and
John said that this shouldn't be written out because it's mainly a
debugging feature. I had not changed my METplus system (still working from
an old beta), but I did change MET to v9. This dump file was not produced
in the old system. John said that this would happen if the -dump option
was included in the PB2NC command.
Here's the command that was used for the most recent use of METplus, and
the -dump option is not included in the command. Maybe the -v 4 is one
thing that causes the output to be written? Or is it something else?
Maybe I'll try to run with a -v 2 or 3 and see if it happens? (Not today
because the machines are not accessible today).
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.0/bin/pb2nc -v
4 /gpfs/dell1/nco/ops/com/nam/prod/nam.20200319/nam.t06z.prepbufr.tm06
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/nam/conus_sfc/
prepbufr.nam.2020031900.nc
/gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-beta1/parm/met_config/PB2NCConfig_perry
Thanks!
Perry
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: prepbufr dump files being written out
From: John Halley Gotway
Time: Mon Mar 23 12:24:03 2020
Perry,
This is very interesting. I did test met-9.0 pb2nc with some sample
data
using "-v 4" on the command line but that did not replicate this
behavior
you describe. When I added "-dump ." to command line, it triggered
that
logic and wrote many ascii output files to my current working
directory...
one for each message type (see below).
So the mystery is, how is this pb2nc logic getting triggered via
METplus?
Thanks for sending that pb2nc command. Can you also please send...
(1) the full path to the logfile from which you retrieved that
command?
(2) the full path to the "*_ADPUPA.txt" file that's showing up (I want
to
see what directory it's showing up in).
Thanks,
John
dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPSFC.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPUPA.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCAR.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCFT.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_ERS1DA.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_GOESND.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_GPSIPW.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_MSONET.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_PROFLR.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_QKSWND.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_RASSDA.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATEMP.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATWND.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCBOG.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCSHP.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_SPSSMI.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_SYNDAT.txt
dump_ndas.t00z.prepbufr.tm12.20070401.nr_VADWND.txt
On Mon, Mar 23, 2020 at 12:08 PM perry.shafran at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> Mon Mar 23 12:08:05 2020: Request 94683 was acted upon.
> Transaction: Ticket created by perry.shafran at noaa.gov
> Queue: met_help
> Subject: prepbufr dump files being written out
> Owner: Nobody
> Requestors: perry.shafran at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
>
>
> Hi, everyone,
>
> At today's METplus call with EMC, I had asked John about the fact
that with
> the new METv9, that I am seeing prepbufr dump files being written
out, and
> John said that this shouldn't be written out because it's mainly a
> debugging feature. I had not changed my METplus system (still
working from
> an old beta), but I did change MET to v9. This dump file was not
produced
> in the old system. John said that this would happen if the -dump
option
> was included in the PB2NC command.
>
> Here's the command that was used for the most recent use of METplus,
and
> the -dump option is not included in the command. Maybe the -v 4 is
one
> thing that causes the output to be written? Or is it something
else?
> Maybe I'll try to run with a -v 2 or 3 and see if it happens? (Not
today
> because the machines are not accessible today).
>
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.0/bin/pb2nc
-v
> 4
/gpfs/dell1/nco/ops/com/nam/prod/nam.20200319/nam.t06z.prepbufr.tm06
>
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/nam/conus_sfc/
> prepbufr.nam.2020031900.nc
>
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/met_config/PB2NCConfig_perry
>
> Thanks!
>
> Perry
>
>
------------------------------------------------
Subject: prepbufr dump files being written out
From: perry.shafran at noaa.gov
Time: Mon Mar 23 12:26:34 2020
I've since deleted the .txt files, but I'll do this again tomorrow
when
Venus is back open for developers, and then I'll get you all that you
requested.
Thanks!
Perry
On Mon, Mar 23, 2020 at 2:24 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Perry,
>
> This is very interesting. I did test met-9.0 pb2nc with some sample
data
> using "-v 4" on the command line but that did not replicate this
behavior
> you describe. When I added "-dump ." to command line, it triggered
that
> logic and wrote many ascii output files to my current working
directory...
> one for each message type (see below).
>
> So the mystery is, how is this pb2nc logic getting triggered via
METplus?
>
> Thanks for sending that pb2nc command. Can you also please send...
> (1) the full path to the logfile from which you retrieved that
command?
> (2) the full path to the "*_ADPUPA.txt" file that's showing up (I
want to
> see what directory it's showing up in).
>
> Thanks,
> John
>
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPSFC.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPUPA.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCAR.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCFT.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_ERS1DA.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_GOESND.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_GPSIPW.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_MSONET.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_PROFLR.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_QKSWND.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_RASSDA.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATEMP.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATWND.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCBOG.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCSHP.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_SPSSMI.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_SYNDAT.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_VADWND.txt
>
> On Mon, Mar 23, 2020 at 12:08 PM perry.shafran at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > Mon Mar 23 12:08:05 2020: Request 94683 was acted upon.
> > Transaction: Ticket created by perry.shafran at noaa.gov
> > Queue: met_help
> > Subject: prepbufr dump files being written out
> > Owner: Nobody
> > Requestors: perry.shafran at noaa.gov
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
> >
> >
> > Hi, everyone,
> >
> > At today's METplus call with EMC, I had asked John about the fact
that
> with
> > the new METv9, that I am seeing prepbufr dump files being written
out,
> and
> > John said that this shouldn't be written out because it's mainly a
> > debugging feature. I had not changed my METplus system (still
working
> from
> > an old beta), but I did change MET to v9. This dump file was not
> produced
> > in the old system. John said that this would happen if the -dump
option
> > was included in the PB2NC command.
> >
> > Here's the command that was used for the most recent use of
METplus, and
> > the -dump option is not included in the command. Maybe the -v 4
is one
> > thing that causes the output to be written? Or is it something
else?
> > Maybe I'll try to run with a -v 2 or 3 and see if it happens?
(Not today
> > because the machines are not accessible today).
> >
> >
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.0/bin/pb2nc
> -v
> > 4
/gpfs/dell1/nco/ops/com/nam/prod/nam.20200319/nam.t06z.prepbufr.tm06
> >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/nam/conus_sfc/
> > prepbufr.nam.2020031900.nc
> >
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/met_config/PB2NCConfig_perry
> >
> > Thanks!
> >
> > Perry
> >
> >
>
>
------------------------------------------------
Subject: prepbufr dump files being written out
From: perry.shafran at noaa.gov
Time: Mon Mar 23 12:43:04 2020
FYI - I found one of these lines in the dump file. This is when I run
interactively in the
directory /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/use_cases/perry
DEBUG 1: Dumping to ASCII output directory: .
I also see that there are files that were not deleted in the
directory.
You can find them there.
I think the log file that goes with these files (based on the
timestamp of
all the files)
is
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200320182603.
Perry
On Mon, Mar 23, 2020 at 2:24 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Perry,
>
> This is very interesting. I did test met-9.0 pb2nc with some sample
data
> using "-v 4" on the command line but that did not replicate this
behavior
> you describe. When I added "-dump ." to command line, it triggered
that
> logic and wrote many ascii output files to my current working
directory...
> one for each message type (see below).
>
> So the mystery is, how is this pb2nc logic getting triggered via
METplus?
>
> Thanks for sending that pb2nc command. Can you also please send...
> (1) the full path to the logfile from which you retrieved that
command?
> (2) the full path to the "*_ADPUPA.txt" file that's showing up (I
want to
> see what directory it's showing up in).
>
> Thanks,
> John
>
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPSFC.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPUPA.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCAR.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCFT.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_ERS1DA.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_GOESND.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_GPSIPW.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_MSONET.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_PROFLR.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_QKSWND.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_RASSDA.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATEMP.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATWND.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCBOG.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCSHP.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_SPSSMI.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_SYNDAT.txt
> dump_ndas.t00z.prepbufr.tm12.20070401.nr_VADWND.txt
>
> On Mon, Mar 23, 2020 at 12:08 PM perry.shafran at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > Mon Mar 23 12:08:05 2020: Request 94683 was acted upon.
> > Transaction: Ticket created by perry.shafran at noaa.gov
> > Queue: met_help
> > Subject: prepbufr dump files being written out
> > Owner: Nobody
> > Requestors: perry.shafran at noaa.gov
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
> >
> >
> > Hi, everyone,
> >
> > At today's METplus call with EMC, I had asked John about the fact
that
> with
> > the new METv9, that I am seeing prepbufr dump files being written
out,
> and
> > John said that this shouldn't be written out because it's mainly a
> > debugging feature. I had not changed my METplus system (still
working
> from
> > an old beta), but I did change MET to v9. This dump file was not
> produced
> > in the old system. John said that this would happen if the -dump
option
> > was included in the PB2NC command.
> >
> > Here's the command that was used for the most recent use of
METplus, and
> > the -dump option is not included in the command. Maybe the -v 4
is one
> > thing that causes the output to be written? Or is it something
else?
> > Maybe I'll try to run with a -v 2 or 3 and see if it happens?
(Not today
> > because the machines are not accessible today).
> >
> >
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.0/bin/pb2nc
> -v
> > 4
/gpfs/dell1/nco/ops/com/nam/prod/nam.20200319/nam.t06z.prepbufr.tm06
> >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/nam/conus_sfc/
> > prepbufr.nam.2020031900.nc
> >
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/met_config/PB2NCConfig_perry
> >
> > Thanks!
> >
> > Perry
> >
> >
>
>
------------------------------------------------
Subject: prepbufr dump files being written out
From: John Halley Gotway
Time: Mon Mar 23 14:04:46 2020
Perry,
Yes, that log message indicates that somehow the dump logic in PB2NC
has
been enabled...
DEBUG 1: Dumping to ASCII output directory: .
When the machines are available again, I'll take a closer look. Seems
like
the suspects still are:
(1) an issue in pb2nc itself
(2) an issue in METplus
(3) an issue in your runtime environment
Seems like we should be able to figure this one out!
Thanks,
John
On Mon, Mar 23, 2020 at 12:43 PM perry.shafran at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
>
> FYI - I found one of these lines in the dump file. This is when I
run
> interactively in the
> directory
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/use_cases/perry
>
> DEBUG 1: Dumping to ASCII output directory: .
>
> I also see that there are files that were not deleted in the
directory.
> You can find them there.
>
> I think the log file that goes with these files (based on the
timestamp of
> all the files)
> is
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200320182603.
>
> Perry
>
> On Mon, Mar 23, 2020 at 2:24 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Perry,
> >
> > This is very interesting. I did test met-9.0 pb2nc with some
sample data
> > using "-v 4" on the command line but that did not replicate this
behavior
> > you describe. When I added "-dump ." to command line, it
triggered that
> > logic and wrote many ascii output files to my current working
> directory...
> > one for each message type (see below).
> >
> > So the mystery is, how is this pb2nc logic getting triggered via
METplus?
> >
> > Thanks for sending that pb2nc command. Can you also please
send...
> > (1) the full path to the logfile from which you retrieved that
command?
> > (2) the full path to the "*_ADPUPA.txt" file that's showing up (I
want to
> > see what directory it's showing up in).
> >
> > Thanks,
> > John
> >
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPSFC.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPUPA.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCAR.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCFT.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ERS1DA.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GOESND.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GPSIPW.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_MSONET.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_PROFLR.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_QKSWND.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_RASSDA.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATEMP.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATWND.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCBOG.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCSHP.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SPSSMI.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SYNDAT.txt
> > dump_ndas.t00z.prepbufr.tm12.20070401.nr_VADWND.txt
> >
> > On Mon, Mar 23, 2020 at 12:08 PM perry.shafran at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > Mon Mar 23 12:08:05 2020: Request 94683 was acted upon.
> > > Transaction: Ticket created by perry.shafran at noaa.gov
> > > Queue: met_help
> > > Subject: prepbufr dump files being written out
> > > Owner: Nobody
> > > Requestors: perry.shafran at noaa.gov
> > > Status: new
> > > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
> >
> > >
> > >
> > > Hi, everyone,
> > >
> > > At today's METplus call with EMC, I had asked John about the
fact that
> > with
> > > the new METv9, that I am seeing prepbufr dump files being
written out,
> > and
> > > John said that this shouldn't be written out because it's mainly
a
> > > debugging feature. I had not changed my METplus system (still
working
> > from
> > > an old beta), but I did change MET to v9. This dump file was
not
> > produced
> > > in the old system. John said that this would happen if the
-dump
> option
> > > was included in the PB2NC command.
> > >
> > > Here's the command that was used for the most recent use of
METplus,
> and
> > > the -dump option is not included in the command. Maybe the -v 4
is one
> > > thing that causes the output to be written? Or is it something
else?
> > > Maybe I'll try to run with a -v 2 or 3 and see if it happens?
(Not
> today
> > > because the machines are not accessible today).
> > >
> > >
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.0/bin/pb2nc
> > -v
> > > 4
/gpfs/dell1/nco/ops/com/nam/prod/nam.20200319/nam.t06z.prepbufr.tm06
> > >
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/nam/conus_sfc/
> > > prepbufr.nam.2020031900.nc
> > >
> > >
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/met_config/PB2NCConfig_perry
> > >
> > > Thanks!
> > >
> > > Perry
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: prepbufr dump files being written out
From: perry.shafran at noaa.gov
Time: Mon Mar 23 14:10:17 2020
The machine is available now, since they halted the testing they were
doing, but they will try to do the test again tomorrow. Which means
now is
your chance to take a look-see.
I am also re-running so I have a more complete case to show you. When
finished, that log file will
be
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200323200145
Thanks!
Perry
On Mon, Mar 23, 2020 at 4:06 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Perry,
>
> Yes, that log message indicates that somehow the dump logic in PB2NC
has
> been enabled...
> DEBUG 1: Dumping to ASCII output directory: .
>
> When the machines are available again, I'll take a closer look.
Seems like
> the suspects still are:
> (1) an issue in pb2nc itself
> (2) an issue in METplus
> (3) an issue in your runtime environment
>
> Seems like we should be able to figure this one out!
>
> Thanks,
> John
>
>
>
> On Mon, Mar 23, 2020 at 12:43 PM perry.shafran at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
> >
> > FYI - I found one of these lines in the dump file. This is when I
run
> > interactively in the
> > directory
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/use_cases/perry
> >
> > DEBUG 1: Dumping to ASCII output directory: .
> >
> > I also see that there are files that were not deleted in the
directory.
> > You can find them there.
> >
> > I think the log file that goes with these files (based on the
timestamp
> of
> > all the files)
> > is
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200320182603.
> >
> > Perry
> >
> > On Mon, Mar 23, 2020 at 2:24 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Perry,
> > >
> > > This is very interesting. I did test met-9.0 pb2nc with some
sample
> data
> > > using "-v 4" on the command line but that did not replicate this
> behavior
> > > you describe. When I added "-dump ." to command line, it
triggered
> that
> > > logic and wrote many ascii output files to my current working
> > directory...
> > > one for each message type (see below).
> > >
> > > So the mystery is, how is this pb2nc logic getting triggered via
> METplus?
> > >
> > > Thanks for sending that pb2nc command. Can you also please
send...
> > > (1) the full path to the logfile from which you retrieved that
command?
> > > (2) the full path to the "*_ADPUPA.txt" file that's showing up
(I want
> to
> > > see what directory it's showing up in).
> > >
> > > Thanks,
> > > John
> > >
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPSFC.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPUPA.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCAR.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCFT.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ERS1DA.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GOESND.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GPSIPW.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_MSONET.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_PROFLR.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_QKSWND.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_RASSDA.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATEMP.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATWND.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCBOG.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCSHP.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SPSSMI.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SYNDAT.txt
> > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_VADWND.txt
> > >
> > > On Mon, Mar 23, 2020 at 12:08 PM perry.shafran at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > Mon Mar 23 12:08:05 2020: Request 94683 was acted upon.
> > > > Transaction: Ticket created by perry.shafran at noaa.gov
> > > > Queue: met_help
> > > > Subject: prepbufr dump files being written out
> > > > Owner: Nobody
> > > > Requestors: perry.shafran at noaa.gov
> > > > Status: new
> > > > Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
> > >
> > > >
> > > >
> > > > Hi, everyone,
> > > >
> > > > At today's METplus call with EMC, I had asked John about the
fact
> that
> > > with
> > > > the new METv9, that I am seeing prepbufr dump files being
written
> out,
> > > and
> > > > John said that this shouldn't be written out because it's
mainly a
> > > > debugging feature. I had not changed my METplus system (still
> working
> > > from
> > > > an old beta), but I did change MET to v9. This dump file was
not
> > > produced
> > > > in the old system. John said that this would happen if the
-dump
> > option
> > > > was included in the PB2NC command.
> > > >
> > > > Here's the command that was used for the most recent use of
METplus,
> > and
> > > > the -dump option is not included in the command. Maybe the -v
4 is
> one
> > > > thing that causes the output to be written? Or is it
something else?
> > > > Maybe I'll try to run with a -v 2 or 3 and see if it happens?
(Not
> > today
> > > > because the machines are not accessible today).
> > > >
> > > >
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.0/bin/pb2nc
> > > -v
> > > > 4
> /gpfs/dell1/nco/ops/com/nam/prod/nam.20200319/nam.t06z.prepbufr.tm06
> > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/nam/conus_sfc/
> > > > prepbufr.nam.2020031900.nc
> > > >
> > > >
> > >
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/met_config/PB2NCConfig_perry
> > > >
> > > > Thanks!
> > > >
> > > > Perry
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: prepbufr dump files being written out
From: John Halley Gotway
Time: Mon Mar 23 18:46:44 2020
Hi Perry,
I was able to log on and do some testing. I'm working on venus
in /u/John.H.Gotway/MET/MET_Help/shafran_data_20200323
I was able to compile a test version of pb2nc there and try things
out. I
definitely see the behavior you describe. pb2nc sets the dump_flag to
true,
even though we haven't used the "-dump" command line option to do so.
This
looks to me like a lot like a memory issue. When I add some debug log
messages and recompile, the behavior either stays the same or goes
away,
depending on where I add the log message. Any change to the compiled
code,
as small as it might be, affects the memory alignment. And it can
mask the
memory problem.
The code for handling the "dump_flag" is correct. The boolean value
is
correctly set to false. Then some other part of the code is
overwriting
the end of its array and corrupting that boolean value... setting it
to
some non-zero value... e.g. true. While the problem appears as an
issue
with dump_flag, the real problem is somewhere else. So I'm pretty
confident this is a pesky little bug in the MET code itself.
There is an Intel compiler option that's really useful in these cases
(-ftrapuv). Rather than initializing allocated memory to normal
values,
like 0, it initialize it to really weird values. And that often leads
to
other runtime arrows that highlight the offending code.
Thanks for letting us know about this behavior!
Julie, can you please compile a second version of MET on venus... just
the
met-9.0 code. We can reuse the existing dependent libraries. But
configure/compile MET using the "-ftrapuv" option.
Thanks,
John
On Mon, Mar 23, 2020 at 2:11 PM perry.shafran at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
>
> The machine is available now, since they halted the testing they
were
> doing, but they will try to do the test again tomorrow. Which means
now is
> your chance to take a look-see.
>
> I am also re-running so I have a more complete case to show you.
When
> finished, that log file will
> be
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200323200145
>
> Thanks!
>
> Perry
>
> On Mon, Mar 23, 2020 at 4:06 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Perry,
> >
> > Yes, that log message indicates that somehow the dump logic in
PB2NC has
> > been enabled...
> > DEBUG 1: Dumping to ASCII output directory: .
> >
> > When the machines are available again, I'll take a closer look.
Seems
> like
> > the suspects still are:
> > (1) an issue in pb2nc itself
> > (2) an issue in METplus
> > (3) an issue in your runtime environment
> >
> > Seems like we should be able to figure this one out!
> >
> > Thanks,
> > John
> >
> >
> >
> > On Mon, Mar 23, 2020 at 12:43 PM perry.shafran at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
> > >
> > > FYI - I found one of these lines in the dump file. This is when
I run
> > > interactively in the
> > > directory
> > >
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/use_cases/perry
> > >
> > > DEBUG 1: Dumping to ASCII output directory: .
> > >
> > > I also see that there are files that were not deleted in the
directory.
> > > You can find them there.
> > >
> > > I think the log file that goes with these files (based on the
timestamp
> > of
> > > all the files)
> > > is
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200320182603.
> > >
> > > Perry
> > >
> > > On Mon, Mar 23, 2020 at 2:24 PM John Halley Gotway via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > > Perry,
> > > >
> > > > This is very interesting. I did test met-9.0 pb2nc with some
sample
> > data
> > > > using "-v 4" on the command line but that did not replicate
this
> > behavior
> > > > you describe. When I added "-dump ." to command line, it
triggered
> > that
> > > > logic and wrote many ascii output files to my current working
> > > directory...
> > > > one for each message type (see below).
> > > >
> > > > So the mystery is, how is this pb2nc logic getting triggered
via
> > METplus?
> > > >
> > > > Thanks for sending that pb2nc command. Can you also please
send...
> > > > (1) the full path to the logfile from which you retrieved that
> command?
> > > > (2) the full path to the "*_ADPUPA.txt" file that's showing up
(I
> want
> > to
> > > > see what directory it's showing up in).
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPSFC.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPUPA.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCAR.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCFT.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ERS1DA.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GOESND.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GPSIPW.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_MSONET.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_PROFLR.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_QKSWND.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_RASSDA.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATEMP.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATWND.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCBOG.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCSHP.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SPSSMI.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SYNDAT.txt
> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_VADWND.txt
> > > >
> > > > On Mon, Mar 23, 2020 at 12:08 PM perry.shafran at noaa.gov via RT
<
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > >
> > > > > Mon Mar 23 12:08:05 2020: Request 94683 was acted upon.
> > > > > Transaction: Ticket created by perry.shafran at noaa.gov
> > > > > Queue: met_help
> > > > > Subject: prepbufr dump files being written out
> > > > > Owner: Nobody
> > > > > Requestors: perry.shafran at noaa.gov
> > > > > Status: new
> > > > > Ticket <URL:
> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
> > > >
> > > > >
> > > > >
> > > > > Hi, everyone,
> > > > >
> > > > > At today's METplus call with EMC, I had asked John about the
fact
> > that
> > > > with
> > > > > the new METv9, that I am seeing prepbufr dump files being
written
> > out,
> > > > and
> > > > > John said that this shouldn't be written out because it's
mainly a
> > > > > debugging feature. I had not changed my METplus system
(still
> > working
> > > > from
> > > > > an old beta), but I did change MET to v9. This dump file
was not
> > > > produced
> > > > > in the old system. John said that this would happen if the
-dump
> > > option
> > > > > was included in the PB2NC command.
> > > > >
> > > > > Here's the command that was used for the most recent use of
> METplus,
> > > and
> > > > > the -dump option is not included in the command. Maybe the
-v 4 is
> > one
> > > > > thing that causes the output to be written? Or is it
something
> else?
> > > > > Maybe I'll try to run with a -v 2 or 3 and see if it
happens? (Not
> > > today
> > > > > because the machines are not accessible today).
> > > > >
> > > > >
> >
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.0/bin/pb2nc
> > > > -v
> > > > > 4
> >
/gpfs/dell1/nco/ops/com/nam/prod/nam.20200319/nam.t06z.prepbufr.tm06
> > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/nam/conus_sfc/
> > > > > prepbufr.nam.2020031900.nc
> > > > >
> > > > >
> > > >
> > >
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/met_config/PB2NCConfig_perry
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Perry
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: prepbufr dump files being written out
From: John Halley Gotway
Time: Tue Mar 24 15:16:28 2020
Perry,
FYI, here's the bug report ticket I created for this issue:
https://github.com/NCAR/MET/issues/1286
If you send me your GitHub username, I can include you on the ticket
so
you'll get notifications about it.
Thanks,
John
On Mon, Mar 23, 2020 at 6:46 PM John Halley Gotway <johnhg at ucar.edu>
wrote:
> Hi Perry,
>
> I was able to log on and do some testing. I'm working on venus
> in /u/John.H.Gotway/MET/MET_Help/shafran_data_20200323
>
> I was able to compile a test version of pb2nc there and try things
out. I
> definitely see the behavior you describe. pb2nc sets the dump_flag
to true,
> even though we haven't used the "-dump" command line option to do
so. This
> looks to me like a lot like a memory issue. When I add some debug
log
> messages and recompile, the behavior either stays the same or goes
away,
> depending on where I add the log message. Any change to the
compiled code,
> as small as it might be, affects the memory alignment. And it can
mask the
> memory problem.
>
> The code for handling the "dump_flag" is correct. The boolean value
is
> correctly set to false. Then some other part of the code is
overwriting
> the end of its array and corrupting that boolean value... setting it
to
> some non-zero value... e.g. true. While the problem appears as an
issue
> with dump_flag, the real problem is somewhere else. So I'm pretty
> confident this is a pesky little bug in the MET code itself.
>
> There is an Intel compiler option that's really useful in these
cases
> (-ftrapuv). Rather than initializing allocated memory to normal
values,
> like 0, it initialize it to really weird values. And that often
leads to
> other runtime arrows that highlight the offending code.
>
> Thanks for letting us know about this behavior!
>
> Julie, can you please compile a second version of MET on venus...
just the
> met-9.0 code. We can reuse the existing dependent libraries. But
> configure/compile MET using the "-ftrapuv" option.
>
> Thanks,
> John
>
> On Mon, Mar 23, 2020 at 2:11 PM perry.shafran at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
>>
>> The machine is available now, since they halted the testing they
were
>> doing, but they will try to do the test again tomorrow. Which
means now
>> is
>> your chance to take a look-see.
>>
>> I am also re-running so I have a more complete case to show you.
When
>> finished, that log file will
>> be
>>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200323200145
>>
>> Thanks!
>>
>> Perry
>>
>> On Mon, Mar 23, 2020 at 4:06 PM John Halley Gotway via RT <
>> met_help at ucar.edu>
>> wrote:
>>
>> > Perry,
>> >
>> > Yes, that log message indicates that somehow the dump logic in
PB2NC has
>> > been enabled...
>> > DEBUG 1: Dumping to ASCII output directory: .
>> >
>> > When the machines are available again, I'll take a closer look.
Seems
>> like
>> > the suspects still are:
>> > (1) an issue in pb2nc itself
>> > (2) an issue in METplus
>> > (3) an issue in your runtime environment
>> >
>> > Seems like we should be able to figure this one out!
>> >
>> > Thanks,
>> > John
>> >
>> >
>> >
>> > On Mon, Mar 23, 2020 at 12:43 PM perry.shafran at noaa.gov via RT <
>> > met_help at ucar.edu> wrote:
>> >
>> > >
>> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
>> > >
>> > > FYI - I found one of these lines in the dump file. This is
when I run
>> > > interactively in the
>> > > directory
>> > >
>> >
>> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/use_cases/perry
>> > >
>> > > DEBUG 1: Dumping to ASCII output directory: .
>> > >
>> > > I also see that there are files that were not deleted in the
>> directory.
>> > > You can find them there.
>> > >
>> > > I think the log file that goes with these files (based on the
>> timestamp
>> > of
>> > > all the files)
>> > > is
>> > >
>> >
>>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200320182603.
>> > >
>> > > Perry
>> > >
>> > > On Mon, Mar 23, 2020 at 2:24 PM John Halley Gotway via RT <
>> > > met_help at ucar.edu>
>> > > wrote:
>> > >
>> > > > Perry,
>> > > >
>> > > > This is very interesting. I did test met-9.0 pb2nc with some
sample
>> > data
>> > > > using "-v 4" on the command line but that did not replicate
this
>> > behavior
>> > > > you describe. When I added "-dump ." to command line, it
triggered
>> > that
>> > > > logic and wrote many ascii output files to my current working
>> > > directory...
>> > > > one for each message type (see below).
>> > > >
>> > > > So the mystery is, how is this pb2nc logic getting triggered
via
>> > METplus?
>> > > >
>> > > > Thanks for sending that pb2nc command. Can you also please
send...
>> > > > (1) the full path to the logfile from which you retrieved
that
>> command?
>> > > > (2) the full path to the "*_ADPUPA.txt" file that's showing
up (I
>> want
>> > to
>> > > > see what directory it's showing up in).
>> > > >
>> > > > Thanks,
>> > > > John
>> > > >
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPSFC.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPUPA.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCAR.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCFT.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ERS1DA.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GOESND.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GPSIPW.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_MSONET.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_PROFLR.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_QKSWND.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_RASSDA.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATEMP.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATWND.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCBOG.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCSHP.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SPSSMI.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SYNDAT.txt
>> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_VADWND.txt
>> > > >
>> > > > On Mon, Mar 23, 2020 at 12:08 PM perry.shafran at noaa.gov via
RT <
>> > > > met_help at ucar.edu> wrote:
>> > > >
>> > > > >
>> > > > > Mon Mar 23 12:08:05 2020: Request 94683 was acted upon.
>> > > > > Transaction: Ticket created by perry.shafran at noaa.gov
>> > > > > Queue: met_help
>> > > > > Subject: prepbufr dump files being written out
>> > > > > Owner: Nobody
>> > > > > Requestors: perry.shafran at noaa.gov
>> > > > > Status: new
>> > > > > Ticket <URL:
>> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
>> > > >
>> > > > >
>> > > > >
>> > > > > Hi, everyone,
>> > > > >
>> > > > > At today's METplus call with EMC, I had asked John about
the fact
>> > that
>> > > > with
>> > > > > the new METv9, that I am seeing prepbufr dump files being
written
>> > out,
>> > > > and
>> > > > > John said that this shouldn't be written out because it's
mainly a
>> > > > > debugging feature. I had not changed my METplus system
(still
>> > working
>> > > > from
>> > > > > an old beta), but I did change MET to v9. This dump file
was not
>> > > > produced
>> > > > > in the old system. John said that this would happen if the
-dump
>> > > option
>> > > > > was included in the PB2NC command.
>> > > > >
>> > > > > Here's the command that was used for the most recent use of
>> METplus,
>> > > and
>> > > > > the -dump option is not included in the command. Maybe the
-v 4
>> is
>> > one
>> > > > > thing that causes the output to be written? Or is it
something
>> else?
>> > > > > Maybe I'll try to run with a -v 2 or 3 and see if it
happens?
>> (Not
>> > > today
>> > > > > because the machines are not accessible today).
>> > > > >
>> > > > >
>> >
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.0/bin/pb2nc
>> > > > -v
>> > > > > 4
>> >
/gpfs/dell1/nco/ops/com/nam/prod/nam.20200319/nam.t06z.prepbufr.tm06
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/nam/conus_sfc/
>> > > > > prepbufr.nam.2020031900.nc
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/met_config/PB2NCConfig_perry
>> > > > >
>> > > > > Thanks!
>> > > > >
>> > > > > Perry
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
------------------------------------------------
Subject: prepbufr dump files being written out
From: perry.shafran at noaa.gov
Time: Tue Mar 24 15:20:11 2020
I just got onto GitHub late last week. PerryShafran-NOAA I think is
my
username.
Perry
On Tue, Mar 24, 2020 at 5:16 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Perry,
>
> FYI, here's the bug report ticket I created for this issue:
> https://github.com/NCAR/MET/issues/1286
>
> If you send me your GitHub username, I can include you on the ticket
so
> you'll get notifications about it.
>
> Thanks,
> John
>
> On Mon, Mar 23, 2020 at 6:46 PM John Halley Gotway <johnhg at ucar.edu>
> wrote:
>
> > Hi Perry,
> >
> > I was able to log on and do some testing. I'm working on venus
> > in /u/John.H.Gotway/MET/MET_Help/shafran_data_20200323
> >
> > I was able to compile a test version of pb2nc there and try things
out.
> I
> > definitely see the behavior you describe. pb2nc sets the dump_flag
to
> true,
> > even though we haven't used the "-dump" command line option to do
so.
> This
> > looks to me like a lot like a memory issue. When I add some debug
log
> > messages and recompile, the behavior either stays the same or goes
away,
> > depending on where I add the log message. Any change to the
compiled
> code,
> > as small as it might be, affects the memory alignment. And it can
mask
> the
> > memory problem.
> >
> > The code for handling the "dump_flag" is correct. The boolean
value is
> > correctly set to false. Then some other part of the code is
overwriting
> > the end of its array and corrupting that boolean value... setting
it to
> > some non-zero value... e.g. true. While the problem appears as an
issue
> > with dump_flag, the real problem is somewhere else. So I'm pretty
> > confident this is a pesky little bug in the MET code itself.
> >
> > There is an Intel compiler option that's really useful in these
cases
> > (-ftrapuv). Rather than initializing allocated memory to normal
values,
> > like 0, it initialize it to really weird values. And that often
leads to
> > other runtime arrows that highlight the offending code.
> >
> > Thanks for letting us know about this behavior!
> >
> > Julie, can you please compile a second version of MET on venus...
just
> the
> > met-9.0 code. We can reuse the existing dependent libraries. But
> > configure/compile MET using the "-ftrapuv" option.
> >
> > Thanks,
> > John
> >
> > On Mon, Mar 23, 2020 at 2:11 PM perry.shafran at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> >>
> >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
> >>
> >> The machine is available now, since they halted the testing they
were
> >> doing, but they will try to do the test again tomorrow. Which
means now
> >> is
> >> your chance to take a look-see.
> >>
> >> I am also re-running so I have a more complete case to show you.
When
> >> finished, that log file will
> >> be
> >>
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200323200145
> >>
> >> Thanks!
> >>
> >> Perry
> >>
> >> On Mon, Mar 23, 2020 at 4:06 PM John Halley Gotway via RT <
> >> met_help at ucar.edu>
> >> wrote:
> >>
> >> > Perry,
> >> >
> >> > Yes, that log message indicates that somehow the dump logic in
PB2NC
> has
> >> > been enabled...
> >> > DEBUG 1: Dumping to ASCII output directory: .
> >> >
> >> > When the machines are available again, I'll take a closer look.
Seems
> >> like
> >> > the suspects still are:
> >> > (1) an issue in pb2nc itself
> >> > (2) an issue in METplus
> >> > (3) an issue in your runtime environment
> >> >
> >> > Seems like we should be able to figure this one out!
> >> >
> >> > Thanks,
> >> > John
> >> >
> >> >
> >> >
> >> > On Mon, Mar 23, 2020 at 12:43 PM perry.shafran at noaa.gov via RT
<
> >> > met_help at ucar.edu> wrote:
> >> >
> >> > >
> >> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
>
> >> > >
> >> > > FYI - I found one of these lines in the dump file. This is
when I
> run
> >> > > interactively in the
> >> > > directory
> >> > >
> >> >
> >>
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/use_cases/perry
> >> > >
> >> > > DEBUG 1: Dumping to ASCII output directory: .
> >> > >
> >> > > I also see that there are files that were not deleted in the
> >> directory.
> >> > > You can find them there.
> >> > >
> >> > > I think the log file that goes with these files (based on the
> >> timestamp
> >> > of
> >> > > all the files)
> >> > > is
> >> > >
> >> >
> >>
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200320182603.
> >> > >
> >> > > Perry
> >> > >
> >> > > On Mon, Mar 23, 2020 at 2:24 PM John Halley Gotway via RT <
> >> > > met_help at ucar.edu>
> >> > > wrote:
> >> > >
> >> > > > Perry,
> >> > > >
> >> > > > This is very interesting. I did test met-9.0 pb2nc with
some
> sample
> >> > data
> >> > > > using "-v 4" on the command line but that did not replicate
this
> >> > behavior
> >> > > > you describe. When I added "-dump ." to command line, it
> triggered
> >> > that
> >> > > > logic and wrote many ascii output files to my current
working
> >> > > directory...
> >> > > > one for each message type (see below).
> >> > > >
> >> > > > So the mystery is, how is this pb2nc logic getting
triggered via
> >> > METplus?
> >> > > >
> >> > > > Thanks for sending that pb2nc command. Can you also please
> send...
> >> > > > (1) the full path to the logfile from which you retrieved
that
> >> command?
> >> > > > (2) the full path to the "*_ADPUPA.txt" file that's showing
up (I
> >> want
> >> > to
> >> > > > see what directory it's showing up in).
> >> > > >
> >> > > > Thanks,
> >> > > > John
> >> > > >
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPSFC.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPUPA.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCAR.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCFT.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ERS1DA.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GOESND.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GPSIPW.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_MSONET.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_PROFLR.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_QKSWND.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_RASSDA.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATEMP.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATWND.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCBOG.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCSHP.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SPSSMI.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SYNDAT.txt
> >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_VADWND.txt
> >> > > >
> >> > > > On Mon, Mar 23, 2020 at 12:08 PM perry.shafran at noaa.gov via
RT <
> >> > > > met_help at ucar.edu> wrote:
> >> > > >
> >> > > > >
> >> > > > > Mon Mar 23 12:08:05 2020: Request 94683 was acted upon.
> >> > > > > Transaction: Ticket created by perry.shafran at noaa.gov
> >> > > > > Queue: met_help
> >> > > > > Subject: prepbufr dump files being written out
> >> > > > > Owner: Nobody
> >> > > > > Requestors: perry.shafran at noaa.gov
> >> > > > > Status: new
> >> > > > > Ticket <URL:
> >> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
> >> > > >
> >> > > > >
> >> > > > >
> >> > > > > Hi, everyone,
> >> > > > >
> >> > > > > At today's METplus call with EMC, I had asked John about
the
> fact
> >> > that
> >> > > > with
> >> > > > > the new METv9, that I am seeing prepbufr dump files being
> written
> >> > out,
> >> > > > and
> >> > > > > John said that this shouldn't be written out because it's
> mainly a
> >> > > > > debugging feature. I had not changed my METplus system
(still
> >> > working
> >> > > > from
> >> > > > > an old beta), but I did change MET to v9. This dump file
was
> not
> >> > > > produced
> >> > > > > in the old system. John said that this would happen if
the
> -dump
> >> > > option
> >> > > > > was included in the PB2NC command.
> >> > > > >
> >> > > > > Here's the command that was used for the most recent use
of
> >> METplus,
> >> > > and
> >> > > > > the -dump option is not included in the command. Maybe
the -v 4
> >> is
> >> > one
> >> > > > > thing that causes the output to be written? Or is it
something
> >> else?
> >> > > > > Maybe I'll try to run with a -v 2 or 3 and see if it
happens?
> >> (Not
> >> > > today
> >> > > > > because the machines are not accessible today).
> >> > > > >
> >> > > > >
> >> >
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.0/bin/pb2nc
> >> > > > -v
> >> > > > > 4
> >> >
/gpfs/dell1/nco/ops/com/nam/prod/nam.20200319/nam.t06z.prepbufr.tm06
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/nam/conus_sfc/
> >> > > > > prepbufr.nam.2020031900.nc
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/met_config/PB2NCConfig_perry
> >> > > > >
> >> > > > > Thanks!
> >> > > > >
> >> > > > > Perry
> >> > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
>
>
------------------------------------------------
Subject: prepbufr dump files being written out
From: John Halley Gotway
Time: Tue Mar 24 16:13:08 2020
Perry,
Thanks. FYI, I just added you to the MET repository, so we can assign
issues to you ;) You should be receiving an email inviting you to
join.
John
On Tue, Mar 24, 2020 at 3:20 PM perry.shafran at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
>
> I just got onto GitHub late last week. PerryShafran-NOAA I think is
my
> username.
>
> Perry
>
> On Tue, Mar 24, 2020 at 5:16 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Perry,
> >
> > FYI, here's the bug report ticket I created for this issue:
> > https://github.com/NCAR/MET/issues/1286
> >
> > If you send me your GitHub username, I can include you on the
ticket so
> > you'll get notifications about it.
> >
> > Thanks,
> > John
> >
> > On Mon, Mar 23, 2020 at 6:46 PM John Halley Gotway
<johnhg at ucar.edu>
> > wrote:
> >
> > > Hi Perry,
> > >
> > > I was able to log on and do some testing. I'm working on venus
> > > in /u/John.H.Gotway/MET/MET_Help/shafran_data_20200323
> > >
> > > I was able to compile a test version of pb2nc there and try
things out.
> > I
> > > definitely see the behavior you describe. pb2nc sets the
dump_flag to
> > true,
> > > even though we haven't used the "-dump" command line option to
do so.
> > This
> > > looks to me like a lot like a memory issue. When I add some
debug log
> > > messages and recompile, the behavior either stays the same or
goes
> away,
> > > depending on where I add the log message. Any change to the
compiled
> > code,
> > > as small as it might be, affects the memory alignment. And it
can mask
> > the
> > > memory problem.
> > >
> > > The code for handling the "dump_flag" is correct. The boolean
value is
> > > correctly set to false. Then some other part of the code is
> overwriting
> > > the end of its array and corrupting that boolean value...
setting it to
> > > some non-zero value... e.g. true. While the problem appears as
an
> issue
> > > with dump_flag, the real problem is somewhere else. So I'm
pretty
> > > confident this is a pesky little bug in the MET code itself.
> > >
> > > There is an Intel compiler option that's really useful in these
cases
> > > (-ftrapuv). Rather than initializing allocated memory to normal
> values,
> > > like 0, it initialize it to really weird values. And that often
leads
> to
> > > other runtime arrows that highlight the offending code.
> > >
> > > Thanks for letting us know about this behavior!
> > >
> > > Julie, can you please compile a second version of MET on
venus... just
> > the
> > > met-9.0 code. We can reuse the existing dependent libraries.
But
> > > configure/compile MET using the "-ftrapuv" option.
> > >
> > > Thanks,
> > > John
> > >
> > > On Mon, Mar 23, 2020 at 2:11 PM perry.shafran at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > >>
> > >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
> > >>
> > >> The machine is available now, since they halted the testing
they were
> > >> doing, but they will try to do the test again tomorrow. Which
means
> now
> > >> is
> > >> your chance to take a look-see.
> > >>
> > >> I am also re-running so I have a more complete case to show
you. When
> > >> finished, that log file will
> > >> be
> > >>
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200323200145
> > >>
> > >> Thanks!
> > >>
> > >> Perry
> > >>
> > >> On Mon, Mar 23, 2020 at 4:06 PM John Halley Gotway via RT <
> > >> met_help at ucar.edu>
> > >> wrote:
> > >>
> > >> > Perry,
> > >> >
> > >> > Yes, that log message indicates that somehow the dump logic
in PB2NC
> > has
> > >> > been enabled...
> > >> > DEBUG 1: Dumping to ASCII output directory: .
> > >> >
> > >> > When the machines are available again, I'll take a closer
look.
> Seems
> > >> like
> > >> > the suspects still are:
> > >> > (1) an issue in pb2nc itself
> > >> > (2) an issue in METplus
> > >> > (3) an issue in your runtime environment
> > >> >
> > >> > Seems like we should be able to figure this one out!
> > >> >
> > >> > Thanks,
> > >> > John
> > >> >
> > >> >
> > >> >
> > >> > On Mon, Mar 23, 2020 at 12:43 PM perry.shafran at noaa.gov via
RT <
> > >> > met_help at ucar.edu> wrote:
> > >> >
> > >> > >
> > >> > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
> > >> > >
> > >> > > FYI - I found one of these lines in the dump file. This is
when I
> > run
> > >> > > interactively in the
> > >> > > directory
> > >> > >
> > >> >
> > >>
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/use_cases/perry
> > >> > >
> > >> > > DEBUG 1: Dumping to ASCII output directory: .
> > >> > >
> > >> > > I also see that there are files that were not deleted in
the
> > >> directory.
> > >> > > You can find them there.
> > >> > >
> > >> > > I think the log file that goes with these files (based on
the
> > >> timestamp
> > >> > of
> > >> > > all the files)
> > >> > > is
> > >> > >
> > >> >
> > >>
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200320182603.
> > >> > >
> > >> > > Perry
> > >> > >
> > >> > > On Mon, Mar 23, 2020 at 2:24 PM John Halley Gotway via RT <
> > >> > > met_help at ucar.edu>
> > >> > > wrote:
> > >> > >
> > >> > > > Perry,
> > >> > > >
> > >> > > > This is very interesting. I did test met-9.0 pb2nc with
some
> > sample
> > >> > data
> > >> > > > using "-v 4" on the command line but that did not
replicate this
> > >> > behavior
> > >> > > > you describe. When I added "-dump ." to command line, it
> > triggered
> > >> > that
> > >> > > > logic and wrote many ascii output files to my current
working
> > >> > > directory...
> > >> > > > one for each message type (see below).
> > >> > > >
> > >> > > > So the mystery is, how is this pb2nc logic getting
triggered via
> > >> > METplus?
> > >> > > >
> > >> > > > Thanks for sending that pb2nc command. Can you also
please
> > send...
> > >> > > > (1) the full path to the logfile from which you retrieved
that
> > >> command?
> > >> > > > (2) the full path to the "*_ADPUPA.txt" file that's
showing up
> (I
> > >> want
> > >> > to
> > >> > > > see what directory it's showing up in).
> > >> > > >
> > >> > > > Thanks,
> > >> > > > John
> > >> > > >
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPSFC.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPUPA.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCAR.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCFT.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ERS1DA.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GOESND.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GPSIPW.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_MSONET.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_PROFLR.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_QKSWND.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_RASSDA.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATEMP.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATWND.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCBOG.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCSHP.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SPSSMI.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SYNDAT.txt
> > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_VADWND.txt
> > >> > > >
> > >> > > > On Mon, Mar 23, 2020 at 12:08 PM perry.shafran at noaa.gov
via RT
> <
> > >> > > > met_help at ucar.edu> wrote:
> > >> > > >
> > >> > > > >
> > >> > > > > Mon Mar 23 12:08:05 2020: Request 94683 was acted upon.
> > >> > > > > Transaction: Ticket created by perry.shafran at noaa.gov
> > >> > > > > Queue: met_help
> > >> > > > > Subject: prepbufr dump files being written out
> > >> > > > > Owner: Nobody
> > >> > > > > Requestors: perry.shafran at noaa.gov
> > >> > > > > Status: new
> > >> > > > > Ticket <URL:
> > >> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
> > >> > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > Hi, everyone,
> > >> > > > >
> > >> > > > > At today's METplus call with EMC, I had asked John
about the
> > fact
> > >> > that
> > >> > > > with
> > >> > > > > the new METv9, that I am seeing prepbufr dump files
being
> > written
> > >> > out,
> > >> > > > and
> > >> > > > > John said that this shouldn't be written out because
it's
> > mainly a
> > >> > > > > debugging feature. I had not changed my METplus system
(still
> > >> > working
> > >> > > > from
> > >> > > > > an old beta), but I did change MET to v9. This dump
file was
> > not
> > >> > > > produced
> > >> > > > > in the old system. John said that this would happen if
the
> > -dump
> > >> > > option
> > >> > > > > was included in the PB2NC command.
> > >> > > > >
> > >> > > > > Here's the command that was used for the most recent
use of
> > >> METplus,
> > >> > > and
> > >> > > > > the -dump option is not included in the command. Maybe
the
> -v 4
> > >> is
> > >> > one
> > >> > > > > thing that causes the output to be written? Or is it
> something
> > >> else?
> > >> > > > > Maybe I'll try to run with a -v 2 or 3 and see if it
happens?
> > >> (Not
> > >> > > today
> > >> > > > > because the machines are not accessible today).
> > >> > > > >
> > >> > > > >
> > >> >
> >
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.0/bin/pb2nc
> > >> > > > -v
> > >> > > > > 4
> > >> >
/gpfs/dell1/nco/ops/com/nam/prod/nam.20200319/nam.t06z.prepbufr.tm06
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/nam/conus_sfc/
> > >> > > > > prepbufr.nam.2020031900.nc
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/met_config/PB2NCConfig_perry
> > >> > > > >
> > >> > > > > Thanks!
> > >> > > > >
> > >> > > > > Perry
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >>
> > >>
> >
> >
>
>
------------------------------------------------
Subject: prepbufr dump files being written out
From: perry.shafran at noaa.gov
Time: Wed Mar 25 06:06:15 2020
Hi, John,
I joined, so I think I'm now part of your team!
Perry
On Tue, Mar 24, 2020 at 6:13 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Perry,
>
> Thanks. FYI, I just added you to the MET repository, so we can
assign
> issues to you ;) You should be receiving an email inviting you to
join.
>
> John
>
> On Tue, Mar 24, 2020 at 3:20 PM perry.shafran at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
> >
> > I just got onto GitHub late last week. PerryShafran-NOAA I think
is my
> > username.
> >
> > Perry
> >
> > On Tue, Mar 24, 2020 at 5:16 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Perry,
> > >
> > > FYI, here's the bug report ticket I created for this issue:
> > > https://github.com/NCAR/MET/issues/1286
> > >
> > > If you send me your GitHub username, I can include you on the
ticket so
> > > you'll get notifications about it.
> > >
> > > Thanks,
> > > John
> > >
> > > On Mon, Mar 23, 2020 at 6:46 PM John Halley Gotway
<johnhg at ucar.edu>
> > > wrote:
> > >
> > > > Hi Perry,
> > > >
> > > > I was able to log on and do some testing. I'm working on
venus
> > > > in /u/John.H.Gotway/MET/MET_Help/shafran_data_20200323
> > > >
> > > > I was able to compile a test version of pb2nc there and try
things
> out.
> > > I
> > > > definitely see the behavior you describe. pb2nc sets the
dump_flag to
> > > true,
> > > > even though we haven't used the "-dump" command line option to
do so.
> > > This
> > > > looks to me like a lot like a memory issue. When I add some
debug
> log
> > > > messages and recompile, the behavior either stays the same or
goes
> > away,
> > > > depending on where I add the log message. Any change to the
compiled
> > > code,
> > > > as small as it might be, affects the memory alignment. And it
can
> mask
> > > the
> > > > memory problem.
> > > >
> > > > The code for handling the "dump_flag" is correct. The boolean
value
> is
> > > > correctly set to false. Then some other part of the code is
> > overwriting
> > > > the end of its array and corrupting that boolean value...
setting it
> to
> > > > some non-zero value... e.g. true. While the problem appears
as an
> > issue
> > > > with dump_flag, the real problem is somewhere else. So I'm
pretty
> > > > confident this is a pesky little bug in the MET code itself.
> > > >
> > > > There is an Intel compiler option that's really useful in
these cases
> > > > (-ftrapuv). Rather than initializing allocated memory to
normal
> > values,
> > > > like 0, it initialize it to really weird values. And that
often
> leads
> > to
> > > > other runtime arrows that highlight the offending code.
> > > >
> > > > Thanks for letting us know about this behavior!
> > > >
> > > > Julie, can you please compile a second version of MET on
venus...
> just
> > > the
> > > > met-9.0 code. We can reuse the existing dependent libraries.
But
> > > > configure/compile MET using the "-ftrapuv" option.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > > On Mon, Mar 23, 2020 at 2:11 PM perry.shafran at noaa.gov via RT
<
> > > > met_help at ucar.edu> wrote:
> > > >
> > > >>
> > > >> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
>
> > > >>
> > > >> The machine is available now, since they halted the testing
they
> were
> > > >> doing, but they will try to do the test again tomorrow.
Which means
> > now
> > > >> is
> > > >> your chance to take a look-see.
> > > >>
> > > >> I am also re-running so I have a more complete case to show
you.
> When
> > > >> finished, that log file will
> > > >> be
> > > >>
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200323200145
> > > >>
> > > >> Thanks!
> > > >>
> > > >> Perry
> > > >>
> > > >> On Mon, Mar 23, 2020 at 4:06 PM John Halley Gotway via RT <
> > > >> met_help at ucar.edu>
> > > >> wrote:
> > > >>
> > > >> > Perry,
> > > >> >
> > > >> > Yes, that log message indicates that somehow the dump logic
in
> PB2NC
> > > has
> > > >> > been enabled...
> > > >> > DEBUG 1: Dumping to ASCII output directory: .
> > > >> >
> > > >> > When the machines are available again, I'll take a closer
look.
> > Seems
> > > >> like
> > > >> > the suspects still are:
> > > >> > (1) an issue in pb2nc itself
> > > >> > (2) an issue in METplus
> > > >> > (3) an issue in your runtime environment
> > > >> >
> > > >> > Seems like we should be able to figure this one out!
> > > >> >
> > > >> > Thanks,
> > > >> > John
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Mon, Mar 23, 2020 at 12:43 PM perry.shafran at noaa.gov via
RT <
> > > >> > met_help at ucar.edu> wrote:
> > > >> >
> > > >> > >
> > > >> > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
> > > >> > >
> > > >> > > FYI - I found one of these lines in the dump file. This
is
> when I
> > > run
> > > >> > > interactively in the
> > > >> > > directory
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/use_cases/perry
> > > >> > >
> > > >> > > DEBUG 1: Dumping to ASCII output directory: .
> > > >> > >
> > > >> > > I also see that there are files that were not deleted in
the
> > > >> directory.
> > > >> > > You can find them there.
> > > >> > >
> > > >> > > I think the log file that goes with these files (based on
the
> > > >> timestamp
> > > >> > of
> > > >> > > all the files)
> > > >> > > is
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200320182603.
> > > >> > >
> > > >> > > Perry
> > > >> > >
> > > >> > > On Mon, Mar 23, 2020 at 2:24 PM John Halley Gotway via RT
<
> > > >> > > met_help at ucar.edu>
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Perry,
> > > >> > > >
> > > >> > > > This is very interesting. I did test met-9.0 pb2nc
with some
> > > sample
> > > >> > data
> > > >> > > > using "-v 4" on the command line but that did not
replicate
> this
> > > >> > behavior
> > > >> > > > you describe. When I added "-dump ." to command line,
it
> > > triggered
> > > >> > that
> > > >> > > > logic and wrote many ascii output files to my current
working
> > > >> > > directory...
> > > >> > > > one for each message type (see below).
> > > >> > > >
> > > >> > > > So the mystery is, how is this pb2nc logic getting
triggered
> via
> > > >> > METplus?
> > > >> > > >
> > > >> > > > Thanks for sending that pb2nc command. Can you also
please
> > > send...
> > > >> > > > (1) the full path to the logfile from which you
retrieved that
> > > >> command?
> > > >> > > > (2) the full path to the "*_ADPUPA.txt" file that's
showing up
> > (I
> > > >> want
> > > >> > to
> > > >> > > > see what directory it's showing up in).
> > > >> > > >
> > > >> > > > Thanks,
> > > >> > > > John
> > > >> > > >
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPSFC.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPUPA.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCAR.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCFT.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ERS1DA.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GOESND.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GPSIPW.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_MSONET.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_PROFLR.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_QKSWND.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_RASSDA.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATEMP.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATWND.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCBOG.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCSHP.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SPSSMI.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SYNDAT.txt
> > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_VADWND.txt
> > > >> > > >
> > > >> > > > On Mon, Mar 23, 2020 at 12:08 PM perry.shafran at noaa.gov
via
> RT
> > <
> > > >> > > > met_help at ucar.edu> wrote:
> > > >> > > >
> > > >> > > > >
> > > >> > > > > Mon Mar 23 12:08:05 2020: Request 94683 was acted
upon.
> > > >> > > > > Transaction: Ticket created by perry.shafran at noaa.gov
> > > >> > > > > Queue: met_help
> > > >> > > > > Subject: prepbufr dump files being written out
> > > >> > > > > Owner: Nobody
> > > >> > > > > Requestors: perry.shafran at noaa.gov
> > > >> > > > > Status: new
> > > >> > > > > Ticket <URL:
> > > >> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
> > > >> > > >
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > Hi, everyone,
> > > >> > > > >
> > > >> > > > > At today's METplus call with EMC, I had asked John
about the
> > > fact
> > > >> > that
> > > >> > > > with
> > > >> > > > > the new METv9, that I am seeing prepbufr dump files
being
> > > written
> > > >> > out,
> > > >> > > > and
> > > >> > > > > John said that this shouldn't be written out because
it's
> > > mainly a
> > > >> > > > > debugging feature. I had not changed my METplus
system
> (still
> > > >> > working
> > > >> > > > from
> > > >> > > > > an old beta), but I did change MET to v9. This dump
file
> was
> > > not
> > > >> > > > produced
> > > >> > > > > in the old system. John said that this would happen
if the
> > > -dump
> > > >> > > option
> > > >> > > > > was included in the PB2NC command.
> > > >> > > > >
> > > >> > > > > Here's the command that was used for the most recent
use of
> > > >> METplus,
> > > >> > > and
> > > >> > > > > the -dump option is not included in the command.
Maybe the
> > -v 4
> > > >> is
> > > >> > one
> > > >> > > > > thing that causes the output to be written? Or is it
> > something
> > > >> else?
> > > >> > > > > Maybe I'll try to run with a -v 2 or 3 and see if it
> happens?
> > > >> (Not
> > > >> > > today
> > > >> > > > > because the machines are not accessible today).
> > > >> > > > >
> > > >> > > > >
> > > >> >
> > >
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.0/bin/pb2nc
> > > >> > > > -v
> > > >> > > > > 4
> > > >> >
> /gpfs/dell1/nco/ops/com/nam/prod/nam.20200319/nam.t06z.prepbufr.tm06
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/nam/conus_sfc/
> > > >> > > > > prepbufr.nam.2020031900.nc
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/met_config/PB2NCConfig_perry
> > > >> > > > >
> > > >> > > > > Thanks!
> > > >> > > > >
> > > >> > > > > Perry
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >> >
> > > >>
> > > >>
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: prepbufr dump files being written out
From: John Halley Gotway
Time: Wed Mar 25 09:36:26 2020
Perry,
According to GitHub, it still says your invite is Pending. See
attached
screenshot.
Try signing into GitHub and then going to this link:
https://github.com/NCAR/MET/invitations
Thanks,
John
On Wed, Mar 25, 2020 at 6:06 AM perry.shafran at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
>
> Hi, John,
>
> I joined, so I think I'm now part of your team!
>
> Perry
>
> On Tue, Mar 24, 2020 at 6:13 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Perry,
> >
> > Thanks. FYI, I just added you to the MET repository, so we can
assign
> > issues to you ;) You should be receiving an email inviting you to
join.
> >
> > John
> >
> > On Tue, Mar 24, 2020 at 3:20 PM perry.shafran at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
> > >
> > > I just got onto GitHub late last week. PerryShafran-NOAA I
think is my
> > > username.
> > >
> > > Perry
> > >
> > > On Tue, Mar 24, 2020 at 5:16 PM John Halley Gotway via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > > Perry,
> > > >
> > > > FYI, here's the bug report ticket I created for this issue:
> > > > https://github.com/NCAR/MET/issues/1286
> > > >
> > > > If you send me your GitHub username, I can include you on the
ticket
> so
> > > > you'll get notifications about it.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > > On Mon, Mar 23, 2020 at 6:46 PM John Halley Gotway
<johnhg at ucar.edu>
> > > > wrote:
> > > >
> > > > > Hi Perry,
> > > > >
> > > > > I was able to log on and do some testing. I'm working on
venus
> > > > > in /u/John.H.Gotway/MET/MET_Help/shafran_data_20200323
> > > > >
> > > > > I was able to compile a test version of pb2nc there and try
things
> > out.
> > > > I
> > > > > definitely see the behavior you describe. pb2nc sets the
dump_flag
> to
> > > > true,
> > > > > even though we haven't used the "-dump" command line option
to do
> so.
> > > > This
> > > > > looks to me like a lot like a memory issue. When I add some
debug
> > log
> > > > > messages and recompile, the behavior either stays the same
or goes
> > > away,
> > > > > depending on where I add the log message. Any change to the
> compiled
> > > > code,
> > > > > as small as it might be, affects the memory alignment. And
it can
> > mask
> > > > the
> > > > > memory problem.
> > > > >
> > > > > The code for handling the "dump_flag" is correct. The
boolean
> value
> > is
> > > > > correctly set to false. Then some other part of the code is
> > > overwriting
> > > > > the end of its array and corrupting that boolean value...
setting
> it
> > to
> > > > > some non-zero value... e.g. true. While the problem appears
as an
> > > issue
> > > > > with dump_flag, the real problem is somewhere else. So I'm
pretty
> > > > > confident this is a pesky little bug in the MET code itself.
> > > > >
> > > > > There is an Intel compiler option that's really useful in
these
> cases
> > > > > (-ftrapuv). Rather than initializing allocated memory to
normal
> > > values,
> > > > > like 0, it initialize it to really weird values. And that
often
> > leads
> > > to
> > > > > other runtime arrows that highlight the offending code.
> > > > >
> > > > > Thanks for letting us know about this behavior!
> > > > >
> > > > > Julie, can you please compile a second version of MET on
venus...
> > just
> > > > the
> > > > > met-9.0 code. We can reuse the existing dependent
libraries. But
> > > > > configure/compile MET using the "-ftrapuv" option.
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > > On Mon, Mar 23, 2020 at 2:11 PM perry.shafran at noaa.gov via
RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > >>
> > > > >> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
> > > > >>
> > > > >> The machine is available now, since they halted the testing
they
> > were
> > > > >> doing, but they will try to do the test again tomorrow.
Which
> means
> > > now
> > > > >> is
> > > > >> your chance to take a look-see.
> > > > >>
> > > > >> I am also re-running so I have a more complete case to show
you.
> > When
> > > > >> finished, that log file will
> > > > >> be
> > > > >>
> > > >
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200323200145
> > > > >>
> > > > >> Thanks!
> > > > >>
> > > > >> Perry
> > > > >>
> > > > >> On Mon, Mar 23, 2020 at 4:06 PM John Halley Gotway via RT <
> > > > >> met_help at ucar.edu>
> > > > >> wrote:
> > > > >>
> > > > >> > Perry,
> > > > >> >
> > > > >> > Yes, that log message indicates that somehow the dump
logic in
> > PB2NC
> > > > has
> > > > >> > been enabled...
> > > > >> > DEBUG 1: Dumping to ASCII output directory: .
> > > > >> >
> > > > >> > When the machines are available again, I'll take a closer
look.
> > > Seems
> > > > >> like
> > > > >> > the suspects still are:
> > > > >> > (1) an issue in pb2nc itself
> > > > >> > (2) an issue in METplus
> > > > >> > (3) an issue in your runtime environment
> > > > >> >
> > > > >> > Seems like we should be able to figure this one out!
> > > > >> >
> > > > >> > Thanks,
> > > > >> > John
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On Mon, Mar 23, 2020 at 12:43 PM perry.shafran at noaa.gov
via RT
> <
> > > > >> > met_help at ucar.edu> wrote:
> > > > >> >
> > > > >> > >
> > > > >> > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
> >
> > > > >> > >
> > > > >> > > FYI - I found one of these lines in the dump file.
This is
> > when I
> > > > run
> > > > >> > > interactively in the
> > > > >> > > directory
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/use_cases/perry
> > > > >> > >
> > > > >> > > DEBUG 1: Dumping to ASCII output directory: .
> > > > >> > >
> > > > >> > > I also see that there are files that were not deleted
in the
> > > > >> directory.
> > > > >> > > You can find them there.
> > > > >> > >
> > > > >> > > I think the log file that goes with these files (based
on the
> > > > >> timestamp
> > > > >> > of
> > > > >> > > all the files)
> > > > >> > > is
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200320182603.
> > > > >> > >
> > > > >> > > Perry
> > > > >> > >
> > > > >> > > On Mon, Mar 23, 2020 at 2:24 PM John Halley Gotway via
RT <
> > > > >> > > met_help at ucar.edu>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > > Perry,
> > > > >> > > >
> > > > >> > > > This is very interesting. I did test met-9.0 pb2nc
with
> some
> > > > sample
> > > > >> > data
> > > > >> > > > using "-v 4" on the command line but that did not
replicate
> > this
> > > > >> > behavior
> > > > >> > > > you describe. When I added "-dump ." to command
line, it
> > > > triggered
> > > > >> > that
> > > > >> > > > logic and wrote many ascii output files to my current
> working
> > > > >> > > directory...
> > > > >> > > > one for each message type (see below).
> > > > >> > > >
> > > > >> > > > So the mystery is, how is this pb2nc logic getting
triggered
> > via
> > > > >> > METplus?
> > > > >> > > >
> > > > >> > > > Thanks for sending that pb2nc command. Can you also
please
> > > > send...
> > > > >> > > > (1) the full path to the logfile from which you
retrieved
> that
> > > > >> command?
> > > > >> > > > (2) the full path to the "*_ADPUPA.txt" file that's
showing
> up
> > > (I
> > > > >> want
> > > > >> > to
> > > > >> > > > see what directory it's showing up in).
> > > > >> > > >
> > > > >> > > > Thanks,
> > > > >> > > > John
> > > > >> > > >
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPSFC.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPUPA.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCAR.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCFT.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ERS1DA.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GOESND.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GPSIPW.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_MSONET.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_PROFLR.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_QKSWND.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_RASSDA.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATEMP.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATWND.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCBOG.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCSHP.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SPSSMI.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SYNDAT.txt
> > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_VADWND.txt
> > > > >> > > >
> > > > >> > > > On Mon, Mar 23, 2020 at 12:08 PM
perry.shafran at noaa.gov via
> > RT
> > > <
> > > > >> > > > met_help at ucar.edu> wrote:
> > > > >> > > >
> > > > >> > > > >
> > > > >> > > > > Mon Mar 23 12:08:05 2020: Request 94683 was acted
upon.
> > > > >> > > > > Transaction: Ticket created by
perry.shafran at noaa.gov
> > > > >> > > > > Queue: met_help
> > > > >> > > > > Subject: prepbufr dump files being written out
> > > > >> > > > > Owner: Nobody
> > > > >> > > > > Requestors: perry.shafran at noaa.gov
> > > > >> > > > > Status: new
> > > > >> > > > > Ticket <URL:
> > > > >> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
> > > > >> > > >
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > > > Hi, everyone,
> > > > >> > > > >
> > > > >> > > > > At today's METplus call with EMC, I had asked John
about
> the
> > > > fact
> > > > >> > that
> > > > >> > > > with
> > > > >> > > > > the new METv9, that I am seeing prepbufr dump files
being
> > > > written
> > > > >> > out,
> > > > >> > > > and
> > > > >> > > > > John said that this shouldn't be written out
because it's
> > > > mainly a
> > > > >> > > > > debugging feature. I had not changed my METplus
system
> > (still
> > > > >> > working
> > > > >> > > > from
> > > > >> > > > > an old beta), but I did change MET to v9. This
dump file
> > was
> > > > not
> > > > >> > > > produced
> > > > >> > > > > in the old system. John said that this would
happen if
> the
> > > > -dump
> > > > >> > > option
> > > > >> > > > > was included in the PB2NC command.
> > > > >> > > > >
> > > > >> > > > > Here's the command that was used for the most
recent use
> of
> > > > >> METplus,
> > > > >> > > and
> > > > >> > > > > the -dump option is not included in the command.
Maybe
> the
> > > -v 4
> > > > >> is
> > > > >> > one
> > > > >> > > > > thing that causes the output to be written? Or is
it
> > > something
> > > > >> else?
> > > > >> > > > > Maybe I'll try to run with a -v 2 or 3 and see if
it
> > happens?
> > > > >> (Not
> > > > >> > > today
> > > > >> > > > > because the machines are not accessible today).
> > > > >> > > > >
> > > > >> > > > >
> > > > >> >
> > > >
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.0/bin/pb2nc
> > > > >> > > > -v
> > > > >> > > > > 4
> > > > >> >
> >
/gpfs/dell1/nco/ops/com/nam/prod/nam.20200319/nam.t06z.prepbufr.tm06
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/nam/conus_sfc/
> > > > >> > > > > prepbufr.nam.2020031900.nc
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/met_config/PB2NCConfig_perry
> > > > >> > > > >
> > > > >> > > > > Thanks!
> > > > >> > > > >
> > > > >> > > > > Perry
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: prepbufr dump files being written out
From: perry.shafran at noaa.gov
Time: Wed Mar 25 09:42:02 2020
OK, now it should have been accepted!
Perry
On Wed, Mar 25, 2020 at 11:36 AM John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Perry,
>
> According to GitHub, it still says your invite is Pending. See
attached
> screenshot.
>
> Try signing into GitHub and then going to this link:
> https://github.com/NCAR/MET/invitations
>
> Thanks,
> John
>
> On Wed, Mar 25, 2020 at 6:06 AM perry.shafran at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
> >
> > Hi, John,
> >
> > I joined, so I think I'm now part of your team!
> >
> > Perry
> >
> > On Tue, Mar 24, 2020 at 6:13 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Perry,
> > >
> > > Thanks. FYI, I just added you to the MET repository, so we can
assign
> > > issues to you ;) You should be receiving an email inviting you
to
> join.
> > >
> > > John
> > >
> > > On Tue, Mar 24, 2020 at 3:20 PM perry.shafran at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
>
> > > >
> > > > I just got onto GitHub late last week. PerryShafran-NOAA I
think is
> my
> > > > username.
> > > >
> > > > Perry
> > > >
> > > > On Tue, Mar 24, 2020 at 5:16 PM John Halley Gotway via RT <
> > > > met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > > Perry,
> > > > >
> > > > > FYI, here's the bug report ticket I created for this issue:
> > > > > https://github.com/NCAR/MET/issues/1286
> > > > >
> > > > > If you send me your GitHub username, I can include you on
the
> ticket
> > so
> > > > > you'll get notifications about it.
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > > On Mon, Mar 23, 2020 at 6:46 PM John Halley Gotway <
> johnhg at ucar.edu>
> > > > > wrote:
> > > > >
> > > > > > Hi Perry,
> > > > > >
> > > > > > I was able to log on and do some testing. I'm working on
venus
> > > > > > in /u/John.H.Gotway/MET/MET_Help/shafran_data_20200323
> > > > > >
> > > > > > I was able to compile a test version of pb2nc there and
try
> things
> > > out.
> > > > > I
> > > > > > definitely see the behavior you describe. pb2nc sets the
> dump_flag
> > to
> > > > > true,
> > > > > > even though we haven't used the "-dump" command line
option to do
> > so.
> > > > > This
> > > > > > looks to me like a lot like a memory issue. When I add
some
> debug
> > > log
> > > > > > messages and recompile, the behavior either stays the same
or
> goes
> > > > away,
> > > > > > depending on where I add the log message. Any change to
the
> > compiled
> > > > > code,
> > > > > > as small as it might be, affects the memory alignment.
And it
> can
> > > mask
> > > > > the
> > > > > > memory problem.
> > > > > >
> > > > > > The code for handling the "dump_flag" is correct. The
boolean
> > value
> > > is
> > > > > > correctly set to false. Then some other part of the code
is
> > > > overwriting
> > > > > > the end of its array and corrupting that boolean value...
setting
> > it
> > > to
> > > > > > some non-zero value... e.g. true. While the problem
appears as
> an
> > > > issue
> > > > > > with dump_flag, the real problem is somewhere else. So
I'm
> pretty
> > > > > > confident this is a pesky little bug in the MET code
itself.
> > > > > >
> > > > > > There is an Intel compiler option that's really useful in
these
> > cases
> > > > > > (-ftrapuv). Rather than initializing allocated memory to
normal
> > > > values,
> > > > > > like 0, it initialize it to really weird values. And that
often
> > > leads
> > > > to
> > > > > > other runtime arrows that highlight the offending code.
> > > > > >
> > > > > > Thanks for letting us know about this behavior!
> > > > > >
> > > > > > Julie, can you please compile a second version of MET on
venus...
> > > just
> > > > > the
> > > > > > met-9.0 code. We can reuse the existing dependent
libraries.
> But
> > > > > > configure/compile MET using the "-ftrapuv" option.
> > > > > >
> > > > > > Thanks,
> > > > > > John
> > > > > >
> > > > > > On Mon, Mar 23, 2020 at 2:11 PM perry.shafran at noaa.gov via
RT <
> > > > > > met_help at ucar.edu> wrote:
> > > > > >
> > > > > >>
> > > > > >> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
> > > > > >>
> > > > > >> The machine is available now, since they halted the
testing they
> > > were
> > > > > >> doing, but they will try to do the test again tomorrow.
Which
> > means
> > > > now
> > > > > >> is
> > > > > >> your chance to take a look-see.
> > > > > >>
> > > > > >> I am also re-running so I have a more complete case to
show you.
> > > When
> > > > > >> finished, that log file will
> > > > > >> be
> > > > > >>
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200323200145
> > > > > >>
> > > > > >> Thanks!
> > > > > >>
> > > > > >> Perry
> > > > > >>
> > > > > >> On Mon, Mar 23, 2020 at 4:06 PM John Halley Gotway via RT
<
> > > > > >> met_help at ucar.edu>
> > > > > >> wrote:
> > > > > >>
> > > > > >> > Perry,
> > > > > >> >
> > > > > >> > Yes, that log message indicates that somehow the dump
logic in
> > > PB2NC
> > > > > has
> > > > > >> > been enabled...
> > > > > >> > DEBUG 1: Dumping to ASCII output directory: .
> > > > > >> >
> > > > > >> > When the machines are available again, I'll take a
closer
> look.
> > > > Seems
> > > > > >> like
> > > > > >> > the suspects still are:
> > > > > >> > (1) an issue in pb2nc itself
> > > > > >> > (2) an issue in METplus
> > > > > >> > (3) an issue in your runtime environment
> > > > > >> >
> > > > > >> > Seems like we should be able to figure this one out!
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> > John
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > On Mon, Mar 23, 2020 at 12:43 PM perry.shafran at noaa.gov
via
> RT
> > <
> > > > > >> > met_help at ucar.edu> wrote:
> > > > > >> >
> > > > > >> > >
> > > > > >> > > <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
> > >
> > > > > >> > >
> > > > > >> > > FYI - I found one of these lines in the dump file.
This is
> > > when I
> > > > > run
> > > > > >> > > interactively in the
> > > > > >> > > directory
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/use_cases/perry
> > > > > >> > >
> > > > > >> > > DEBUG 1: Dumping to ASCII output directory: .
> > > > > >> > >
> > > > > >> > > I also see that there are files that were not deleted
in the
> > > > > >> directory.
> > > > > >> > > You can find them there.
> > > > > >> > >
> > > > > >> > > I think the log file that goes with these files
(based on
> the
> > > > > >> timestamp
> > > > > >> > of
> > > > > >> > > all the files)
> > > > > >> > > is
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200320182603.
> > > > > >> > >
> > > > > >> > > Perry
> > > > > >> > >
> > > > > >> > > On Mon, Mar 23, 2020 at 2:24 PM John Halley Gotway
via RT <
> > > > > >> > > met_help at ucar.edu>
> > > > > >> > > wrote:
> > > > > >> > >
> > > > > >> > > > Perry,
> > > > > >> > > >
> > > > > >> > > > This is very interesting. I did test met-9.0 pb2nc
with
> > some
> > > > > sample
> > > > > >> > data
> > > > > >> > > > using "-v 4" on the command line but that did not
> replicate
> > > this
> > > > > >> > behavior
> > > > > >> > > > you describe. When I added "-dump ." to command
line, it
> > > > > triggered
> > > > > >> > that
> > > > > >> > > > logic and wrote many ascii output files to my
current
> > working
> > > > > >> > > directory...
> > > > > >> > > > one for each message type (see below).
> > > > > >> > > >
> > > > > >> > > > So the mystery is, how is this pb2nc logic getting
> triggered
> > > via
> > > > > >> > METplus?
> > > > > >> > > >
> > > > > >> > > > Thanks for sending that pb2nc command. Can you
also
> please
> > > > > send...
> > > > > >> > > > (1) the full path to the logfile from which you
retrieved
> > that
> > > > > >> command?
> > > > > >> > > > (2) the full path to the "*_ADPUPA.txt" file that's
> showing
> > up
> > > > (I
> > > > > >> want
> > > > > >> > to
> > > > > >> > > > see what directory it's showing up in).
> > > > > >> > > >
> > > > > >> > > > Thanks,
> > > > > >> > > > John
> > > > > >> > > >
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPSFC.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPUPA.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCAR.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCFT.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_ERS1DA.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GOESND.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_GPSIPW.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_MSONET.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_PROFLR.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_QKSWND.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_RASSDA.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATEMP.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATWND.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCBOG.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCSHP.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SPSSMI.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_SYNDAT.txt
> > > > > >> > > > dump_ndas.t00z.prepbufr.tm12.20070401.nr_VADWND.txt
> > > > > >> > > >
> > > > > >> > > > On Mon, Mar 23, 2020 at 12:08 PM
perry.shafran at noaa.gov
> via
> > > RT
> > > > <
> > > > > >> > > > met_help at ucar.edu> wrote:
> > > > > >> > > >
> > > > > >> > > > >
> > > > > >> > > > > Mon Mar 23 12:08:05 2020: Request 94683 was acted
upon.
> > > > > >> > > > > Transaction: Ticket created by
perry.shafran at noaa.gov
> > > > > >> > > > > Queue: met_help
> > > > > >> > > > > Subject: prepbufr dump files being written
out
> > > > > >> > > > > Owner: Nobody
> > > > > >> > > > > Requestors: perry.shafran at noaa.gov
> > > > > >> > > > > Status: new
> > > > > >> > > > > Ticket <URL:
> > > > > >> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
> > > > > >> > > >
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > > > Hi, everyone,
> > > > > >> > > > >
> > > > > >> > > > > At today's METplus call with EMC, I had asked
John about
> > the
> > > > > fact
> > > > > >> > that
> > > > > >> > > > with
> > > > > >> > > > > the new METv9, that I am seeing prepbufr dump
files
> being
> > > > > written
> > > > > >> > out,
> > > > > >> > > > and
> > > > > >> > > > > John said that this shouldn't be written out
because
> it's
> > > > > mainly a
> > > > > >> > > > > debugging feature. I had not changed my METplus
system
> > > (still
> > > > > >> > working
> > > > > >> > > > from
> > > > > >> > > > > an old beta), but I did change MET to v9. This
dump
> file
> > > was
> > > > > not
> > > > > >> > > > produced
> > > > > >> > > > > in the old system. John said that this would
happen if
> > the
> > > > > -dump
> > > > > >> > > option
> > > > > >> > > > > was included in the PB2NC command.
> > > > > >> > > > >
> > > > > >> > > > > Here's the command that was used for the most
recent use
> > of
> > > > > >> METplus,
> > > > > >> > > and
> > > > > >> > > > > the -dump option is not included in the command.
Maybe
> > the
> > > > -v 4
> > > > > >> is
> > > > > >> > one
> > > > > >> > > > > thing that causes the output to be written? Or
is it
> > > > something
> > > > > >> else?
> > > > > >> > > > > Maybe I'll try to run with a -v 2 or 3 and see if
it
> > > happens?
> > > > > >> (Not
> > > > > >> > > today
> > > > > >> > > > > because the machines are not accessible today).
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> >
> > > > >
> >
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.0/bin/pb2nc
> > > > > >> > > > -v
> > > > > >> > > > > 4
> > > > > >> >
> > >
/gpfs/dell1/nco/ops/com/nam/prod/nam.20200319/nam.t06z.prepbufr.tm06
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/nam/conus_sfc/
> > > > > >> > > > > prepbufr.nam.2020031900.nc
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/met_config/PB2NCConfig_perry
> > > > > >> > > > >
> > > > > >> > > > > Thanks!
> > > > > >> > > > >
> > > > > >> > > > > Perry
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> >
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: prepbufr dump files being written out
From: John Halley Gotway
Time: Wed Mar 25 09:49:40 2020
Yep, I see that. And I added you as an assignee on the PB2NC WCOSS
issue:
https://github.com/NCAR/MET/issues/1286
So you'll get an email every time a comment is added to that issue.
FYI, I've also learned that GitHub notifies people when they are
mentioned
in a comment on any issue. For example, if I comment on an issue like
this:
"@PerryShafran-NOAA recommends that we..."
Just use the @ symbol followed by the person's GitHub name.
John
On Wed, Mar 25, 2020 at 9:42 AM perry.shafran at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
>
> OK, now it should have been accepted!
>
> Perry
>
> On Wed, Mar 25, 2020 at 11:36 AM John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Perry,
> >
> > According to GitHub, it still says your invite is Pending. See
attached
> > screenshot.
> >
> > Try signing into GitHub and then going to this link:
> > https://github.com/NCAR/MET/invitations
> >
> > Thanks,
> > John
> >
> > On Wed, Mar 25, 2020 at 6:06 AM perry.shafran at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
> > >
> > > Hi, John,
> > >
> > > I joined, so I think I'm now part of your team!
> > >
> > > Perry
> > >
> > > On Tue, Mar 24, 2020 at 6:13 PM John Halley Gotway via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > > Perry,
> > > >
> > > > Thanks. FYI, I just added you to the MET repository, so we
can
> assign
> > > > issues to you ;) You should be receiving an email inviting
you to
> > join.
> > > >
> > > > John
> > > >
> > > > On Tue, Mar 24, 2020 at 3:20 PM perry.shafran at noaa.gov via RT
<
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683 >
> > > > >
> > > > > I just got onto GitHub late last week. PerryShafran-NOAA I
think
> is
> > my
> > > > > username.
> > > > >
> > > > > Perry
> > > > >
> > > > > On Tue, Mar 24, 2020 at 5:16 PM John Halley Gotway via RT <
> > > > > met_help at ucar.edu>
> > > > > wrote:
> > > > >
> > > > > > Perry,
> > > > > >
> > > > > > FYI, here's the bug report ticket I created for this
issue:
> > > > > > https://github.com/NCAR/MET/issues/1286
> > > > > >
> > > > > > If you send me your GitHub username, I can include you on
the
> > ticket
> > > so
> > > > > > you'll get notifications about it.
> > > > > >
> > > > > > Thanks,
> > > > > > John
> > > > > >
> > > > > > On Mon, Mar 23, 2020 at 6:46 PM John Halley Gotway <
> > johnhg at ucar.edu>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Perry,
> > > > > > >
> > > > > > > I was able to log on and do some testing. I'm working
on venus
> > > > > > > in /u/John.H.Gotway/MET/MET_Help/shafran_data_20200323
> > > > > > >
> > > > > > > I was able to compile a test version of pb2nc there and
try
> > things
> > > > out.
> > > > > > I
> > > > > > > definitely see the behavior you describe. pb2nc sets the
> > dump_flag
> > > to
> > > > > > true,
> > > > > > > even though we haven't used the "-dump" command line
option to
> do
> > > so.
> > > > > > This
> > > > > > > looks to me like a lot like a memory issue. When I add
some
> > debug
> > > > log
> > > > > > > messages and recompile, the behavior either stays the
same or
> > goes
> > > > > away,
> > > > > > > depending on where I add the log message. Any change to
the
> > > compiled
> > > > > > code,
> > > > > > > as small as it might be, affects the memory alignment.
And it
> > can
> > > > mask
> > > > > > the
> > > > > > > memory problem.
> > > > > > >
> > > > > > > The code for handling the "dump_flag" is correct. The
boolean
> > > value
> > > > is
> > > > > > > correctly set to false. Then some other part of the
code is
> > > > > overwriting
> > > > > > > the end of its array and corrupting that boolean
value...
> setting
> > > it
> > > > to
> > > > > > > some non-zero value... e.g. true. While the problem
appears as
> > an
> > > > > issue
> > > > > > > with dump_flag, the real problem is somewhere else. So
I'm
> > pretty
> > > > > > > confident this is a pesky little bug in the MET code
itself.
> > > > > > >
> > > > > > > There is an Intel compiler option that's really useful
in these
> > > cases
> > > > > > > (-ftrapuv). Rather than initializing allocated memory
to
> normal
> > > > > values,
> > > > > > > like 0, it initialize it to really weird values. And
that
> often
> > > > leads
> > > > > to
> > > > > > > other runtime arrows that highlight the offending code.
> > > > > > >
> > > > > > > Thanks for letting us know about this behavior!
> > > > > > >
> > > > > > > Julie, can you please compile a second version of MET on
> venus...
> > > > just
> > > > > > the
> > > > > > > met-9.0 code. We can reuse the existing dependent
libraries.
> > But
> > > > > > > configure/compile MET using the "-ftrapuv" option.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > John
> > > > > > >
> > > > > > > On Mon, Mar 23, 2020 at 2:11 PM perry.shafran at noaa.gov
via RT
> <
> > > > > > > met_help at ucar.edu> wrote:
> > > > > > >
> > > > > > >>
> > > > > > >> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
> >
> > > > > > >>
> > > > > > >> The machine is available now, since they halted the
testing
> they
> > > > were
> > > > > > >> doing, but they will try to do the test again tomorrow.
Which
> > > means
> > > > > now
> > > > > > >> is
> > > > > > >> your chance to take a look-see.
> > > > > > >>
> > > > > > >> I am also re-running so I have a more complete case to
show
> you.
> > > > When
> > > > > > >> finished, that log file will
> > > > > > >> be
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200323200145
> > > > > > >>
> > > > > > >> Thanks!
> > > > > > >>
> > > > > > >> Perry
> > > > > > >>
> > > > > > >> On Mon, Mar 23, 2020 at 4:06 PM John Halley Gotway via
RT <
> > > > > > >> met_help at ucar.edu>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> > Perry,
> > > > > > >> >
> > > > > > >> > Yes, that log message indicates that somehow the dump
logic
> in
> > > > PB2NC
> > > > > > has
> > > > > > >> > been enabled...
> > > > > > >> > DEBUG 1: Dumping to ASCII output directory: .
> > > > > > >> >
> > > > > > >> > When the machines are available again, I'll take a
closer
> > look.
> > > > > Seems
> > > > > > >> like
> > > > > > >> > the suspects still are:
> > > > > > >> > (1) an issue in pb2nc itself
> > > > > > >> > (2) an issue in METplus
> > > > > > >> > (3) an issue in your runtime environment
> > > > > > >> >
> > > > > > >> > Seems like we should be able to figure this one out!
> > > > > > >> >
> > > > > > >> > Thanks,
> > > > > > >> > John
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > On Mon, Mar 23, 2020 at 12:43 PM
perry.shafran at noaa.gov via
> > RT
> > > <
> > > > > > >> > met_help at ucar.edu> wrote:
> > > > > > >> >
> > > > > > >> > >
> > > > > > >> > > <URL:
> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
> > > >
> > > > > > >> > >
> > > > > > >> > > FYI - I found one of these lines in the dump file.
This
> is
> > > > when I
> > > > > > run
> > > > > > >> > > interactively in the
> > > > > > >> > > directory
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/use_cases/perry
> > > > > > >> > >
> > > > > > >> > > DEBUG 1: Dumping to ASCII output directory: .
> > > > > > >> > >
> > > > > > >> > > I also see that there are files that were not
deleted in
> the
> > > > > > >> directory.
> > > > > > >> > > You can find them there.
> > > > > > >> > >
> > > > > > >> > > I think the log file that goes with these files
(based on
> > the
> > > > > > >> timestamp
> > > > > > >> > of
> > > > > > >> > > all the files)
> > > > > > >> > > is
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/logs/master_metplus.log.20200320182603.
> > > > > > >> > >
> > > > > > >> > > Perry
> > > > > > >> > >
> > > > > > >> > > On Mon, Mar 23, 2020 at 2:24 PM John Halley Gotway
via RT
> <
> > > > > > >> > > met_help at ucar.edu>
> > > > > > >> > > wrote:
> > > > > > >> > >
> > > > > > >> > > > Perry,
> > > > > > >> > > >
> > > > > > >> > > > This is very interesting. I did test met-9.0
pb2nc with
> > > some
> > > > > > sample
> > > > > > >> > data
> > > > > > >> > > > using "-v 4" on the command line but that did not
> > replicate
> > > > this
> > > > > > >> > behavior
> > > > > > >> > > > you describe. When I added "-dump ." to command
line,
> it
> > > > > > triggered
> > > > > > >> > that
> > > > > > >> > > > logic and wrote many ascii output files to my
current
> > > working
> > > > > > >> > > directory...
> > > > > > >> > > > one for each message type (see below).
> > > > > > >> > > >
> > > > > > >> > > > So the mystery is, how is this pb2nc logic
getting
> > triggered
> > > > via
> > > > > > >> > METplus?
> > > > > > >> > > >
> > > > > > >> > > > Thanks for sending that pb2nc command. Can you
also
> > please
> > > > > > send...
> > > > > > >> > > > (1) the full path to the logfile from which you
> retrieved
> > > that
> > > > > > >> command?
> > > > > > >> > > > (2) the full path to the "*_ADPUPA.txt" file
that's
> > showing
> > > up
> > > > > (I
> > > > > > >> want
> > > > > > >> > to
> > > > > > >> > > > see what directory it's showing up in).
> > > > > > >> > > >
> > > > > > >> > > > Thanks,
> > > > > > >> > > > John
> > > > > > >> > > >
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPSFC.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_ADPUPA.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCAR.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_AIRCFT.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_ERS1DA.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_GOESND.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_GPSIPW.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_MSONET.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_PROFLR.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_QKSWND.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_RASSDA.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATEMP.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_SATWND.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCBOG.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_SFCSHP.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_SPSSMI.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_SYNDAT.txt
> > > > > > >> > > >
dump_ndas.t00z.prepbufr.tm12.20070401.nr_VADWND.txt
> > > > > > >> > > >
> > > > > > >> > > > On Mon, Mar 23, 2020 at 12:08 PM
perry.shafran at noaa.gov
> > via
> > > > RT
> > > > > <
> > > > > > >> > > > met_help at ucar.edu> wrote:
> > > > > > >> > > >
> > > > > > >> > > > >
> > > > > > >> > > > > Mon Mar 23 12:08:05 2020: Request 94683 was
acted
> upon.
> > > > > > >> > > > > Transaction: Ticket created by
perry.shafran at noaa.gov
> > > > > > >> > > > > Queue: met_help
> > > > > > >> > > > > Subject: prepbufr dump files being written
out
> > > > > > >> > > > > Owner: Nobody
> > > > > > >> > > > > Requestors: perry.shafran at noaa.gov
> > > > > > >> > > > > Status: new
> > > > > > >> > > > > Ticket <URL:
> > > > > > >> >
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94683
> > > > > > >> > > >
> > > > > > >> > > > >
> > > > > > >> > > > >
> > > > > > >> > > > > Hi, everyone,
> > > > > > >> > > > >
> > > > > > >> > > > > At today's METplus call with EMC, I had asked
John
> about
> > > the
> > > > > > fact
> > > > > > >> > that
> > > > > > >> > > > with
> > > > > > >> > > > > the new METv9, that I am seeing prepbufr dump
files
> > being
> > > > > > written
> > > > > > >> > out,
> > > > > > >> > > > and
> > > > > > >> > > > > John said that this shouldn't be written out
because
> > it's
> > > > > > mainly a
> > > > > > >> > > > > debugging feature. I had not changed my
METplus
> system
> > > > (still
> > > > > > >> > working
> > > > > > >> > > > from
> > > > > > >> > > > > an old beta), but I did change MET to v9. This
dump
> > file
> > > > was
> > > > > > not
> > > > > > >> > > > produced
> > > > > > >> > > > > in the old system. John said that this would
happen
> if
> > > the
> > > > > > -dump
> > > > > > >> > > option
> > > > > > >> > > > > was included in the PB2NC command.
> > > > > > >> > > > >
> > > > > > >> > > > > Here's the command that was used for the most
recent
> use
> > > of
> > > > > > >> METplus,
> > > > > > >> > > and
> > > > > > >> > > > > the -dump option is not included in the
command.
> Maybe
> > > the
> > > > > -v 4
> > > > > > >> is
> > > > > > >> > one
> > > > > > >> > > > > thing that causes the output to be written? Or
is it
> > > > > something
> > > > > > >> else?
> > > > > > >> > > > > Maybe I'll try to run with a -v 2 or 3 and see
if it
> > > > happens?
> > > > > > >> (Not
> > > > > > >> > > today
> > > > > > >> > > > > because the machines are not accessible today).
> > > > > > >> > > > >
> > > > > > >> > > > >
> > > > > > >> >
> > > > > >
> > >
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/9.0/bin/pb2nc
> > > > > > >> > > > -v
> > > > > > >> > > > > 4
> > > > > > >> >
> > > >
/gpfs/dell1/nco/ops/com/nam/prod/nam.20200319/nam.t06z.prepbufr.tm06
> > > > > > >> > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Perry.Shafran/metplus3_test/nam/conus_sfc/
> > > > > > >> > > > > prepbufr.nam.2020031900.nc
> > > > > > >> > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> /gpfs/dell2/emc/verification/save/Perry.Shafran/METplus-3.0-
beta1/parm/met_config/PB2NCConfig_perry
> > > > > > >> > > > >
> > > > > > >> > > > > Thanks!
> > > > > > >> > > > >
> > > > > > >> > > > > Perry
> > > > > > >> > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >> >
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
More information about the Met_help
mailing list