an array modified during a non-related reading? 1

[JohannesRS]

Hi all!

Well, this is my first post in this forum, and I hope one of few related to "problems"...

I've tried this compilation already on ifort 8.1, compaq visual fortran 6.5 and pgf90 (unknown version). Each compiler is on a different machine. In all cases, it gives me:

forrtl: severe (174): SIGSEGV, segmentation fault occurred

Stack trace terminated abnormally.

or equivalent error messages. The above one is from ifort.

Traking down the code by using the old fashioned write(6,*) "variable" to find the mistake, I found that at a certain point the array "origem" had its values changed from 4 and 6 to 1034080485 and -1104470973...

Tracking this again, I found that it was changed during this (including the test writes):

write(6,*) 'TESTE ORIGEM:', origem
   call read_config(natomtot, atomnames, xyz, carga, ntypes, boxtype, boxLx, boxLy, boxLz, nmol, natomos, vol)
write(6,*) 'origem:', origem

So, the array was changed inside a subroutine that *hadn't* it passed to and hadn't any variable or array or whatever inside it with that name.

To track it deeper, I decided then to virtually pass this variable to the subroutine, and declare it as it should be, BUT with an "intent(in)" argument to make it unmodified. Didn't help. So I decided to find where it's being changed.

So, during the 63rd and 64th reading in the following looping, I found the array values changing:

do iatom = 1, natomtot
   write(6,*) 'teste origem M:', iatom, origem
   read (79,*,end=66) atomnames(iatom), xyz(1, iatom), xyz(2, iatom), xyz(3, iatom), carga(iatom)
   write(6,*) 'teste origem N:', iatom, origem
enddo !iatom

So, after performing some "reads" to completelly non-related variables, I got my array values completelly modified. In a way that makes no sense for me.

I know I should give the files for testing, but as I see in here I can't just attach them to the thread. So, I put it on the internet in the following address:

http://www.geocities.com/johannesrs/trj2grid8bug.tgz

This tgz file was created from the last trial, what means that it already passes the array to the subroutine with intent(in), instead of just not passing.

Files in it:
trj2grid8.f90: main program
mod_pbc.f90: module pbc_routines, with 2 suboutines.
mod_trj_read.f90: module read_trj, with 3 subroutines, including the read_config one, where seems that the problem happens.
teste.in: input for the program
teste.trj: file the program reads and deal with.

Anyway, sorry if this was too long, or if I posted in the wrong place. And thanks in advance for any help provided!

Thanks a lot,

Jones

 

[ArkM]

Check (print befor input loop, for example) anatomtot value and related (from input list) arrays dimension bounds. It seems you have an ordinal index range error...

 

[JohannesRS]

Hi!

Just tried that. Not too much hope, anyway. Well, the arrays sizes, as well as "natomtot" integer value are correct. And the "origem" array values keep on being changed by someone who doesn't care about it...

Any idea around?

 

[ArkM]

Must not any (abstract?) ideas without context (equivalences, aliasing via parameters or common blocks, reading in not yeat allocated memory in F90+ etc)...

 

[JohannesRS]

Evil ISP here.

Ok, my english is not that good, so I didn't understand or didn't use equivalence or aliasing via parameters.

I don't use comon block (hate them!)

all arrays are properly allocated.

Any other idea?

Thanks for everything in advance!

 

[JohannesRS]

Ok, news from here.

I decide to step back on the code, and move forward on it's writing again, on a slower pass.

So, I got the old version of the code, with everything straigh written on it, broke one-by-one the 3 subroutines and placed it in the same file as the main program with a "contains". Everything worked.

Then, started to recreate the module file. The subroutines "read_params" and "read_header" were transfered with absolutelly no problem. BUT when the subroutine "read_config" was transfered to the module file it heavilly failed in compilation

Using PGF90, I get this error message:

pgf90 -C mod_pbc.f90 mod_read_trj.f90 trj2grid8l.f90
mod_pbc.f90:
mod_read_trj.f90:
trj2grid8l.f90:
PGF90-S-0186-Argument missing for formal argument origem (trj2grid8l.f90: 512)
  0 inform,   0 warnings,   1 severes, 0 fatal for trj2grid3dv80l

and using IFORT8.1, this message here:

ifort mod_pbc.f90 mod_read_trj.f90 trj2grid8l.f90 -o trj2grid8l.x
fortcom: Error: trj2grid8l.f90, line 512: The type of the actual argument differs from the type of the dummy argument.   [CARGA]
      call read_config(natomtot, atomnames, xyz, carga, ntypes, boxtype, boxLx, boxLy, boxLz, nmol, natomos, vol)
-------------------------------------------------^
fortcom: Error: trj2grid8l.f90, line 512: A non-optional actual argument must be present when invoking a procedure with an explicit interface.   [ORIGEM]
      call read_config(natomtot, atomnames, xyz, carga, ntypes, boxtype, boxLx, boxLy, boxLz, nmol, natomos, vol)
-----------^
fortcom: Error: trj2grid8l.f90, line 512: If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element.   [CARGA]
      call read_config(natomtot, atomnames, xyz, carga, ntypes, boxtype, boxLx, boxLy, boxLz, nmol, natomos, vol)
-----------^
fortcom: Error: trj2grid8l.f90, line 512: The shape matching rules of actual arguments and dummy arguments have been violated.   [CARGA]
      call read_config(natomtot, atomnames, xyz, carga, ntypes, boxtype, boxLx, boxLy, boxLz, nmol, natomos, vol)
-------------------------------------------------^
compilation aborted for trj2grid8l.f90 (code 1)

The subroutine is called as:

call read_config(natomtot, atomnames, xyz, carga, ntypes, boxtype, boxLx, boxLy, boxLz, nmol, natomos, vol)

And the module file is:

module mod_read_trj
contains
subroutine read_params(natomtot, ntypes)
implicit none
...
end subroutine read_params

subroutine read_header(ntypes, nmol, natomos, time, boxtype, boxLx, boxLy, boxLz, PEtot, eof)
implicit none
...
end subroutine read_header

subroutine read_config(natomtot, atomnames, xyz, carga, ntypes, boxtype, boxLx, boxLy, boxLz, nmol, natomos, vol)
use mod_pbc, only:rebonding
implicit none

integer             :: iatom = 1
integer, intent(in) :: natomtot, ntypes
integer, intent(in) :: boxtype
real, intent(in)    :: boxLx, boxLy, boxLz
real, intent(out)   :: vol
integer, dimension(:), intent(in) :: nmol, natomos
character(len = 20) :: carga
character(len = 5), dimension(:), intent(out) :: atomnames
real, dimension(:,:), intent(out) :: xyz

   do iatom = 1, natomtot
      read (79,*,end=67) atomnames(iatom), &
           &xyz(1, iatom), &
           &xyz(2, iatom), &
           &xyz(3, iatom), carga
      cycle
67    STOP 'Arquivo terminado inesperadamente!'
   enddo !iatom

   call rebonding(ntypes, boxtype, boxLx, &
        &boxLy, boxLz, nmol, natomos, xyz, vol)

end subroutine read_config
!end contains
end module

Now we have something. The code works perfectly if the routines are kept in the main program "contains" structure, BUT does not when it's passed to the module file. Any clue of what am I doing wrong here?

Thanks a lot in advance.

 

[xwb]

In the original code, are allocating the wrong size array for carga (trj2grid8.f90 line 115/118). It should be natomtot, not ntypes and allocated around line 459 where you are allocating space for atomnames and xyz.

It gets past your problem but then you'll get

At line 32 of file mod_read_trj.f90
STOP Cabecalho do arquivo danificado!

I don't know any Spanish/Portuguese and I've got no idea what it means.

 

[xwb]

Your rewritten program - declare carga as character*(*). Then you won't get any moans about shape problems.

 

[JohannesRS]

God!

Thanks a lot, guys, it would take centuries for me find that!

Just 6 months without programming, and already making these sort of mistakes?

xwb: just to let you know, it means "header of file damaged". And there I just forgot to put the sentence between '...'.

Anyway, thank you all for your help!

 

[xwb]

Also, when opening your output file, use trim otherwise you end up with a file called "teste.trj .xmol"

open(171, file = trim (trjin)//'.xmol', status = 'unknown')

 

[JohannesRS]

Thanks, xwb.

"len_trim", you mean.

This is one of the updates for this program. I just knew about tis intrinsic after writing this code, while working on another one.

But thanks for that too.