Re: problematic array assignment in double precision (ifort, windows)


Steve Lionel wrote:
mvukovic@xxxxxxxxxxxx wrote:

As I noted in my previous post, the problem has been solved.

But I didn't see that you told us what was causing the problem. I am
very curious to learn that.

Steve

Steve,

Well, I started writing you that I don't know what caused the problem.
However, I now think that I know what caused the problem. The following
is from memory:

In the first version of my program, I was calling the function
rn_points_on_sphere() as an argument of another subroutine.

do iPart=1,self%cPart
self%vParticles(iPart)=new_particle( &
& self%oParticle_obj_creator,self%vRinit, &
& rn_point_on_sphere())
end do

where the new_particle routine looks as follows (it is in another
module)

function new_particle(self,vR,vV) result(oParticle)
type (particle_obj_creator),intent(in):: self
type (particle)::oParticle
real,intent(in)::vR(3),vV(3)

call
create_obj(oParticle,self%M,vR,vV,self%poMover,self%poScatterer )
return
end function new_particle

I believed that because the procedure argument is declared as vector of
size 3, the compiler would have enough information. But see below,
because as I write this, I realize where my mistake may have been.

Now this procedure (new_particle) is in a module whose header is:

MODULE particle_obj_creator_class

use mover_class
use scatterer_rw_3d_class
use particle_class
use physics_constants
implicit none
type particle_obj_creator
real M
type (mover), pointer:: poMover
type (scatterer_rw_3d),pointer::poScatterer
end type particle_obj_creator
interface create_obj
module procedure create_particle_obj_creator_obj
end interface
interface print_obj_def
module procedure print_particle_obj_creator_def
end interface

CONTAINS
.... stuff omitted...

This header *does not* have an interface declaration for the subroutine
new_particle. So, the compiler could not know about the argument type.

What happened was that as I was running the MonteCarlo simulation in
single precision, I was getting OK results. However, at some point in
the simulation, I would start getting NaN.s

My initial reaction was that I might have hit an overflow, and that is
when I switched to double precision. At this point, due to some
problems (don't remember which), I reduced the number of particles and
time-steps to 3.

At that point, I got an out-of-bounds warning. In the loop where iPart
was supposed to go from 1 to 3, it actually got a value of 4, and
outside the range of self%vParticles. Something was getting corrupted
somewhere.

At that point I started putting in diagnostic statements, and noticed
that the outputs of the rn_points_on_sphere did not make sense. That
is when I posted my original email.

What puzzles me is that I _think_ that after a bit of playing I did do
something along the lines of

subroutine load_init_parts(self)
type (simulation) self
real,dimension(3):: vSomeOtherVariableName


do iPart=1,self%cPart
vSomeOtherVariableName=rn_point_on_sphere()
self%vParticles(iPart)=new_particle( &
& self%oParticle_obj_creator,self%vRinit, &
& vSomeOtherVariableName)
end do

end subroutine load_init_parts

trying to make it explicit that I was dealing with a 3-element vector.
The problem still remained, until I stumbled upon the last version of
my program, where instead of vSomeOtherVariableName I use vV.

As a final note, now my NaN's which have started this whole thing are
gone, so I hope that I have fixed something. This discussion has also
prompted me to try and simplify my code a bit by removing some of the
objects.

I hope this helps some. I will try the /warn:interfaces to see if this
can shed some light.


Mirko

.

Relevant Pages