×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

an array modified during a non-related reading?

an array modified during a non-related reading?

an array modified during a non-related reading?

(OP)
Hi all!

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

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:

CODE

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... :P

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

CODE

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:

CODE

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

RE: an array modified during a non-related reading?

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...

RE: an array modified during a non-related reading?

(OP)
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?

RE: an array modified during a non-related reading?

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

RE: an array modified during a non-related reading?

(OP)
Evil ISP here. :P

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! ;)

RE: an array modified during a non-related reading?

(OP)
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:

CODE

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:

CODE

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:

CODE

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

And the module file is:

CODE

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.

RE: an array modified during a non-related reading?

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

Quote:


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.

RE: an array modified during a non-related reading?

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

RE: an array modified during a non-related reading?

(OP)
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? :P

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!

RE: an array modified during a non-related reading?

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

CODE

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

RE: an array modified during a non-related reading?

(OP)
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. ;)

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login


Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close