<div dir="ltr"><div><div><div><div>Hello again Klaus,<br><br></div>       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.<br><br></div>       In io_ptWriteParticleData.F90 at the top the particles are sorted <u>always assuming only one particle type</u>:<br><br><span style="font-family:monospace">  integer,parameter :: particleTypes=1<br><br>!! This call returns particles sorted by block numbers and also the <br>!! the number of particles that each block has.<br><br>  call Grid_sortParticles(particles,NPART_PROPS,l_numParticles,particleTypes,&<br>       pt_maxPerProc,particlesPerBlk, BLK_PART_PROP)<br><br></span></div><span style="font-family:monospace"><font face="sans-serif">Afterward no call is made to pt_updateTypeDS. This of course means that the </font>pt_typeInfo <font face="sans-serif">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.<br><br></font></span></div><div><span style="font-family:monospace"><font face="sans-serif">Hopefully if no change is made at least this helps others with the same problem.<br><br></font></span></div><div><span style="font-family:monospace"><font face="sans-serif">Cordially,<br><br></font></span></div><div><span style="font-family:monospace"><font face="sans-serif">Josh<br></font></span></div><div><span style="font-family:monospace"><font face="sans-serif"><br></font></span></div><span style="font-family:monospace"><font face="sans-serif"><br></font></span></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Apr 26, 2017 at 7:09 PM Klaus Weide <<a href="mailto:klaus@flash.uchicago.edu">klaus@flash.uchicago.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 26 Apr 2017, Joshua Wall wrote:<br>
<br>
> So my question is basically, should Particles_sinkSyncWithParticles be<br>
> modified to include the BLK_PART_PROP<br>
> in the call to Grid_sortParticles when TYPE_PART_PROP is defined as seen in<br>
> other sections of the code? Doing<br>
> so in my case seems to fix a problem where sinks and a second particle type<br>
> appear to get their places exchanged in the particles array after a<br>
> particle file is written (which calls Particles_sinkSyncWithParticles).<br>
<br>
Hello Josh,<br>
<br>
After reviewing the code of Grid_sortParticles.F90, I believe that the<br>
answer is: yes, Particles_sinkSyncWithParticles should be modified as<br>
you have proposed.<br>
<br>
Grid_sortParticles isn't really a general-purpose sorting routine - one<br>
cannot just sort on any attribute. In practice, attrib1 pretty much has to<br>
be BLK_PART_PROP, and attrib2 should be TYPE_PART_PROP if present.<br>
<br>
(The likely reason for passing these as arguments instead of hardwiring<br>
them is that Grid_sortParticles may be used for other data elements than<br>
particles (e.g., rays, protons), and those can use different index<br>
values.)<br>
<br>
So the<br>
  call Grid_sortParticles(particles,NPART_PROPS,pt_numLocal,NPART_TYPES, &<br>
       pt_maxPerProc,particlesPerBlk,TYPE_PART_PROP)<br>
is basically invalid, but happens to work, more or less, without invalid<br>
array references as long as for all particle type attribute values T:<br>
     0 < int(T) < number of blocks on local proc  .<br>
<br>
Klaus<br>
</blockquote></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div><div><div><div>Joshua Wall<br></div>Doctoral Candidate<br></div>Department of Physics<br></div>Drexel University<br></div>3141 Chestnut Street<br></div>Philadelphia, PA 19104<br></div></div>