Errors in computing the Crank-Nicolson Method

Click For Summary
The discussion revolves around the adaptation of the Crank-Nicolson method to solve the one-dimensional heat equation. The user, Daniel, faced issues with the results of his algorithm, which produced an inaccurate solution compared to Mathematica. He described his approach using a specific formula for the tridiagonal system and shared two graphs illustrating the discrepancies between his results and those from Mathematica. A key observation noted was the difference in boundary conditions, particularly the slopes at the edges of the computational region. After further analysis, it was determined that correcting the Dirichlet boundary conditions in Daniel's code resolved the discrepancies, aligning his results with those generated by Mathematica.
danielakkerma
Messages
230
Reaction score
0
Hi all!
Having decided to return to coding some of the physical problems that I require solving(in lieu say, of Mathematica), I endeavored to adapt the Crank-Nicolson to my needs, but, in order to test my algorithm, I had first attempted to resolve the common and trivial heat equation, in one dimension, e.g \alpha\frac{\partial^2u}{\partial x^2} = \frac{\partial u}{\partial t}, with some plain boundary conditions, that is u(x, 0) = some trivial function(sine times cosine) and u(0, t) = 10(or some value), and at the end-point(10, t in this case), the same(essentially a rod kept at both ends at an equal temperature).
The results however, are unsatisfactory; For sake of my equation, I used:
\beta u^{i+1}_{j+1}+(1+2\beta)u^{i+1}_{j}+\beta u^{i+1}_{j-1}=u^{i}_{j}
Where beta is a constant derived from my step sizes(i.e, dx, dt) and i & j denote the step in time and displacement respectively.
This, as is well known, creates a tridiagonal system, which is readily evaluated for all U(i+1)ns(in my case, I've got a grid with a size of 100 units).
I've attached two graphs corresponding to the solutions; Image2 was created by Mathematica, and Image1 is done using my program. You can see the very disturbing groove that's created, that seems to wedge and ebb towards the margins of the computational region. This is, first-and-foremost, physically inaccurate, and should not occur, and in fact, using Mathematica, does not.
In short, I am reliant on your aid to solve this discrepancy,
I thank you for your attention,
Beholden,
Daniel
 

Attachments

  • Image1.gif
    Image1.gif
    12 KB · Views: 570
  • Image2.gif
    Image2.gif
    7.8 KB · Views: 548
Technology news on Phys.org
One obvious difference between the plots is that the slope of the function at the left and right edges is different.

In the right hand plot the slopes apparear to be constrained to be 0, in the left hand plot they are not.

It's not very clear from your description of the problem or from the the plots (no labels on the axes) exactly what you were trying to do, but I would guess the boundary conditions are different in your code and in Mathematica.
 
You're absolutely right on the matter, and indeed, correct, or rather, setting the proper Dirichlet boundary conditions aligned the two!
Thank you for your help!
Daniel
 
I tried a web search "the loss of programming ", and found an article saying that all aspects of writing, developing, and testing software programs will one day all be handled through artificial intelligence. One must wonder then, who is responsible. WHO is responsible for any problems, bugs, deficiencies, or whatever malfunctions which the programs make their users endure? Things may work wrong however the "wrong" happens. AI needs to fix the problems for the users. Any way to...

Similar threads

  • · Replies 6 ·
Replies
6
Views
2K
  • · Replies 2 ·
Replies
2
Views
2K
  • · Replies 1 ·
Replies
1
Views
2K
  • · Replies 5 ·
Replies
5
Views
4K
  • · Replies 2 ·
Replies
2
Views
3K
  • · Replies 2 ·
Replies
2
Views
4K
  • · Replies 8 ·
Replies
8
Views
5K
  • · Replies 3 ·
Replies
3
Views
4K
  • · Replies 1 ·
Replies
1
Views
4K
  • · Replies 5 ·
Replies
5
Views
4K