FEAPpv4.1 pform.f ht1, ht2, ht3 no declination

[__Jules_]

hello,

i downloaded the current FEAPpv4.1 and tried to compile it with Visual Studio 2015. I realized their is no declination of ht1, ht2 and ht3 in pform.f. I found out through the manual that they were definied in hdata.h. In hdata.h is only nt1, nt2 and nt3 defined, so i changed ht1 ->nt1 and so on.

There were a few other bugs i discovered by using the interl fortran compiler with the settings for interface check turned on. I deactivated for now so I was able to compile (I will dig deeper on a different day).

After a succesfull compilation I run the validation example in release, which works fine but unfortunately the debuging it is not possible. The program crashes in vinput.f in line 111 if(n.gt.no.and.nv.le.nn) call setval(xxx(no:n),n-no,d(nv))

fortrtl: svere(408): fort:(4): variable XXX has substring ending point 16 which is greater then the variable of 15. I could not dig deeper yet to find a solution for this.

Is there already an updated version availuable?

Greetings

[Prof. R.L. Taylor]

You should have changed the nt1 to ht1 etc. in the hdata.h

You are using the integer*4 include which is suspicious since most computers today need the integer*8 values. 

Also, did the error in vinput.f occur during compilation or during the solution of a problem?

There are several declarations with character (len=15) in the code.

[__Jules_]

okay thank you.

Yes thats correct. Of course my computer is running a 64bit system but I didnt feel the need to use integer*8 when it is not neccessary. It is just a different data type, it works perfectly fine on a x86 or x64 machine.

The error appeared during running the example in debug. In release it works because certain checks are deactivated (boundary checks etc.) so the error is not detected in release. For now i fixed this by changing the

Code: [Select]

errck = vinput(yyy(16:30),15,td,1) into

Code: [Select]

errck = vinput(yyy(16:31),15,td,1) in file pnums.f row 430. Probably not he best way to do it.

Unfortunately I am running in an other problem in setmem.f

There is an call to a subroutine (line 120)

Code: [Select]

call pzero (hr(np(n)),length)
The array hr is of size 1024 but np(n) is a very big number. I found out that np(n) is set in a way I can not understand. It is happening in the same file in line 78-88

Code: [Select]

!         Use Malloc to allocate space for length*ipa bytes

          adr(n) = malloc(length*ipa)

!         Set pointer for array use

          if(ip.eq.1) then
            np(n) = 1 + (adr(n) - loc(mr(1))) / ipa
          else
            np(n) = 1 + (adr(n) - loc(hr(1))) / ipa
          endif

A certain amount of memory is allocated an the adress is saved in adr(n)

Code: [Select]

!         Use Malloc to allocate space for length*ipa bytes

          adr(n) = malloc(length*ipa)

Then this address is minus by the address of a independent variable hr(1) and futher on to get the distance of those two addresses. This is then later used to function as an indice of an array. I am not sure if this is meant to be like this.

Code: [Select]

!         Set pointer for array use

          if(ip.eq.1) then
            np(n) = 1 + (adr(n) - loc(mr(1))) / ipa
          else
            np(n) = 1 + (adr(n) - loc(hr(1))) / ipa
          endif

[Prof. R.L. Taylor]

This is why you need integer*8

[__Jules_]

How can it be possible that this has anything to do with integer*4 for or integer*8. It is very clear that this is a bug in the programming code.

I am able to run a program with integer*4 for and integer*8 settings as long i dont have boundary checks on, which of course would throw an exception all the time at this line because the variable is defined from 1:1024 and this address operations always will try to access an indice way higher or lower randomly. I am just trying to report a bug.

[Prof. R.L. Taylor]

No, the computer is addressing a memory location that cannot be expressed in 32 bit arithmetic.  Try the integer*8.

[Prof. S. Govindjee]

If your computer uses 64bit addressing you need to use the interger8 include files.  In FEAP the integer8 files are only for memory addressing, all other integers default to integer*4 (unless you force them otherwise).  See also: http://feap.berkeley.edu/wiki/index.php/Programming#Memory

[__Jules_]

Ok I understand. Thanks for the provided link that clarifies it but unfortunately the boundary check has to be turned off otherwise it is not working.

To be able to turn on the boundary checks wouldnt it be enough to just use adr(n) which is not the offset but the absolut address.

Anyway thanks for providing this program for free. 

[FEAP_Admin]

Yes you could re-write the code to use adr( ).  The history of the memory management in FEAPpv is complicated and reflects incremental changes to the ways memory could be managed under Fortran.  What you see presently, reflects this history.  Someday we may invest the time to make the complete switch.