[KarenRei]

So, I've been for a couple days baffled about some behavior I was seeing in a simulation of an array of spark gaps. When I run a non-decomposed case, it worked as expected. But when I ran a decomposed case with mpirun, I was getting far too many sparks, and in weird locations.

All of the sudden, it hit me: every single parallel case runs my scalarCodedSourceCoeffs / codeAddSup code in fvOptions. This code involves tracking down the closest cell to the spark (computing the x and y differences from mesh_.C(), aka the cell centres) and then adding in the appropriate power during the appropriate cycles. Obviously, in the non-decomposed case, this works. But in the decomposed case, many of the parallel segments won't even be close to any given spark. The code is just picking the closest cell regardless, even though it may be very far away.

My first thought was a distance limit, but that doesn't really work. The cells can be radically different in size, and they're generated by snappyHexMesh over an autogenerated model. So a distance limit would disk both failing to detect that a spark does belong within a given cell if that cell is large, or by having different parallel cases both simulate the spark if the spark is on the border zone and the cells are small in size.

Really what would be *ideal* would be some sort of "is_inside_cell(x, y, z)" function. Does anything like that exist?

[KarenRei]

Oh hey... findCell? Let's try that


ED: Lol, okay, solved my own problem. Guess it helps just to talk things out...