segmentation fault

[mikibelavista]

I am running a bash script,large code.I have problems with some arrays in this subroutine:
subroutine atupv(m,n,u,v)
include 'ray.par'
parameter(nnzmax=100000, ndmax=1000)
parameter(nsconst=3*nximax*nzimax,
+ nszero=7*nximax*nzimax,
+ nmmax=nximax*nzimax)
integer row(nnzmax+nszero),column(nnzmax+nszero)
real anz(nnzmax+nszero),u(m),v,sum(nmmax)
common /blk1/ anz,row,column,nnzero
do j=1,n
sum(j)=0.
end do
do i=1,nnzero
sum(column(i))=sum(column(i))+anz(i)*u(row(i))
end do
do j=1,n
v(j)=v(j)+sum(j)
end do
return
end
nsconst=450
nszero=1050
nmmax= 150
nnzero=2685
What should be dimension of array u?

 

[salgerman]

First of all, I do not recommend using your own array variable named "sum" ...this is already an intrinsic function since fortran 90.

Second, the dimension of u() should be at least as large as the largest number stored in row(i).

That's all I can say from the info you have provided.

 

[xwb]

It also depends on

1) What are the values of nximax, nzimax
2) Whether all the column(i) values between indices 1 and nnzero have values between 1 and nmmax
3) Whether all the row(i) values between indices 1 and nnzero have values between 1 and m

The v array is never initialized so adding to it is not a very good idea.

 

[salgerman]

well...yeah, all that...I was just only answering the one question the OP asked.

Also, the loop

do j=1,n
  sum(j)=0.
end do

only zeroes out the values 1 through n in the array sum(), but I don't see a guarantee that only these indexes will be used in the following loop:

do i=1,nnzero
   sum(column(i))=sum(column(i))+anz(i)*u(row(i))
end do

after all, the indexes will come from the values stored in column(i)...are these values guaranteed to fall between 1 and n?

By the way, the loop

do j=1,n
  sum(j)=0.
end do

could be replaced with the expression:

sum(1:n)=0.

for the same effect. Maybe even

sum=0.

if what you want is to truly zero out sum()

The same goes for the last loop, it could simply be:

v = v + sum

o.k., v was not initialized in the subroutine, but it is an argument to it...I presume it comes in with some values in it already...or something; otherwise, initiliazation of v shouldn't be up to the subroutine

 

[gummibaer]

mikibelavista,
Maybe it would help, if you would rethink your way of organising your data.

What I mean is, within 20 lines of code you manage to define six arrays (which is okay), defining 8 parameters to evaluate 5 different parameters for sizing these arrays and then use two further parameters as max loop indices. Some of these parameters get defined in this routine, apparently others come in by including ray.par (or whereever nximax or nzimax are defined) In addition you pass three more arrays by common block. You have to keep dimensions consistent throughout all your routines here. Using an expression to do this is not so easy to debug. And one variable that you use - I mean u - uses indices from an array that may have any value for all we know.

Well, who on earth shall debug this program while coding or maintaining this, I dare say, even you yourself will have a problem to find your way through this jungle say six months from now.

I would recommend you use module(s) like this

module mydata
    integer, parameter :: nnzmax = 100000    ! maximum number of ..., corresponds to number of ... in test
    integer, parameter :: ndmax = 1000       ! maximum number of ..., corresponds to ...
    integer, parameter :: nximax = ...       ! ....
    integer, parameter :: nzimax = ...       ! ....

! define all your parameters that you use for setting your arrays here. 
! Then declare your globally used arrays
    real anz (...)                           ! and explain what this is
    real row (...)                           ! I would avoid to have expressions to size my arrays.
    real column (...)
    real v (...)
end module

Your subprogram might look like this now:

subroutine atupv ()
    use mydata               ! this invokes all the data from the module

    implicit none            ! to see if you have all the variables defined that you use and avoid typos this way

    real sum (nmmax)         ! you can use the module's parameters to define local arrays

!   do your maths
    return
end

For me, one of the major challenges in programming is not to get lost in your data and your coding. And having a clear input and output of data is one of the things to use.

Ah, I almost forgot, when you set up such a module, I dare say you will find out easily how big this array u has to be.

Norbert



The optimist believes we live in the best of all possible worlds - the pessimist fears this might be true.

 

[mikibelavista]

Well,just to explain the code is not mine,I am using it for my Phd thesis.So to rewrite it FORTRAN90 does not make sense.The problem is that some parameters are within the code,so the code is compiled with them,the other ones are read from numerous input files.it is a little bit tricky to find out where is the segmentation fault.

 

[gummibaer]

What do you mean by 'segmentation fault' ?

Norbert


The optimist believes we live in the best of all possible worlds - the pessimist fears this might be true.

 

[melmacianalf]

mikibelavista:

I think you should put some effort into explaining your problem clearly. Otherwise it cuts an impression that you yourself are not interested in looking into the problem. BTW what bash script are you talking about? A simple strategy is to just go through the post (before posting) line by line and think if it will make any sense to others. Of course this is applicable to about 60-70% of the posts in this forum.