Re: dimensions issue!
- From: glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx>
- Date: Fri, 20 Jan 2012 11:12:06 +0000 (UTC)
milenko markovic <milenko.markovic@xxxxxxxxxxxxxx> wrote:
Well it has been defiened as allocatable,i am now attaching my code:
integer :: i,j,k,c,s,n_data
real,dimension(2) :: work_s
real,dimension(8,2) :: x
real,dimension(2,8) :: work_cn
It looks suspicious, though not necessarily wrong, to see two
arrays with the subscript values swapped.
real,dimension(8) :: work_n,work1_n
real,dimension(2,2) :: vv,dvv
real,dimension(4) :: dv,pp
It would have been useful to also supply the input data for these...
vv = reshape(pp, (/ c, s /))
Nothing against RESHAPE, but it isn't hard to read in the values
in the right order:
Note that without the ORDER option, RESHAPE keeps the origina order,
which is the same as that in the data. Possibly not the order
that you expect.
do i = 1, c
do k = 1, n_data
work_s = vv(i,:) - x(k,:)
work_cn(i,k) = 1.0/dot_product(work_s, work_s)
work_n(k) = double_sum(work_cn(:,k))
do i = 1, c
work1_n = (work_cn(i,:)/work_n)**2
dvv(i,k) = double_sum(work1_n*(vv(i,k)-x(:,k)))*2.0
Scalar (vv(i,k)) time array slice (x(:,k)) has the dimension of the
slice, so (2).
work1_n has dimension (8), multiplied by (2) doesn't look good.
dv = reshape(dvv, (/ c*s /))
I get this:
forrtl: severe (408): fort: (2): Subscript #2 of the array VV has
value 3 which is greater than the upper bound of 2
It does look like all the second subscript of vv should only have
the value up to 2. The mixed dimension multiply could do it, though.
Also, if I remember it, double_sum() uses assumed shape, and I don't see
it in a module, or otherwise with an explicit interface so that it gets
called appropriately. That can easily cause variables to have unexpected
values, such that this could happen.
- Prev by Date: Re: dimensions issue!
- Next by Date: graphics program oddity
- Previous by thread: Re: dimensions issue!
- Next by thread: graphics program oddity