Fail to understand code

[nichols__john]

c ---   initialize
        call izero (l(1),kndid,ksofar)
100     Continue
        call indco2 (nnods,l(kndid),l(kcoord),kdata)

L is the blank common.

izero attempts to set l from kndid to ksofar to all equal zero. kndid is 2 and ksofar is 17

But when izero returns l is only one long at the continue

c **********************************************************************
      SUBROUTINE IZERO (ia,n1,n2)
c **********************************************************************
c     PURPOSE : Zero terms n1 through n2 of an iteger array
c ----------------------------------------------------------------------
c     DOUBLE PRECISION / LARGE
      include 'C:\Users\macne\Documents\Visual Studio 2013\Projects\Pro
     1gram067 - Drain3DX\Ares\Ares\Ares\common\double.h'
c ----------------------------------------------------------------------
c     ARGUMENTS
c     ia = array
c     n1,n2 = range to be zeroed
c ----------------------------------------------------------------------
c     ARGUMENT DECLARATIONS
      dimension ia(n2)
c **********************************************************************
      do 10 n=n1,n2
        ia(n) = 0
   10 continue
c **********************************************************************
      RETURN
      END

Any ideas would be appreciated as this is weird to me

Thanks

John

[nichols__john]

Steve:

I have been playing with this program for about a week.  Like all programs that grew in many hands it is a bit challenging. Not impossible just interesting. However, it is brilliant for what we want to do. I found in the authors many notes a comment that they had had problems with running a windows version back about '94 or thereabouts, but at the time it ran on other os's.  It was written in DOS. There are no sample input files so I have been making one up for a standard engineering problem as I go along.

The program compiles, I can input the data and it is going into the correct places. However as soon as the author starts the analysis he pokes real*8 arrays into a integer common area, L(*).  I have never done this nor seen it done, so he passes an address for the start of the real array in the L(address) in a call to a subroutine. I have played with one of these calls.  The coordinates were fed into L  in the parent routine, but did not come out in the child routine.  I changed the calls so it passed Real*8 arrays and this fixed the problem.

This is a fairly simple program in theory, it sets up an array, inverts the array and then determines the solution vector, just it does it for Newtons' second equation nicely, and is accessible.

I tried the original program on SilverFrost and it compiles, but the data file throws errors.

Am I completely missing something, is this call technique supposed to work, or is it an unsupported side effect that IF catches or is it a Windows thing. 

I can slowly work though and fix all the calls.  This program is so valuable it is worth doing.

I could also compile the program on Linux (How do I get a Linux IF program?).

Eventually it will be recoded by experts, me I am just an average hack, but I need it to develop our theories.

John

I used to have MSFortran 3.3? wish I still did.

[John_Campbell]

John,

It is important in this memory management approach to consider how many bytes each array element uses.

It would be useful to know which Operating System the code was developed for. However, if it was developed in 1990's it is most likely that it used REAL*8 reals and INTEGER*4, ie 8 byte reals and 4 byte integers. As a consequence, if you are allocating space in INTEGER*4 L(*) for a real*8 array(n,m), starting from L(Karray), the next available location in L(Knext) wouldf be given by Knext = Karray + 2*n*m.

Some early implementations of this approach at UCB would have used REAL L(maxL) and ignored half size integer arrays, so Knext = Karray + n*m for cases of array is either integer or real.  The use of most compilers that you are discussing would probably used 8-byte reals and 4-byte integers, so this is unlikely to be the source of your problem.

I did note that the .zip file you attached had a multi-level listing of source files, with include files in separate directories. I would be checking that this is working for your compiler.  Possibly changing so that all files are in the same directory may simplify the build process.

I noted that some claims above of run success appear to be only success in reading the data. The analysis is the big test, especially demonstrating that data read is retained in the managed arrays.

Again, the problem will probably be with managing the code and the build process so minimise the changes you make to the code and if changes you test don't work, you would be better off to remove these changes and go back to the original code and look for a different solution.

Keep looking and good luck,

John

[nichols__john]

Dear John:

Thank you for your response.  I have dealt with code from this group before, it is world class engineering but somewhat problematic as code. I have no doubt with the first class help here I will get it running properly.

DRAIN 3DX is one of those mythical programs that people talk about but never used, think like L Long, so it has been quite interesting to work with although somewhat tedious at times.  It is really the only code at this engineering level in this problem set that is freely available, I do not mind paying for code - we have STRAND7 and access to ABACUS, but one cannot play inside the code easily - so it is hard to investigate engineering problems at the core of the matter.  The team has several people who will solve these problems in the commercial packages, but I am looking two years down the road not right now.

The last successful stuff written on DRAIN3DX has it compiled in DOS with an extender using probably the old Microsoft PowerStation or older program. There are no sample files and the manual and the code do not agree on the structure of the input.  Wish I had an old computer and those old programs -- I used to have them and threw them away - stupid thing to do.

This code may ultimately be used in a life safety situation so it needs to be fully and completely checked. So I am in for a long haul.

So I have set up a common block of Real*8 and I will use that as alternative storage for the moment for passing real  data. Long term this not realistic for this code, but at least I can get it so it runs - inputs a file and actually does a simple analysis. A simple analysis here is a truss -- like first year engineering level.

So I switched of the warnings about interfaces and got about 500 errors. I have been going through and fixing the code so it at least compiles, I screwed up and created another 500 errors. Never do a bulk replace.  I also found that with implicit variables there are spelling mistakes and so the fact that the code ran is quite interesting. Forensic engineering is a wonderful experience. I can fix these errors.

I am using   VS 2013 so the issue of the multiple folders is not a problem, the code is pretty well organized and commented in terms of the variables, the logic is ok in terms of following a very traditional engineering approach which I understand quite well - although the non-linear stuff is outside my current ken. But it will come. 

There is a lot of memory management code  and the small code bits are very spaghetti in places.

But the ideas are brilliant and the engineering is brilliant so it is worth the pain to work with it.  Also one has to do something with one's days - cannot just sit back and drink.

So first get it compiling again, get an input file that makes sense and will go into the right places, fix the manual and then work through the code a routine at a time to make sure it works as it should and the answers are sensible. Eliminate the common blocks and the common storage areas.  Fun actually.

Of course it would be faster in real terms to recode in C# - but what is the fun in that and mecej4 would rightly point out it is faster in Fortran.

John

[FortranFan]

jm-nichols@tamu.edu wrote:

..

So I have set up a common block of Real*8 ..

So I switched of the warnings about interfaces and got about 500 errors. I have been going through and fixing the code so it at least compiles, I screwed up and created another 500 errors. ..

There is a lot of memory management code  and the small code bits are very spaghetti in places.

..

So first get it compiling again, get an input file that makes sense and will go into the right places, fix the manual and then work through the code a routine at a time to make sure it works as it should and the answers are sensible. Eliminate the common blocks and the common storage areas.  Fun actually.

Of course it would be faster in real terms to recode in C# - ..

@John Nichols,

This new thread is "deja vu all over again" given a previous thread:

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/509581

I'm not sure which code among all the attachments and link in this new thread you're working on and what exactly you're up to, but this appears to be on the same track where there are umpteen comments but where a reader is unclear if there are any real issues worthy of continued discussion on this forum.

Out of curiosity, I downloaded zip file for Drain Building program from 2010 and it appears to be well-written and efficient per the facilities of FORTRAN 77 available at the time most of the code was developed.  What is missing in the zip file is drain.inp input file.

In a matter of minutes, I was able to compile and link the program using Intel Fortran compiler 16.0, update 1 and Visual Studio 2013 with no errors - see attached zip.  I made no changes to source code whatsoever.  So what's up with the multiple (500) errors you mention?  What are you trying with "Real*8" and "common blocks" and so forth and why?

If the Drain* program you're working on is the same as Drain-Building, I doubt you would need to make any bulk / major changes to source code at all: once you put together a good set of validation cases and have the associated input files, the code should most likely be able to run as-is.  If one needs to make any changes at all, it may be isolated to some minor input-output (IO) file processing type of adjustments for Windows OS - that should be it.

If you are serious about making progress with running this code, post your input cases (e.g., drain.inp) and expected output (probably derived or induced or extracted from reports, theses, etc.) along with the "untouched" source code.

And you would do well to not even think of C#.

[nichols__john]

Dear Fortran Fan:

Thank you for the excellent comments.

I enclose an input file - it has little more data than the previous txt file - you need to rename it to Drain.inp for this program.  You cannot upload an inp file.

This file works quite well in terms of input with the Drain3DX that I am using - Drain3dx is from the early 90's and includes 8 different elements whilst Drain-Building is for 2 elements only for RC buildings.  I am trying to do bridges which require all 8 elements.

I use Intel Fortran - Drain -Building compiled with 2 errors and 999 warnings - it crashed on the second input line from the file. 

I appreciate that there are very many routines to do most of the things in DRAIN3DX.

I also appreciate that this forum provides a place to discuss Fortran with experts. I enjoy that aspect of the site.

John

[mecej4]

I can sympathize with FortranFan's vexation, and to many readers the melodrama  (the English Professor and her crumpets), sideshows (Drain2D, Drain3D, Drain-Building), threats to switch to another language than Fortran (C#) and the din of codesmiths pounding on code that needs no fixing -- all this may be more excitement than one may be prepared for when reading posts in this Fortran forum on a quiet morning.

The Drain3DX source code of #5 can be built with no changes needed; extract the Zip file of #5, preserving the directory structure, and run the batch file that I provide below to build the program: put the batch file in the SOURCE directory, create a new directory LIBS inside SOURCE, and run the batch file in an IFort command window. The EXE will be built in the MAIN subdirectory.

From the report http://mae.cee.illinois.edu/publications/reports/Report00-05.pdf, extract the text for the three input files from appendices B1, B2 and B3. This can be error-prone and troublesome if your PDF -> text extraction utility mangles spaces, because all the data items have to be in their appropriate columns. For your convenience, I attach these files (in the Zip file below). For each input file, do the following:

• In the MAIN subdirectory, copy the input file to DRAIN.INP, and remove any output files from earlier runs of Drain3DX
• Provide acceleration data files needed with the input file (look for lines with ".acn" in the input file)
• Run the program and examine the output files (summary and result files)

Here is the batch file for building the EXE, to be put into and run from the SOURCE directory.

for /D %%d in (216TDREC,ANAL,CONTRL,E*,INPUT,SPECT,UTIL) do (^
   cd %%d
   ifort /MP /MD /Od /w /I..\common /c *.for & lib /out:..\libs\%%d.lib *.obj
   cd ..
   )
cd MAIN
ifort /MP /MD /Od /I..\common main.for block.for ..\libs\*.lib

Once you have the program working properly, you can remove the /Od option, if you wish to take advantage of the compiler's optimizations.

Here are the input files from appendices B1, B2 and B3 of the Illinois report mentioned above. 

[nichols__john]

Dear mecej4:

Thank you.

Why do you think the program works in IFORT and the same program in VS2013 does not? Am I missing compile switches.

John

[nichols__john]

Taking the same code set and making a VS 2013 project. 

I can turn off the warnings on the interfaces and execute the code with a DRAIN.INP file that works in the IFORT version and get the error shown in the picture.  It complies without incident as shown in the build log.

Which is where I started in the first place.  So I have to use IFORT I cannot use VS

John

[Steven_L_Intel1]

The reason it "works" when building from the command line is that there you don't get array bounds checking enabled, where in a VS debug project it is enabled by default. You're getting an array bounds violation, indicating a coding error or possibly the use of (1) as an array bound where in modern Fortran it should be (*). You can turn off array bounds checking if you'd rather "run with scissors") - Runtime > Array and String Bounds Checking > No.

[FortranFan]

jm-nichols@tamu.ed wrote:

Taking the same code set and making a VS 2013 project. 

I can turn off the warnings on the interfaces and execute the code with a DRAIN.INP file that works in the IFORT version and get the error shown in the picture.  It complies without incident as shown in the build log.

Which is where I started in the first place.  So I have to use IFORT I cannot use VS

John

No, when you're with working older code which generally involves older style (FORTRAN 66 and prior) dummy argument approaches for arrays such as dimensions of 1 (unity), then you need to turn off many of the compiler diagnostics but more importantly the run-time checks.  It appears the /check:bounds option for run-time checking of array bounds is interfering.

Here, attached is zip file with a Visual Studio 2013 solution as well as project files for Drain3DX which compiles without any errors and executes the 4 cases all the way to completion; as to whether the results are reliable will depend on the input data as well as the code.  You may be better off focusing on the input and results aspects rather than anything else such as Real*8 and COMMON blocks at this stage.

I reiterate my earlier point, "I doubt you would need to make any bulk / major changes to source code at all: once you put together a good set of validation cases and have the associated input files, the code should most likely be able to run as-is.  If one needs to make any changes at all, it may be isolated to some minor input-output (IO) file processing type of adjustments for Windows OS - that should be it."  As I look further into code, one can make a few COSMETIC changes to make the usage experience better, if and only if one so desires:

1. modify MAIN.for file such that it can accept an input file of any name i.e., it need not be restricted to Drain.inp file,
2. not require the user to "clean out" the output i.e., delete manually all the files, rather the program can do it for the user via standard Fortran syntax of STATUS="REPLACE",
3. modify all the Fortran statements for IO such as OPEN, READ, and CLOSE to include IOSTAT= and IOMSG= clauses and do proper handling to ensure a graceful exit in case of input file error(s), (see Message #7 in this thread for a fully worked example: https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/593480) ;and
4. consider replacing the fixed format input file format with something more user-friendly, such as NAMELIST, etc. - note none of this changes the core program architecture - you would do better not to muck with it until much, much later, if at all.

And a point about C# since you brought it up here and you had done so with your Shells drama earlier: if you're itching to do something with C#, you can use it to put together a nice, little user-interface (UI) for Drain3DX program, one that makes user input and output processing much easier and which can even have an "intermediate window" which can display all messages from the program.

Finally: there appear to be no real Fortran or (Intel compiler) issues here - this thread deserves a quick closure at this point, I suggest.

[nichols__john]

Closed