relocate particles using plane equations

[sigvaldm]

Today particles are relocated by following trajectories using projections through inner products. These equations could be slightly simplified by rewriting them to the equations of a plane and storing the plane coefficient for each facet instead. It is also slightly less memory demanding to store these coefficients than normal vectors and facet midpoints.

[sigvaldm]

This is implemented. Somewhat disappointingly, this only reduced the time (spent by the update() method in the test simulation) from 1:01 to 54 s. That's 11.5%. Still something for long simulations where the update() method may take roughly half the simulation time.

[sigvaldm]

Another gain down to 42 s was achieved by a slight modification to the algorithm. The total reduction is then 31.1%. Let p be the perpendicular distance from the facet plane to the particle position. Before it used to relocate recursively to the cell adjacent to the facet having the largest p (granted that it is positive). Finding the maximum takes some time. Now it immediately relocates to the cell adjacent to the first facet having p>0 without checking the other facets. This may lead to more relocations in rare cases, but apparently it's more efficient on average. The recursion doesn't stop before it's inside the right cell so this should not cause altered numerical results except, perhaps, in cases where two object boundaries are very close to one another and the particle may therefore propagate to one instead of the other. For sufficiently small timesteps this shouldn't be a problem. The old relocate() function with only the 11.5% gain will be kept for a while in the codebase.

[sigvaldm]

Tested using integration test and merged into develop.

[sigvaldm]

It is also worth noting that as the timestep gets larger compared to the spatial resolution, the more recursions are needed by relocate(), and the slower update() gets. As an example, in one simulation I ran with dtwp=0.2, update() spent 12:01 (40% of the total). Continuing with dtwp=0.02 and everyhing else similar update() took only 3:56 (20% of the total). This is with the new version (I've seen it spend 60% before this fix).

For the record, all other parts took the same amount of time on dtwp=0.2 and dtwp=0.02 except the injector, which took 2:08 in the former case and only 14 s in the latter. This is also natural, there should be a tenth of the particles to generate per time-step in the latter case and the time consumption scales roughly according to that.