Blank Common Block

[nichols__john]

c     BLANK COMMON

      PARAMETER (NTSTP=1000000)
      common l(NTSTP)

call inelem (l(knsb),l(kndfsb),l(kcosb),l(kndid),l(kcoord),
     1             l(kid),l(klstif),l(k1),ndtp,nsnds,nnods,ntnds,
     2             nchar,nelgr,neltot,nelg,kdata)

SUBROUTINE INELEM (nsb,ndfsb,cosb,ndid,coord,
     1                   id,lstif,ielnod,ndtp,nsnds,nnods,ntnds,
     2                   nchar,nelgr,neltot,nelg,kdata)

Interesting problem :  This is a program written in 92 out of UCB.  The main program includes a blank common unit as shown above called L. L is by default left as integer

The Finite Element Program than uses l for everything.  In the call to inelem the third element is a double precision cosb , but the stuff passed is from L at location kcosb or something. 

-----------------------------------------------------------------------------------------------------------------------

This is a major structural program used by a lot of people, but I am lost as to how to compile it without a major rewrite.  Is this old legal Fortran -?

John

[jimdempseyatthecove · Accepted solution]

You will want to compile this _without_ interface checking.

Also, l is an integer array, each element is 4 bytes (by default). cosb, being a double precision is 8 bytes. Therefor cosb occupies l(kcosb:kcosb+1). It is not unusual for old program to treat a large block of COMMON in multiple ways.

*** It is your responsibility to not muck anything up. In this case a conversion of what used to be REAL(4) into REAL(8) could potentially cause problems relating to size of elements change.

Jim Dempsey

[nichols__john]

Error 5  error #6633: The type of the actual argument differs from the type of the dummy argument.    C:\Users\macne\Documents\Visual Studio 2013\Projects\Program067 - Drain3DX\Ares\ARES\Ares\INPUT\GENDIS.FOR 81 
 

Jim:

I am getting a 6633 error so I cannot compile the program as the L appears to conflict with the double precision. I know it used to compile as I have a 2002 exe that works.

Is there a way around the 6633 error code -- can I turn it off--

John

[nichols__john]

Sorry missed the first line

john

[nichols__john]

Thanks worked

John

[jimdempseyatthecove]

Did you read my last paragraph.

COMMON blocks, both named and unnamed, have subtleties in how you use them. Any change can cause problems. Inserting variables, changing types "cleaning up code and data" can all have adverse consequences to carefully laid out COMMON blocks.

Just a word of caution in the event something else breaks.

Jim Dempsey

[nichols__john]

Jim:

Yes I am being very careful thank you.

This is a program called DRAIN3DX written by Powell's group of out UCB in 1992.  I have used a lot of their programs over the years and one can see the code being reused a lot.  This FEM program gives me access to the direct code and I can play with the elements of the structural matrix. Which given what the English professor does in Bristol is a must. 

I have a very large drainage analysis program with a lot of common blocks, which are a lousy idea and one needs to be very careful.  The main problem here is that it is written for UCB UNIX machine and windows has some interesting differences.  I am working through the code line by line to check it now that I have it compiled.  I have standard problems so I can check the code.

You can tell these people were never Lispers as the code is old world FORTRAN and quite interesting to work out.  It has good comments and they code well - just terse. 

John

[LRaim]

Nothing of particular strange, though my attention was about whether the L vector indexes had been previously defined as:

knsb = ....;

The subroutine call passes addresses and the subroutine can use the memory content at those addresses at will. 

I use many common blocks to keep key and critical information of very large simulation software.

[nichols__john]

Thank you

One learns something new every day until one is dead.  This program has a number of interesting features that will keep me on my toes.

John

[John_Campbell]

The coding approach in DRAIN3D has worked successfully for over 40 years and predates modern Fortran approaches. You can make the code more conforming by replacing the memory management technique with ALLOCATE, although there may be some dynamic array sizing approaches adopted that ALLOCATE still does not support. You could replace the call with something like:

! declarations could look like
      integer(4), allocatable :: nsb(:,:), ndfsb(:,:), ndid(:,:), id(:), ielnod(:,:) 
      real(8),    allocatable :: cosb(:,:), coord(:,:), lstif(:,:)

...
!  allocates could look like
      allocate ( nsb(m,m), stat=stat )
        call allocate_check ( 'nsb(m,m)', stat)
      allocate ( coord(3,nn), stat=stat )
...
! call could look like
      CALL INELEM (nsb,ndfsb,cosb,ndid,coord,    &
                   id,lstif,ielnod ,...

You should also note that the array "L" is only a million or 4 mb, which shows the age of the code.
Also, at present this code works so if you try to "fix" it then it may not remain that way.

The advantage of changing to ALLOCATE is that it is easier to manage the allocation and release of arrays with ALLOCATE and you do not have to worry about which parts of the array "L" are still in use. Changes, such as modifying the size or especially scope of arrays becomes much easier to manage, as you modify the program capabilities. To have done this the old way, you needed a spreadsheet to map out each array's life. How did we manage without Excel?

The big risk you have when changing the memory management approach is that with the memory techniques that were adopted in DRAIN3D, array sizes can be dynamically changed, which is more difficult to make conforming with ALLOCATE. You knew the array sequence in memory so what the memory past the end of each array was being used for. Often the last array allocated could be used and then "resized" once the memory requirement was known. This is not easy to do with ALLOCATE, especially if the array is large.

John

[nichols__john]

John

Thanks for the comment.  I really want to make the current code work without changing it to allocate.  I have been using UCB SEMM code since the 1980 and do not want to change DRAIN 3DX, merely get it running on Windows if I can.  I would prefer to understand what is causing the 408 error code - upon execution from the izero routine and do the minimum intervention to make it work on windows.

Although I did send Professor Powell a note and ask if it was developed on UCB Unix - that would be the next step get a NUC and put UCB Unix on it. 

Thanks

John

[nichols__john]

And sometimes one goes in boots and all and makes a major change

John

[John_Campbell]

I have a an earlier copy of Drain-2D which was developed on CDC. The first few lines of my version looks like:

CDC   PROGRAM MAIN(INPUT,OUTPUT,TAPE1,TAPE2,TAPE3,TAPE4,TAPE5,TAPE6,
CDC  1  TAPE7)
C
C     SET STORAGE AND CALL DRAIN
C
      IMPLICIT INTEGER*4 (I-N)
      IMPLICIT REAL*8 (A-H,O-Z)
C
      COMMON /BIGCOM/ A(10000)
      NNTST=10000
C
      CALL DRAIN (A,NNTST)
C
      END
      SUBROUTINE DRAIN (A,NNTST)
C
      IMPLICIT INTEGER*4 (I-N)
      IMPLICIT REAL*8 (A-H,O-Z)
C
C     DRAIN-2D      DYNAMIC RESPONSE ANALYSIS OF INELASTIC STRUCTURES
C
C     A.E.KANAAN AND G.H.POWELL        UNIV. OF CALIF., BERKELEY, 1972

My conversion is dated 1991, but I have forgotten the update history. I think by the early 1980's 8-byte reals and 4-byte integers were fairly standard, so you should not have a lot of problems with the conversion. I'd chuck out the boots and all version and go back to an original version.

The secret of getting these programs to work is to minimise the changes you make, as the program did work. You can interpret "minimise the changes" as being lines of code, characters, code features or all three. It is important not to do too much.
Set up a list of code structures (see attached) that need to be changed then plan an approach that minimises the potential for typing errors.
Use file comparisons to audit the changes.
Make sure you have an existing data set with documented results.

[nichols__john]

John

I have played with a lot of the code from this group, so I am used to the format.

I actually found that it works to declare every variable - tedious - but you find the real errors quite quick. There will be a lot of coding errors.  There are worse ways to waste a weekend.

There are usually standard problems you can use to check the code.

In this instance I am just getting the code to work - to see if I can do what I want with it, solve the English professor problems - numerical ones I mean.

We have an English professor who is very good experimentally - she is doing major structure stuff at the micro-g range, so the old linear theory is not even close. She was explaining to some people about a problem she had encountered - one famous structures Professor said it could not be done -- she looked at me and I nodded yes it could be done - if I fail there is always medej4 to point me in the right direction.

There has to be a place of forlorn hope and this is it.

The only real problem with English professors is they like tea and crumpets and they expect one to be clean shaven and when one discusses a Real(4) they look at you like you are swearing in Russian.

John

[Les_Neilson]

Aha I am beginning to understand.
I wondered what a professor of English was doing programming Earthquake stuff in Fortran. But I see now that you are talking about a professor who happens to be English (or perhaps British if from another part of the UK) And surely we *all* know that Real(4) is non-standard. Of course it could just be the English professor having difficulty with non-English accents.

:-)
Les

[nichols__john]

Dear Les:

My apologies, I am so used to calling Dr. Adrienn Tomor, from University of the West of England, Bristol, the English Professor as it is a lot simpler than explaining the entire background details.  She is quintessentially English and has no idea what Fortran is, she merely asks if I can do something and luckily I have this forum as the ultimate back up.  She is without doubt the best structural experimental engineer I know, and I have worked with some of the best including Professor Hall from UIUC and Professor Aschheim from some good school in the west, although he should be HOD at UIUC. She does stuff with no equipment to speak of that I would consider difficult at the UIUC lab, does not know any limitations.  Does like to prove me wrong and she is good at it. 

So the Drain stuff is so I can answer her questions on the accelerometer results.  The problem is she is way past linear theory and not likely to stop anytime soon. So the theory has to catch up - thankfully there is mecej4.

As James Hauber of Iowa DOT said once - she is lot better at this than you are.  I agreed, but pointed out she was in England now and I was in Iowa.

I do know I do not want to be in the same room as mecej4 and the English Professor - I really would just carry the bags for that team.

John