[FLASH-USERS] Particles_sinkSyncWithParticles

[Joshua Wall]

Hello again Klaus,

       I have found a second assumption in Flash that while not a bug
directly, can cause problems for users who are introducing their own
routines for particles that are not contained in Particles_advance.F90. It
has caused me some amount of headache to track down, so I feel it best to
at least get it documented on the email archive.

       In io_ptWriteParticleData.F90 at the top the particles are
sorted *always
assuming only one particle type*:

  integer,parameter :: particleTypes=1

!! This call returns particles sorted by block numbers and also the
!! the number of particles that each block has.

  call
Grid_sortParticles(particles,NPART_PROPS,l_numParticles,particleTypes,&
       pt_maxPerProc,particlesPerBlk, BLK_PART_PROP)

Afterward no call is made to pt_updateTypeDS. This of course means
that the pt_typeInfo
data structure is no longer valid if you have more than one type of
particle in the code until a new call to Grid_sortParticles and
pt_updateTypeDS is made (as it is in Particles_advance.F90). So if before
then you try to change or access any particle info for just one type, it
will be a mixture of both types instead. Since this change is made silently
and only periodically (when a checkpoint or particle file is written) it
appears that your particles are randomly changing values on a first (or
perhaps tenth or twelfth if your stubborn like me!) inspection.

Hopefully if no change is made at least this helps others with the same
problem.

Cordially,

Josh



On Wed, Apr 26, 2017 at 7:09 PM Klaus Weide <klaus at flash.uchicago.edu>
wrote:

> On Wed, 26 Apr 2017, Joshua Wall wrote:
>
> > So my question is basically, should Particles_sinkSyncWithParticles be
> > modified to include the BLK_PART_PROP
> > in the call to Grid_sortParticles when TYPE_PART_PROP is defined as seen
> in
> > other sections of the code? Doing
> > so in my case seems to fix a problem where sinks and a second particle
> type
> > appear to get their places exchanged in the particles array after a
> > particle file is written (which calls Particles_sinkSyncWithParticles).
>
> Hello Josh,
>
> After reviewing the code of Grid_sortParticles.F90, I believe that the
> answer is: yes, Particles_sinkSyncWithParticles should be modified as
> you have proposed.
>
> Grid_sortParticles isn't really a general-purpose sorting routine - one
> cannot just sort on any attribute. In practice, attrib1 pretty much has to
> be BLK_PART_PROP, and attrib2 should be TYPE_PART_PROP if present.
>
> (The likely reason for passing these as arguments instead of hardwiring
> them is that Grid_sortParticles may be used for other data elements than
> particles (e.g., rays, protons), and those can use different index
> values.)
>
> So the
>   call Grid_sortParticles(particles,NPART_PROPS,pt_numLocal,NPART_TYPES, &
>        pt_maxPerProc,particlesPerBlk,TYPE_PART_PROP)
> is basically invalid, but happens to work, more or less, without invalid
> array references as long as for all particle type attribute values T:
>      0 < int(T) < number of blocks on local proc  .
>
> Klaus
>
-- 
Joshua Wall
Doctoral Candidate
Department of Physics
Drexel University
3141 Chestnut Street
Philadelphia, PA 19104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20170427/6ce8117c/attachment-0001.htm>