Re: [sundials-users] CVODE error
139 views
Skip to first unread message
Alan C. Hindmarsh
Feb 9, 2022, 8:05:09 PM2/9/22
to sundial...@llnl.gov
Hello Ramon,
The advice from Neil is good. Also, to better see what
the computed solution is doing near the point of failure,
I suggest you switch to one-step mode (itask = CV_ONE_STEP)
at some point (or even for the whole problem if not too many
steps are involved).
-Alan H
On 03/14/2014 02:27 PM, ryllprous wrote:
> Hello, I've got this error and I don't know how to solve it. Any recommendation?
>
> /FVM-SOFC model. Case name: CO:0.25-H2:0.75-800-1-TEST Solve using CVODE
>
> [CVODES ERROR] CVode
> At t = 22.6112 and h = 1.60837e-06, the error test failed repeatedly or with |h| = hmin.
>
> Error during execution:
>
> ***********************************************************************
> CanteraError thrown by CVodesIntegrator:
> CVodes error encountered. Error code: -3
> ***********************************************************************
>
> Solution reached. Results saved in results/CO:0.25-H2:0.75-800-1-TEST
>
>
> RUN FINISHED; exit value 0; real time: 4m 42s; user: 10ms; system: 4m 42s/
>
>
> Thanks,
>
>
> Ramon
>
>
>
> --
> View this message in context: http://sundials.2283335.n4.nabble.com/CVODE-error-tp4653206.html
> Sent from the Sundials - Users mailing list archive at Nabble.com.
>
The advice from Neil is good. Also, to better see what
the computed solution is doing near the point of failure,
I suggest you switch to one-step mode (itask = CV_ONE_STEP)
at some point (or even for the whole problem if not too many
steps are involved).
-Alan H
On 03/14/2014 02:27 PM, ryllprous wrote:
> Hello, I've got this error and I don't know how to solve it. Any recommendation?
>
> /FVM-SOFC model. Case name: CO:0.25-H2:0.75-800-1-TEST Solve using CVODE
>
> [CVODES ERROR] CVode
> At t = 22.6112 and h = 1.60837e-06, the error test failed repeatedly or with |h| = hmin.
>
> Error during execution:
>
> ***********************************************************************
> CanteraError thrown by CVodesIntegrator:
> CVodes error encountered. Error code: -3
> ***********************************************************************
>
> Solution reached. Results saved in results/CO:0.25-H2:0.75-800-1-TEST
>
>
> RUN FINISHED; exit value 0; real time: 4m 42s; user: 10ms; system: 4m 42s/
>
>
> Thanks,
>
>
> Ramon
>
>
>
> --
> View this message in context: http://sundials.2283335.n4.nabble.com/CVODE-error-tp4653206.html
> Sent from the Sundials - Users mailing list archive at Nabble.com.
>
nsing
Feb 9, 2022, 8:05:09 PM2/9/22
to sundial...@llnl.gov
From my experience this happens when you hit a singularity.
To debug this, evaluate your functions as they approach time = 22.6112 (tell cvodes to return the solution just before this time by terminating your
integration) and look at your derivatives. If they are supposed to 'blow up'
then you have learned something about your problem formulation or you may need to rescale it. If not, you need to look at the equations and find your bug.
Look for terms that become huge or terms that go to zero in denominators etc.
Neil
--
View this message in context: http://sundials.2283335.n4.nabble.com/CVODE-error-tp4653206p4653209.html
To debug this, evaluate your functions as they approach time = 22.6112 (tell cvodes to return the solution just before this time by terminating your
integration) and look at your derivatives. If they are supposed to 'blow up'
then you have learned something about your problem formulation or you may need to rescale it. If not, you need to look at the equations and find your bug.
Look for terms that become huge or terms that go to zero in denominators etc.
Neil
--
View this message in context: http://sundials.2283335.n4.nabble.com/CVODE-error-tp4653206p4653209.html
Alan Hindmarsh
Feb 9, 2022, 8:07:14 PM2/9/22
to Andreas Nicolai
Hello Andreas,
You make some good points. If done carefully, I can see that setting
a min. step can be useful. My problem with this is that most users do
not give this issue enough thought to know what a good value is. With
a bad (too large) choice, they get stopped unnecessarily. As an
alternative, I encourage users to use the solver counters (step counts
etc.) to see whether the solver is doing a good job or instead is
taking steps that are too small. It may be important to observe the
solver getting a successful solution with a smaller than expected
average step size, in that this adds insight about the stiffness of
the problem.
Finally, if the model has an error, and the solver takes small steps
as a result, it may well be valuable to see that (wrong) solution in
order to discover the error in the model.
-Alan H
On Fri, 27 Mar 2009, Andreas Nicolai wrote:
> Hi Alan,
>
> > But there is no justification for setting a minimum step that I can
> > think of.
> From the point of view of an application writer for real-world-problems
> and users I have to disagree for once with you in this point :-) The
> difficulty with most physical or engineering questions is that problems
> are often not be so well-defined as one would wish, especially if your PDE
> is boundary condition driven where the BC can be defined flexibly by the
> user. Sometimes you end up with an undesirable combination of BC that
> cause effectively weak discontinuities. These in turn affect the solution
> so strongly, that the solver ends up with time steps of < 1e-8 seconds
> whereas "normal" time scales for the simulation are years. From my point
> of view, such time steps can be interpreted as not part of a nominal
> solver run, in which case I want to react and let the user know about
> this. Often in such cases the user made a mistake in specifying solver
> conditions, so restricting the lower time step limit is sometimes a good
> way to detect such input problems.
>
> But even in custom research-level problems, where you are the user
> yourself and know all input, sometimes restricting the MinStep is a useful
> way to detect problems in the implementation. Many (fresh) CVODE users are
> tempted to use if clauses in the f() function, without knowing what harm
> they do to the poor solver underneath. Here, if you know the approximate
> time scales of your problems, you can set MinStep to something like
> TypicalTimeScale * 1e-10. Usually, if the code works well, you may only
> break this contraint if you have bad initial conditions.
>
> Well, just my thoughts on the matter ;-)
>
> Andreas
>
You make some good points. If done carefully, I can see that setting
a min. step can be useful. My problem with this is that most users do
not give this issue enough thought to know what a good value is. With
a bad (too large) choice, they get stopped unnecessarily. As an
alternative, I encourage users to use the solver counters (step counts
etc.) to see whether the solver is doing a good job or instead is
taking steps that are too small. It may be important to observe the
solver getting a successful solution with a smaller than expected
average step size, in that this adds insight about the stiffness of
the problem.
Finally, if the model has an error, and the solver takes small steps
as a result, it may well be valuable to see that (wrong) solution in
order to discover the error in the model.
-Alan H
On Fri, 27 Mar 2009, Andreas Nicolai wrote:
> Hi Alan,
>
> > But there is no justification for setting a minimum step that I can
> > think of.
> From the point of view of an application writer for real-world-problems
> and users I have to disagree for once with you in this point :-) The
> difficulty with most physical or engineering questions is that problems
> are often not be so well-defined as one would wish, especially if your PDE
> is boundary condition driven where the BC can be defined flexibly by the
> user. Sometimes you end up with an undesirable combination of BC that
> cause effectively weak discontinuities. These in turn affect the solution
> so strongly, that the solver ends up with time steps of < 1e-8 seconds
> whereas "normal" time scales for the simulation are years. From my point
> of view, such time steps can be interpreted as not part of a nominal
> solver run, in which case I want to react and let the user know about
> this. Often in such cases the user made a mistake in specifying solver
> conditions, so restricting the lower time step limit is sometimes a good
> way to detect such input problems.
>
> But even in custom research-level problems, where you are the user
> yourself and know all input, sometimes restricting the MinStep is a useful
> way to detect problems in the implementation. Many (fresh) CVODE users are
> tempted to use if clauses in the f() function, without knowing what harm
> they do to the poor solver underneath. Here, if you know the approximate
> time scales of your problems, you can set MinStep to something like
> TypicalTimeScale * 1e-10. Usually, if the code works well, you may only
> break this contraint if you have bad initial conditions.
>
> Well, just my thoughts on the matter ;-)
>
> Andreas
>
Andreas Nicolai
Feb 9, 2022, 8:19:26 PM2/9/22
to sundial...@llnl.gov
Hi Jingjing,
> This is another code, it builds through, when I run it, there is message:
> Unhandled exception at 0x00428eb0 in filter_sim.exe: 0xC0000005: Access
> violation reading location 0xaaf9d65c.
This is not a CVODE related bug but most likely a result of a programming
error (indexing problem?) in your code. Suggestion: Compile in debug mode
and perhaps you'll get a more verbose assert message during runtime.
Otherwise check the indices you use in arrays/vectors and make sure max
index is always less than size of arrays/vectors.
Andreas
> This is another code, it builds through, when I run it, there is message:
> Unhandled exception at 0x00428eb0 in filter_sim.exe: 0xC0000005: Access
> violation reading location 0xaaf9d65c.
This is not a CVODE related bug but most likely a result of a programming
error (indexing problem?) in your code. Suggestion: Compile in debug mode
and perhaps you'll get a more verbose assert message during runtime.
Otherwise check the indices you use in arrays/vectors and make sure max
index is always less than size of arrays/vectors.
Andreas
Jingjing Pei
Feb 10, 2022, 11:39:06 AM2/10/22
to sundial...@llnl.gov
Hi,
The fact is that when I change the tout from 60sec to 20sec, it can runs until 0.5hours, then the same error message comes out again. when the tout is 10 sec, the same error message is still there. What is the real problem under this? Is there any measures we can take? Thank you!
Regards,
Jingjing
________________________________
From: Wang Huidan <dan...@foxmail.com>
To: sundials-users <sundial...@llnl.gov>
Sent: Wednesday, March 18, 2009 9:39:49 PM
Subject: Re:[sundials-users] CVODE error
can you change the tout to very small value and try it again?
------------------
Best Regards,
Huidan
------------------ Original ------------------
From: "Jingjing Pei"<jpe...@yahoo.com>;
Date: Thu, Mar 19, 2009 06:40 AM
To: "sundials-users"<sundial...@llnl.gov>;
Subject: [sundials-users] CVODE error
Hi, there,
I get error message when using the CVODE:
"At t = 3608.89 and h = 6e-005, the error test failed repeatedly or with |h| = hmin".
The settings I used is:
double relTol = 1e-4; // Relative tolerance
double absTol = 1e-12; // Absolute tolerances
// set CVODE initial step size
CVodeSetInitStep(cvodeMem, 1e-4);
// set CVODE maximum step size
CVodeSetMaxStep(cvodeMem, simdata.max_sim_dt);
// set CVODE minimum step size
CVodeSetMinStep(cvodeMem, 1e-9);
What may be the problme and solution? Thank you!
Regards,
Jingjing
Reply all
Reply to author
Forward
0 new messages