- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
ms=size(X(kk)%component)/3 allocate(yy(ms)) yy=0 yy(Free(kk)%component)=uc ! the size of yy is larger than uc deallocate(uc) allocate(ff(size(X(kk+1)%component)/3)) ! size of ff is larger than yy ff=0 ff=smvpro(pro(kk)%component,yy) ! this line change the size of yy uu=uu+ff(Free(kk+1)%component) deallocate(ff,yy)
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Check for ALLOCATE statements that contain optional clauses such as STAT= and make sure that the program checks for successful allocation before using the variables that were just allocated (or failed to be allocated).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
mecej4 wrote:
Check for ALLOCATE statements that contain optional clauses such as STAT= and make sure that the program checks for successful allocation before using the variables that were just allocated (or failed to be allocated).
Thanks for the reply. I checked all the allocate statements and also checked if anything like array out of boundaries happened. Everything seems ok but the code just doesn't work right beyond level 7.
I suspected there is a problem in the recursive routine. Are there common mistakes when using recursive subroutine? It's weird everything is fine until certain level.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
(name withheld) wrote:
If the discretization of mesh become finer and finer, the results should be better and better.
In general, that is not true, as the following example will show. Consider approximating the derivative of tan(x) at x = 1 using the forward difference ratio [tan(x+δx) - tan(x)]/δx. Calculate the approximate derivative and the error in that approximate result for δx = 10-4, 10-5, ..., 10-15. Is the error the least when the "mesh size" δx is least? (Ans.: No. As you decrease δx, the error decreases, reaches a minimum near δx = 10-8, and increases again. Furthermore, if you decrease δx below a certain value, the approximate derivative becomes zero, which is unacceptable.)
If you want to use a different ID/name, open your IDZ profile and enter a name that does not contain your E-mail address.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
mecej4 wrote:
Quote:
(name withheld) wrote:
If the discretization of mesh become finer and finer, the results should be better and better.
In general, that is not true, as the following example will show. Consider approximating the derivative of tan(x) at x = 1 using the forward difference ratio [tan(x+δx) - tan(x)]/δx. Calculate the approximate derivative and the error in that approximate result for δx = 10-4, 10-5, ..., 10-15. Is the error the least when the "mesh size" δx is least? (Ans.: No. As you decrease δx, he error decreases, reaches a minimum near δx = 10-8, and increases again. Furthermore, if you decrease δx below a certain value, the approximate derivative becomes zero, which is unacceptable.)
If you want to use a different ID/name, open your IDZ profile and enter a name that does not contain your E-mail address.
Thanks. I got your point. But the results of Matlab is good and what I expected. Somehow the results of fortran aren't the same as that of Matlab but basically they are the same code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>Somehow the results of fortran aren't the same as that of Matlab but basically they are the same code
Is your Fortran code using REAL or REAL(8)?
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
jimdempseyatthecove wrote:
>>Somehow the results of fortran aren't the same as that of Matlab but basically they are the same code
Is your Fortran code using REAL or REAL(8)?
Jim Dempsey
I am using real*8. Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Another "gotcha" that can cause (precision difference) issues is literal floating point numbers default to REAL(4). This can introduce differences in calculations when the literal cannot be precisely specified as REAL(4) or REAL(8). e.g. 0.1 is different than 0.1_8 (or 0.1D0). Whole numbers or fractions that can be contained within the precision are also fine. e.g. 0.25
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is it possible that you aren't outputting enough significant figures from Matlab for your matrices and mesh? That could cause symptoms like you are seeing. since Matlab and Fortran would be working on different problems. (In my experience on the systems I have available, you can output binary from Matlab and read it into Fortran to avoid this issue. I don't think this always works, though, if you try this, check the data you read in to make sure it is correct. Also, special handling is required for complex data types, but it doesn't sound like that is an issue here.)
Yes, there are "gotchas" with recursion. Don't do things like "real :: x = 0.0" and expect X to get initialized every time you enter the routine. However, that particular gotcha probably wouldn't explain your bug.
Are there any intermediate results you could output to compare between the Fortran and Matlab to see where the deviation arises?
Good luck!
Laura
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Laura S. wrote:
Is it possible that you aren't outputting enough significant figures from Matlab for your matrices and mesh? That could cause symptoms like you are seeing. since Matlab and Fortran would be working on different problems. (In my experience on the systems I have available, you can output binary from Matlab and read it into Fortran to avoid this issue. I don't think this always works, though, if you try this, check the data you read in to make sure it is correct. Also, special handling is required for complex data types, but it doesn't sound like that is an issue here.)
Yes, there are "gotchas" with recursion. Don't do things like "real :: x = 0.0" and expect X to get initialized every time you enter the routine. However, that particular gotcha probably wouldn't explain your bug.
Are there any intermediate results you could output to compare between the Fortran and Matlab to see where the deviation arises?
Good luck!
Laura
Thanks for the reply. I've already considered the suggestion you mention. But I think I can try the binary one you suggested. Other than that, it seems the data are the same.
Also there are two parts that I doubt the bug lies in . First one is the data which you just mentioned, second one is the recursive routine which now I believe is the problem. But I just cannot find a way to fix that.
I do have some intermediate results, I literally compared all the solutions from level 1 to level 7, the numbers are not exactly the same, but at least the behavior of the algorithm is the same. The error is also the same. But once I hit level 8, the results change drastically.
I think what Jim said is definitely possible. But I don't know how to fix this at this moment. Also the same bug happens in 3D case at level 5.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
jimdempseyatthecove wrote:
Another "gotcha" that can cause (precision difference) issues is literal floating point numbers default to REAL(4). This can introduce differences in calculations when the literal cannot be precisely specified as REAL(4) or REAL(8). e.g. 0.1 is different than 0.1_8 (or 0.1D0). Whole numbers or fractions that can be contained within the precision are also fine. e.g. 0.25
Jim Dempsey
This is actually what I concerned. I changed all the real*8 to real before. The results were worse.
So this is definitely a issue here. But I don't know how to test this.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The only other think I can think of (without seeing the actual code) is, are there any "integers" in your calculations? Matlab will automatically type-cast integers to float, but in Fortran follows a specific set of rules dictating when it will type-cast. So, in Matlab, (5/2) == 2.5, but in Fortran, (5/2) == 2.
Also, do you have "implicit none" at the tops of your subroutines and functions? Perhaps there is a miss-typed variable name and the magnitude of the problem caused by it increases at higher levels. (It doesn't seem likely, since you started with working Matlab code, but the bug seems rather unlikely too.)
One possibility I just thought of ... Fortran isn't case-sensitive. Is there any chance that there are two variables that are different in Matlab (like aB and Ab) but that the Fortran compiler treats as the same? (Again, seems unlikely, but I have written this sort of bug before.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Laura S. wrote:
The only other think I can think of (without seeing the actual code) is, are there any "integers" in your calculations? Matlab will automatically type-cast integers to float, but in Fortran follows a specific set of rules dictating when it will type-cast. So, in Matlab, (5/2) == 2.5, but in Fortran, (5/2) == 2.
Also, do you have "implicit none" at the tops of your subroutines and functions? Perhaps there is a miss-typed variable name and the magnitude of the problem caused by it increases at higher levels. (It doesn't seem likely, since you started with working Matlab code, but the bug seems rather unlikely too.)
One possibility I just thought of ... Fortran isn't case-sensitive. Is there any chance that there are two variables that are different in Matlab (like aB and Ab) but that the Fortran compiler treats as the same? (Again, seems unlikely, but I have written this sort of bug before.)
Thanks for the advice. I've checked my code and found no such mistakes. I am trying to export the data from Matlab to binary files. I'll give the feedbacks later.
One more thing, does it matter if I use same input variable name when I define two functions? For example,
function f1(A,v) and function f2(A,v). Will this be a problem? Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sharon Jl wrote:
One more thing, does it matter if I use same input variable name when I define two functions? For example,
function f1(A,v) and function f2(A,v). Will this be a problem?
The scope in which the names of the dummy arguments apply is within the boundaries of the function code. So, no this will not be a problem.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page