Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.

Borr - Looping

Valued Contributor II

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



0 Kudos
5 Replies
Valued Contributor II
subroutine PardisoSolver(GK,nl,nk,ndf,X,Load)

      implicit none
      include ''

      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)
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'
    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?


Valued Contributor II

It started to work when I added lines 49-51 but they should not be required?

Black Belt

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.

Black Belt

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.

Valued Contributor II

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.