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 ?


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!

| cite | improve this answer | |
  • $\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$ – Sumedh Joshi May 8 '15 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$ – Wolfgang Bangerth May 8 '15 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$ – Gaurav Saxena May 9 '15 at 3:14
  • $\begingroup$ But I still have my doubts as to why the same problem is not working with float data type ! $\endgroup$ – Gaurav Saxena May 9 '15 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$ – Wolfgang Bangerth May 9 '15 at 20:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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