[FLASH-USERS] Continuing to evolve particles that leave the domain

[Anshu Dubey]

Hi James,

I am completely unfamiliar with the internals of the sink particles, so
there I can't be of any help.

But if you assign it to the first block, what happens when it tries to find
the cell it is overlapping with ?

I still think your best bet might be to exploit the possibility of multiple
particle
types existing, and just turn the leaving particles into a different type,
name it
something else. That is because you can supply different advance, map etc
methods for different particle types. Sort will put them at the back, so
sink particles shouldn't even see them.

Anshu

On Sat, Mar 28, 2015 at 10:16 AM, James Guillochon <jfg at ucolick.org> wrote:

> Hi Anshu, evolution of the particles is done via the Sinks module
> currently, which seems to have its own routines for evolving the particles.
> At the moment I am not using the sink functionality (removing gas from the
> grid), but in principle it's something I'd like to be able to do in the
> future, which is why I'm using that module rather than just the active
> module.
>
> Anyway, if we ignore the sink functionality for now, I guess I'm not
> understanding why my current solution isn't working. Right now when the
> LOST flag would be applied, I instead just assign it to the first block on
> a processor within gr_ptLocalMatch:
>
> if(outside)blockID=gr_ptBlkList(1)
>
> I've also tried assigning it to its original block, which doesn't work
> either. And I make sure that the LOST flag is not applied in gr_ptOneFaceBC
> (I just comment out the "particle(gr_ptBlk)=LOST" line).
>
> Otherwise, there are no other locations in the code where particles can be
> marked as "LOST", as far as I can tell. Particles can be marked as
> "NONEXISTENT," but if this is happening I would think the particles
> wouldn't even be saved in the lost list, which would be a bug.
>
> My guess would be is that the Sinks module is doing something else that is
> removing particles that leave the domain?
>
> On Sat, Mar 28, 2015 at 12:38 PM, Anshu <adubey at lbl.gov> wrote:
>
>> Try adding another category such as OUTSIDE, with that particle should
>> not get deleted.
>> Give it a number > maxblocks so that sort puts those particles at the
>> end. When you pass the data structure to particle routines make sure the
>> local count is such that these particles are not
>> processed. And then add a routine to treat them separately. It has been a
>> couple of years since
>> I worked with this code, so I might have a few things wrong and a few
>> details missing, but I think
>> in general this should work.
>>
>> Best,
>> Anshu
>>
>> On Mar 28, 2015, at 9:16 AM, James Guillochon <jfg at ucolick.org> wrote:
>>
>> Hi all,
>>
>> I'm having a bit of trouble getting this to work. I need to leave a
>> particle assigned to a block at all times, and not marked as NONEXISTENT or
>> LOST, resulting in its deletion. Unfortunately it seems like there's a
>> number of places where particles can be mark as NONEXISTENT in the code,
>> and changing them all seems difficult (there's a only a few places where
>> the particle is marked as "LOST", which I've disabled).
>>
>> Anyone have any additional insight here? At the moment, particles are
>> deleted as soon as they leave the domain, even with the changes I've made.
>>
>> Thanks,
>> - James
>>
>> On Sat, Mar 28, 2015 at 12:15 PM, James Guillochon <guillochon at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> I'm having a bit of trouble getting this to work. I need to leave a
>>> particle assigned to a block at all times, and not marked as NONEXISTENT or
>>> LOST, resulting in its deletion. Unfortunately it seems like there's a
>>> number of places where particles can be mark as NONEXISTENT in the code,
>>> and changing them all seems difficult (there's a only a few places where
>>> the particle is marked as "LOST", which I've disabled).
>>>
>>> Anyone have any additional insight here? At the moment, particles are
>>> deleted as soon as they leave the domain, even with the changes I've made.
>>>
>>> Thanks,
>>> - James
>>>
>>> On Fri, Mar 27, 2015 at 4:58 PM, Anshu Dubey <adubey at lbl.gov> wrote:
>>>
>>>> If you don't need them to interact with the mesh in anyway I don't see
>>>> any conceptual problem with advancing them. You will still have to make
>>>> sure that they are not treated the same as particles within domain
>>>> in any function.
>>>>
>>>> Anshu
>>>>
>>>> On Fri, Mar 27, 2015 at 1:48 PM, James Guillochon <jfg at ucolick.org>
>>>> wrote:
>>>>
>>>>> Hi all, I'm using active particles in my calculation, and I would like
>>>>> to continue to evolve the particle trajectories even once the particles
>>>>> have left the domain. I see that particles that leave the domain can be
>>>>> saved after they leave by enabling a flag, but it appears that their
>>>>> evolution at this point is frozen. It looks like a few relatively simple
>>>>> changes in Particles_advance may be able to continue their evolution, but I
>>>>> wasn't sure if evolving these particles would cause issues.
>>>>>
>>>>> Has anyone tried to do something like this before?
>>>>>
>>>>> Cheers,
>>>>> - James
>>>>>
>>>>> --
>>>>> James Guillochon
>>>>> Einstein Fellow at the Harvard-Smithsonian CfA
>>>>> jguillochon at cfa.harvard.edu
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Anshu Dubey <adubey at lbl.gov>
>>>> Mailstop: 50A1148
>>>> Building-Room 050A-2154
>>>> 510-486-5242
>>>>
>>>
>>>
>>>
>>> --
>>> James Guillochon
>>> Einstein Fellow at the Harvard-Smithsonian CfA
>>> jguillochon at cfa.harvard.edu
>>>
>>
>>
>>
>> --
>> James Guillochon
>> Einstein Fellow at the Harvard-Smithsonian CfA
>> jguillochon at cfa.harvard.edu
>>
>>
>
>
> --
> James Guillochon
> Einstein Fellow at the Harvard-Smithsonian CfA
> jguillochon at cfa.harvard.edu
>



-- 
Anshu Dubey <adubey at lbl.gov>
Mailstop: 50A1148
Building-Room 050A-2154
510-486-5242
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20150328/ad2ed6ab/attachment-0001.htm>