[Met_help] [rt.rap.ucar.edu #94991] History for MODE Analysis [NetCDF: HDF error w/StageIV + WRF Output]
John Halley Gotway via RT
met_help at ucar.edu
Wed May 20 14:27:52 MDT 2020
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello,
I'm trying to run ''mode" analysis for WRFv3.7/8.1 output (RAINNC+RAINC)
with respect to summed, 24hr StageIV precipitation data (over 72hrs).
Unfortunately, I encountered the following error while running
./bin/mode... According to my mode.log file, I need 3 arguments for my
forecasted dataset (I only provided 3 inputs while running mode).
[image: image.png]
Can you provide some feedback to help me resolve this problem?
Here is my procedure:
1) Get WRF total accumulation .nc file
AFWA_TOTPRECIP: "AFWA Diagnostic: Total simulation precip"
1.a) Load NCO
module load nco/4.4.0
1.b) Process data for final wrfout hour
ncks -v AFWA_TOTPRECIP wrfout_d01_2006-02-13_06:00:00 AFWA_TOTPRECIP.nc
2) Sum StageIV precipitation Analysis
2.a) Extract tar/.Z files
tar -xvf [file_name]
gunzip *.Z
2.b) Sum three, 24hrly StageIV precipitation files.
At the met-8.1.2 directory:
./bin/pcp_combine -sum 00000000_000000 24 20060213_120000 72 sum_test.nc
-pcpdir ./MODE_PROCEDURE/STAGEIV_Test/
3) Run 'mode'
At the met-8.1.2 directory:
./bin/mode ./MODE_PROCEDURE/MODE_Files_nc/AFWA_TOTPRECIP.nc
./MODE_PROCEDURE/MODE_Files_nc/sum_test.nc
./MODE_PROCEDURE/MODE_Files_nc/MODEConfig_APCP_WWE -log mode.log
I believe by adding "to_grid = FCST;" into the mode configuration file,
regridding sum_test.nc to the grid of AFWA_TOTPRECIP.nc is unnecessary.
Any help will greatly be appreciated!
I attached my configuration file, AFWA_TOTPRECIP.nc, sum_test.nc, and
mode.log if it helps!
--
*Sincerely,*
Michael S. Walters | B.S. Atmospheric Science
Graduate Research Assistant
Master's Student | Civil and Environmental Engineering
261 Glenbrook Road. Storrs, CT, 06269-3037
University of Connecticut
Phone: 774-254-6608
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: MODE Analysis [NetCDF: HDF error w/StageIV + WRF Output]
From: Julie Prestopnik
Time: Tue Apr 21 18:33:00 2020
Hi Michael.
I have assigned this ticket to John Halley Gotway, who should be able
to
assist you with this work. Please allow a few business days for a
response.
Julie
--
Julie Prestopnik
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: MODE Analysis [NetCDF: HDF error w/StageIV + WRF Output]
From: John Halley Gotway
Time: Wed Apr 22 23:16:17 2020
Hi Michael,
Sorry for the delay in getting back to you on this. I see you're
having
some trouble running the MODE tool. Thanks for sending your sample
data
files.
I ran mode using the files you sent was able to replicate the behavior
you
describe:
> mode AFWA_TOTPRECIP.nc sum_test.nc MODEConfig_APCP_WWE
ERROR : NcCfFile::getData(NcVar *, const LongArray &, DataPlane &)
const
-> needed 3 arguments for variable AFWA_TOTPRECIP, got 2
Take a look in the AFWA file at the AFWA_TOTPRECIP variable:
> ncdump -h AFWA_TOTPRECIP.nc
float AFWA_TOTPRECIP(XTIME, y, x) ;
Notice that it's indexed by 3 dimensions. In the MODE config file,
the
"level" setting must include an entry for each of those 3 dimensions.
I
updated MODEConfig_APCP_WWE as shown below:
*fcst = { field = { name = "AFWA_TOTPRECIP"; level =
"(0,*,*)"; }*
I also had to revert the colortable settings back to:
* color_table = "MET_BASE/colortables/met_default.ctable";
color_table = "MET_BASE/colortables/met_default.ctable";
color_table = "MET_BASE/colortables/mode_obj.ctable";*
And then it ran fine. See a png version of the first page of the
PostScript output from MODE.
Judging by the size of the resolved objects, I'd recommend reducing
the
convolution radius or increasing the threshold to make smaller
objects.
Hopefully this helps get you going.
Thanks,
John Halley Gotway
On Tue, Apr 21, 2020 at 6:33 PM Julie Prestopnik via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94991 >
>
> Hi Michael.
>
> I have assigned this ticket to John Halley Gotway, who should be
able to
> assist you with this work. Please allow a few business days for a
> response.
>
> Julie
>
> --
> Julie Prestopnik
> Software Engineer
> National Center for Atmospheric Research
> Research Applications Laboratory
> Phone: 303.497.8399
> Email: jpresto at ucar.edu
>
> My working day may not be your working day. Please do not feel
obliged to
> reply to this email outside of your normal working hours.
>
>
------------------------------------------------
Subject: MODE Analysis [NetCDF: HDF error w/StageIV + WRF Output]
From: Michael Walters
Time: Thu Apr 23 11:03:23 2020
Thank you so very much, John! This tool is great! I have a few other
questions that I'd like your feedback for though.
My domain setup for WRF is about the size of the plotted box. Would
you
recommend masking StageIV (observation) precipitation data to the
bounds of
the WRF (forecast) domain for better results?
Also, through your experience, would you recommend changing any of the
mode
options (such as conv. radius)? A little bit of background, I ran 38
simulations (for 3 different modeling systems) for significant snow
events
based on the Regional Snowfall Index (for the Northeast U.S.) and I'm
comparing NWP qpf fields to StageIV precipitation analysis. My goal is
to
determine how well NWP performs with respect to broad areas of
precipitation (possibly linking it to banded precipitation as well)
during
snow events.
Thanks again!
<http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Thu, Apr 23, 2020 at 1:16 AM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> *Message sent from a system outside of UConn.*
>
>
> Hi Michael,
>
> Sorry for the delay in getting back to you on this. I see you're
having
> some trouble running the MODE tool. Thanks for sending your sample
data
> files.
>
> I ran mode using the files you sent was able to replicate the
behavior you
> describe:
> > mode AFWA_TOTPRECIP.nc sum_test.nc MODEConfig_APCP_WWE
> ERROR : NcCfFile::getData(NcVar *, const LongArray &, DataPlane &)
const
> -> needed 3 arguments for variable AFWA_TOTPRECIP, got 2
>
> Take a look in the AFWA file at the AFWA_TOTPRECIP variable:
> > ncdump -h AFWA_TOTPRECIP.nc
> float AFWA_TOTPRECIP(XTIME, y, x) ;
>
> Notice that it's indexed by 3 dimensions. In the MODE config file,
the
> "level" setting must include an entry for each of those 3
dimensions. I
> updated MODEConfig_APCP_WWE as shown below:
>
>
>
>
>
> *fcst = { field = { name = "AFWA_TOTPRECIP"; level =
> "(0,*,*)"; }*
>
> I also had to revert the colortable settings back to:
>
>
>
> * color_table = "MET_BASE/colortables/met_default.ctable";
> color_table = "MET_BASE/colortables/met_default.ctable";
> color_table = "MET_BASE/colortables/mode_obj.ctable";*
>
> And then it ran fine. See a png version of the first page of the
> PostScript output from MODE.
>
> Judging by the size of the resolved objects, I'd recommend reducing
the
> convolution radius or increasing the threshold to make smaller
objects.
>
> Hopefully this helps get you going.
>
> Thanks,
> John Halley Gotway
>
> On Tue, Apr 21, 2020 at 6:33 PM Julie Prestopnik via RT
<met_help at ucar.edu
> >
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94991 >
> >
> > Hi Michael.
> >
> > I have assigned this ticket to John Halley Gotway, who should be
able to
> > assist you with this work. Please allow a few business days for a
> > response.
> >
> > Julie
> >
> > --
> > Julie Prestopnik
> > Software Engineer
> > National Center for Atmospheric Research
> > Research Applications Laboratory
> > Phone: 303.497.8399
> > Email: jpresto at ucar.edu
> >
> > My working day may not be your working day. Please do not feel
obliged
> to
> > reply to this email outside of your normal working hours.
> >
> >
>
>
--
*Sincerely,*
Michael S. Walters | B.S. Atmospheric Science
Graduate Research Assistant
Master's Student | Civil and Environmental Engineering
261 Glenbrook Road. Storrs, CT, 06269-3037
University of Connecticut
Phone: 774-254-6608
<http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
------------------------------------------------
Subject: MODE Analysis [NetCDF: HDF error w/StageIV + WRF Output]
From: John Halley Gotway
Time: Thu Apr 23 12:33:56 2020
Michael,
Since you're already using the "regrid" configuration option to
automatically regrid the StageIV data to your WRF model domain, I
can't see
how additional masking of the StageIV data would be useful. I don't
think
it'd have any impact on the results.
As for the settings, you can modify the convolution radius and
threshold to
create objects which match the features you're trying to study. So it
really is up to you. I will say though that generally I find MODE's
results easiest to interpret when the size of the objects are
relatively
small compared to the size of the domain. In your case, with such a
small
domain in the northeast and with relatively large scale precipitation
objects, you're be left with lot's of edge effects.
If you were to run MODE on a global grid, then the MODE's object area
would
accurately represent the area of the precipitation feature. In your
case,
the precip feature will very often be truncated by the edge of the
domain.
And that makes the interpretation more difficult. When looking at
matched
fcst/obs pairs, you may see a difference in the centroid locations.
But is
that centroid offset due to a true offset in the precipitation object
or
due to what part of that object happens to fall in your domain?
Whenever
an object touches the edge of the domain, we can't really answer that
question.
Thanks,
John
On Thu, Apr 23, 2020 at 11:06 AM Michael Walters via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94991 >
>
> Thank you so very much, John! This tool is great! I have a few other
> questions that I'd like your feedback for though.
>
> My domain setup for WRF is about the size of the plotted box. Would
you
> recommend masking StageIV (observation) precipitation data to the
bounds of
> the WRF (forecast) domain for better results?
>
> Also, through your experience, would you recommend changing any of
the mode
> options (such as conv. radius)? A little bit of background, I ran 38
> simulations (for 3 different modeling systems) for significant snow
events
> based on the Regional Snowfall Index (for the Northeast U.S.) and
I'm
> comparing NWP qpf fields to StageIV precipitation analysis. My goal
is to
> determine how well NWP performs with respect to broad areas of
> precipitation (possibly linking it to banded precipitation as well)
during
> snow events.
>
> Thanks again!
>
>
> <
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> >
> Virus-free.
> www.avg.com
> <
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Thu, Apr 23, 2020 at 1:16 AM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > *Message sent from a system outside of UConn.*
> >
> >
> > Hi Michael,
> >
> > Sorry for the delay in getting back to you on this. I see you're
having
> > some trouble running the MODE tool. Thanks for sending your
sample data
> > files.
> >
> > I ran mode using the files you sent was able to replicate the
behavior
> you
> > describe:
> > > mode AFWA_TOTPRECIP.nc sum_test.nc MODEConfig_APCP_WWE
> > ERROR : NcCfFile::getData(NcVar *, const LongArray &, DataPlane
&) const
> > -> needed 3 arguments for variable AFWA_TOTPRECIP, got 2
> >
> > Take a look in the AFWA file at the AFWA_TOTPRECIP variable:
> > > ncdump -h AFWA_TOTPRECIP.nc
> > float AFWA_TOTPRECIP(XTIME, y, x) ;
> >
> > Notice that it's indexed by 3 dimensions. In the MODE config
file, the
> > "level" setting must include an entry for each of those 3
dimensions. I
> > updated MODEConfig_APCP_WWE as shown below:
> >
> >
> >
> >
> >
> > *fcst = { field = { name = "AFWA_TOTPRECIP"; level =
> > "(0,*,*)"; }*
> >
> > I also had to revert the colortable settings back to:
> >
> >
> >
> > * color_table = "MET_BASE/colortables/met_default.ctable";
> > color_table = "MET_BASE/colortables/met_default.ctable";
> > color_table = "MET_BASE/colortables/mode_obj.ctable";*
> >
> > And then it ran fine. See a png version of the first page of the
> > PostScript output from MODE.
> >
> > Judging by the size of the resolved objects, I'd recommend
reducing the
> > convolution radius or increasing the threshold to make smaller
objects.
> >
> > Hopefully this helps get you going.
> >
> > Thanks,
> > John Halley Gotway
> >
> > On Tue, Apr 21, 2020 at 6:33 PM Julie Prestopnik via RT <
> met_help at ucar.edu
> > >
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94991 >
> > >
> > > Hi Michael.
> > >
> > > I have assigned this ticket to John Halley Gotway, who should be
able
> to
> > > assist you with this work. Please allow a few business days for
a
> > > response.
> > >
> > > Julie
> > >
> > > --
> > > Julie Prestopnik
> > > Software Engineer
> > > National Center for Atmospheric Research
> > > Research Applications Laboratory
> > > Phone: 303.497.8399
> > > Email: jpresto at ucar.edu
> > >
> > > My working day may not be your working day. Please do not feel
obliged
> > to
> > > reply to this email outside of your normal working hours.
> > >
> > >
> >
> >
>
> --
>
> *Sincerely,*
>
> Michael S. Walters | B.S. Atmospheric Science
> Graduate Research Assistant
> Master's Student | Civil and Environmental Engineering
> 261 Glenbrook Road. Storrs, CT, 06269-3037
> University of Connecticut
> Phone: 774-254-6608
>
> <
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> >
> Virus-free.
> www.avg.com
> <
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
------------------------------------------------
Subject: MODE Analysis [NetCDF: HDF error w/StageIV + WRF Output]
From: Michael Walters
Time: Thu Apr 23 13:45:07 2020
Thanks for your feedback and help, John.
That's a good point that I did not consider (poor centroids defined as
a
result of NWP's boundary). Given what you wrote, if this is applicable
to
what I'd like to study, I'll configure MODE specifically to what I
want to
analyze. I'll try to define any boundary related errors if they arise.
Have a great day!
<http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail>
<#m_-6519207214278552914_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Thu, Apr 23, 2020 at 2:34 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> *Message sent from a system outside of UConn.*
>
>
> Michael,
>
> Since you're already using the "regrid" configuration option to
> automatically regrid the StageIV data to your WRF model domain, I
can't see
> how additional masking of the StageIV data would be useful. I don't
think
> it'd have any impact on the results.
>
> As for the settings, you can modify the convolution radius and
threshold to
> create objects which match the features you're trying to study. So
it
> really is up to you. I will say though that generally I find MODE's
> results easiest to interpret when the size of the objects are
relatively
> small compared to the size of the domain. In your case, with such a
small
> domain in the northeast and with relatively large scale
precipitation
> objects, you're be left with lot's of edge effects.
>
> If you were to run MODE on a global grid, then the MODE's object
area would
> accurately represent the area of the precipitation feature. In your
case,
> the precip feature will very often be truncated by the edge of the
domain.
> And that makes the interpretation more difficult. When looking at
matched
> fcst/obs pairs, you may see a difference in the centroid locations.
But is
> that centroid offset due to a true offset in the precipitation
object or
> due to what part of that object happens to fall in your domain?
Whenever
> an object touches the edge of the domain, we can't really answer
that
> question.
>
> Thanks,
> John
>
> On Thu, Apr 23, 2020 at 11:06 AM Michael Walters via RT
<met_help at ucar.edu
> >
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94991 >
> >
> > Thank you so very much, John! This tool is great! I have a few
other
> > questions that I'd like your feedback for though.
> >
> > My domain setup for WRF is about the size of the plotted box.
Would you
> > recommend masking StageIV (observation) precipitation data to the
bounds
> of
> > the WRF (forecast) domain for better results?
> >
> > Also, through your experience, would you recommend changing any of
the
> mode
> > options (such as conv. radius)? A little bit of background, I ran
38
> > simulations (for 3 different modeling systems) for significant
snow
> events
> > based on the Regional Snowfall Index (for the Northeast U.S.) and
I'm
> > comparing NWP qpf fields to StageIV precipitation analysis. My
goal is to
> > determine how well NWP performs with respect to broad areas of
> > precipitation (possibly linking it to banded precipitation as
well)
> during
> > snow events.
> >
> > Thanks again!
> >
> >
> > <
> >
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> > >
> > Virus-free.
> > www.avg.com
> > <
> >
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> > >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> > On Thu, Apr 23, 2020 at 1:16 AM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > *Message sent from a system outside of UConn.*
> > >
> > >
> > > Hi Michael,
> > >
> > > Sorry for the delay in getting back to you on this. I see
you're
> having
> > > some trouble running the MODE tool. Thanks for sending your
sample
> data
> > > files.
> > >
> > > I ran mode using the files you sent was able to replicate the
behavior
> > you
> > > describe:
> > > > mode AFWA_TOTPRECIP.nc sum_test.nc MODEConfig_APCP_WWE
> > > ERROR : NcCfFile::getData(NcVar *, const LongArray &, DataPlane
&)
> const
> > > -> needed 3 arguments for variable AFWA_TOTPRECIP, got 2
> > >
> > > Take a look in the AFWA file at the AFWA_TOTPRECIP variable:
> > > > ncdump -h AFWA_TOTPRECIP.nc
> > > float AFWA_TOTPRECIP(XTIME, y, x) ;
> > >
> > > Notice that it's indexed by 3 dimensions. In the MODE config
file, the
> > > "level" setting must include an entry for each of those 3
dimensions.
> I
> > > updated MODEConfig_APCP_WWE as shown below:
> > >
> > >
> > >
> > >
> > >
> > > *fcst = { field = { name = "AFWA_TOTPRECIP"; level
=
> > > "(0,*,*)"; }*
> > >
> > > I also had to revert the colortable settings back to:
> > >
> > >
> > >
> > > * color_table =
"MET_BASE/colortables/met_default.ctable";
> > > color_table = "MET_BASE/colortables/met_default.ctable";
> > > color_table = "MET_BASE/colortables/mode_obj.ctable";*
> > >
> > > And then it ran fine. See a png version of the first page of
the
> > > PostScript output from MODE.
> > >
> > > Judging by the size of the resolved objects, I'd recommend
reducing the
> > > convolution radius or increasing the threshold to make smaller
objects.
> > >
> > > Hopefully this helps get you going.
> > >
> > > Thanks,
> > > John Halley Gotway
> > >
> > > On Tue, Apr 21, 2020 at 6:33 PM Julie Prestopnik via RT <
> > met_help at ucar.edu
> > > >
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94991
>
> > > >
> > > > Hi Michael.
> > > >
> > > > I have assigned this ticket to John Halley Gotway, who should
be able
> > to
> > > > assist you with this work. Please allow a few business days
for a
> > > > response.
> > > >
> > > > Julie
> > > >
> > > > --
> > > > Julie Prestopnik
> > > > Software Engineer
> > > > National Center for Atmospheric Research
> > > > Research Applications Laboratory
> > > > Phone: 303.497.8399
> > > > Email: jpresto at ucar.edu
> > > >
> > > > My working day may not be your working day. Please do not
feel
> obliged
> > > to
> > > > reply to this email outside of your normal working hours.
> > > >
> > > >
> > >
> > >
> >
> > --
> >
> > *Sincerely,*
> >
> > Michael S. Walters | B.S. Atmospheric Science
> > Graduate Research Assistant
> > Master's Student | Civil and Environmental Engineering
> > 261 Glenbrook Road. Storrs, CT, 06269-3037
> > University of Connecticut
> > Phone: 774-254-6608
> >
> > <
> >
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> > >
> > Virus-free.
> > www.avg.com
> > <
> >
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> > >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> >
>
>
--
*Sincerely,*
Michael S. Walters | B.S. Atmospheric Science
Graduate Research Assistant
Master's Student | Civil and Environmental Engineering
261 Glenbrook Road. Storrs, CT, 06269-3037
University of Connecticut
Phone: 774-254-6608
<http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail>
<#m_-6519207214278552914_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
------------------------------------------------
Subject: MODE Analysis [NetCDF: HDF error w/StageIV + WRF Output]
From: John Halley Gotway
Time: Thu Apr 23 14:01:35 2020
Sure thing. Hope you find MODE useful in your work.
I'll go ahead and resolve this ticket.
Thanks,
John
On Thu, Apr 23, 2020 at 1:45 PM Michael Walters via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94991 >
>
> Thanks for your feedback and help, John.
>
> That's a good point that I did not consider (poor centroids defined
as a
> result of NWP's boundary). Given what you wrote, if this is
applicable to
> what I'd like to study, I'll configure MODE specifically to what I
want to
> analyze. I'll try to define any boundary related errors if they
arise.
>
> Have a great day!
>
>
>
> <
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> >
> Virus-free.
> www.avg.com
> <
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> >
> <#m_-6519207214278552914_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Thu, Apr 23, 2020 at 2:34 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > *Message sent from a system outside of UConn.*
> >
> >
> > Michael,
> >
> > Since you're already using the "regrid" configuration option to
> > automatically regrid the StageIV data to your WRF model domain, I
can't
> see
> > how additional masking of the StageIV data would be useful. I
don't think
> > it'd have any impact on the results.
> >
> > As for the settings, you can modify the convolution radius and
threshold
> to
> > create objects which match the features you're trying to study.
So it
> > really is up to you. I will say though that generally I find
MODE's
> > results easiest to interpret when the size of the objects are
relatively
> > small compared to the size of the domain. In your case, with such
a
> small
> > domain in the northeast and with relatively large scale
precipitation
> > objects, you're be left with lot's of edge effects.
> >
> > If you were to run MODE on a global grid, then the MODE's object
area
> would
> > accurately represent the area of the precipitation feature. In
your
> case,
> > the precip feature will very often be truncated by the edge of the
> domain.
> > And that makes the interpretation more difficult. When looking at
> matched
> > fcst/obs pairs, you may see a difference in the centroid
locations. But
> is
> > that centroid offset due to a true offset in the precipitation
object or
> > due to what part of that object happens to fall in your domain?
Whenever
> > an object touches the edge of the domain, we can't really answer
that
> > question.
> >
> > Thanks,
> > John
> >
> > On Thu, Apr 23, 2020 at 11:06 AM Michael Walters via RT <
> met_help at ucar.edu
> > >
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94991 >
> > >
> > > Thank you so very much, John! This tool is great! I have a few
other
> > > questions that I'd like your feedback for though.
> > >
> > > My domain setup for WRF is about the size of the plotted box.
Would you
> > > recommend masking StageIV (observation) precipitation data to
the
> bounds
> > of
> > > the WRF (forecast) domain for better results?
> > >
> > > Also, through your experience, would you recommend changing any
of the
> > mode
> > > options (such as conv. radius)? A little bit of background, I
ran 38
> > > simulations (for 3 different modeling systems) for significant
snow
> > events
> > > based on the Regional Snowfall Index (for the Northeast U.S.)
and I'm
> > > comparing NWP qpf fields to StageIV precipitation analysis. My
goal is
> to
> > > determine how well NWP performs with respect to broad areas of
> > > precipitation (possibly linking it to banded precipitation as
well)
> > during
> > > snow events.
> > >
> > > Thanks again!
> > >
> > >
> > > <
> > >
> >
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> > > >
> > > Virus-free.
> > > www.avg.com
> > > <
> > >
> >
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> > > >
> > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > >
> > > On Thu, Apr 23, 2020 at 1:16 AM John Halley Gotway via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > > *Message sent from a system outside of UConn.*
> > > >
> > > >
> > > > Hi Michael,
> > > >
> > > > Sorry for the delay in getting back to you on this. I see
you're
> > having
> > > > some trouble running the MODE tool. Thanks for sending your
sample
> > data
> > > > files.
> > > >
> > > > I ran mode using the files you sent was able to replicate the
> behavior
> > > you
> > > > describe:
> > > > > mode AFWA_TOTPRECIP.nc sum_test.nc MODEConfig_APCP_WWE
> > > > ERROR : NcCfFile::getData(NcVar *, const LongArray &,
DataPlane &)
> > const
> > > > -> needed 3 arguments for variable AFWA_TOTPRECIP, got 2
> > > >
> > > > Take a look in the AFWA file at the AFWA_TOTPRECIP variable:
> > > > > ncdump -h AFWA_TOTPRECIP.nc
> > > > float AFWA_TOTPRECIP(XTIME, y, x) ;
> > > >
> > > > Notice that it's indexed by 3 dimensions. In the MODE config
file,
> the
> > > > "level" setting must include an entry for each of those 3
dimensions.
> > I
> > > > updated MODEConfig_APCP_WWE as shown below:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > *fcst = { field = { name = "AFWA_TOTPRECIP";
level =
> > > > "(0,*,*)"; }*
> > > >
> > > > I also had to revert the colortable settings back to:
> > > >
> > > >
> > > >
> > > > * color_table =
"MET_BASE/colortables/met_default.ctable";
> > > > color_table = "MET_BASE/colortables/met_default.ctable";
> > > > color_table = "MET_BASE/colortables/mode_obj.ctable";*
> > > >
> > > > And then it ran fine. See a png version of the first page of
the
> > > > PostScript output from MODE.
> > > >
> > > > Judging by the size of the resolved objects, I'd recommend
reducing
> the
> > > > convolution radius or increasing the threshold to make smaller
> objects.
> > > >
> > > > Hopefully this helps get you going.
> > > >
> > > > Thanks,
> > > > John Halley Gotway
> > > >
> > > > On Tue, Apr 21, 2020 at 6:33 PM Julie Prestopnik via RT <
> > > met_help at ucar.edu
> > > > >
> > > > wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94991 >
> > > > >
> > > > > Hi Michael.
> > > > >
> > > > > I have assigned this ticket to John Halley Gotway, who
should be
> able
> > > to
> > > > > assist you with this work. Please allow a few business days
for a
> > > > > response.
> > > > >
> > > > > Julie
> > > > >
> > > > > --
> > > > > Julie Prestopnik
> > > > > Software Engineer
> > > > > National Center for Atmospheric Research
> > > > > Research Applications Laboratory
> > > > > Phone: 303.497.8399
> > > > > Email: jpresto at ucar.edu
> > > > >
> > > > > My working day may not be your working day. Please do not
feel
> > obliged
> > > > to
> > > > > reply to this email outside of your normal working hours.
> > > > >
> > > > >
> > > >
> > > >
> > >
> > > --
> > >
> > > *Sincerely,*
> > >
> > > Michael S. Walters | B.S. Atmospheric Science
> > > Graduate Research Assistant
> > > Master's Student | Civil and Environmental Engineering
> > > 261 Glenbrook Road. Storrs, CT, 06269-3037
> > > University of Connecticut
> > > Phone: 774-254-6608
> > >
> > > <
> > >
> >
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> > > >
> > > Virus-free.
> > > www.avg.com
> > > <
> > >
> >
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> > > >
> > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > >
> > >
> >
> >
>
> --
>
> *Sincerely,*
>
> Michael S. Walters | B.S. Atmospheric Science
> Graduate Research Assistant
> Master's Student | Civil and Environmental Engineering
> 261 Glenbrook Road. Storrs, CT, 06269-3037
> University of Connecticut
> Phone: 774-254-6608
>
> <
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> >
> Virus-free.
> www.avg.com
> <
> http://www.avg.com/email-
signature?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=webmail
> >
> <#m_-6519207214278552914_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
------------------------------------------------
Subject: MODE Analysis [NetCDF: HDF error w/StageIV + WRF Output]
From: Michael Walters
Time: Tue May 05 11:47:26 2020
Hello again John,
I'd like to confirm an alteration I made to the MODE configuration
file. I
believe I'm confusing the threshold terminology.
I decided to add 4 thresholds to my evaluation (MODE analysis) so I
altered
the configuration file to the following (only these two lines):
filter_attr_name = [ "AREA", "AREA", "AREA", "AREA" ];
filter_attr_thresh = [ >=10.16, >=25.40, >=50.80, >=76.20 ];
However, the resulting .txt, .ps, and .nc files do not show additional
objects. If what I did above isn't correct to define additional
threshold/objects, I suppose the changes that I'm looking for should
be:
conv_thresh = [ >=10.16, >=25.40, >=50.80, >=76.20 ];
If so, what should the following lines be altered to?
filter_attr_name = [];
filter_attr_thresh = [];
On Thu, Apr 23, 2020 at 4:01 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> *Message sent from a system outside of UConn.*
>
>
> According to our records, your request has been resolved. If you
have any
> further questions or concerns, please respond to this message.
>
--
*Sincerely,*
Michael S. Walters | B.S. Atmospheric Science
Graduate Research Assistant
Master's Student | Civil and Environmental Engineering
261 Glenbrook Road. Storrs, CT, 06269-3037
University of Connecticut
Phone: 774-254-6608
------------------------------------------------
Subject: MODE Analysis [NetCDF: HDF error w/StageIV + WRF Output]
From: Michael Walters
Time: Tue May 05 11:47:26 2020
VERSION MODEL N_VALID GRID_RES DESC FCST_LEAD FCST_VALID
FCST_ACCUM OBS_LEAD OBS_VALID OBS_ACCUM FCST_RAD FCST_THR
OBS_RAD OBS_THR FCST_VAR FCST_UNITS FCST_LEV OBS_VAR OBS_UNITS OBS_LEV
OBTYPE OBJECT_ID OBJECT_CAT CENTROID_X CENTROID_Y CENTROID_LAT
CENTROID_LON AXIS_ANG LENGTH WIDTH AREA AREA_THRESH CURVATURE
CURVATURE_X CURVATURE_Y COMPLEXITY INTENSITY_10 INTENSITY_25
INTENSITY_50 INTENSITY_75 INTENSITY_90 INTENSITY_50 INTENSITY_SUM
CENTROID_DIST BOUNDARY_DIST CONVEX_HULL_DIST ANGLE_DIFF ASPECT_DIFF
AREA_RATIO INTERSECTION_AREA UNION_AREA SYMMETRIC_DIFF
INTERSECTION_OVER_AREA CURVATURE_RATIO COMPLEXITY_RATIO
PERCENTILE_INTENSITY_RATIO INTEREST
V8.1.2 WRF 28476 4 NA 720000 20070317_120000 240000
000000 20070317_120000 240000 5 >=5.0 5 >=5.0
APCP_24 kg/m^2 A24 APCP_24 kg/m^2 A24 MC_PCP
F001 CF001 87.78117 99.44667 43.31926 -73.63779
-3.29506 178.23188 159.01834 23044 22301 169.9277 149.89719
159.04582 0.051687 9.9 17.4 33
51.5 66.3 33 833486.79998 NA
NA NA NA NA NA
NA NA NA NA NA
NA NA NA
V8.1.2 WRF 28476 4 NA 720000 20070317_120000 240000
000000 20070317_120000 240000 5 >=5.0 5 >=5.0
APCP_24 kg/m^2 A24 APCP_24 kg/m^2 A24 MC_PCP
O001 CO001 89.88996 80.91281 42.65247 -73.53532
42.45828 242.39309 183.10245 25750 25453 162.21899 152.27309
139.25771 0.030369 8.3 15.4 25
36.6 47 25 690733.39743 NA
NA NA NA NA NA
NA NA NA NA NA
NA NA NA
V8.1.2 WRF 28476 4 NA 720000 20070317_120000 240000
000000 20070317_120000 240000 5 >=5.0 5 >=5.0
APCP_24 kg/m^2 A24 APCP_24 kg/m^2 A24 MC_PCP
F001_O001 CF001_CO001 NA NA NA NA
NA NA NA NA NA NA NA
NA NA NA NA NA NA
NA NA NA 18.65345 0
0 45.75334 0.1368 0.89491 20576 28218
7642 0.8929 0.95464 0.58756
0.75758 0.98635
V8.1.2 WRF 28476 4 NA 720000 20070317_120000 240000
000000 20070317_120000 240000 5 >=5.0 5 >=5.0
APCP_24 kg/m^2 A24 APCP_24 kg/m^2 A24 MC_PCP
CF001 CF001 87.78117 99.44667 43.31926 -73.63779
-3.29506 178.23188 159.01834 23044 22301 169.9277 149.89719
159.04582 0.051687 9.9 17.4 33
51.5 66.3 33 833486.79998 NA
NA NA NA NA NA
NA NA NA NA NA
NA NA NA
V8.1.2 WRF 28476 4 NA 720000 20070317_120000 240000
000000 20070317_120000 240000 5 >=5.0 5 >=5.0
APCP_24 kg/m^2 A24 APCP_24 kg/m^2 A24 MC_PCP
CO001 CO001 89.88996 80.91281 42.65247 -73.53532
42.45828 242.39309 183.10245 25750 25453 162.21899 152.27309
139.25771 0.030369 8.3 15.4 25
36.6 47 25 690733.39743 NA
NA NA NA NA NA
NA NA NA NA NA
NA NA NA
V8.1.2 WRF 28476 4 NA 720000 20070317_120000 240000
000000 20070317_120000 240000 5 >=5.0 5 >=5.0
APCP_24 kg/m^2 A24 APCP_24 kg/m^2 A24 MC_PCP
CF001_CO001 CF001_CO001 NA NA NA NA
NA NA NA NA NA NA NA
NA NA NA NA NA NA
NA NA NA 18.65345 0
0 45.75334 0.1368 0.89491 20576 28218
7642 0.8929 0.95464 0.58756
0.75758 0.98635
------------------------------------------------
Subject: MODE Analysis [NetCDF: HDF error w/StageIV + WRF Output]
From: Michael Walters
Time: Tue May 05 11:47:26 2020
VERSION MODEL N_VALID GRID_RES DESC FCST_LEAD FCST_VALID
FCST_ACCUM OBS_LEAD OBS_VALID OBS_ACCUM FCST_RAD FCST_THR
OBS_RAD OBS_THR FCST_VAR FCST_UNITS FCST_LEV OBS_VAR OBS_UNITS OBS_LEV
OBTYPE FIELD TOTAL FY_OY FY_ON FN_OY FN_ON BASER FMEAN ACC
FBIAS PODY PODN POFD FAR CSI GSS HK
HSS ODDS
V8.1.2 WRF 28476 4 NA 720000 20070317_120000 240000
000000 20070317_120000 240000 5 >=5.0 5 >=5.0
APCP_24 kg/m^2 A24 APCP_24 kg/m^2 A24 MC_PCP RAW
28476 19858 2483 5729 406 0.89855 0.78456 0.71162 0.87314 0.7761
0.14053 0.85947 0.11114 0.70745 -0.027067 -0.08337 -0.055641 0.56677
V8.1.2 WRF 28476 4 NA 720000 20070317_120000 240000
000000 20070317_120000 240000 5 >=5.0 5 >=5.0
APCP_24 kg/m^2 A24 APCP_24 kg/m^2 A24 MC_PCP OBJECT
28476 20567 2462 5170 277 0.90381 0.80872 0.73198 0.89478 0.79912
0.10113 0.89887 0.10691 0.72935 -0.033436 -0.099746 -0.069185 0.44758
------------------------------------------------
Subject: MODE Analysis [NetCDF: HDF error w/StageIV + WRF Output]
From: John Halley Gotway
Time: Wed May 06 16:34:14 2020
Hello Michael,
Sorry for the delay. I see you have a question about running MODE
using
multiple thresholds.
Earlier versions of MODE only supported the definition of 1
convolution
radius and 1 convolution threshold to define a single set of objects.
We
enhanced more recent versions of MODE to support the use of multiple
convolution radii and thresholds in a single call.
So the "conv_radius" and "conv_thresh" config options can be defined
either
as a single value or as an array of values. Please take a look in this
README file, which is also include in the MET User's Guide:
https://github.com/NCAR/MET/blob/master_v9.0/met/data/config/README
Here's a selection from line 2349:
// - The "conv_radius" entry specifies the convolution radius in
grid
// squares. The larger the convolution radius, the smoother the
objects.
// Multiple convolution radii may be specified as an array:
// conv_radius = [ 5, 10, 15 ];
//
// - The "conv_thresh" entry specifies the convolution threshold
used to
// define MODE objects. The lower the threshold, the larger the
objects.
// Multiple convolution thresholds may be specified as an array:
// conv_thresh = [ >=5.0, >=10.0, >=15.0 ];
Also, note the description of the quilt entry on line 2331:
// The "quilt" entry is a boolean to indicate whether all permutations
of
// convolution radii and thresholds should be run. If set to false,
the
number
// of forecast and observation convolution radii and thresholds must
all
match.
// One configuration of MODE will be run for each group of settings in
those
// lists. If set to true, the number of forecast and observation
convolution
// radii must match and the number of forecast and observation
convolution
// thresholds must match. For N radii and M thresholds, NxM
configurations
of
// MODE will be run.
When quilt = false, then the number of radii and thresholds must
match:
*quilt = false;*
*conv_radius = [ 5, 5, 5, 5 ];*
*conv_thresh = [ >=10.16, >=25.40, >=50.80, >=76.20 ];*
When quilt = true, then all permutations of conv_radius and
conv_thresh
will be run:
*quilt = true;*
*conv_radius = 5;*
*conv_thresh = [ >=10.16, >=25.40, >=50.80, >=76.20 ];*
Note that the output is written to different output files, where
"_Rn_Tm"
indicates output for the n-th Radius and m-th threshold.
See line 2361 for a description of filter_attr_name and
filter_attr_thresh:
// - The "filter_attr_name" and "filter_attr_thresh" entries are
arrays
of
// the same length which specify object filtering criteria. By
default, no
// object filtering criteria is defined.
//
// The "filter_attr_name" entry is an array of strings specifying
the
MODE
// output header column names for the object attributes of
interest,
such
// as "AREA", "LENGTH", "WIDTH", and "INTENSITY_50". In addition,
// "ASPECT_RATIO" specifies the aspect ratio (width/length),
// "INTENSITY_101" specifies the mean intensity value, and
"INTENSITY_102"
// specifies the sum of the intensity values.
//
// The "filter_attr_thresh" entry is an array of thresholds for
the
// object attributes. Any simple objects not meeting all of these
// filtering criteria are discarded.
Hope that helps clarify.
Thanks,
John
On Tue, May 5, 2020 at 11:47 AM Michael Walters via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94991 >
>
> Hello again John,
>
> I'd like to confirm an alteration I made to the MODE configuration
file. I
> believe I'm confusing the threshold terminology.
>
> I decided to add 4 thresholds to my evaluation (MODE analysis) so I
altered
> the configuration file to the following (only these two lines):
> filter_attr_name = [ "AREA", "AREA", "AREA", "AREA" ];
> filter_attr_thresh = [ >=10.16, >=25.40, >=50.80, >=76.20 ];
>
> However, the resulting .txt, .ps, and .nc files do not show
additional
> objects. If what I did above isn't correct to define additional
> threshold/objects, I suppose the changes that I'm looking for should
be:
> conv_thresh = [ >=10.16, >=25.40, >=50.80, >=76.20 ];
>
> If so, what should the following lines be altered to?
> filter_attr_name = [];
> filter_attr_thresh = [];
>
> On Thu, Apr 23, 2020 at 4:01 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > *Message sent from a system outside of UConn.*
> >
> >
> > According to our records, your request has been resolved. If you
have any
> > further questions or concerns, please respond to this message.
> >
>
>
> --
>
> *Sincerely,*
>
> Michael S. Walters | B.S. Atmospheric Science
> Graduate Research Assistant
> Master's Student | Civil and Environmental Engineering
> 261 Glenbrook Road. Storrs, CT, 06269-3037
> University of Connecticut
> Phone: 774-254-6608
>
>
------------------------------------------------
Subject: MODE Analysis [NetCDF: HDF error w/StageIV + WRF Output]
From: Michael Walters
Time: Wed May 20 14:22:42 2020
Hello John,
This clarified my question! Sorry for not emailing sooner.
On Wed, May 20, 2020 at 4:13 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> *Message sent from a system outside of UConn.*
>
>
> According to our records, your request has been resolved. If you
have any
> further questions or concerns, please respond to this message.
>
--
*Sincerely,*
Michael S. Walters | B.S. Atmospheric Science
Graduate Research Assistant
Master's Student | Civil and Environmental Engineering
261 Glenbrook Road. Storrs, CT, 06269-3037
University of Connecticut
Phone: 774-254-6608
------------------------------------------------
Subject: MODE Analysis [NetCDF: HDF error w/StageIV + WRF Output]
From: John Halley Gotway
Time: Wed May 20 14:27:41 2020
Michael,
Great, thanks for confirming. I was just cleaning up stale tickets
that
have been idle for a couple weeks.
John
On Wed, May 20, 2020 at 2:23 PM Michael Walters via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=94991 >
>
> Hello John,
>
> This clarified my question! Sorry for not emailing sooner.
>
> On Wed, May 20, 2020 at 4:13 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > *Message sent from a system outside of UConn.*
> >
> >
> > According to our records, your request has been resolved. If you
have any
> > further questions or concerns, please respond to this message.
> >
>
>
> --
>
> *Sincerely,*
>
> Michael S. Walters | B.S. Atmospheric Science
> Graduate Research Assistant
> Master's Student | Civil and Environmental Engineering
> 261 Glenbrook Road. Storrs, CT, 06269-3037
> University of Connecticut
> Phone: 774-254-6608
>
>
------------------------------------------------
More information about the Met_help
mailing list