From: rudra on
sorry ...that is a run time error(segmentation fault).
here are the declaration of the caller(main file) both are too tidy ,
though!

DECLARATION OF MAIN FILE(CALLER)
use kinds, only: RDP,i3
use mhop
use mmat
implicit none
integer(i3):: i,j,k,il,l
integer(i3)::ios
integer(i3),parameter::ntype=2
integer(i3):: ienrp,istart,iend,ie,iie
real(RDP)::q,de,e
character(25):: ASMAP,STRUCTURE

integer(i3),parameter::idim=3,norb=3,nrsite=14,nasite=73109,ntsite=nrsite
+3

integer(i3),parameter::imax=172,info=172,llmax=16,jl=7,lorbit=9
integer(i3),parameter::ienum=7,ienump=ienum+1
real(RDP),parameter::emin=-0.9d0,emax=1.00d0
real(RDP)::xxa,yya,temp
integer(i3),parameter::npn=lorbit*ienump
integer(i3),parameter::nsite=369902,nkp=17,maxrec=12
integer(i3),parameter::nfn=900
real(RDP),parameter::x=0.60_RDP
real(RDP),parameter::y=1.00d0-x
real(RDP),parameter::ALPF=0.0058820d0

real(RDP),parameter::ALPS=0.350d0,ALPP=0.0571670d0,ALPD=0.0168070d0
real(RDP),parameter::e_a=6.0d0, e_b=7.0d0,filling=x*e_a+y*e_b
real(RDP),parameter::z_a=24.0d0,z_b=25.0d0,c_a=z_a-e_a,c_b=z_b-e_b
real(RDP),parameter::ruban=0.10d0,amix=0.06d0
real(RDP),dimension(maxrec,ienum+1)::xa,ya
real(RDP),dimension(lorbit,lorbit)::ap5
real(RDP),dimension(lorbit)::ap1,ap6, &
ap7,ap8,ap9,ap10,ap11,ap12,ap13
real(RDP),dimension(npn)::ap2,ap3,ap4
real(RDP),dimension(lorbit)::p2,p3,p4
real(RDP),dimension(2):: es, cs, ds, xx1, gs, &
ep, cp, dp, gp, ed, cd, dd, gd, xx2 , &
xx3,xx4,xx5,xx6
real(RDP),dimension(2):: dels, delp, deld, rs, &
rp, rd
real(RDP),dimension(2):: dsqs, dsqp, dsqd, ccs, &
ccp, ccd, os, op, od
real(RDP),dimension(ntype,lorbit):: &
agc,agd,enu_ag,ag_op
real(RDP),dimension(lorbit)::cpot,enuc,dpot_sq,opc
integer(i3),dimension(nasite,ntsite)::map
real(RDP),dimension(lorbit,lorbit,0:nrsite+1)::srl
character(10)::potin,potout
real(RDP):: sum1,sum2,sum3,sum4,sum5
real(RDP):: sum6,sum7,sum8,sum9,sum10,sum11,sum12,sum13
integer(i3)::ipdos
real(RDP),dimension(ienum+1)::seed
real(RDP)::dsum
..
..
..
!MAIN IS CALLING THE SUBROUTINE hop(CALLEE)
write(*,*) "callin hop"
call hop(il,ienrp,nsite,nasite,nrsite,ntsite, &
maxrec,map,lorbit,ienum,srl,npn,ap1, &
ap6,ap7,ap8,ap9,ap10,ap11,ap12, &
ap13,p2,p3,p4,xa,ya)
..
..
end main

HERE IS THE DECLARATION OF hop(THE CALLEE)
module mhop
CONTAINS

subroutine hop (il,ienrp,nsite,nasite,nrsite,ntsite, &
maxrec,map,lorbit,ienum,srl,npn,ap1, &
ap6,ap7,ap8,ap9,ap10,ap11,ap12,ap13, &
p2,p3,p4,xa,ya)

use kinds, only: RDP,i3

implicit none
integer(i3):: i,il,ikl,ifind,ii,j
integer(i3),intent(in):: maxrec,nsite,nasite,nrsite,ntsite
integer(i3):: nfill,jfill,isfill,nrec
integer(i3),intent(in)::npn,lorbit,ienum
integer(i3):: kc,k,ienrp
real(RDP):: emin,emax,x
real(RDP):: s1,sum1,sum2,sum3
real(RDP),dimension(lorbit,lorbit,0:nrsite+1),intent(in):: srl

real(RDP),dimension(lorbit),intent(in)::ap7,ap8,ap9,ap10,ap11,ap12,ap13
real(RDP),dimension(lorbit),intent(in)::ap1,ap6
real(RDP),dimension(nsite,lorbit)::psii,psij,psik,psim
real(RDP)::alpha(maxrec),beta(0:maxrec)
real(RDP),dimension(lorbit)::cons,ar
integer(i3),dimension(nasite,ntsite),intent(in)::map
integer(i3):: mfill,ikk
real(RDP),dimension(lorbit):: p2,p3,p4
real(RDP),dimension(maxrec,ienum+1):: ya,xa
write(*,*) "running hop"

..
..
..
end subroutine hop

end module mhop
From: Richard Maine on
rudra <bnrj.rudra(a)gmail.com> wrote:

> sorry ...that is a run time error(segmentation fault).
> here are the declaration of the caller(main file) both are too tidy ,
> though!
[code elided]

Ok. That looks reasonably "clean" to my eye, though others here might
catch things that I missed. It doesn't look like it actually needed the
explicit interface from being in a module (there aren't assumed-shape
dummies after all), but that shouldn't hurt at all and helps with some
things that my eyes might miss.

I don't recall whether you tried with array bounds checking turned on.
That's certainly another common source of segmentation faults, and you
have enough arrays with various different bounds to make it easy to
overlook a bounds error.

But one thing does strike my eye. You have several so-called automatic
arrays. Those are arrays that are automatically dynamically allocated on
entry to the subroutine. Nothing at all wrong with that in principle.
But several compilers by default have pretty low default limits on stack
size, which can be exceeded by such automatic arrays. That could cause a
segmentation fault. You might try increasing the stack size. I don't
recall how to do that on Windows (I'm guessing you are on Windows), but
it shouldn't be hard. That would also fit the reported symptoms of
working ok with some other compilers.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
From: rudra on
Richard,
since i am not aware of the compiler option of array-bounds checking
in ifort, i have tried that with gfortran which gives no error. and
the 2nd think i wld like to know is the way of increasing the stack
size(and even before that, how to check the stack size).i am in GNU/
Linux ..so if you know that,plz let me know as well.


From: rudra on
oh...no!!i AM using -CB option for ifort...which is not generating any
error/warnning
From: David Duffy on
rudra <bnrj.rudra(a)gmail.com> wrote:
> Richard,
> since i am not aware of the compiler option of array-bounds checking
> in ifort, i have tried that with gfortran which gives no error. and
> the 2nd think i wld like to know is the way of increasing the stack
> size(and even before that, how to check the stack size).i am in GNU/
> Linux ..so if you know that,plz let me know as well.

Since you are on linux, you should run it again using valgrind, given
that the idb message wasn't particularly informative.

David Duffy.
--
| David Duffy (MBBS PhD) ,-_|\
| email: davidD(a)qimr.edu.au ph: INT+61+7+3362-0217 fax: -0101 / *
| Epidemiology Unit, Queensland Institute of Medical Research \_,-._/
| 300 Herston Rd, Brisbane, Queensland 4029, Australia GPG 4D0B994A v