[RegCNET] Postproc error print*, 'Values Out of Range: FIELD=', vnambc(ni)
Moetasim Ashfaq
moetasim at stanford.edu
Fri Jan 29 10:03:01 CET 2010
Hi Simon,
Postproc may give this error if you are writing compressed netcdf
format (byte*2), which calculates scale_factor and add_offset based on
min and max of particular variable. Now, this error may not
necessarily come from RegCM output. There are many variables, which
are calculated in the post-processing step. Sometimes, I have seen
this out of range error for snow water equivalent (swe) variable,
which comes from RegCM3 directly. Also, recently one of my colleague
found out of range error for divergence and vorticity, which are
calculated in postproc.
I do not have any smart way of defining min and max for all variables
which work for everyone all the time over every domain. The best
practice is what you do i.e. adjust the range if out of range error is
encountered. However, one has to be very careful in the choice of min
and max, because the values of variables in the compressed netcdf
format largely depend on them. Anyway, it is quite fortunate that I
have never seen this error for the variables which can not be derived
from other variables except for swe.
Anyway, in short, I would recommend that if anyone is using compressed
netcdf output option and gets out of range error, he should be careful
in the choice of min and max for the problematic variable. A
comparison between byte*2 and byte*4 netcdf output would be useful to
check that the newly adjusted min and max values are not creating
difference between compressed and uncompressed netcdf format at the
order of more than 10E-2 for that particular variable.
Meanwhile, I am also trying to get bit smarter to resolve this
postproc issue in more useful way.
Moet
On Jan 29, 2010, at 12:29 AM, Simon Krichak wrote:
> Dear All,
>
> I have an additional issue for discussion. In some cases my
> simulations are completed successfully without any Nan error. And
> the Postproc produces reasonable monthly averaged files. But the
> same code prints the following ,'Values Out of Range:
> FIELD=',vnambc(ni)when I am running the code with daily averaging.
> Of course I always can change the min max limits in the code. Still
> the diagnostics apparently means that the model produced results are
> not physically reasonable.
> What are the REGCNET recommendations for such situations?
>
> Best
>
> Simon Krichak
>
> ----- Original Message -----
> From: Satyaban Bishoyi Ratna
> To: rauscher at lanl.gov
> Cc: regcnet at lists.ictp.it
> Sent: Friday, January 29, 2010 7:20 AM
> Subject: [RegCNET] Nan error during model run-Common problem
>
>
> Dear Sara and All,
> Thanks for your mail and detail information about the Nan error in
> the RegCM3 model run.
> As this Nan error is a common problem in RegCM, I have some point in
> continuation with this discussion.
> Mainly, even though model is encountering Nan error during the
> integration still it proceeds up to completion of the integration.
> For long simulation people don't monitor continuously whether model
> running smoothly or there is a chance of nan error.
> Sometimes, people see that they have completed their simulation
> successfully but at the time of analyse their model output they
> realize that there is Nan error and the model output is no use.
> So they need to start or restart the simulation again.
> In my opinion it will better if there will be facility such that, In
> case there is a Nan error during the run it should come out
> immediately and stop the integration automatically without proceed
> further.
> In this way we can save lot of time.
>
> Thanking you.
>
> Best regards
> Satyaban
>
> On Thu, 28 Jan 2010 22:24:41 +0530 wrote
> >Dear Dwijenra,
>
> This is the most common question on the list (in fact, it was answered
> the other day). Everyone, please read the user's guide! It contains
> valuable information that will help you run your simulations.
> http://users.ictp.it/RegCNET/regcm.pdf
>
> The model is sensitive to the time step used. The first rule of
> thumb is
> to use 3 times the horizontal grid spacing. In your case, 60 km, so
> 180
> is the best to start with. However, in cases of steep topography you
> may
> need to decrease this time step. You might want to try 150, for
> example.
>
> If you are doing a long simulation, and this just happens once or
> twice,
> you can work around this. Set the time step to a lower value, restart
> the model to a point before where it blew up, and then after this
> point,
> stop the model, put the time step back to its original value, and
> restart the model. So for example, if my model had died on January
> 5th,
> I would probably restart at the beginning of January, do that month
> at a
> lower time step, and then continue the simulation in February at the
> original time step if that's been working. Note that this is
> acceptable
> to do once or twice in a long simulation (like > 5 years), but if it
> happens more often, you should restart the simulation from the
> beginning
> at a shorter time step.
>
> In the regcm user guide, there is a table that gives suggestions
> (these
> are just suggestions) for time steps for different grid spacing (Table
> 12, page 40):
> Table 12: Time steps with different resolutions:
>
> dx(km) dt(sec) abatm(sec) abemh(hr) radfrq(min)
> 10 30 90 18 30
> 20 60 120 18 30
> 30 100 300 18 30
> 45 150 300 18 30
> 50 150 450 18 30
> 60 200 600 18 30
> 90 225 900 18 30
>
> There is discussion of how to set the time step on page 35 in the
> user's
> guide.
> cheers
> sara
>
>
> d d wrote:
> > Dear RegCNET Users,
> >
> > I am having similar problem as Dr. Satyaban getting the NaN error
> > while running RegCM for 6 months simulation. The ICBC files are OK
> > when i checked them on grads. The Model can run successfully upto 4
> > months and after that it encounters NaN error for last two months.
> > I had tried to restart the simulation but still the same
> > domain.param configuration
> > Idate1=1997010100 start day of simulation
> > Idate2=1997063000 End day of simulation
> > ds = 60km
> >
> > regcm.in configuration
> > Idate0=1997010100
> > Idate1=1997010100
> > Idate2=1997063000
> > dt=180
> > radfrq=30
> > abemh=18
> > abatm=540
> >
> > please kindly suggests whar might be the problem
> >
> > Best regards
> > Dwijendra
> >
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > RegCNET mailing list
> > RegCNET at lists.ictp.it
> > https://lists.ictp.it/mailman/listinfo/regcnet
>
>
> --
> Sara A. Rauscher
> T-3 Fluid Dynamics
> MS B216
> Los Alamos National Lab
> Los Alamos, NM 87545 USA
> (505) 606-0512
>
> _______________________________________________
> RegCNET mailing list
> RegCNET at lists.ictp.it
> https://lists.ictp.it/mailman/listinfo/regcnet
>
>
> -------------------------------------------------------------------------------
> Dr. Satyaban Bishoyi Ratna
> Computational Atmospheric Sciences Team
> Scientific & Engineering Computing Group
> Centre for Development of Advanced Computing (C-DAC)
> Pune University Campus, Ganeshkhind
> Pune - 411 007, Maharashtra, India
> E-mail: satyabanb at cdac.in
> Tel (O): +91-020-2570 4226, (Cell): +91-094223 56326
> --------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> RegCNET mailing list
> RegCNET at lists.ictp.it
> https://lists.ictp.it/mailman/listinfo/regcnet
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.733 / Virus Database: 271.1.1/2653 - Release Date:
> 01/28/10 16:55:00
> _______________________________________________
> RegCNET mailing list
> RegCNET at lists.ictp.it
> https://lists.ictp.it/mailman/listinfo/regcnet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ictp.it/pipermail/regcnet/attachments/20100129/00e04758/attachment.html>
More information about the RegCNET
mailing list