Hex lattices indices update and lattice interior cell coincidence
Created by: pshriwise
Hex lattice indices
This PR updates how containing lattice cells are selected in hexagonal lattices. Previously, the particle was bumped along its trajectory to ensure the cell which the particle is moving into is selected. This was used to resolve cases where the particle was on the boundary of two cells. Minimal squared distances to cell centers are then used to determine which cell indices to return.
Rather than bumping the particle along its direction vector, the changes here detect particles on the boundary by identifying coincident minimal distances as particles on a boundary will be equally close to at least 2 of the cell centers. If coincidence is detected with the current minimum distance, a dot product calculation between the particle direction and the particle's local position vectors wrt each cell is used to select between the cells adjacent to the boundary. The cell center the particle is moving toward is preferentially selected.
Coincident surfaces in a lattice cell
Particles can currently be lost in lattices if a cell in that lattice has a boundary coincident with the lattice boundary. In particle tracking, we select between surface and lattice cell crossings based on distance, but for coincident (maybe equivalent is a better word...) distances the lattice cell should be selected so that particles do not leave the cell unintentionally. I've added a test problem with a hex lattice containing cylinders tangent to the lattice cell edges (coincident at a single point) to demonstrate this. The test problem seed is set such that a run with the
develop branch results in a lost particle via leakage through a line where the cylinder contacts the lattice cell. This branch fixes that problem by selecting the lattice crossing if the location of the cell and lattice crossing are coincident. An extended run with millions of particles on this same lattice results in no lost particles as well.
Looking for input on...
coincident I've added in geometry. Distance comparison isn't necessarily testing for coincidence, but in the context we're talking about here it is. Intuitively, a function like this would take two
Position's but it would be somewhat wasteful to construct those just to make a comparison we can do with a single double value for this case. I considered adding a
coincident function just to have it, but seeing as we wouldn't use it anywhere at that point it seemed sort of frivolous.
Anyhow, I put some thought into these two issues but please let me know if I missed any corner cases here!