You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using the periodic_distance policy everywhere introduces significant overhead, since this method is very central to the package. In the inner cells, a normal cartesian distance would suffice.
Furthermore, I am working on an additional boundary condition right now, that further complicates the distance calculation and introduces more overhead.
Therefore, I propose a combined distance policy. Using this policy, one (simple) distance policy for inner cells can be set and additional ones for each boundary (i.e. x, y and z, maybe even x+/x-, y+/y- and z+/z-). Using a combined distance policy as an interface between CellLists and DistanceInterface reduces the refactoring necessary to a minimum and enables extensibility in the future.
The text was updated successfully, but these errors were encountered:
Using the periodic_distance policy everywhere introduces significant overhead, since this method is very central to the package. In the inner cells, a normal cartesian distance would suffice.
Furthermore, I am working on an additional boundary condition right now, that further complicates the distance calculation and introduces more overhead.
Therefore, I propose a combined distance policy. Using this policy, one (simple) distance policy for inner cells can be set and additional ones for each boundary (i.e. x, y and z, maybe even x+/x-, y+/y- and z+/z-). Using a combined distance policy as an interface between CellLists and DistanceInterface reduces the refactoring necessary to a minimum and enables extensibility in the future.
The text was updated successfully, but these errors were encountered: