I have a f90 program:
!------------------------------------------------------------------------------------------------
program testx
include 'CommonVariable'
type(ATOM),allocatable::ATOMT(:)
integer:: NN
call testxyz(NN,ATOMT)
print*, ATOMT(1)%nam
end
subroutine testxyz(N_atom,ATOMTH)
include 'CommonVariable'
integer::N_atom
integer::i
integer::n
character(len=20)::file_name
type(ATOM),allocatable::ATOMTH(:)
print*,'input filename'
read*,file_name
open(1,file = file_name, status = 'old')
read(1,*) N_atom
read(1,*)
allocate(ATOMTH(N_atom))
do i = 1,N_atom
read(1,*) ATOMTH(i)%nam,ATOMTH(i)%x,ATOMTH(i)%y,ATOMTH(i)%z
end do
close(1)
end subroutine
!----------------------------------------------------------------------------------------------------------------
in which the file 'CommonVariable' is
!-------------------------------------------------------------------------------
IMPLICIT NONE
TYPE ATOM
character(len=2):: nam
double precision:: x,y,z
END TYPE ATOM
!--------------------------------------------------------------------------------
the aim of this program is to read a xyz file, for example, co.xyz
!----------------------------------------
2
C 0.0 0.0 0.0
O 1.1 1.2 1.3
!-------------------------------------------
I compile this code with gfortran, an when I run this program, I get:
filename
co.xyz
Segmentation fault
Can you help me?
Thank you very much.
Manh
Well, without looking further, you need to place your type definition
for ATOM in a module that you access via a use statement in each
procedure. That way you have one definition of one type. What you have
now is one definition of two different types (see also "Fortran 95/
Explained, bottom of p. 148). Your include is simply a textual
substitution and NOT a means to access global entities.
I would also recommend making testxyz an internal procedure, or
putting it too into a module.
Regards,
Mike Metcalf
Hmm... I get:
704 elelyon:/home/mai > gfortran stuff.f90
In file stuff.f90:15
type(ATOM),allocatable::ATOMTH(:)
1
Error: ALLOCATABLE attribute conflicts with DUMMY attribute at (1)
In file stuff.f90:22
allocate(ATOMTH(N_atom))
1
Error: Syntax error in ALLOCATE statement at (1)
In file stuff.f90:25
read(1,*) ATOMTH(i)%nam,ATOMTH(i)%x,ATOMTH(i)%y,ATOMTH(i)%z
1
Error: Syntax error in READ statement at (1)
In file stuff.f90:9
subroutine testxyz(N_atom,ATOMTH)
1
Error: Symbol 'atomth' at (1) has no IMPLICIT type
> On Nov 23, 5:01 pm, Manh <manhthuo...@gmail.com> wrote:
[code elided]
>
> Well, without looking further, you need to place your type definition
> for ATOM in a module that you access via a use statement in each
> procedure. That way you have one definition of one type. What you have
> now is one definition of two different types (see also "Fortran 95/
> Explained, bottom of p. 148). Your include is simply a textual
> substitution and NOT a means to access global entities.
Yes, at least according to the standard. I doubt this is the cause of
the segmentation fault. I suspect the code would work with at least some
compilers regardless of this (though I could be wrong), but it would be
illegal code; you'd have no guarantee that it would continue to work or
would work in all contexts.
> I would also recommend making testxyz an internal procedure, or
> putting it too into a module.
This, I think, is the cause of the error. That's more than just a
recomendation. The subroutine has an allocatable dummy argument and is
thus required to have an explicit interface. Those are two of the ways
to meet that requirement. Writing an interface body is the third way,
but I generally disrecommend it. A segmentation fault is a quite
plausible result from this problem.
I make it a practice to put almost all of my procedures in modules, with
exceptions only in rare special cases. That way, you don't have to worry
about memorizing the list of situations that require explicit
interfaces; you'll have explicit interfaces in all cases. There are
other benefits as well.
I suspect squid is running an older version of gfortran. Allocatable
dummy arguments were new to the so-called allocatable TR (and became
part of the base standard with f2003). Early f95 compilers did not
support the feature. I was under the impression that current versions of
most compilers, including gfortran, do support it.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
The first thing you need is an explicit interface.
Second, allocatable dummy arguments are not part of F90.
Thirdly, using unit 1 may cause problems. Better to use a unit number
10 or above.