[FLASH-USERS] Strange abort condition with Particles

[Chris Daley]

Hi Josef,

I'm interested to know how many processors you are using, and the
dimensionality of your simulation?  Someone at the FLASH center
actually reported the exact same problem this morning.  We are going
to look at the problem tomorrow when he returns.  In his case, the
problem occurred at a large scale (4096 processors).  If you have a
smaller scale problem that reproduces the problem then that would be
very useful for me.

I'm very surprised about the original error message you receive.  This
abort is triggered from an assertion about neighboring processor IDs.
The actual value is obtained from a PARAMESH data-structure, so
perhaps in some situation I'm accessing the incorrect index in this
structure?

I'll keep you updated.

Chris


Lynn Reid wrote:
> Hi Josef:
>
> Thanks for reporting the problem.  Could you please email me back your 
> setup line?
> e.g. prompt> ./setup SkiTeam -auto -blah blah blah
> And also your run configuration
> prompt> mpirun -np ? SkiTeam
>
> We'll take a look at figuring out what's going wrong.  As you may have 
> noticed, there was considerable change in the Particles routines from 
> FLASH3.0 to FLASH3.1.
>
> Best wishes,
> Lynn
>
> Josef Stöckl wrote:
>> Hello,
>>
>> I'v migrated a simulation from FLASH 3.0 which uses active particles 
>> with CIC mapping. I've changed the Config file to reflect the changes 
>> in the particle unit (PARTICLETYPE active INITMETHOD CUSTOM MAPMETHOD 
>> WEIGHTED) and everything compiles quite nicely.
>>
>> At runtime however after reading in the particles files (256^3 
>> particles), I get some "Error, we should not be here." as well as the 
>> following abort message: "Shouldn't be here!".
>>
>> I've found this message to originate from gr_ptFindNegh.F90 (line 
>> 487) of the Grid/GridParticles/GridParticlesMapToMesh/Paramesh unit. 
>> I'm a bit puzzled why this seems to happen, especially since 
>> commenting out the abort and restoring the old gr_ptSearchBlk 
>> behaviour also leads to other errors ("[gr_ptMoveMappedData]: 
>> timesInLoop >= gr_numProcs" and "[gr_ptDumpState]: Metadata loop will 
>> not exit cleanly!" in the log).
>>
>> I had another look at the Pancake example and checked if there were 
>> some other differences in those routines compared to release 3.0, but 
>> didn't find anything. Can anyone of you tell me or give me a clue as 
>> to why this is happening?
>>
>> Thanks in advance and best regards,
>> Josef
>>
>> PS: I included my simulation's Config file.
>>
>