Surface collisions during adjacency search

[zhangchonglin]

During particle push and particle search operations, there may be wall surfaces along the particle's trajectory. I am wondering

• how does PUMIPic currently handle this type of particle and wall surface collision during particle search?
• similarly, how does GITRm handle this type of situation when using PUMIPic?
• additionally, if particle interacts with the surface, surface reactions may occur, leading to the creation of new particles. How should this be handled in PUMIPic? How is this being done in GITRm currently?

For example, in this 2D adjacency search function: https://github.com/SCOREC/pumi-pic/blob/0af57ac5f7be7d61235c308eafca0e51d2637578/src/pumipic_adjacency.hpp#L1010-L1019 If the vector from particle's old position to its new position is crossing some wall surface, this situation needs to be handled properly. Above function does not seem to check for surface collision.

[cwsmith]

Hello. I'm not aware of any specific code in pumipic to handle particle-wall interactions, but I could be mistaken.

@dhyan1272 Can you point out some of the gitrm code that handles this and any code in pumipic that was added to support it?

[dhyan1272]

The particle surface interaction in handled in GITRm through PUMIPIc API here (for 3D mesh) https://github.com/SCOREC/pumi-pic/blob/0af57ac5f7be7d61235c308eafca0e51d2637578/src/pumipic_adjacency.hpp#L314 When on the path between the current and final position lies an "exposed" face(3D) , the search routine says that the new elem id of the particles is -1. That means the particle will be killed in the next time step.

Looking very quickly, I see something similar on the 2D API too (exposed edges in place of exposed faces need to be checked)

If your physics is known which particles to not kill, you can explicitly set those particles elem ids not as -1 (the boundary elem)

[dhyan1272]

New particles can be added as here: https://github.com/SCOREC/gitrm/blob/MultiSpecies/src/GITRm.cpp#L419-L429 https://github.com/SCOREC/gitrm/blob/MultiSpecies/src/GitrmSurfaceModel.hpp#L677-L704

[cwsmith]

Thank you @dhyan1272 .

[zhangchonglin]

The particle surface interaction in handled in GITRm through PUMIPIc API here (for 3D mesh)

https://github.com/SCOREC/pumi-pic/blob/0af57ac5f7be7d61235c308eafca0e51d2637578/src/pumipic_adjacency.hpp#L314

When on the path between the current and final position lies an "exposed" face(3D) , the search routine says that the new elem id of the particles is -1. That means the particle will be killed in the next time step. Looking very quickly, I see something similar on the 2D API too (exposed edges in place of exposed faces need to be checked)

If your physics is known which particles to not kill, you can explicitly set those particles elem ids not as -1 (the boundary elem)

Thank you @dhyan1272! In terms of handling particle-wall collision in this function, how do you ensure time accurate simulation. I assume that: once particle hits a wall, it will stop the ray-tracing. Then in the next time step, do you move a longer distance with the left time step not moved for the particle hitting the wall? If this is the case, then the statistics in the current time step will not be accurate any more. Or are you only interested in the steady state results?

[dhyan1272]

Yes we had discussion on that aspect regarding what happens in the rest of the time step i.e when particles hit a surface in the middle of a time step. We donot account for it, I do not remember all the reasons, but some point I remember i) Particles are decoupled from the field ii) We are interested in steady state solution iii) No particle particle interaction

[cwsmith]

Notes from discussion with @zhangchonglin: We should separate the application specific logic that handles wall interactions from the adjacency search logic provided by pumipic. One approach to is to have the application provide a call back function that is called when the collision event is detected. This is only a partial solution though as it couldn't handle adding particles as a result of the collision and, as discussed above continuing the search for those added particles.

[zhangchonglin]

Some potential issues not letting particle continue to finish its push operation when it hits a walls:

• time accurate solution will be incorrect;
• even for steady state simulation, if the particle also need to interact with other particles (particle-particle collision) or the field (charge scatter for example), then the statistics will be incorrect.

Other than the above comments, I think this issue can be considered complete.