[Met_help] [rt.rap.ucar.edu #95293] History for METviewer
Tatiana Burek via RT
met_help at ucar.edu
Tue Oct 13 12:08:30 MDT 2020
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
I forgot to add that I am running that on Hera:
cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/script
$ mv_delete_db_on_aws.sh binyu.wang mv_g2g_met_verf_kasat
Thank you.
---------- Forwarded message ---------
From: Binyu Wang - NOAA Affiliate <binyu.wang at noaa.gov>
Date: Mon, May 18, 2020 at 1:35 PM
Subject: METviewer
To: <met_help at ucar.edu>
Hello Methelp,
I have a question about MEtviewer: two hours ago I deleted a database using
"mv_delete_db_on_aws.sh binyu.wang mv_g2g_met_verf_kasat" and it seems the
database is gone. But I still can see it on METviewer even on a new window,
what is the problem here?
Thank you.
Binyu
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: METviewer
From: Tatiana Burek
Time: Mon May 18 12:48:13 2020
Hi Binyu
You are correct - 'mv_g2g_met_verf_kasat' database is deleted from AWS
server.
For the performance reason, METviewer cashes databases names in memory
and that is why it was present in the list of databases in GUI.
To clear the cash you need to click on 'Reload databases' in the upper
right corner and reload the page. Deleted database should be removed
from the menu after that.
I have done this already so you should not see that database after you
reload the page.
Tatiana
On Mon May 18 12:05:01 2020, binyu.wang at noaa.gov wrote:
> Hello Methelp,
>
> I have a question about MEtviewer: two hours ago I deleted a
database using
> "mv_delete_db_on_aws.sh binyu.wang mv_g2g_met_verf_kasat" and it
seems the
> database is gone. But I still can see it on METviewer even on a new
window,
> what is the problem here?
>
> Thank you.
> Binyu
------------------------------------------------
Subject: METviewer
From: binyu.wang at noaa.gov
Time: Mon May 18 13:18:02 2020
Thank you very much, Tatiana.
Binyu
On Mon, May 18, 2020 at 2:48 PM Tatiana Burek via RT
<met_help at ucar.edu>
wrote:
> Hi Binyu
> You are correct - 'mv_g2g_met_verf_kasat' database is deleted from
AWS
> server.
> For the performance reason, METviewer cashes databases names in
memory and
> that is why it was present in the list of databases in GUI.
> To clear the cash you need to click on 'Reload databases' in the
upper
> right corner and reload the page. Deleted database should be removed
from
> the menu after that.
> I have done this already so you should not see that database after
you
> reload the page.
>
> Tatiana
>
> On Mon May 18 12:05:01 2020, binyu.wang at noaa.gov wrote:
> > Hello Methelp,
> >
> > I have a question about MEtviewer: two hours ago I deleted a
database
> using
> > "mv_delete_db_on_aws.sh binyu.wang mv_g2g_met_verf_kasat" and it
seems
> the
> > database is gone. But I still can see it on METviewer even on a
new
> window,
> > what is the problem here?
> >
> > Thank you.
> > Binyu
>
>
>
>
------------------------------------------------
Subject: METviewer
From: binyu.wang at noaa.gov
Time: Mon May 18 21:18:28 2020
Hello Tatiana,
I have another question for you: when I tried to load the data, for
some reason, many unrelated data/files from nowhere were uploaded too.
Those files were not inside of the directory at all! ( there are only
2
files I want to upload and they are located
at /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/stat/*) . I have to stop it
from
running. It didn't happen the first time when I tried to upload the
data
What is the problem here? I am working on Hera now:
cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
-sh-4.2$ ./run_g2g_met_verf_kasat.sh
CALLING: cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET
CALLING: scp -r ./* binyu.wang at 205.156.8.85://data/mv_data/binyu.wang
verf_g2o_point_stat_sref_config_prebufr 100% 12KB 931.7KB/s
00:00
run_test.sh 100% 533 39.8KB/s
00:00
EnsembleStatConfig 100% 5157 389.4KB/s
00:00
PB2NCConfig_SREF 100% 2195 162.9KB/s
00:00
verf_g2o_ens_stat_sref_config_prebufr 100% 5399 404.5KB/s
00:00
gefs_file_list_00z_20190621_000 100% 2943 221.2KB/s
00:00
verf_g2g_gefs.201906.sh 100% 665 49.6KB/s
00:00
ensemble_stat_gefs_test_20190621_000000V_orank. 100% 28MB 41.5MB/s
00:00
grid_stat_gefs_test_000000L_20190621_000000V.st 100% 763KB 16.8MB/s
00:00
ensemble_stat_gefs_test_20190621_000000V.stat 100% 19KB 1.4MB/s
00:00
ensemble_stat_gefs_Reven_20190225_000000V_relp. 100% 4657 348.1KB/s
00:00
ensemble_stat_gefs_Reven_20190225_000000V_ens.n 100% 90MB 6.9MB/s
00:12
ensemble_stat_gefs_test_20190621_000000V_ssvar. 100% 5091 359.8KB/s
00:00
ensemble_stat_gefs_test_20190621_000000V_relp.t 100% 4074 290.1KB/s
00:00
ensemble_stat_gefs_Reven_20190225_000000V_ssvar 100% 6817 483.7KB/s
00:00
ensemble_stat_gefs_test_20190621_000000V_ens.nc 100% 127MB 5.9MB/s
00:21
ensemble_stat_gefs_Reven_20190225_000000V.stat 100% 25KB 1.7MB/s
00:00
CKilled by signal 2.
ERROR: Command returned with non-zero status (1): scp -r ./*
binyu.wang@
205.156.8.85://data/mv_data/binyu.wang
Thank you.
Binyu
On Mon, May 18, 2020 at 3:17 PM Binyu Wang - NOAA Affiliate <
binyu.wang at noaa.gov> wrote:
> Thank you very much, Tatiana.
>
> Binyu
>
> On Mon, May 18, 2020 at 2:48 PM Tatiana Burek via RT
<met_help at ucar.edu>
> wrote:
>
>> Hi Binyu
>> You are correct - 'mv_g2g_met_verf_kasat' database is deleted from
AWS
>> server.
>> For the performance reason, METviewer cashes databases names in
memory
>> and that is why it was present in the list of databases in GUI.
>> To clear the cash you need to click on 'Reload databases' in the
upper
>> right corner and reload the page. Deleted database should be
removed from
>> the menu after that.
>> I have done this already so you should not see that database after
you
>> reload the page.
>>
>> Tatiana
>>
>> On Mon May 18 12:05:01 2020, binyu.wang at noaa.gov wrote:
>> > Hello Methelp,
>> >
>> > I have a question about MEtviewer: two hours ago I deleted a
database
>> using
>> > "mv_delete_db_on_aws.sh binyu.wang mv_g2g_met_verf_kasat" and it
seems
>> the
>> > database is gone. But I still can see it on METviewer even on a
new
>> window,
>> > what is the problem here?
>> >
>> > Thank you.
>> > Binyu
>>
>>
>>
>>
------------------------------------------------
Subject: METviewer
From: Tatiana Burek
Time: Tue May 19 09:08:42 2020
Hi Binyu
I don't have an access to Hera and can't see that is in
/scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g directory or
how your XML is configured.
METviewer loading scripts copies ALL directories and files from the
directory you specify in the XML. It performs the data loading based
on the configuration from XML and then deletes all copied data files
from AWS.
If your data directory contains files other then from MET or VSDB they
would be also copied to the AWS but ignored and later removed.
It is better if you avoid putting other files to your data
directories.
Tatiana
On Mon May 18 21:18:28 2020, binyu.wang at noaa.gov wrote:
> Hello Tatiana,
>
> I have another question for you: when I tried to load the data, for
> some reason, many unrelated data/files from nowhere were uploaded
too.
> Those files were not inside of the directory at all! ( there are
only 2
> files I want to upload and they are located
> at /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/stat/*) . I have to stop
it from
> running. It didn't happen the first time when I tried to upload the
data
>
> What is the problem here? I am working on Hera now:
> cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
>
> -sh-4.2$ ./run_g2g_met_verf_kasat.sh
> CALLING: cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET
> CALLING: scp -r ./*
binyu.wang at 205.156.8.85://data/mv_data/binyu.wang
> verf_g2o_point_stat_sref_config_prebufr 100% 12KB
931.7KB/s
> 00:00
> run_test.sh 100% 533
39.8KB/s
> 00:00
> EnsembleStatConfig 100% 5157
389.4KB/s
> 00:00
> PB2NCConfig_SREF 100% 2195
162.9KB/s
> 00:00
> verf_g2o_ens_stat_sref_config_prebufr 100% 5399
404.5KB/s
> 00:00
> gefs_file_list_00z_20190621_000 100% 2943
221.2KB/s
> 00:00
> verf_g2g_gefs.201906.sh 100% 665
49.6KB/s
> 00:00
> ensemble_stat_gefs_test_20190621_000000V_orank. 100% 28MB
41.5MB/s
> 00:00
> grid_stat_gefs_test_000000L_20190621_000000V.st 100% 763KB
16.8MB/s
> 00:00
> ensemble_stat_gefs_test_20190621_000000V.stat 100% 19KB
1.4MB/s
> 00:00
> ensemble_stat_gefs_Reven_20190225_000000V_relp. 100% 4657
348.1KB/s
> 00:00
> ensemble_stat_gefs_Reven_20190225_000000V_ens.n 100% 90MB
6.9MB/s
> 00:12
> ensemble_stat_gefs_test_20190621_000000V_ssvar. 100% 5091
359.8KB/s
> 00:00
> ensemble_stat_gefs_test_20190621_000000V_relp.t 100% 4074
290.1KB/s
> 00:00
> ensemble_stat_gefs_Reven_20190225_000000V_ssvar 100% 6817
483.7KB/s
> 00:00
> ensemble_stat_gefs_test_20190621_000000V_ens.nc 100% 127MB
5.9MB/s
> 00:21
> ensemble_stat_gefs_Reven_20190225_000000V.stat 100% 25KB
1.7MB/s
> 00:00
> CKilled by signal 2.
> ERROR: Command returned with non-zero status (1): scp -r ./*
binyu.wang@
> 205.156.8.85://data/mv_data/binyu.wang
>
> Thank you.
> Binyu
>
> On Mon, May 18, 2020 at 3:17 PM Binyu Wang - NOAA Affiliate <
> binyu.wang at noaa.gov> wrote:
>
> > Thank you very much, Tatiana.
> >
> > Binyu
> >
> > On Mon, May 18, 2020 at 2:48 PM Tatiana Burek via RT
<met_help at ucar.edu>
> > wrote:
> >
> >> Hi Binyu
> >> You are correct - 'mv_g2g_met_verf_kasat' database is deleted
from AWS
> >> server.
> >> For the performance reason, METviewer cashes databases names in
memory
> >> and that is why it was present in the list of databases in GUI.
> >> To clear the cash you need to click on 'Reload databases' in the
upper
> >> right corner and reload the page. Deleted database should be
removed from
> >> the menu after that.
> >> I have done this already so you should not see that database
after you
> >> reload the page.
> >>
> >> Tatiana
> >>
> >> On Mon May 18 12:05:01 2020, binyu.wang at noaa.gov wrote:
> >> > Hello Methelp,
> >> >
> >> > I have a question about MEtviewer: two hours ago I deleted a
database
> >> using
> >> > "mv_delete_db_on_aws.sh binyu.wang mv_g2g_met_verf_kasat" and
it seems
> >> the
> >> > database is gone. But I still can see it on METviewer even on a
new
> >> window,
> >> > what is the problem here?
> >> >
> >> > Thank you.
> >> > Binyu
> >>
> >>
> >>
> >>
------------------------------------------------
Subject: METviewer
From: binyu.wang at noaa.gov
Time: Tue May 19 13:07:09 2020
Thank you, Tatinana.
Binyu
On Tue, May 19, 2020 at 11:08 AM Tatiana Burek via RT
<met_help at ucar.edu>
wrote:
> Hi Binyu
>
> I don't have an access to Hera and can't see that is in
> /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g directory
or how
> your XML is configured.
> METviewer loading scripts copies ALL directories and files from the
> directory you specify in the XML. It performs the data loading based
on the
> configuration from XML and then deletes all copied data files from
AWS.
> If your data directory contains files other then from MET or VSDB
they
> would be also copied to the AWS but ignored and later removed.
> It is better if you avoid putting other files to your data
directories.
>
> Tatiana
>
>
> On Mon May 18 21:18:28 2020, binyu.wang at noaa.gov wrote:
> > Hello Tatiana,
> >
> > I have another question for you: when I tried to load the data,
for
> > some reason, many unrelated data/files from nowhere were uploaded
too.
> > Those files were not inside of the directory at all! ( there are
only 2
> > files I want to upload and they are located
> > at /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/stat/*) . I have to stop
it
> from
> > running. It didn't happen the first time when I tried to upload
the data
> >
> > What is the problem here? I am working on Hera now:
> > cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
> >
> > -sh-4.2$ ./run_g2g_met_verf_kasat.sh
> > CALLING: cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET
> > CALLING: scp -r ./*
binyu.wang at 205.156.8.85://data/mv_data/binyu.wang
> > verf_g2o_point_stat_sref_config_prebufr 100% 12KB
931.7KB/s
> > 00:00
> > run_test.sh 100% 533
39.8KB/s
> > 00:00
> > EnsembleStatConfig 100% 5157
389.4KB/s
> > 00:00
> > PB2NCConfig_SREF 100% 2195
162.9KB/s
> > 00:00
> > verf_g2o_ens_stat_sref_config_prebufr 100% 5399
404.5KB/s
> > 00:00
> > gefs_file_list_00z_20190621_000 100% 2943
221.2KB/s
> > 00:00
> > verf_g2g_gefs.201906.sh 100% 665
49.6KB/s
> > 00:00
> > ensemble_stat_gefs_test_20190621_000000V_orank. 100% 28MB
41.5MB/s
> > 00:00
> > grid_stat_gefs_test_000000L_20190621_000000V.st 100% 763KB
16.8MB/s
> > 00:00
> > ensemble_stat_gefs_test_20190621_000000V.stat 100% 19KB
1.4MB/s
> > 00:00
> > ensemble_stat_gefs_Reven_20190225_000000V_relp. 100% 4657
348.1KB/s
> > 00:00
> > ensemble_stat_gefs_Reven_20190225_000000V_ens.n 100% 90MB
6.9MB/s
> > 00:12
> > ensemble_stat_gefs_test_20190621_000000V_ssvar. 100% 5091
359.8KB/s
> > 00:00
> > ensemble_stat_gefs_test_20190621_000000V_relp.t 100% 4074
290.1KB/s
> > 00:00
> > ensemble_stat_gefs_Reven_20190225_000000V_ssvar 100% 6817
483.7KB/s
> > 00:00
> > ensemble_stat_gefs_test_20190621_000000V_ens.nc 100% 127MB
5.9MB/s
> > 00:21
> > ensemble_stat_gefs_Reven_20190225_000000V.stat 100% 25KB
1.7MB/s
> > 00:00
> > CKilled by signal 2.
> > ERROR: Command returned with non-zero status (1): scp -r ./*
binyu.wang@
> > 205.156.8.85://data/mv_data/binyu.wang
> >
> > Thank you.
> > Binyu
> >
> > On Mon, May 18, 2020 at 3:17 PM Binyu Wang - NOAA Affiliate <
> > binyu.wang at noaa.gov> wrote:
> >
> > > Thank you very much, Tatiana.
> > >
> > > Binyu
> > >
> > > On Mon, May 18, 2020 at 2:48 PM Tatiana Burek via RT <
> met_help at ucar.edu>
> > > wrote:
> > >
> > >> Hi Binyu
> > >> You are correct - 'mv_g2g_met_verf_kasat' database is deleted
from AWS
> > >> server.
> > >> For the performance reason, METviewer cashes databases names in
memory
> > >> and that is why it was present in the list of databases in GUI.
> > >> To clear the cash you need to click on 'Reload databases' in
the upper
> > >> right corner and reload the page. Deleted database should be
removed
> from
> > >> the menu after that.
> > >> I have done this already so you should not see that database
after you
> > >> reload the page.
> > >>
> > >> Tatiana
> > >>
> > >> On Mon May 18 12:05:01 2020, binyu.wang at noaa.gov wrote:
> > >> > Hello Methelp,
> > >> >
> > >> > I have a question about MEtviewer: two hours ago I deleted a
> database
> > >> using
> > >> > "mv_delete_db_on_aws.sh binyu.wang mv_g2g_met_verf_kasat" and
it
> seems
> > >> the
> > >> > database is gone. But I still can see it on METviewer even on
a new
> > >> window,
> > >> > what is the problem here?
> > >> >
> > >> > Thank you.
> > >> > Binyu
> > >>
> > >>
> > >>
> > >>
>
>
>
>
------------------------------------------------
Subject: METviewer
From: binyu.wang at noaa.gov
Time: Tue May 26 09:24:22 2020
Hello Tatinana,
I have a question for you about the "Rely" plot on METviewer, I could
make
a plot without picking " Series Variables", but I can not make the
plot if
I did pick "Series Variable". Below is the details:
I had a database "mv_g2g_met_verf_kasat" under "NCEP bwang", I tried
to
make a "Rely" plot, but it is weird that I can not make a plot if I
pick
"Kasatochi" as the Model, but I could make a plot without any model
selected (although it is a bad plot).
I attached the plots to the email. "Rely_blank.png" is the one without
a
plot, "Rely.png" is the one with a plot, you can see I didn't pick any
model for this plot. The same thing happens for Roc plot as well. Any
hint
on this?
Thank you.
Binyu
On Tue, May 19, 2020 at 3:06 PM Binyu Wang - NOAA Affiliate <
binyu.wang at noaa.gov> wrote:
> Thank you, Tatinana.
> Binyu
>
> On Tue, May 19, 2020 at 11:08 AM Tatiana Burek via RT
<met_help at ucar.edu>
> wrote:
>
>> Hi Binyu
>>
>> I don't have an access to Hera and can't see that is in
>> /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g directory
or how
>> your XML is configured.
>> METviewer loading scripts copies ALL directories and files from the
>> directory you specify in the XML. It performs the data loading
based on the
>> configuration from XML and then deletes all copied data files from
AWS.
>> If your data directory contains files other then from MET or VSDB
they
>> would be also copied to the AWS but ignored and later removed.
>> It is better if you avoid putting other files to your data
directories.
>>
>> Tatiana
>>
>>
>> On Mon May 18 21:18:28 2020, binyu.wang at noaa.gov wrote:
>> > Hello Tatiana,
>> >
>> > I have another question for you: when I tried to load the data,
for
>> > some reason, many unrelated data/files from nowhere were uploaded
too.
>> > Those files were not inside of the directory at all! ( there are
only 2
>> > files I want to upload and they are located
>> > at /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/stat/*) . I have to
stop it
>> from
>> > running. It didn't happen the first time when I tried to upload
the data
>> >
>> > What is the problem here? I am working on Hera now:
>> > cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
>> >
>> > -sh-4.2$ ./run_g2g_met_verf_kasat.sh
>> > CALLING: cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET
>> > CALLING: scp -r ./*
binyu.wang at 205.156.8.85://data/mv_data/binyu.wang
>> > verf_g2o_point_stat_sref_config_prebufr 100% 12KB
931.7KB/s
>> > 00:00
>> > run_test.sh 100% 533
39.8KB/s
>> > 00:00
>> > EnsembleStatConfig 100% 5157
389.4KB/s
>> > 00:00
>> > PB2NCConfig_SREF 100% 2195
162.9KB/s
>> > 00:00
>> > verf_g2o_ens_stat_sref_config_prebufr 100% 5399
404.5KB/s
>> > 00:00
>> > gefs_file_list_00z_20190621_000 100% 2943
221.2KB/s
>> > 00:00
>> > verf_g2g_gefs.201906.sh 100% 665
49.6KB/s
>> > 00:00
>> > ensemble_stat_gefs_test_20190621_000000V_orank. 100% 28MB
41.5MB/s
>> > 00:00
>> > grid_stat_gefs_test_000000L_20190621_000000V.st 100% 763KB
16.8MB/s
>> > 00:00
>> > ensemble_stat_gefs_test_20190621_000000V.stat 100% 19KB
1.4MB/s
>> > 00:00
>> > ensemble_stat_gefs_Reven_20190225_000000V_relp. 100% 4657
348.1KB/s
>> > 00:00
>> > ensemble_stat_gefs_Reven_20190225_000000V_ens.n 100% 90MB
6.9MB/s
>> > 00:12
>> > ensemble_stat_gefs_test_20190621_000000V_ssvar. 100% 5091
359.8KB/s
>> > 00:00
>> > ensemble_stat_gefs_test_20190621_000000V_relp.t 100% 4074
290.1KB/s
>> > 00:00
>> > ensemble_stat_gefs_Reven_20190225_000000V_ssvar 100% 6817
483.7KB/s
>> > 00:00
>> > ensemble_stat_gefs_test_20190621_000000V_ens.nc 100% 127MB
5.9MB/s
>> > 00:21
>> > ensemble_stat_gefs_Reven_20190225_000000V.stat 100% 25KB
1.7MB/s
>> > 00:00
>> > CKilled by signal 2.
>> > ERROR: Command returned with non-zero status (1): scp -r ./*
binyu.wang@
>> > 205.156.8.85://data/mv_data/binyu.wang
>> >
>> > Thank you.
>> > Binyu
>> >
>> > On Mon, May 18, 2020 at 3:17 PM Binyu Wang - NOAA Affiliate <
>> > binyu.wang at noaa.gov> wrote:
>> >
>> > > Thank you very much, Tatiana.
>> > >
>> > > Binyu
>> > >
>> > > On Mon, May 18, 2020 at 2:48 PM Tatiana Burek via RT <
>> met_help at ucar.edu>
>> > > wrote:
>> > >
>> > >> Hi Binyu
>> > >> You are correct - 'mv_g2g_met_verf_kasat' database is deleted
from
>> AWS
>> > >> server.
>> > >> For the performance reason, METviewer cashes databases names
in
>> memory
>> > >> and that is why it was present in the list of databases in
GUI.
>> > >> To clear the cash you need to click on 'Reload databases' in
the
>> upper
>> > >> right corner and reload the page. Deleted database should be
removed
>> from
>> > >> the menu after that.
>> > >> I have done this already so you should not see that database
after
>> you
>> > >> reload the page.
>> > >>
>> > >> Tatiana
>> > >>
>> > >> On Mon May 18 12:05:01 2020, binyu.wang at noaa.gov wrote:
>> > >> > Hello Methelp,
>> > >> >
>> > >> > I have a question about MEtviewer: two hours ago I deleted a
>> database
>> > >> using
>> > >> > "mv_delete_db_on_aws.sh binyu.wang mv_g2g_met_verf_kasat"
and it
>> seems
>> > >> the
>> > >> > database is gone. But I still can see it on METviewer even
on a new
>> > >> window,
>> > >> > what is the problem here?
>> > >> >
>> > >> > Thank you.
>> > >> > Binyu
>> > >>
>> > >>
>> > >>
>> > >>
>>
>>
>>
>>
------------------------------------------------
Subject: METviewer
From: Tatiana Burek
Time: Tue May 26 12:39:12 2020
Hi Binyu,
You are getting an empty plot when you choose Kasatochi model for
"Rely" plot because there is no data with these criteria in PCT table.
Variable 'VAFTD_ENS_FREQ_gt2.and.le3' has data only for the model
'gefs'. Actually, there is no data for 'Kasatochi' in PCT table at
all.
Tatiana
On Tue May 26 09:24:22 2020, binyu.wang at noaa.gov wrote:
> Hello Tatinana,
>
> I have a question for you about the "Rely" plot on METviewer, I
could
> make
> a plot without picking " Series Variables", but I can not make the
> plot if
> I did pick "Series Variable". Below is the details:
>
> I had a database "mv_g2g_met_verf_kasat" under "NCEP bwang", I
tried
> to
> make a "Rely" plot, but it is weird that I can not make a plot if I
> pick
> "Kasatochi" as the Model, but I could make a plot without any model
> selected (although it is a bad plot).
>
> I attached the plots to the email. "Rely_blank.png" is the one
without
> a
> plot, "Rely.png" is the one with a plot, you can see I didn't pick
any
> model for this plot. The same thing happens for Roc plot as well.
Any
> hint
> on this?
>
> Thank you.
> Binyu
>
> On Tue, May 19, 2020 at 3:06 PM Binyu Wang - NOAA Affiliate <
> binyu.wang at noaa.gov> wrote:
>
> > Thank you, Tatinana.
> > Binyu
> >
> > On Tue, May 19, 2020 at 11:08 AM Tatiana Burek via RT
> > <met_help at ucar.edu>
> > wrote:
> >
> >> Hi Binyu
> >>
> >> I don't have an access to Hera and can't see that is in
> >> /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
directory
> >> or how
> >> your XML is configured.
> >> METviewer loading scripts copies ALL directories and files from
the
> >> directory you specify in the XML. It performs the data loading
based
> >> on the
> >> configuration from XML and then deletes all copied data files
from
> >> AWS.
> >> If your data directory contains files other then from MET or VSDB
> >> they
> >> would be also copied to the AWS but ignored and later removed.
> >> It is better if you avoid putting other files to your data
> >> directories.
> >>
> >> Tatiana
> >>
> >>
> >> On Mon May 18 21:18:28 2020, binyu.wang at noaa.gov wrote:
> >> > Hello Tatiana,
> >> >
> >> > I have another question for you: when I tried to load the data,
> >> > for
> >> > some reason, many unrelated data/files from nowhere were
uploaded
> >> > too.
> >> > Those files were not inside of the directory at all! ( there
are
> >> > only 2
> >> > files I want to upload and they are located
> >> > at /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/stat/*) . I have to
stop
> >> > it
> >> from
> >> > running. It didn't happen the first time when I tried to upload
> >> > the data
> >> >
> >> > What is the problem here? I am working on Hera now:
> >> > cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
> >> >
> >> > -sh-4.2$ ./run_g2g_met_verf_kasat.sh
> >> > CALLING: cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET
> >> > CALLING: scp -r ./*
> >> > binyu.wang at 205.156.8.85://data/mv_data/binyu.wang
> >> > verf_g2o_point_stat_sref_config_prebufr 100% 12KB
> >> > 931.7KB/s
> >> > 00:00
> >> > run_test.sh 100% 533
> >> > 39.8KB/s
> >> > 00:00
> >> > EnsembleStatConfig 100% 5157
> >> > 389.4KB/s
> >> > 00:00
> >> > PB2NCConfig_SREF 100% 2195
> >> > 162.9KB/s
> >> > 00:00
> >> > verf_g2o_ens_stat_sref_config_prebufr 100% 5399
> >> > 404.5KB/s
> >> > 00:00
> >> > gefs_file_list_00z_20190621_000 100% 2943
> >> > 221.2KB/s
> >> > 00:00
> >> > verf_g2g_gefs.201906.sh 100% 665
> >> > 49.6KB/s
> >> > 00:00
> >> > ensemble_stat_gefs_test_20190621_000000V_orank. 100% 28MB
> >> > 41.5MB/s
> >> > 00:00
> >> > grid_stat_gefs_test_000000L_20190621_000000V.st 100% 763KB
> >> > 16.8MB/s
> >> > 00:00
> >> > ensemble_stat_gefs_test_20190621_000000V.stat 100% 19KB
> >> > 1.4MB/s
> >> > 00:00
> >> > ensemble_stat_gefs_Reven_20190225_000000V_relp. 100% 4657
> >> > 348.1KB/s
> >> > 00:00
> >> > ensemble_stat_gefs_Reven_20190225_000000V_ens.n 100% 90MB
> >> > 6.9MB/s
> >> > 00:12
> >> > ensemble_stat_gefs_test_20190621_000000V_ssvar. 100% 5091
> >> > 359.8KB/s
> >> > 00:00
> >> > ensemble_stat_gefs_test_20190621_000000V_relp.t 100% 4074
> >> > 290.1KB/s
> >> > 00:00
> >> > ensemble_stat_gefs_Reven_20190225_000000V_ssvar 100% 6817
> >> > 483.7KB/s
> >> > 00:00
> >> > ensemble_stat_gefs_test_20190621_000000V_ens.nc 100% 127MB
> >> > 5.9MB/s
> >> > 00:21
> >> > ensemble_stat_gefs_Reven_20190225_000000V.stat 100% 25KB
> >> > 1.7MB/s
> >> > 00:00
> >> > CKilled by signal 2.
> >> > ERROR: Command returned with non-zero status (1): scp -r ./*
> >> > binyu.wang@
> >> > 205.156.8.85://data/mv_data/binyu.wang
> >> >
> >> > Thank you.
> >> > Binyu
> >> >
> >> > On Mon, May 18, 2020 at 3:17 PM Binyu Wang - NOAA Affiliate <
> >> > binyu.wang at noaa.gov> wrote:
> >> >
> >> > > Thank you very much, Tatiana.
> >> > >
> >> > > Binyu
> >> > >
> >> > > On Mon, May 18, 2020 at 2:48 PM Tatiana Burek via RT <
> >> met_help at ucar.edu>
> >> > > wrote:
> >> > >
> >> > >> Hi Binyu
> >> > >> You are correct - 'mv_g2g_met_verf_kasat' database is
deleted
> >> > >> from
> >> AWS
> >> > >> server.
> >> > >> For the performance reason, METviewer cashes databases names
in
> >> memory
> >> > >> and that is why it was present in the list of databases in
GUI.
> >> > >> To clear the cash you need to click on 'Reload databases' in
> >> > >> the
> >> upper
> >> > >> right corner and reload the page. Deleted database should be
> >> > >> removed
> >> from
> >> > >> the menu after that.
> >> > >> I have done this already so you should not see that database
> >> > >> after
> >> you
> >> > >> reload the page.
> >> > >>
> >> > >> Tatiana
> >> > >>
> >> > >> On Mon May 18 12:05:01 2020, binyu.wang at noaa.gov wrote:
> >> > >> > Hello Methelp,
> >> > >> >
> >> > >> > I have a question about MEtviewer: two hours ago I deleted
a
> >> database
> >> > >> using
> >> > >> > "mv_delete_db_on_aws.sh binyu.wang mv_g2g_met_verf_kasat"
and
> >> > >> > it
> >> seems
> >> > >> the
> >> > >> > database is gone. But I still can see it on METviewer even
on
> >> > >> > a new
> >> > >> window,
> >> > >> > what is the problem here?
> >> > >> >
> >> > >> > Thank you.
> >> > >> > Binyu
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >>
> >>
> >>
> >>
------------------------------------------------
Subject: METviewer
From: binyu.wang at noaa.gov
Time: Tue May 26 13:08:24 2020
Tatiana,
Thank you for the clarification. But why I could make "HIST" plot when
I
choose the Kasatchi model?
By the way, where to set which model to use in the MET scripts? There
is
only one script needed to be changed to upload the data, I attached
the
scripts I used to this mail. I use the script
"run_g2g_met_verf_kasat.sh"
to upload the stat. data.
-sh-4.2$ pwd
/scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/stat/met_kasat_stat
-sh-4.2$ ls
ensemble_stat_volc_20080808_130000V.stat
grid_stat_Kasatochi_090000L_20080808_130000V.stat
ensemble_stat_volc_20080809_000000V.stat
grid_stat_Kasatochi_200000L_20080809_000000V.stat
ensemble_stat_volc_20080809_120000V.stat
grid_stat_Kasatochi_320000L_20080809_120000V.stat
ensemble_stat_volc_20080809_230000V.stat
grid_stat_Kasatochi_430000L_20080809_230000V.stat
ensemble_stat_volc_20080810_100000V.stat
grid_stat_Kasatochi_540000L_20080810_100000V.stat
ensemble_stat_volc_20080810_120000V.stat
grid_stat_Kasatochi_560000L_20080810_120000V.stat
Thank you very much!
Binyu
On Tue, May 26, 2020 at 2:39 PM Tatiana Burek via RT
<met_help at ucar.edu>
wrote:
> Hi Binyu,
> You are getting an empty plot when you choose Kasatochi model for
"Rely"
> plot because there is no data with these criteria in PCT table.
Variable
> 'VAFTD_ENS_FREQ_gt2.and.le3' has data only for the model 'gefs'.
Actually,
> there is no data for 'Kasatochi' in PCT table at all.
>
> Tatiana
>
> On Tue May 26 09:24:22 2020, binyu.wang at noaa.gov wrote:
> > Hello Tatinana,
> >
> > I have a question for you about the "Rely" plot on METviewer, I
could
> > make
> > a plot without picking " Series Variables", but I can not make the
> > plot if
> > I did pick "Series Variable". Below is the details:
> >
> > I had a database "mv_g2g_met_verf_kasat" under "NCEP bwang", I
tried
> > to
> > make a "Rely" plot, but it is weird that I can not make a plot if
I
> > pick
> > "Kasatochi" as the Model, but I could make a plot without any
model
> > selected (although it is a bad plot).
> >
> > I attached the plots to the email. "Rely_blank.png" is the one
without
> > a
> > plot, "Rely.png" is the one with a plot, you can see I didn't pick
any
> > model for this plot. The same thing happens for Roc plot as well.
Any
> > hint
> > on this?
> >
> > Thank you.
> > Binyu
> >
> > On Tue, May 19, 2020 at 3:06 PM Binyu Wang - NOAA Affiliate <
> > binyu.wang at noaa.gov> wrote:
> >
> > > Thank you, Tatinana.
> > > Binyu
> > >
> > > On Tue, May 19, 2020 at 11:08 AM Tatiana Burek via RT
> > > <met_help at ucar.edu>
> > > wrote:
> > >
> > >> Hi Binyu
> > >>
> > >> I don't have an access to Hera and can't see that is in
> > >> /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
directory
> > >> or how
> > >> your XML is configured.
> > >> METviewer loading scripts copies ALL directories and files from
the
> > >> directory you specify in the XML. It performs the data loading
based
> > >> on the
> > >> configuration from XML and then deletes all copied data files
from
> > >> AWS.
> > >> If your data directory contains files other then from MET or
VSDB
> > >> they
> > >> would be also copied to the AWS but ignored and later removed.
> > >> It is better if you avoid putting other files to your data
> > >> directories.
> > >>
> > >> Tatiana
> > >>
> > >>
> > >> On Mon May 18 21:18:28 2020, binyu.wang at noaa.gov wrote:
> > >> > Hello Tatiana,
> > >> >
> > >> > I have another question for you: when I tried to load the
data,
> > >> > for
> > >> > some reason, many unrelated data/files from nowhere were
uploaded
> > >> > too.
> > >> > Those files were not inside of the directory at all! ( there
are
> > >> > only 2
> > >> > files I want to upload and they are located
> > >> > at /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/stat/*) . I have to
stop
> > >> > it
> > >> from
> > >> > running. It didn't happen the first time when I tried to
upload
> > >> > the data
> > >> >
> > >> > What is the problem here? I am working on Hera now:
> > >> > cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
> > >> >
> > >> > -sh-4.2$ ./run_g2g_met_verf_kasat.sh
> > >> > CALLING: cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET
> > >> > CALLING: scp -r ./*
> > >> > binyu.wang at 205.156.8.85://data/mv_data/binyu.wang
> > >> > verf_g2o_point_stat_sref_config_prebufr 100% 12KB
> > >> > 931.7KB/s
> > >> > 00:00
> > >> > run_test.sh 100% 533
> > >> > 39.8KB/s
> > >> > 00:00
> > >> > EnsembleStatConfig 100% 5157
> > >> > 389.4KB/s
> > >> > 00:00
> > >> > PB2NCConfig_SREF 100% 2195
> > >> > 162.9KB/s
> > >> > 00:00
> > >> > verf_g2o_ens_stat_sref_config_prebufr 100% 5399
> > >> > 404.5KB/s
> > >> > 00:00
> > >> > gefs_file_list_00z_20190621_000 100% 2943
> > >> > 221.2KB/s
> > >> > 00:00
> > >> > verf_g2g_gefs.201906.sh 100% 665
> > >> > 49.6KB/s
> > >> > 00:00
> > >> > ensemble_stat_gefs_test_20190621_000000V_orank. 100% 28MB
> > >> > 41.5MB/s
> > >> > 00:00
> > >> > grid_stat_gefs_test_000000L_20190621_000000V.st 100% 763KB
> > >> > 16.8MB/s
> > >> > 00:00
> > >> > ensemble_stat_gefs_test_20190621_000000V.stat 100% 19KB
> > >> > 1.4MB/s
> > >> > 00:00
> > >> > ensemble_stat_gefs_Reven_20190225_000000V_relp. 100% 4657
> > >> > 348.1KB/s
> > >> > 00:00
> > >> > ensemble_stat_gefs_Reven_20190225_000000V_ens.n 100% 90MB
> > >> > 6.9MB/s
> > >> > 00:12
> > >> > ensemble_stat_gefs_test_20190621_000000V_ssvar. 100% 5091
> > >> > 359.8KB/s
> > >> > 00:00
> > >> > ensemble_stat_gefs_test_20190621_000000V_relp.t 100% 4074
> > >> > 290.1KB/s
> > >> > 00:00
> > >> > ensemble_stat_gefs_Reven_20190225_000000V_ssvar 100% 6817
> > >> > 483.7KB/s
> > >> > 00:00
> > >> > ensemble_stat_gefs_test_20190621_000000V_ens.nc 100% 127MB
> > >> > 5.9MB/s
> > >> > 00:21
> > >> > ensemble_stat_gefs_Reven_20190225_000000V.stat 100% 25KB
> > >> > 1.7MB/s
> > >> > 00:00
> > >> > CKilled by signal 2.
> > >> > ERROR: Command returned with non-zero status (1): scp -r ./*
> > >> > binyu.wang@
> > >> > 205.156.8.85://data/mv_data/binyu.wang
> > >> >
> > >> > Thank you.
> > >> > Binyu
> > >> >
> > >> > On Mon, May 18, 2020 at 3:17 PM Binyu Wang - NOAA Affiliate <
> > >> > binyu.wang at noaa.gov> wrote:
> > >> >
> > >> > > Thank you very much, Tatiana.
> > >> > >
> > >> > > Binyu
> > >> > >
> > >> > > On Mon, May 18, 2020 at 2:48 PM Tatiana Burek via RT <
> > >> met_help at ucar.edu>
> > >> > > wrote:
> > >> > >
> > >> > >> Hi Binyu
> > >> > >> You are correct - 'mv_g2g_met_verf_kasat' database is
deleted
> > >> > >> from
> > >> AWS
> > >> > >> server.
> > >> > >> For the performance reason, METviewer cashes databases
names in
> > >> memory
> > >> > >> and that is why it was present in the list of databases in
GUI.
> > >> > >> To clear the cash you need to click on 'Reload databases'
in
> > >> > >> the
> > >> upper
> > >> > >> right corner and reload the page. Deleted database should
be
> > >> > >> removed
> > >> from
> > >> > >> the menu after that.
> > >> > >> I have done this already so you should not see that
database
> > >> > >> after
> > >> you
> > >> > >> reload the page.
> > >> > >>
> > >> > >> Tatiana
> > >> > >>
> > >> > >> On Mon May 18 12:05:01 2020, binyu.wang at noaa.gov wrote:
> > >> > >> > Hello Methelp,
> > >> > >> >
> > >> > >> > I have a question about MEtviewer: two hours ago I
deleted a
> > >> database
> > >> > >> using
> > >> > >> > "mv_delete_db_on_aws.sh binyu.wang
mv_g2g_met_verf_kasat" and
> > >> > >> > it
> > >> seems
> > >> > >> the
> > >> > >> > database is gone. But I still can see it on METviewer
even on
> > >> > >> > a new
> > >> > >> window,
> > >> > >> > what is the problem here?
> > >> > >> >
> > >> > >> > Thank you.
> > >> > >> > Binyu
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >>
> > >>
> > >>
> > >>
> > >>
>
>
>
>
------------------------------------------------
Subject: METviewer
From: Tatiana Burek
Time: Tue May 26 13:45:17 2020
Binyu
METviewer uses data from phist or rhist tables to create a
corresponding plot. Both of those tables have data for Kashtochi model
and VAFTD variable. This is why you can create these plots.
The script that loads data to the database doesn't have a 'model'
parameter. All valid data that is present in the .stat files would be
loaded.
Tatiana
On Tue May 26 13:08:24 2020, binyu.wang at noaa.gov wrote:
> Tatiana,
>
> Thank you for the clarification. But why I could make "HIST" plot
when I
> choose the Kasatchi model?
>
> By the way, where to set which model to use in the MET scripts?
There is
> only one script needed to be changed to upload the data, I attached
the
> scripts I used to this mail. I use the script
"run_g2g_met_verf_kasat.sh"
> to upload the stat. data.
>
> -sh-4.2$ pwd
> /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/stat/met_kasat_stat
> -sh-4.2$ ls
> ensemble_stat_volc_20080808_130000V.stat
> grid_stat_Kasatochi_090000L_20080808_130000V.stat
> ensemble_stat_volc_20080809_000000V.stat
> grid_stat_Kasatochi_200000L_20080809_000000V.stat
> ensemble_stat_volc_20080809_120000V.stat
> grid_stat_Kasatochi_320000L_20080809_120000V.stat
> ensemble_stat_volc_20080809_230000V.stat
> grid_stat_Kasatochi_430000L_20080809_230000V.stat
> ensemble_stat_volc_20080810_100000V.stat
> grid_stat_Kasatochi_540000L_20080810_100000V.stat
> ensemble_stat_volc_20080810_120000V.stat
> grid_stat_Kasatochi_560000L_20080810_120000V.stat
>
> Thank you very much!
> Binyu
>
> On Tue, May 26, 2020 at 2:39 PM Tatiana Burek via RT
<met_help at ucar.edu>
> wrote:
>
> > Hi Binyu,
> > You are getting an empty plot when you choose Kasatochi model for
"Rely"
> > plot because there is no data with these criteria in PCT table.
Variable
> > 'VAFTD_ENS_FREQ_gt2.and.le3' has data only for the model 'gefs'.
Actually,
> > there is no data for 'Kasatochi' in PCT table at all.
> >
> > Tatiana
> >
> > On Tue May 26 09:24:22 2020, binyu.wang at noaa.gov wrote:
> > > Hello Tatinana,
> > >
> > > I have a question for you about the "Rely" plot on METviewer, I
could
> > > make
> > > a plot without picking " Series Variables", but I can not make
the
> > > plot if
> > > I did pick "Series Variable". Below is the details:
> > >
> > > I had a database "mv_g2g_met_verf_kasat" under "NCEP bwang", I
tried
> > > to
> > > make a "Rely" plot, but it is weird that I can not make a plot
if I
> > > pick
> > > "Kasatochi" as the Model, but I could make a plot without any
model
> > > selected (although it is a bad plot).
> > >
> > > I attached the plots to the email. "Rely_blank.png" is the one
without
> > > a
> > > plot, "Rely.png" is the one with a plot, you can see I didn't
pick any
> > > model for this plot. The same thing happens for Roc plot as
well. Any
> > > hint
> > > on this?
> > >
> > > Thank you.
> > > Binyu
> > >
> > > On Tue, May 19, 2020 at 3:06 PM Binyu Wang - NOAA Affiliate <
> > > binyu.wang at noaa.gov> wrote:
> > >
> > > > Thank you, Tatinana.
> > > > Binyu
> > > >
> > > > On Tue, May 19, 2020 at 11:08 AM Tatiana Burek via RT
> > > > <met_help at ucar.edu>
> > > > wrote:
> > > >
> > > >> Hi Binyu
> > > >>
> > > >> I don't have an access to Hera and can't see that is in
> > > >> /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
directory
> > > >> or how
> > > >> your XML is configured.
> > > >> METviewer loading scripts copies ALL directories and files
from the
> > > >> directory you specify in the XML. It performs the data
loading based
> > > >> on the
> > > >> configuration from XML and then deletes all copied data files
from
> > > >> AWS.
> > > >> If your data directory contains files other then from MET or
VSDB
> > > >> they
> > > >> would be also copied to the AWS but ignored and later
removed.
> > > >> It is better if you avoid putting other files to your data
> > > >> directories.
> > > >>
> > > >> Tatiana
> > > >>
> > > >>
> > > >> On Mon May 18 21:18:28 2020, binyu.wang at noaa.gov wrote:
> > > >> > Hello Tatiana,
> > > >> >
> > > >> > I have another question for you: when I tried to load the
data,
> > > >> > for
> > > >> > some reason, many unrelated data/files from nowhere were
uploaded
> > > >> > too.
> > > >> > Those files were not inside of the directory at all! (
there are
> > > >> > only 2
> > > >> > files I want to upload and they are located
> > > >> > at /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/stat/*) . I have
to stop
> > > >> > it
> > > >> from
> > > >> > running. It didn't happen the first time when I tried to
upload
> > > >> > the data
> > > >> >
> > > >> > What is the problem here? I am working on Hera now:
> > > >> > cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
> > > >> >
> > > >> > -sh-4.2$ ./run_g2g_met_verf_kasat.sh
> > > >> > CALLING: cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET
> > > >> > CALLING: scp -r ./*
> > > >> > binyu.wang at 205.156.8.85://data/mv_data/binyu.wang
> > > >> > verf_g2o_point_stat_sref_config_prebufr 100% 12KB
> > > >> > 931.7KB/s
> > > >> > 00:00
> > > >> > run_test.sh 100% 533
> > > >> > 39.8KB/s
> > > >> > 00:00
> > > >> > EnsembleStatConfig 100% 5157
> > > >> > 389.4KB/s
> > > >> > 00:00
> > > >> > PB2NCConfig_SREF 100% 2195
> > > >> > 162.9KB/s
> > > >> > 00:00
> > > >> > verf_g2o_ens_stat_sref_config_prebufr 100% 5399
> > > >> > 404.5KB/s
> > > >> > 00:00
> > > >> > gefs_file_list_00z_20190621_000 100% 2943
> > > >> > 221.2KB/s
> > > >> > 00:00
> > > >> > verf_g2g_gefs.201906.sh 100% 665
> > > >> > 49.6KB/s
> > > >> > 00:00
> > > >> > ensemble_stat_gefs_test_20190621_000000V_orank. 100% 28MB
> > > >> > 41.5MB/s
> > > >> > 00:00
> > > >> > grid_stat_gefs_test_000000L_20190621_000000V.st 100% 763KB
> > > >> > 16.8MB/s
> > > >> > 00:00
> > > >> > ensemble_stat_gefs_test_20190621_000000V.stat 100% 19KB
> > > >> > 1.4MB/s
> > > >> > 00:00
> > > >> > ensemble_stat_gefs_Reven_20190225_000000V_relp. 100% 4657
> > > >> > 348.1KB/s
> > > >> > 00:00
> > > >> > ensemble_stat_gefs_Reven_20190225_000000V_ens.n 100% 90MB
> > > >> > 6.9MB/s
> > > >> > 00:12
> > > >> > ensemble_stat_gefs_test_20190621_000000V_ssvar. 100% 5091
> > > >> > 359.8KB/s
> > > >> > 00:00
> > > >> > ensemble_stat_gefs_test_20190621_000000V_relp.t 100% 4074
> > > >> > 290.1KB/s
> > > >> > 00:00
> > > >> > ensemble_stat_gefs_Reven_20190225_000000V_ssvar 100% 6817
> > > >> > 483.7KB/s
> > > >> > 00:00
> > > >> > ensemble_stat_gefs_test_20190621_000000V_ens.nc 100% 127MB
> > > >> > 5.9MB/s
> > > >> > 00:21
> > > >> > ensemble_stat_gefs_Reven_20190225_000000V.stat 100% 25KB
> > > >> > 1.7MB/s
> > > >> > 00:00
> > > >> > CKilled by signal 2.
> > > >> > ERROR: Command returned with non-zero status (1): scp -r
./*
> > > >> > binyu.wang@
> > > >> > 205.156.8.85://data/mv_data/binyu.wang
> > > >> >
> > > >> > Thank you.
> > > >> > Binyu
> > > >> >
> > > >> > On Mon, May 18, 2020 at 3:17 PM Binyu Wang - NOAA Affiliate
<
> > > >> > binyu.wang at noaa.gov> wrote:
> > > >> >
> > > >> > > Thank you very much, Tatiana.
> > > >> > >
> > > >> > > Binyu
> > > >> > >
> > > >> > > On Mon, May 18, 2020 at 2:48 PM Tatiana Burek via RT <
> > > >> met_help at ucar.edu>
> > > >> > > wrote:
> > > >> > >
> > > >> > >> Hi Binyu
> > > >> > >> You are correct - 'mv_g2g_met_verf_kasat' database is
deleted
> > > >> > >> from
> > > >> AWS
> > > >> > >> server.
> > > >> > >> For the performance reason, METviewer cashes databases
names in
> > > >> memory
> > > >> > >> and that is why it was present in the list of databases
in GUI.
> > > >> > >> To clear the cash you need to click on 'Reload
databases' in
> > > >> > >> the
> > > >> upper
> > > >> > >> right corner and reload the page. Deleted database
should be
> > > >> > >> removed
> > > >> from
> > > >> > >> the menu after that.
> > > >> > >> I have done this already so you should not see that
database
> > > >> > >> after
> > > >> you
> > > >> > >> reload the page.
> > > >> > >>
> > > >> > >> Tatiana
> > > >> > >>
> > > >> > >> On Mon May 18 12:05:01 2020, binyu.wang at noaa.gov wrote:
> > > >> > >> > Hello Methelp,
> > > >> > >> >
> > > >> > >> > I have a question about MEtviewer: two hours ago I
deleted a
> > > >> database
> > > >> > >> using
> > > >> > >> > "mv_delete_db_on_aws.sh binyu.wang
mv_g2g_met_verf_kasat" and
> > > >> > >> > it
> > > >> seems
> > > >> > >> the
> > > >> > >> > database is gone. But I still can see it on METviewer
even on
> > > >> > >> > a new
> > > >> > >> window,
> > > >> > >> > what is the problem here?
> > > >> > >> >
> > > >> > >> > Thank you.
> > > >> > >> > Binyu
> > > >> > >>
> > > >> > >>
> > > >> > >>
> > > >> > >>
> > > >>
> > > >>
> > > >>
> > > >>
> >
> >
> >
> >
------------------------------------------------
Subject: METviewer
From: binyu.wang at noaa.gov
Time: Tue May 26 15:22:07 2020
Thank you, Tatiana.
Is there a way that we can check what is included inside of PCT table
by
ourselves?
Binyu
On Tue, May 26, 2020 at 3:45 PM Tatiana Burek via RT
<met_help at ucar.edu>
wrote:
> Binyu
>
> METviewer uses data from phist or rhist tables to create a
corresponding
> plot. Both of those tables have data for Kashtochi model and VAFTD
> variable. This is why you can create these plots.
> The script that loads data to the database doesn't have a 'model'
> parameter. All valid data that is present in the .stat files would
be
> loaded.
>
> Tatiana
>
> On Tue May 26 13:08:24 2020, binyu.wang at noaa.gov wrote:
> > Tatiana,
> >
> > Thank you for the clarification. But why I could make "HIST" plot
when I
> > choose the Kasatchi model?
> >
> > By the way, where to set which model to use in the MET scripts?
There is
> > only one script needed to be changed to upload the data, I
attached the
> > scripts I used to this mail. I use the script
"run_g2g_met_verf_kasat.sh"
> > to upload the stat. data.
> >
> > -sh-4.2$ pwd
> > /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/stat/met_kasat_stat
> > -sh-4.2$ ls
> > ensemble_stat_volc_20080808_130000V.stat
> > grid_stat_Kasatochi_090000L_20080808_130000V.stat
> > ensemble_stat_volc_20080809_000000V.stat
> > grid_stat_Kasatochi_200000L_20080809_000000V.stat
> > ensemble_stat_volc_20080809_120000V.stat
> > grid_stat_Kasatochi_320000L_20080809_120000V.stat
> > ensemble_stat_volc_20080809_230000V.stat
> > grid_stat_Kasatochi_430000L_20080809_230000V.stat
> > ensemble_stat_volc_20080810_100000V.stat
> > grid_stat_Kasatochi_540000L_20080810_100000V.stat
> > ensemble_stat_volc_20080810_120000V.stat
> > grid_stat_Kasatochi_560000L_20080810_120000V.stat
> >
> > Thank you very much!
> > Binyu
> >
> > On Tue, May 26, 2020 at 2:39 PM Tatiana Burek via RT
<met_help at ucar.edu>
> > wrote:
> >
> > > Hi Binyu,
> > > You are getting an empty plot when you choose Kasatochi model
for
> "Rely"
> > > plot because there is no data with these criteria in PCT table.
> Variable
> > > 'VAFTD_ENS_FREQ_gt2.and.le3' has data only for the model 'gefs'.
> Actually,
> > > there is no data for 'Kasatochi' in PCT table at all.
> > >
> > > Tatiana
> > >
> > > On Tue May 26 09:24:22 2020, binyu.wang at noaa.gov wrote:
> > > > Hello Tatinana,
> > > >
> > > > I have a question for you about the "Rely" plot on METviewer,
I could
> > > > make
> > > > a plot without picking " Series Variables", but I can not make
the
> > > > plot if
> > > > I did pick "Series Variable". Below is the details:
> > > >
> > > > I had a database "mv_g2g_met_verf_kasat" under "NCEP bwang",
I
> tried
> > > > to
> > > > make a "Rely" plot, but it is weird that I can not make a
plot if I
> > > > pick
> > > > "Kasatochi" as the Model, but I could make a plot without any
model
> > > > selected (although it is a bad plot).
> > > >
> > > > I attached the plots to the email. "Rely_blank.png" is the one
> without
> > > > a
> > > > plot, "Rely.png" is the one with a plot, you can see I didn't
pick
> any
> > > > model for this plot. The same thing happens for Roc plot as
well. Any
> > > > hint
> > > > on this?
> > > >
> > > > Thank you.
> > > > Binyu
> > > >
> > > > On Tue, May 19, 2020 at 3:06 PM Binyu Wang - NOAA Affiliate <
> > > > binyu.wang at noaa.gov> wrote:
> > > >
> > > > > Thank you, Tatinana.
> > > > > Binyu
> > > > >
> > > > > On Tue, May 19, 2020 at 11:08 AM Tatiana Burek via RT
> > > > > <met_help at ucar.edu>
> > > > > wrote:
> > > > >
> > > > >> Hi Binyu
> > > > >>
> > > > >> I don't have an access to Hera and can't see that is in
> > > > >> /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
directory
> > > > >> or how
> > > > >> your XML is configured.
> > > > >> METviewer loading scripts copies ALL directories and files
from
> the
> > > > >> directory you specify in the XML. It performs the data
loading
> based
> > > > >> on the
> > > > >> configuration from XML and then deletes all copied data
files from
> > > > >> AWS.
> > > > >> If your data directory contains files other then from MET
or VSDB
> > > > >> they
> > > > >> would be also copied to the AWS but ignored and later
removed.
> > > > >> It is better if you avoid putting other files to your data
> > > > >> directories.
> > > > >>
> > > > >> Tatiana
> > > > >>
> > > > >>
> > > > >> On Mon May 18 21:18:28 2020, binyu.wang at noaa.gov wrote:
> > > > >> > Hello Tatiana,
> > > > >> >
> > > > >> > I have another question for you: when I tried to load the
data,
> > > > >> > for
> > > > >> > some reason, many unrelated data/files from nowhere were
> uploaded
> > > > >> > too.
> > > > >> > Those files were not inside of the directory at all! (
there are
> > > > >> > only 2
> > > > >> > files I want to upload and they are located
> > > > >> > at /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/stat/*) . I
have to
> stop
> > > > >> > it
> > > > >> from
> > > > >> > running. It didn't happen the first time when I tried to
upload
> > > > >> > the data
> > > > >> >
> > > > >> > What is the problem here? I am working on Hera now:
> > > > >> > cd
/scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
> > > > >> >
> > > > >> > -sh-4.2$ ./run_g2g_met_verf_kasat.sh
> > > > >> > CALLING: cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET
> > > > >> > CALLING: scp -r ./*
> > > > >> > binyu.wang at 205.156.8.85://data/mv_data/binyu.wang
> > > > >> > verf_g2o_point_stat_sref_config_prebufr 100%
12KB
> > > > >> > 931.7KB/s
> > > > >> > 00:00
> > > > >> > run_test.sh 100% 533
> > > > >> > 39.8KB/s
> > > > >> > 00:00
> > > > >> > EnsembleStatConfig 100% 5157
> > > > >> > 389.4KB/s
> > > > >> > 00:00
> > > > >> > PB2NCConfig_SREF 100% 2195
> > > > >> > 162.9KB/s
> > > > >> > 00:00
> > > > >> > verf_g2o_ens_stat_sref_config_prebufr 100% 5399
> > > > >> > 404.5KB/s
> > > > >> > 00:00
> > > > >> > gefs_file_list_00z_20190621_000 100% 2943
> > > > >> > 221.2KB/s
> > > > >> > 00:00
> > > > >> > verf_g2g_gefs.201906.sh 100% 665
> > > > >> > 49.6KB/s
> > > > >> > 00:00
> > > > >> > ensemble_stat_gefs_test_20190621_000000V_orank. 100%
28MB
> > > > >> > 41.5MB/s
> > > > >> > 00:00
> > > > >> > grid_stat_gefs_test_000000L_20190621_000000V.st 100%
763KB
> > > > >> > 16.8MB/s
> > > > >> > 00:00
> > > > >> > ensemble_stat_gefs_test_20190621_000000V.stat 100%
19KB
> > > > >> > 1.4MB/s
> > > > >> > 00:00
> > > > >> > ensemble_stat_gefs_Reven_20190225_000000V_relp. 100% 4657
> > > > >> > 348.1KB/s
> > > > >> > 00:00
> > > > >> > ensemble_stat_gefs_Reven_20190225_000000V_ens.n 100%
90MB
> > > > >> > 6.9MB/s
> > > > >> > 00:12
> > > > >> > ensemble_stat_gefs_test_20190621_000000V_ssvar. 100% 5091
> > > > >> > 359.8KB/s
> > > > >> > 00:00
> > > > >> > ensemble_stat_gefs_test_20190621_000000V_relp.t 100% 4074
> > > > >> > 290.1KB/s
> > > > >> > 00:00
> > > > >> > ensemble_stat_gefs_Reven_20190225_000000V_ssvar 100% 6817
> > > > >> > 483.7KB/s
> > > > >> > 00:00
> > > > >> > ensemble_stat_gefs_test_20190621_000000V_ens.nc 100%
127MB
> > > > >> > 5.9MB/s
> > > > >> > 00:21
> > > > >> > ensemble_stat_gefs_Reven_20190225_000000V.stat 100%
25KB
> > > > >> > 1.7MB/s
> > > > >> > 00:00
> > > > >> > CKilled by signal 2.
> > > > >> > ERROR: Command returned with non-zero status (1): scp -r
./*
> > > > >> > binyu.wang@
> > > > >> > 205.156.8.85://data/mv_data/binyu.wang
> > > > >> >
> > > > >> > Thank you.
> > > > >> > Binyu
> > > > >> >
> > > > >> > On Mon, May 18, 2020 at 3:17 PM Binyu Wang - NOAA
Affiliate <
> > > > >> > binyu.wang at noaa.gov> wrote:
> > > > >> >
> > > > >> > > Thank you very much, Tatiana.
> > > > >> > >
> > > > >> > > Binyu
> > > > >> > >
> > > > >> > > On Mon, May 18, 2020 at 2:48 PM Tatiana Burek via RT <
> > > > >> met_help at ucar.edu>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > >> Hi Binyu
> > > > >> > >> You are correct - 'mv_g2g_met_verf_kasat' database is
deleted
> > > > >> > >> from
> > > > >> AWS
> > > > >> > >> server.
> > > > >> > >> For the performance reason, METviewer cashes databases
names
> in
> > > > >> memory
> > > > >> > >> and that is why it was present in the list of
databases in
> GUI.
> > > > >> > >> To clear the cash you need to click on 'Reload
databases' in
> > > > >> > >> the
> > > > >> upper
> > > > >> > >> right corner and reload the page. Deleted database
should be
> > > > >> > >> removed
> > > > >> from
> > > > >> > >> the menu after that.
> > > > >> > >> I have done this already so you should not see that
database
> > > > >> > >> after
> > > > >> you
> > > > >> > >> reload the page.
> > > > >> > >>
> > > > >> > >> Tatiana
> > > > >> > >>
> > > > >> > >> On Mon May 18 12:05:01 2020, binyu.wang at noaa.gov
wrote:
> > > > >> > >> > Hello Methelp,
> > > > >> > >> >
> > > > >> > >> > I have a question about MEtviewer: two hours ago I
deleted
> a
> > > > >> database
> > > > >> > >> using
> > > > >> > >> > "mv_delete_db_on_aws.sh binyu.wang
mv_g2g_met_verf_kasat"
> and
> > > > >> > >> > it
> > > > >> seems
> > > > >> > >> the
> > > > >> > >> > database is gone. But I still can see it on
METviewer even
> on
> > > > >> > >> > a new
> > > > >> > >> window,
> > > > >> > >> > what is the problem here?
> > > > >> > >> >
> > > > >> > >> > Thank you.
> > > > >> > >> > Binyu
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > >
> > >
> > >
> > >
>
>
>
>
------------------------------------------------
Subject: METviewer
From: Tatiana Burek
Time: Wed May 27 09:05:01 2020
Binyu
We don't have an user interface that would support database viewing.
Currently in PCT table you have 49 records for 'gefs' model, 'L20000-
0' fcst_level, 'Surface' obs_level, 'FULL' mask, 'NEAREST'
interp_method, '==0.10000' fcst_thresh, fcst_valid_beg from 2008-08-08
13:00:00 to 2008-08-10 12:00:00
Tatiana
On Tue May 26 15:22:07 2020, binyu.wang at noaa.gov wrote:
> Thank you, Tatiana.
>
> Is there a way that we can check what is included inside of PCT
table
> by
> ourselves?
>
> Binyu
>
> On Tue, May 26, 2020 at 3:45 PM Tatiana Burek via RT
> <met_help at ucar.edu>
> wrote:
>
> > Binyu
> >
> > METviewer uses data from phist or rhist tables to create a
> > corresponding
> > plot. Both of those tables have data for Kashtochi model and VAFTD
> > variable. This is why you can create these plots.
> > The script that loads data to the database doesn't have a 'model'
> > parameter. All valid data that is present in the .stat files would
be
> > loaded.
> >
> > Tatiana
> >
> > On Tue May 26 13:08:24 2020, binyu.wang at noaa.gov wrote:
> > > Tatiana,
> > >
> > > Thank you for the clarification. But why I could make "HIST"
plot
> > > when I
> > > choose the Kasatchi model?
> > >
> > > By the way, where to set which model to use in the MET scripts?
> > > There is
> > > only one script needed to be changed to upload the data, I
> > > attached the
> > > scripts I used to this mail. I use the script
> > > "run_g2g_met_verf_kasat.sh"
> > > to upload the stat. data.
> > >
> > > -sh-4.2$ pwd
> > > /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/stat/met_kasat_stat
> > > -sh-4.2$ ls
> > > ensemble_stat_volc_20080808_130000V.stat
> > > grid_stat_Kasatochi_090000L_20080808_130000V.stat
> > > ensemble_stat_volc_20080809_000000V.stat
> > > grid_stat_Kasatochi_200000L_20080809_000000V.stat
> > > ensemble_stat_volc_20080809_120000V.stat
> > > grid_stat_Kasatochi_320000L_20080809_120000V.stat
> > > ensemble_stat_volc_20080809_230000V.stat
> > > grid_stat_Kasatochi_430000L_20080809_230000V.stat
> > > ensemble_stat_volc_20080810_100000V.stat
> > > grid_stat_Kasatochi_540000L_20080810_100000V.stat
> > > ensemble_stat_volc_20080810_120000V.stat
> > > grid_stat_Kasatochi_560000L_20080810_120000V.stat
> > >
> > > Thank you very much!
> > > Binyu
> > >
> > > On Tue, May 26, 2020 at 2:39 PM Tatiana Burek via RT
> > > <met_help at ucar.edu>
> > > wrote:
> > >
> > > > Hi Binyu,
> > > > You are getting an empty plot when you choose Kasatochi model
for
> > "Rely"
> > > > plot because there is no data with these criteria in PCT
table.
> > Variable
> > > > 'VAFTD_ENS_FREQ_gt2.and.le3' has data only for the model
'gefs'.
> > Actually,
> > > > there is no data for 'Kasatochi' in PCT table at all.
> > > >
> > > > Tatiana
> > > >
> > > > On Tue May 26 09:24:22 2020, binyu.wang at noaa.gov wrote:
> > > > > Hello Tatinana,
> > > > >
> > > > > I have a question for you about the "Rely" plot on
METviewer, I
> > > > > could
> > > > > make
> > > > > a plot without picking " Series Variables", but I can not
make
> > > > > the
> > > > > plot if
> > > > > I did pick "Series Variable". Below is the details:
> > > > >
> > > > > I had a database "mv_g2g_met_verf_kasat" under "NCEP bwang",
> > > > > I
> > tried
> > > > > to
> > > > > make a "Rely" plot, but it is weird that I can not make a
plot
> > > > > if I
> > > > > pick
> > > > > "Kasatochi" as the Model, but I could make a plot without
any
> > > > > model
> > > > > selected (although it is a bad plot).
> > > > >
> > > > > I attached the plots to the email. "Rely_blank.png" is the
one
> > without
> > > > > a
> > > > > plot, "Rely.png" is the one with a plot, you can see I
didn't
> > > > > pick
> > any
> > > > > model for this plot. The same thing happens for Roc plot as
> > > > > well. Any
> > > > > hint
> > > > > on this?
> > > > >
> > > > > Thank you.
> > > > > Binyu
> > > > >
> > > > > On Tue, May 19, 2020 at 3:06 PM Binyu Wang - NOAA Affiliate
<
> > > > > binyu.wang at noaa.gov> wrote:
> > > > >
> > > > > > Thank you, Tatinana.
> > > > > > Binyu
> > > > > >
> > > > > > On Tue, May 19, 2020 at 11:08 AM Tatiana Burek via RT
> > > > > > <met_help at ucar.edu>
> > > > > > wrote:
> > > > > >
> > > > > >> Hi Binyu
> > > > > >>
> > > > > >> I don't have an access to Hera and can't see that is in
> > > > > >> /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
> > > > > >> directory
> > > > > >> or how
> > > > > >> your XML is configured.
> > > > > >> METviewer loading scripts copies ALL directories and
files
> > > > > >> from
> > the
> > > > > >> directory you specify in the XML. It performs the data
> > > > > >> loading
> > based
> > > > > >> on the
> > > > > >> configuration from XML and then deletes all copied data
> > > > > >> files from
> > > > > >> AWS.
> > > > > >> If your data directory contains files other then from MET
or
> > > > > >> VSDB
> > > > > >> they
> > > > > >> would be also copied to the AWS but ignored and later
> > > > > >> removed.
> > > > > >> It is better if you avoid putting other files to your
data
> > > > > >> directories.
> > > > > >>
> > > > > >> Tatiana
> > > > > >>
> > > > > >>
> > > > > >> On Mon May 18 21:18:28 2020, binyu.wang at noaa.gov wrote:
> > > > > >> > Hello Tatiana,
> > > > > >> >
> > > > > >> > I have another question for you: when I tried to load
the
> > > > > >> > data,
> > > > > >> > for
> > > > > >> > some reason, many unrelated data/files from nowhere
were
> > uploaded
> > > > > >> > too.
> > > > > >> > Those files were not inside of the directory at all! (
> > > > > >> > there are
> > > > > >> > only 2
> > > > > >> > files I want to upload and they are located
> > > > > >> > at /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/stat/*) . I
have
> > > > > >> > to
> > stop
> > > > > >> > it
> > > > > >> from
> > > > > >> > running. It didn't happen the first time when I tried
to
> > > > > >> > upload
> > > > > >> > the data
> > > > > >> >
> > > > > >> > What is the problem here? I am working on Hera now:
> > > > > >> > cd
> > > > > >> >
/scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
> > > > > >> >
> > > > > >> > -sh-4.2$ ./run_g2g_met_verf_kasat.sh
> > > > > >> > CALLING: cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET
> > > > > >> > CALLING: scp -r ./*
> > > > > >> > binyu.wang at 205.156.8.85://data/mv_data/binyu.wang
> > > > > >> > verf_g2o_point_stat_sref_config_prebufr 100%
> > > > > >> > 12KB
> > > > > >> > 931.7KB/s
> > > > > >> > 00:00
> > > > > >> > run_test.sh 100%
533
> > > > > >> > 39.8KB/s
> > > > > >> > 00:00
> > > > > >> > EnsembleStatConfig 100%
5157
> > > > > >> > 389.4KB/s
> > > > > >> > 00:00
> > > > > >> > PB2NCConfig_SREF 100%
2195
> > > > > >> > 162.9KB/s
> > > > > >> > 00:00
> > > > > >> > verf_g2o_ens_stat_sref_config_prebufr 100%
5399
> > > > > >> > 404.5KB/s
> > > > > >> > 00:00
> > > > > >> > gefs_file_list_00z_20190621_000 100%
2943
> > > > > >> > 221.2KB/s
> > > > > >> > 00:00
> > > > > >> > verf_g2g_gefs.201906.sh 100%
665
> > > > > >> > 49.6KB/s
> > > > > >> > 00:00
> > > > > >> > ensemble_stat_gefs_test_20190621_000000V_orank. 100%
> > > > > >> > 28MB
> > > > > >> > 41.5MB/s
> > > > > >> > 00:00
> > > > > >> > grid_stat_gefs_test_000000L_20190621_000000V.st 100%
> > > > > >> > 763KB
> > > > > >> > 16.8MB/s
> > > > > >> > 00:00
> > > > > >> > ensemble_stat_gefs_test_20190621_000000V.stat 100%
> > > > > >> > 19KB
> > > > > >> > 1.4MB/s
> > > > > >> > 00:00
> > > > > >> > ensemble_stat_gefs_Reven_20190225_000000V_relp. 100%
4657
> > > > > >> > 348.1KB/s
> > > > > >> > 00:00
> > > > > >> > ensemble_stat_gefs_Reven_20190225_000000V_ens.n 100%
> > > > > >> > 90MB
> > > > > >> > 6.9MB/s
> > > > > >> > 00:12
> > > > > >> > ensemble_stat_gefs_test_20190621_000000V_ssvar. 100%
5091
> > > > > >> > 359.8KB/s
> > > > > >> > 00:00
> > > > > >> > ensemble_stat_gefs_test_20190621_000000V_relp.t 100%
4074
> > > > > >> > 290.1KB/s
> > > > > >> > 00:00
> > > > > >> > ensemble_stat_gefs_Reven_20190225_000000V_ssvar 100%
6817
> > > > > >> > 483.7KB/s
> > > > > >> > 00:00
> > > > > >> > ensemble_stat_gefs_test_20190621_000000V_ens.nc 100%
> > > > > >> > 127MB
> > > > > >> > 5.9MB/s
> > > > > >> > 00:21
> > > > > >> > ensemble_stat_gefs_Reven_20190225_000000V.stat 100%
> > > > > >> > 25KB
> > > > > >> > 1.7MB/s
> > > > > >> > 00:00
> > > > > >> > CKilled by signal 2.
> > > > > >> > ERROR: Command returned with non-zero status (1): scp
-r
> > > > > >> > ./*
> > > > > >> > binyu.wang@
> > > > > >> > 205.156.8.85://data/mv_data/binyu.wang
> > > > > >> >
> > > > > >> > Thank you.
> > > > > >> > Binyu
> > > > > >> >
> > > > > >> > On Mon, May 18, 2020 at 3:17 PM Binyu Wang - NOAA
> > > > > >> > Affiliate <
> > > > > >> > binyu.wang at noaa.gov> wrote:
> > > > > >> >
> > > > > >> > > Thank you very much, Tatiana.
> > > > > >> > >
> > > > > >> > > Binyu
> > > > > >> > >
> > > > > >> > > On Mon, May 18, 2020 at 2:48 PM Tatiana Burek via RT
<
> > > > > >> met_help at ucar.edu>
> > > > > >> > > wrote:
> > > > > >> > >
> > > > > >> > >> Hi Binyu
> > > > > >> > >> You are correct - 'mv_g2g_met_verf_kasat' database
is
> > > > > >> > >> deleted
> > > > > >> > >> from
> > > > > >> AWS
> > > > > >> > >> server.
> > > > > >> > >> For the performance reason, METviewer cashes
databases
> > > > > >> > >> names
> > in
> > > > > >> memory
> > > > > >> > >> and that is why it was present in the list of
databases
> > > > > >> > >> in
> > GUI.
> > > > > >> > >> To clear the cash you need to click on 'Reload
> > > > > >> > >> databases' in
> > > > > >> > >> the
> > > > > >> upper
> > > > > >> > >> right corner and reload the page. Deleted database
> > > > > >> > >> should be
> > > > > >> > >> removed
> > > > > >> from
> > > > > >> > >> the menu after that.
> > > > > >> > >> I have done this already so you should not see that
> > > > > >> > >> database
> > > > > >> > >> after
> > > > > >> you
> > > > > >> > >> reload the page.
> > > > > >> > >>
> > > > > >> > >> Tatiana
> > > > > >> > >>
> > > > > >> > >> On Mon May 18 12:05:01 2020, binyu.wang at noaa.gov
wrote:
> > > > > >> > >> > Hello Methelp,
> > > > > >> > >> >
> > > > > >> > >> > I have a question about MEtviewer: two hours ago I
> > > > > >> > >> > deleted
> > a
> > > > > >> database
> > > > > >> > >> using
> > > > > >> > >> > "mv_delete_db_on_aws.sh binyu.wang
> > > > > >> > >> > mv_g2g_met_verf_kasat"
> > and
> > > > > >> > >> > it
> > > > > >> seems
> > > > > >> > >> the
> > > > > >> > >> > database is gone. But I still can see it on
METviewer
> > > > > >> > >> > even
> > on
> > > > > >> > >> > a new
> > > > > >> > >> window,
> > > > > >> > >> > what is the problem here?
> > > > > >> > >> >
> > > > > >> > >> > Thank you.
> > > > > >> > >> > Binyu
> > > > > >> > >>
> > > > > >> > >>
> > > > > >> > >>
> > > > > >> > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> >
------------------------------------------------
Subject: METviewer
From: binyu.wang at noaa.gov
Time: Wed May 27 12:13:46 2020
Tatiana, Thank you!
On Wed, May 27, 2020 at 11:05 AM Tatiana Burek via RT
<met_help at ucar.edu>
wrote:
> Binyu
> We don't have an user interface that would support database viewing.
> Currently in PCT table you have 49 records for 'gefs' model,
'L20000-0'
> fcst_level, 'Surface' obs_level, 'FULL' mask, 'NEAREST'
interp_method,
> '==0.10000' fcst_thresh, fcst_valid_beg from 2008-08-08 13:00:00 to
> 2008-08-10 12:00:00
>
> Tatiana
>
> On Tue May 26 15:22:07 2020, binyu.wang at noaa.gov wrote:
> > Thank you, Tatiana.
> >
> > Is there a way that we can check what is included inside of PCT
table
> > by
> > ourselves?
> >
> > Binyu
> >
> > On Tue, May 26, 2020 at 3:45 PM Tatiana Burek via RT
> > <met_help at ucar.edu>
> > wrote:
> >
> > > Binyu
> > >
> > > METviewer uses data from phist or rhist tables to create a
> > > corresponding
> > > plot. Both of those tables have data for Kashtochi model and
VAFTD
> > > variable. This is why you can create these plots.
> > > The script that loads data to the database doesn't have a
'model'
> > > parameter. All valid data that is present in the .stat files
would be
> > > loaded.
> > >
> > > Tatiana
> > >
> > > On Tue May 26 13:08:24 2020, binyu.wang at noaa.gov wrote:
> > > > Tatiana,
> > > >
> > > > Thank you for the clarification. But why I could make "HIST"
plot
> > > > when I
> > > > choose the Kasatchi model?
> > > >
> > > > By the way, where to set which model to use in the MET
scripts?
> > > > There is
> > > > only one script needed to be changed to upload the data, I
> > > > attached the
> > > > scripts I used to this mail. I use the script
> > > > "run_g2g_met_verf_kasat.sh"
> > > > to upload the stat. data.
> > > >
> > > > -sh-4.2$ pwd
> > > > /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/stat/met_kasat_stat
> > > > -sh-4.2$ ls
> > > > ensemble_stat_volc_20080808_130000V.stat
> > > > grid_stat_Kasatochi_090000L_20080808_130000V.stat
> > > > ensemble_stat_volc_20080809_000000V.stat
> > > > grid_stat_Kasatochi_200000L_20080809_000000V.stat
> > > > ensemble_stat_volc_20080809_120000V.stat
> > > > grid_stat_Kasatochi_320000L_20080809_120000V.stat
> > > > ensemble_stat_volc_20080809_230000V.stat
> > > > grid_stat_Kasatochi_430000L_20080809_230000V.stat
> > > > ensemble_stat_volc_20080810_100000V.stat
> > > > grid_stat_Kasatochi_540000L_20080810_100000V.stat
> > > > ensemble_stat_volc_20080810_120000V.stat
> > > > grid_stat_Kasatochi_560000L_20080810_120000V.stat
> > > >
> > > > Thank you very much!
> > > > Binyu
> > > >
> > > > On Tue, May 26, 2020 at 2:39 PM Tatiana Burek via RT
> > > > <met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > > Hi Binyu,
> > > > > You are getting an empty plot when you choose Kasatochi
model for
> > > "Rely"
> > > > > plot because there is no data with these criteria in PCT
table.
> > > Variable
> > > > > 'VAFTD_ENS_FREQ_gt2.and.le3' has data only for the model
'gefs'.
> > > Actually,
> > > > > there is no data for 'Kasatochi' in PCT table at all.
> > > > >
> > > > > Tatiana
> > > > >
> > > > > On Tue May 26 09:24:22 2020, binyu.wang at noaa.gov wrote:
> > > > > > Hello Tatinana,
> > > > > >
> > > > > > I have a question for you about the "Rely" plot on
METviewer, I
> > > > > > could
> > > > > > make
> > > > > > a plot without picking " Series Variables", but I can not
make
> > > > > > the
> > > > > > plot if
> > > > > > I did pick "Series Variable". Below is the details:
> > > > > >
> > > > > > I had a database "mv_g2g_met_verf_kasat" under "NCEP
bwang",
> > > > > > I
> > > tried
> > > > > > to
> > > > > > make a "Rely" plot, but it is weird that I can not make a
plot
> > > > > > if I
> > > > > > pick
> > > > > > "Kasatochi" as the Model, but I could make a plot without
any
> > > > > > model
> > > > > > selected (although it is a bad plot).
> > > > > >
> > > > > > I attached the plots to the email. "Rely_blank.png" is the
one
> > > without
> > > > > > a
> > > > > > plot, "Rely.png" is the one with a plot, you can see I
didn't
> > > > > > pick
> > > any
> > > > > > model for this plot. The same thing happens for Roc plot
as
> > > > > > well. Any
> > > > > > hint
> > > > > > on this?
> > > > > >
> > > > > > Thank you.
> > > > > > Binyu
> > > > > >
> > > > > > On Tue, May 19, 2020 at 3:06 PM Binyu Wang - NOAA
Affiliate <
> > > > > > binyu.wang at noaa.gov> wrote:
> > > > > >
> > > > > > > Thank you, Tatinana.
> > > > > > > Binyu
> > > > > > >
> > > > > > > On Tue, May 19, 2020 at 11:08 AM Tatiana Burek via RT
> > > > > > > <met_help at ucar.edu>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Hi Binyu
> > > > > > >>
> > > > > > >> I don't have an access to Hera and can't see that is in
> > > > > > >>
/scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
> > > > > > >> directory
> > > > > > >> or how
> > > > > > >> your XML is configured.
> > > > > > >> METviewer loading scripts copies ALL directories and
files
> > > > > > >> from
> > > the
> > > > > > >> directory you specify in the XML. It performs the data
> > > > > > >> loading
> > > based
> > > > > > >> on the
> > > > > > >> configuration from XML and then deletes all copied data
> > > > > > >> files from
> > > > > > >> AWS.
> > > > > > >> If your data directory contains files other then from
MET or
> > > > > > >> VSDB
> > > > > > >> they
> > > > > > >> would be also copied to the AWS but ignored and later
> > > > > > >> removed.
> > > > > > >> It is better if you avoid putting other files to your
data
> > > > > > >> directories.
> > > > > > >>
> > > > > > >> Tatiana
> > > > > > >>
> > > > > > >>
> > > > > > >> On Mon May 18 21:18:28 2020, binyu.wang at noaa.gov wrote:
> > > > > > >> > Hello Tatiana,
> > > > > > >> >
> > > > > > >> > I have another question for you: when I tried to load
the
> > > > > > >> > data,
> > > > > > >> > for
> > > > > > >> > some reason, many unrelated data/files from nowhere
were
> > > uploaded
> > > > > > >> > too.
> > > > > > >> > Those files were not inside of the directory at all!
(
> > > > > > >> > there are
> > > > > > >> > only 2
> > > > > > >> > files I want to upload and they are located
> > > > > > >> > at /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/stat/*) . I
have
> > > > > > >> > to
> > > stop
> > > > > > >> > it
> > > > > > >> from
> > > > > > >> > running. It didn't happen the first time when I tried
to
> > > > > > >> > upload
> > > > > > >> > the data
> > > > > > >> >
> > > > > > >> > What is the problem here? I am working on Hera now:
> > > > > > >> > cd
> > > > > > >> >
/scratch2/NCEPDEV/naqfc/Binyu.Wang/MET/METviewer_AWS/g2g
> > > > > > >> >
> > > > > > >> > -sh-4.2$ ./run_g2g_met_verf_kasat.sh
> > > > > > >> > CALLING: cd /scratch2/NCEPDEV/naqfc/Binyu.Wang/MET
> > > > > > >> > CALLING: scp -r ./*
> > > > > > >> > binyu.wang at 205.156.8.85://data/mv_data/binyu.wang
> > > > > > >> > verf_g2o_point_stat_sref_config_prebufr 100%
> > > > > > >> > 12KB
> > > > > > >> > 931.7KB/s
> > > > > > >> > 00:00
> > > > > > >> > run_test.sh 100%
533
> > > > > > >> > 39.8KB/s
> > > > > > >> > 00:00
> > > > > > >> > EnsembleStatConfig 100%
5157
> > > > > > >> > 389.4KB/s
> > > > > > >> > 00:00
> > > > > > >> > PB2NCConfig_SREF 100%
2195
> > > > > > >> > 162.9KB/s
> > > > > > >> > 00:00
> > > > > > >> > verf_g2o_ens_stat_sref_config_prebufr 100%
5399
> > > > > > >> > 404.5KB/s
> > > > > > >> > 00:00
> > > > > > >> > gefs_file_list_00z_20190621_000 100%
2943
> > > > > > >> > 221.2KB/s
> > > > > > >> > 00:00
> > > > > > >> > verf_g2g_gefs.201906.sh 100%
665
> > > > > > >> > 49.6KB/s
> > > > > > >> > 00:00
> > > > > > >> > ensemble_stat_gefs_test_20190621_000000V_orank. 100%
> > > > > > >> > 28MB
> > > > > > >> > 41.5MB/s
> > > > > > >> > 00:00
> > > > > > >> > grid_stat_gefs_test_000000L_20190621_000000V.st 100%
> > > > > > >> > 763KB
> > > > > > >> > 16.8MB/s
> > > > > > >> > 00:00
> > > > > > >> > ensemble_stat_gefs_test_20190621_000000V.stat 100%
> > > > > > >> > 19KB
> > > > > > >> > 1.4MB/s
> > > > > > >> > 00:00
> > > > > > >> > ensemble_stat_gefs_Reven_20190225_000000V_relp. 100%
4657
> > > > > > >> > 348.1KB/s
> > > > > > >> > 00:00
> > > > > > >> > ensemble_stat_gefs_Reven_20190225_000000V_ens.n 100%
> > > > > > >> > 90MB
> > > > > > >> > 6.9MB/s
> > > > > > >> > 00:12
> > > > > > >> > ensemble_stat_gefs_test_20190621_000000V_ssvar. 100%
5091
> > > > > > >> > 359.8KB/s
> > > > > > >> > 00:00
> > > > > > >> > ensemble_stat_gefs_test_20190621_000000V_relp.t 100%
4074
> > > > > > >> > 290.1KB/s
> > > > > > >> > 00:00
> > > > > > >> > ensemble_stat_gefs_Reven_20190225_000000V_ssvar 100%
6817
> > > > > > >> > 483.7KB/s
> > > > > > >> > 00:00
> > > > > > >> > ensemble_stat_gefs_test_20190621_000000V_ens.nc 100%
> > > > > > >> > 127MB
> > > > > > >> > 5.9MB/s
> > > > > > >> > 00:21
> > > > > > >> > ensemble_stat_gefs_Reven_20190225_000000V.stat 100%
> > > > > > >> > 25KB
> > > > > > >> > 1.7MB/s
> > > > > > >> > 00:00
> > > > > > >> > CKilled by signal 2.
> > > > > > >> > ERROR: Command returned with non-zero status (1): scp
-r
> > > > > > >> > ./*
> > > > > > >> > binyu.wang@
> > > > > > >> > 205.156.8.85://data/mv_data/binyu.wang
> > > > > > >> >
> > > > > > >> > Thank you.
> > > > > > >> > Binyu
> > > > > > >> >
> > > > > > >> > On Mon, May 18, 2020 at 3:17 PM Binyu Wang - NOAA
> > > > > > >> > Affiliate <
> > > > > > >> > binyu.wang at noaa.gov> wrote:
> > > > > > >> >
> > > > > > >> > > Thank you very much, Tatiana.
> > > > > > >> > >
> > > > > > >> > > Binyu
> > > > > > >> > >
> > > > > > >> > > On Mon, May 18, 2020 at 2:48 PM Tatiana Burek via
RT <
> > > > > > >> met_help at ucar.edu>
> > > > > > >> > > wrote:
> > > > > > >> > >
> > > > > > >> > >> Hi Binyu
> > > > > > >> > >> You are correct - 'mv_g2g_met_verf_kasat' database
is
> > > > > > >> > >> deleted
> > > > > > >> > >> from
> > > > > > >> AWS
> > > > > > >> > >> server.
> > > > > > >> > >> For the performance reason, METviewer cashes
databases
> > > > > > >> > >> names
> > > in
> > > > > > >> memory
> > > > > > >> > >> and that is why it was present in the list of
databases
> > > > > > >> > >> in
> > > GUI.
> > > > > > >> > >> To clear the cash you need to click on 'Reload
> > > > > > >> > >> databases' in
> > > > > > >> > >> the
> > > > > > >> upper
> > > > > > >> > >> right corner and reload the page. Deleted database
> > > > > > >> > >> should be
> > > > > > >> > >> removed
> > > > > > >> from
> > > > > > >> > >> the menu after that.
> > > > > > >> > >> I have done this already so you should not see
that
> > > > > > >> > >> database
> > > > > > >> > >> after
> > > > > > >> you
> > > > > > >> > >> reload the page.
> > > > > > >> > >>
> > > > > > >> > >> Tatiana
> > > > > > >> > >>
> > > > > > >> > >> On Mon May 18 12:05:01 2020, binyu.wang at noaa.gov
wrote:
> > > > > > >> > >> > Hello Methelp,
> > > > > > >> > >> >
> > > > > > >> > >> > I have a question about MEtviewer: two hours ago
I
> > > > > > >> > >> > deleted
> > > a
> > > > > > >> database
> > > > > > >> > >> using
> > > > > > >> > >> > "mv_delete_db_on_aws.sh binyu.wang
> > > > > > >> > >> > mv_g2g_met_verf_kasat"
> > > and
> > > > > > >> > >> > it
> > > > > > >> seems
> > > > > > >> > >> the
> > > > > > >> > >> > database is gone. But I still can see it on
METviewer
> > > > > > >> > >> > even
> > > on
> > > > > > >> > >> > a new
> > > > > > >> > >> window,
> > > > > > >> > >> > what is the problem here?
> > > > > > >> > >> >
> > > > > > >> > >> > Thank you.
> > > > > > >> > >> > Binyu
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> > >
>
>
>
>
------------------------------------------------
Subject: METviewer
From: binyu.wang at noaa.gov
Time: Wed May 27 15:53:40 2020
Hello Tatiana,
Another question I want to confirm: whenever I try to upload the
database
using " mv_load_to_aws.sh", all the files in the BASE_DIR will be
reloaded
again, is that correct? How about the replaced files? eg: If I
replace an
old file with a new one (same name) in the BASE_DIR, but it seems the
old
file was still left in the R data in the METviewer. So replacing the
file
in the BASE_DIR ONLY will not replace that in the database, is that
correct?
Thank you.
Binyu
On Mon, May 18, 2020 at 2:48 PM Tatiana Burek via RT
<met_help at ucar.edu>
wrote:
> Hi Binyu
> You are correct - 'mv_g2g_met_verf_kasat' database is deleted from
AWS
> server.
> For the performance reason, METviewer cashes databases names in
memory and
> that is why it was present in the list of databases in GUI.
> To clear the cash you need to click on 'Reload databases' in the
upper
> right corner and reload the page. Deleted database should be removed
from
> the menu after that.
> I have done this already so you should not see that database after
you
> reload the page.
>
> Tatiana
>
> On Mon May 18 12:05:01 2020, binyu.wang at noaa.gov wrote:
> > Hello Methelp,
> >
> > I have a question about MEtviewer: two hours ago I deleted a
database
> using
> > "mv_delete_db_on_aws.sh binyu.wang mv_g2g_met_verf_kasat" and it
seems
> the
> > database is gone. But I still can see it on METviewer even on a
new
> window,
> > what is the problem here?
> >
> > Thank you.
> > Binyu
>
>
>
>
------------------------------------------------
Subject: METviewer
From: Tatiana Burek
Time: Fri May 29 13:43:22 2020
Hello Binyu,
METviwer doesn't have replacing-on-load feature.
This is how it works:
Assuming you loaded a set of files to your database... And you would
like to load data located in the same set of files (the data can be
changed since the previous load). Load XML has a tag <force_dup_file>.
If its value is FALSE:
- METviewer will signal that this file has already been loaded and
skip it
If its value is TRUE:
- METviwer would load the data again without deleting the previously
loaded data. So you might end up with duplicated data or different
values for the same header.
And you are correct: replacing the file in the BASE_DIR will not
replace that in the database.
Tatiana
On Wed May 27 15:53:40 2020, binyu.wang at noaa.gov wrote:
> Hello Tatiana,
>
> Another question I want to confirm: whenever I try to upload the
database
> using " mv_load_to_aws.sh", all the files in the BASE_DIR will be
reloaded
> again, is that correct? How about the replaced files? eg: If I
replace an
> old file with a new one (same name) in the BASE_DIR, but it seems
the old
> file was still left in the R data in the METviewer. So replacing
the file
> in the BASE_DIR ONLY will not replace that in the database, is that
correct?
>
> Thank you.
> Binyu
>
> On Mon, May 18, 2020 at 2:48 PM Tatiana Burek via RT
<met_help at ucar.edu>
> wrote:
>
> > Hi Binyu
> > You are correct - 'mv_g2g_met_verf_kasat' database is deleted from
AWS
> > server.
> > For the performance reason, METviewer cashes databases names in
memory and
> > that is why it was present in the list of databases in GUI.
> > To clear the cash you need to click on 'Reload databases' in the
upper
> > right corner and reload the page. Deleted database should be
removed from
> > the menu after that.
> > I have done this already so you should not see that database after
you
> > reload the page.
> >
> > Tatiana
> >
> > On Mon May 18 12:05:01 2020, binyu.wang at noaa.gov wrote:
> > > Hello Methelp,
> > >
> > > I have a question about MEtviewer: two hours ago I deleted a
database
> > using
> > > "mv_delete_db_on_aws.sh binyu.wang mv_g2g_met_verf_kasat" and
it seems
> > the
> > > database is gone. But I still can see it on METviewer even on a
new
> > window,
> > > what is the problem here?
> > >
> > > Thank you.
> > > Binyu
> >
> >
> >
> >
------------------------------------------------
More information about the Met_help
mailing list