iljah
commented
8 months ago Does this consider periodic grids? In that case one cell can be on several sides of another...
Naturally there are many preferred ways to build neighbor lists. In above case for example in periodic grid of two cells they can have only one neighbor but building any kind of solver on top of that doesn't seem easy. On other hand I can see that having same cell 10 times in one neighbor list could also be difficult to work with. Ideally users could choose how neighbor lists are built, maybe that would even be possible without too much effort.
ursg
markusbattarbee
This PR changes the fundamental definition of what a "neighbor" is. So far, in DCCRG, neighbor locations were always specified in units of the origin cell's size. At refinement level interfaces, this sometimes caused unintuitive behaviour, such as the same cell being addressed with different indices, or more cells than necessary being returned. In Vlasiator, this required some extensive workarounds, and a larger communication halo size (n=3) than would otherwise be required by the solvers (n=2).
With this PR, the definition of a neighbor at offset (x,y,z) is changed to mean "a cell that is encountered when walking along the highest refinement level, as the z-th unique cell in dimension 2, x-th cell in dimension 0 and y-th cell in dimension 1". This nontrivial dimension ordering, of course, stems from the internal use of vlasiator's translation solver.
This obviates most of the workarounds in the Vlasiator codebase, but probably breaks general-purpose usage of DCCRG, hence this PR is targeted towards the vlasiator-version branch. As a prototype implementation, no care has been taken to retain the previous structure, and a thorough refactoring would be required if both are to be used side-by-side.
This has been verified with Vlasiator global Magnetospheric runs.