Matlab Code runs, does not converge on my computer but does converge on my friend's computer.

BEFORE READING: The first two/three paragraphs are math heavy and involve the Finite Difference Method so I apologize if that is confusing at all, but the only really important stuff is afterward so you can skip to their if you'd like.
Some Background:
I am doing a coding project/homework for an Aerospace Engineering course, and I have been stuck on the same problem for the last three days. Essentialy, this code I made is used to evaluate the change in temperature of a rod across its length. The temperatures at certain spots are defined in seperate cases labelled in my code (i.e temperature = 0 *C at x = 0 inches and temperature = 100 *C at x = 1 inch where 1 inch is the length of the bar) which serve as the boundary conditions for a set of differential equations. This change in temperature over the rod is solved annalytically with Matlab's symbolic package using equations like Newton's Cooling Law and such, but then the second part of the problem uses the Finite Differences Method (FDM) to solve the same problem.
The professor asked us to also compute q_dot or the change in heat of the bar for each case which is determined annalytically through a simple equation and then found through FDM by iteratively doubling the size of the mesh for FDM where the idea is that the q_dot from FDM will converge to the correct value which is the same as the analytical q_dot once the mesh is large enough.
The Problem:
My problem over the last three day is that my FDM q_dot value almost converges to the right number at a mesh size of 64 divisions in the bar, but with any other greater mesh size my code gets all whacky and does what looks like divergence/oscilation/maybe something else entirely.
After three days of trying to solve my problem and debug what I thought was a problem with my code, I had my friend look over it. He ran it on his own computer and his own version of Matlab and it worked perfectly, converging to the right number. I then assumed that it was a Matlab issue, not a coding issue. I tried restarting Matlab, I tried restarating my computer, and I tried downloading the newest version of Matlab (R2021b) as opposed to the one I was previously using (R2020a) and all to no avail. The code still refused to converge correctly. I then tried running it on a school computer and it worked, so I am pretty certain it is a problem with my computer.
If you have any idea what may be the problem here I am all ears. I am going to ask my professor for an extension tomorrow morning so that hopefully I have some time to fix this. My code is attached (I commented a lot of things out that arent necessary for solving q_dot to speed it up) and below are partial command window prints from my code being run on my computer and then my friend's computer along with my computer properties. Thank you to anyone who even attempts to read or solve this!
My computer's output (incorrect):
qDotFDM1 =
-7.0312
-6.4813
-6.3364
-6.2953
-6.2858
-6.3605
-5.7041
-8.0275
-1.5831
-1.5769
qDotFDM2 =
-7.0185
-6.4718
-6.3277
-6.2867
-6.2773
-6.3527
-5.6878
-8.0263
-0.0123
-0.0061
qDotFDM3 =
-7.0380
-6.4839
-6.3376
-6.2958
-6.2861
-6.3606
-5.7042
-8.0275
-1.5838
-1.5773
My friend's computer's output (Correct):
qDotFDM1 =
-7.0312
-6.4813
-6.3364
-6.2997
-6.2905
-6.2882
-6.2876
-6.2875
-6.2874
-6.2874
qDotFDM2 =
-7.0185
-6.4718
-6.3277
-6.2912
-6.2820
-6.2797
-6.2792
-6.2790
-6.2790
-6.2790
qDotFDM3 =
-7.0204
-6.4734
-6.3292
-6.2926
-6.2834
-6.2811
-6.2806
-6.2804
-6.2804
-6.2804
My Computer Properties:
Device Properties
Device name Andrew-HP
Processor Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz 2.59 GHz
Installed RAM 16.0 GB (15.9 GB usable)
Device ID 1B09C671-0AE2-4F58-9D8F-14D880EBAF4E
Product ID 00330-50000-00000-AAOEM
System type 64-bit operating system, x64-based processor
Pen and touch No pen or touch input is available for this display
Windows Properties
Edition Windows 10 Pro
Version 20H2
Installed on 4/22/2021
OS build 19042.928
Experience Windows Feature Experience Pack 120.2212.551.0

6 Kommentare

interesting, I ran your script as is and got the "correct" values
I'll just put down my computer info here in case it's useful
ver
-----------------------------------------------------------------------------------------------------
MATLAB Version: 9.11.0.1809720 (R2021b) Update 1
MATLAB License Number:
Operating System: Microsoft Windows 11 Education Version 10.0 (Build 22000)
Java Version: Java 1.8.0_202-b08 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
-----------------------------------------------------------------------------------------------------
[str,maxsize,endian] = computer
str = 'PCWIN64'
maxsize = 2.8147e+14
endian = 'L'
Other cpu info
CPUName: 'Intel(R) Core(TM) i9-10850K CPU @ 3.60GHz'
Clock: '3601 MHz'
Cache: 2621440
TotalMemory: 3.4201e+10
NumCPUs: 1
TotalCores: 10
OSType: 'Windows'
OSVersion: 'Microsoft Windows 11 Education'
@Andrew Kraut can you try this version attached? Just replaced the symbolic with the inline version. The replacements are only for your mulMat1,2,3 variables.
Oh my goodness yes that worked perfectly also my run time went from almost 2 minutes to less than 3 seconds which makes sense since subs wasn't used at all. Why did that work and why did it not work specifically on my computer with subs()?
@Andrew Kraut with symbolic expression you have to be careful of the precision. Even though the default precision should be greater than a double.
digits
Digits = 32
There can be some related reasons:
Convert symbolic values to MATLAB double precision - MATLAB double (mathworks.com): "symbolic expressions that suffer from internal cancelation or round-off errors, increase the working precision by using digits before converting the number"
Recognize and Avoid Round-Off Errors - MATLAB & Simulink (mathworks.com)"Approximating these expressions by floating-point numbers can produce very unstable results"
I think once I heard my professor say that some tiny numerical error is beneficial for stable convergence because it creates a kind of numerical viscocity, dampening oscillations. But maybe I am not remembering this correctly.
So working with symbolic can give you better values as long as you take care of the precision and you don't mind that it's slow.
Also I don't know why your computer worked differently as long as precision was default 32.
Also I don't know if it's related but my computer is 64bit like yours, and also my windows installation and matlab version are both 64bit.
hmm ok. I'll double check my Matlab presets to see if I had changed something a while ago. In the meantime I found a differen way of creating the matrices just by using the diag() function (Creating a tridiagonal matrix - (mathworks.com)) which is a lot simpler and about 100 times as fast so I think I will try avoiding using too many symbolic substitutons in big for loops from now on. Thank you so much for your help!

Melden Sie sich an, um zu kommentieren.

Antworten (0)

Produkte

Version

R2021b

Gefragt:

am 18 Feb. 2022

Kommentiert:

am 18 Feb. 2022

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by