Interesting Problem

[JohnNichols]

I am slowly developing a program to analyze FEM results from Strand7.  It saves a lot of time and heartache in looking at 1 million element models.  

I just started to add a new subroutine for the steel columns. 

Set up separate f90 file

created 

subroutine SC(a,b,) in the SC.f90 file

put

call sc(a,b) in the main.f90 file

compiled fine

added some code and amended the 

subroutine SC(a,b,c,d,e) 

where c,d and e are control integers from Strand7. 

Missed adding them to subroutine SC(a,b)  

But it compiled and run until it hit the use of c and then threw an access exception error.  

I would have thought the compiler should have complained about the difference in the call SC and the actual SC?

[mecej4]

Such inconsistencies between actual and dummy argument lists are caught only if you ask the compiler to perform interface checking or if you provide explicit interfaces to called procedures in their callers.

[JohnNichols]

Thanks.  

[JohnNichols]

!An interface to an external subroutine SUB1 with header:
!SUBROUTINE SUB1(I1,I2,R1,R2)
!INTEGER I1,I2
!REAL R1,R2
INTERFACE
  SUBROUTINE SUB1(int1,int2,real1,real2)
    INTEGER int1,int2
    REAL real1,real2
  END SUBROUTINE SUB1
END INTERFACE

From the Intel Manual, should there be an explicit none in the subroutine and should you/ can you include the intents?

It is pure laziness on my part, I should always include these.  

[JohnNichols]

It was turned on in the program.  

[mecej4]

I don't know what exactly you have in your source files, but here is a complete test code that makes the issues easy to understand.

program buggy
   implicit none
   integer ii
   real rr
   ii = 1; rr = 1.5
   call sub(ii,rr)
end program

subroutine sub(i1, i2, r1, r2)
   implicit none
   integer i1, i2
   real r1, r2
   print *,r1
   return
end subroutine

If you build and run without /warn:interfaces, you will get an access violation on line 13. With /warn:interfaces, you will get one #6633 and two #6631 errors at compile time.

[JohnNichols]

This is the current call that I put an error into 

warn interfaces is on 

201 call steelcols(nNode, nBrick,nump)                  !,nums)

I get this error

Severity Code Description Project File Line Suppression State
Error error #6451: A dummy argument name is required in this context. [M] B:\Users\macne\Documents\Visual Studio 2017\Projects\Program023 - Beowulf\Tyr\Tyr\Tyr\Files\SteelColumns.f90 12

    subroutine steelcols(nNode, nBrick,NumP,Nums)

    use Base
    USE St7APICall
    USE St7APIConst
    implicit none

    Integer(4), intent(IN) :: nBrick
    Integer(4), intent(IN) :: nNode
    Integer(4), intent(IN) :: nump
    Integer(4), intent(IN) :: nums
    Integer(4), intent(IN) :: m


    Integer(4) numprimary
    Integer(4) numpoints
    Integer(4) numcolumns
    integer(4) inode,ierr, ncount1, nnum1(21)
    integer(4) connection(21),i,k
    integer(4) n
    integer(4) j
    integer(4) L
    integer(4) astat
    integer(4) counter

    !---------------------------------------------------------------------------------------------------------------------------
    !
    !   Real variables
    !
    !---------------------------------------------------------------------------------------------------------------------------


    REAL (KIND=DP) step
    REAL (KIND=DP) targetNum
    REAL (KIND=DP)  XYZ(3),brickres(6)

    TYPE (integer),    allocatable,   TARGET :: Elements(:)

    write(*,10)
    write(11,10)
10  Format(//"                        **************************************************************************************************************",//&
        "                                                     Steel Columns Analysis "/&
        "                                                      21 Node elements"/)

    call getSCnum(n)
    write(*,30)n
30  Format(/"                        Number of Steel Column Elements :: ",i5,/)
    allocate(elements(n),STAT = astat)
    IF (astat.NE.0) then
        STOP 'Could not allocate Shells or Model'
    endif
    call getSCData(n,elements)

    counter = 0
    L = 1
    j = elements(L)
    do i = 1, nBrick
        connection = 0
        k = 0
        ierr = St7GetBrickResultArray(1, rtBrickStress, stBrickLocal, i, NumP, AtCentroid, NumPoints, NumColumns, BrickRes)
        ierr = St7GetElementConnection(1, tyBRICK, i, Connection)

        if(i .eq. j .and. L .lt. n) then
            counter = counter + 1
            write(*,*)counter,i,connection(1),j
            L = L + 1
            j = elements(L)
        else if(i .eq. j .and. L .lt. n) then

            write(*,*)counter,i,connection(1),j
        endif
    end do

    write(*,20)
20  Format(/"                             End of Steel Column Analysis")




    return
    end subroutine steelcols

    subroutine getSCnum(n)
    implicit none


    Integer(4), intent(INOUT) :: n

    read(14,*)n


    return
    end subroutine getSCnum

    subroutine getSCData(n,A)
    implicit none


    Integer(4), intent(IN) :: n
    Integer(4), intent(INOUT) :: A(n)
    integer(4) i

    do i = 1, n
        read(14,*)A(i)
    end do


    return
    end subroutine getSCData

I tried several variants on the arguments and they all gave correct warnings,

but if you build all 

change one element in the calling routine, drop the required m, it does not recompile the other file and there is no warning, just the access error. 

[JohnNichols]

I have noticed recently, that if you change an element in file1 and element in file 2 that are related, then often file2 is not recompiled by VS 2019.  You have to forcea  build. 

[Steve_Lionel]

Are you doing this from the command line or Visual Studio? Interface checking is not default from the command line. Also, it is highly dependent on compilation order. If you had not recompiled the call, it would not have known to check.

This is why we use modules.

[JohnNichols]

yes, you are correct, part of it is modular, just in a hurry and I need the results, plus I have a month to go back and correct it, but the results first for this bridge.  

Finite Element models are a necessary evil for engineering, but the following article on early programming points to the problems.  

Good read. 

https://www.theguardian.com/lifeandstyle/2023/aug/27/saved-by-a-butterfly-how-chaos-theory-became-the-secret-ingredient-in-my-happy-marriage 

[andrew_4619]

Hmmm IMO you should pretty much never be creating external subroutines. At its most basic, encapsulating your collection of subroutines with module/ end module means that so many errors get picked up automatically and dependencies get managed so much better.....

module thingy
    implicit none(type, external)
    contains
    .....
    .....
    .....
end module thingy

[JohnNichols]

Truer words have never been spoken.  

it takes a while to develop a new program and then fix it.