The help of Mathematica doesn't say so much about the PrecisionGoal for NDSolve, and I never considered much about it even after I met the warning message
NDSolve::eerr
for several times when I was trying to solve a set of PDEs these days: every time I met it I would simply considered it as a proof for the defect of my assumption for the initial or boundary condition, and my resolution strategy for it is to modify the conditions or sometimes I will also lower the value of the PrecisionGoal as the help says.
However, this time I can't ignore it anymore, for I accidentally found that for one of my assumptions, the suitable PrecisionGoal for it is a negative integer…
The thing named "Precision" in my mind was always a positive integer, but this time it is negative! Why?…… What's the exact effect of "PrecisionGoal" option for NDSolve?
Answer
If you look at the documentation for Precision, it says that if x is the value and dx the "absolute uncertainty", Precision[x] is -Log[10,dx/x]. This, whenever the estimated error is larger than the value, Mathematica will give a negative precision.
Thus, for an estimated error $dx$ and a value $x$ such that $dx/x<1$ here is how the precision as defined above looks like:
You see that it is really the number of digits in the ratio of the error to the value. If the error $dx>x$ then the log is negative:
Accuracy is probably closer to what you have in mind: it's basically to the number of effective digits in the number, as it is -Log[10,dx]. If $dx>1$, it can be negative, indicating that a number of digits to the left of the decimal point is incorrect (and of course, it can be non-integer just like the precision). If you really want the number of digits, take the integer part (or round it).
About the last bit of the question, ie, "what does PrecisionGoal option for NDSolve do?", I think the above plus the explanation in the docs covers it: it specifies the precision (as defined above) to be sought in the solution.
Comments
Post a Comment