I am simulating a Mixed-Boundary value (Dirichlet-Neumann) problem using Finite Difference Method on a unit 3-D cube such that the left, lower, and front plane have $u=u(x,y,z)=1$ (Dirichlet) and right, upper and back plane have $\frac{\partial u}{\partial n}=0$. I know that the true solution is $1$ everywhere and hence I have used the stopping condition as $err_\max < 0.00001$ where I find error like $err = 1.0 - u_\text{current}$. The problem converges when input is $16\times16\times16$ and $32\times32\times32$ but when input is $64\times64\times64$, the maximum error does not decrease below $0.000019$. Similarly when the problem size is $128\times128\times128$, the error does not decrease below $0.000040$. My question is : Is this an expected behaviour ?


1 Answer 1


No, it is not expected. Your iteration needs to converge. Since you don't say what your iteration is, it is difficult to say what me be wrong. But it is easy to say that you must have a bug somewhere: as long as your iteration is any reasonable method, it needs to converge!

  • $\begingroup$ What about round-off error? Is it possible for $h \le 1/64$ he's representing the derivative of his constant solution well in exact arithmetic but is more susceptible to round-off error (e.g. cs.cornell.edu/~bindel/class/cs3220-s12/notes/lec22.pdf)? $\endgroup$ May 8, 2015 at 14:10
  • 1
    $\begingroup$ Round-off is, in double precision, no longer a concern today. It happens when you reach a level of $10^{-12}$ or so on your overall error norm, at which point you don't care any more about round-off. That's definitely not @gaurav's problem. $\endgroup$ May 8, 2015 at 16:11
  • $\begingroup$ @WolfgangBangerth thank you for answering, I changed a few conditions and ran the program, it stopped again at 0.000019 for 64x64x64 when I use float but converges when I use double. I think it had both the issues (1) Logical errors for Neumann condition and (2) Floating point round-off error. Thanks @Sumedh and @nicoguaro. $\endgroup$ May 9, 2015 at 3:14
  • $\begingroup$ But I still have my doubts as to why the same problem is not working with float data type ! $\endgroup$ May 9, 2015 at 15:13
  • $\begingroup$ Because with float you only have 8 digits of accuracy in every piece of the calculation you do. The result may be accurate to 5 or 6 digits of accuracy then. That's consistent with what you have. $\endgroup$ May 9, 2015 at 20:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.