- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear All:
My Borr program does a structural analysis and then determines the eigenvalues. The program up until now has only been asked to run on a single file.
I thought I would loop the program so it would run on the same file over and over - I want to make minor changes to the input so I can seek nodes -
but first I am trying to get the code to run --
it works the first time thru on SAMP3, but crashes on SAMP4,
I would think I have carried over some variable and it is causing the crash
Should not the call to the subroutine ANALYSIS - twice wipe out all the stored stuff -- or am I missing something
Regards
John
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
subroutine PardisoSolver(GK,nl,nk,ndf,X,Load) implicit none include 'mkl_pardiso.fi' integer nl,nk,ndf REAL (KIND=dp) GK(nl,nk),X(ndf),Load(ndf),GKTest(nl,nk) REAL (KIND=dp), ALLOCATABLE :: a(:), b(:), c(:,:), atemp(:) integer, allocatable :: ja(:), ia(:), iatemp(:), jatemp(:) INTEGER :: nnodes = 5 integer error, iaN integer :: nnz = 1000, istat, i, j ! count integer :: size = 0 integer :: size1 = 0 integer :: size2 = 0 integer :: flag = 0 REAL (KIND=dp) :: delta = 0.000000000000001 integer no_zero_count(nl), numA GKTest = 0.0d0 no_zero_count = count( gk .NE. GKTEST, DIM=1 ) ! count values in a col numA = sum(no_zero_count) write(sa,2040)numA 2040 Format('--------------------------------------------------------------------------------------------------------------',///& ' Count of the non-zero elements in the stiffness matrix :: ',i6,//) nnz = numA+10 !90*ndf iaN = ndf+1 ALLOCATE (a(nnz), ja(nnz), ia(iaN), jatemp(nnz), iatemp(iaN), b(ndf), c(ndf,ndf), atemp(nnz), STAT=istat) IF (istat.NE.0) THEN WRITE (*, *) '*** Could not allocate some arrays in LINSOLVE' STOP END IF b = 0.0D0 a = 0.0d0 c = 0.0d0 iatemp = 0 jatemp = 0 atemp = 0 ia = 0 ja = 0 size = 0 size1 = 0 size2 = 0
So when I call the Pardiso Solver for the second time -- the size variables size, size1 and size2 are not reset to zero on entry to the routine?
is this normal?
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It started to work when I added lines 49-51 but they should not be required?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The initializations give those variables implicit SAVE attributes, so they retain any values you give them. If you want them initialized each time you enter, those assignments are required.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Despite their syntactic similarities, initialization statements operate differently in Fortran and C. That is, Fortran does "initialize at program start" and C does "initialize at each function entry". After a long period of programming in C (or C#), it may take a bit of effort to remember this distinction when one returns to using Fortran.
Modern Fortran also has "default initialization", i.e., optional initialization at object creation time, but that feature is not in play here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Tim and mecej4:
Yes, I have spent several months buried in LINUX, MONO and a Raspberry PI. It is a lot of fun, but one becomes used to the quirks and as one ages one forgets the Fortran methods.
I have it looping now quite nicely - so thanks for confirming the points. I had to go back to using the debugger --
It would be nice if VS refactored Fortran.
That is the Pardiso code that mecej4 showed me how to code many years ago. Eigenvalues are very interesting beasts with a lot of interesting quirks. Funny how it is just 3 numbers in all that code.
One of my students told me " why program in Fortran - his professor said everything should be in MATLAB." We are raising a generation of people who cannot program properly as engineers. Not good and they know not what they do not know.
John
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page