-
-
Notifications
You must be signed in to change notification settings - Fork 49
Component-wise relative and absolute tolerances #93
base: master
Are you sure you want to change the base?
Conversation
…ing Ordinary Differential Equations I by Hairer and Wanner. Component-wise AbsTol for Implicit Solvers similar to MATLAB ode23s.
tau = max(reltol*norm(x0, Inf), abstol) | ||
d0 = norm(x0, Inf)/tau | ||
tau = max(reltol.*abs(x0), abstol) | ||
d0 = norm(x0,./tau Inf) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks wrong. Should probably be x0./tau, Inf
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes. I had fixed that in my code. Didn't update. Sorry. Will commit it again.
Thanks for the PR! You have accidentally deleted the .travis.yml file, which prevents us from getting Travis feedback. Please put it back. |
I added the file and also fixed the error as you pointed out. |
# Component-wise Tolerance check similar to MATLAB ode23s | ||
# Support for component-wise absolute tolerance only. | ||
# Relative tolerance should be a scalar. | ||
@assert length(reltol) == 1 "Relative tolerance must be a scalar" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why don't you use isa(reltol, Number)
to check if it is a scalar? This also concerns the other asserts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't aware of this function. I just wanted the code to stop if we do not give the proper input.
You mean instead of checking the lengths I simply use isa() function for the asserts?
I would have to do a length check for multidimensional problems eitherways
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. I just realized that length
returns 1
for a scalar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be much better handled with a type spec on the function parameter, ie reltol::Number
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would only apply to reltol in the case of ode23s. For the other tolerances it would not be possible since they can be either a scalar or a vector of the same length as the problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. But in the specific case handled by this line, since length 1 is hard-coded anyway, I think it would be much clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright. I will make this change.
Corrected reltol::Number for ode23s
Now using only norm() since it is provided by the user and default value is provided.
Is there a fundamental reason why Could we use a function for calculating the error estimate and facilitate mult. dispatch to distinguish between scalar and vector tolerances? That way we could keep the the old behavior for the scalar-like input and also avoid creating a tolerance vector for scalar |
In case of scalar reltol "and" abstol, restore old behaviour.
I couldn't find a fundamental reason behind such a restriction. In theory I was able to implement component-wise I have tried to restore the old behaviour when |
In case of scalar reltol "and" abstol, restore old behaviour. Also, passing "norm" to hinit so that the user defined norm can be used for the initial step size computation.
Should execute the old behaviour only if both abstol and reltol are scalars. If either of them are vectors, perform component-wise computations.
Provided type inference works ( |
Ah yes. I will try to update one with a function to get the error using multiple dispatch. 👍 |
…tiff and non-stiff solver This avoids the 'if' construct
What's the current status on this? |
I don't think this should be closed due to an upcoming PR which doesn't include the functionality. It looks to me like this is complete, though I don't see a test. If @sonVishal adds some tests to show that it's working properly I'd vote to merge. How it relates with #49 is a separate issue. |
I will write a test case. I tested it myself but will include a test. Give me a week or so since I am currently very busy working on 2 different projects. |
I simply changed the relative and absolute tolerances for the ROBER test case to arrays and the test passed on my system. Let me know if there is a need for another test case. |
Changes Unknown when pulling f256c4d on sonVishal:master into * on JuliaDiffEq:master*. |
Current coverage is 92.07% (diff: 80.76%)
|
Hi,
I have tried to work out the component-wise relative and absolute tolerances for the non-stiff solvers based on 'Solving Ordinary Differential Equations I by Hairer and Wanner' and component-wise absolute tolerance combined with strictly scalar relative tolerance for the stiff solvers based on the MATLAB ode23s solver.
Since the interface checks does not handle vectors yet, the interface checks fail.
I have also changed the value of the error for the Robertson test since even Matlab's ode23s cannot produce a result with error strictly less than 2e-10. I got 2.0423543e-10 using the same options as used over here. Hence the change.
Please review.
Thanks and regards,
Vishal Sontakke,
Technical University of Munich.