Reduced memory footprint for the FilterHistoryPoint class

Issue/feature addressed

The ´FilterHistoryPoints´ class consumes a lot of memory in the setup phase, i.e., inside the function called v_Initialise(). This prevented us from using a very large amount of history points for sampling. The reason for this turned out to be that each process allocates the member variable m_historyPoints (of type std::vector), which in turn was used to hold one shared pointer to a SpatialDomains::PointGeom for each history point coordinate. The PointGeom class appears to store much more memory than we really need (3 coordinates), and thus also uses more memory than we want.

The second issue with v_Initialise() was that it was a rather complicated function that is hard to follow, and that it contained some unnecessary logic.

Proposed solution

This merge request adds the following changes:

• The m_historyPoints variable was updated to be an Array<OneD, Array<OneD, const NekDouble>> instead of a std::vector
• The m_historyPoints variable is only allocated by the root process, and it only contains the coordinates of the history points, nothing more
• The m_historyList variable now contains a list of tuples. Each tuple contains all the information the code needs to interpolate the data to the corresponding history point, and then add it to a global array which will be communicated and written by the root process
• The distance calculation has been removed completely because it is not needed in the setup phase. The function GetExpIndex() already knows whether a point is inside or outside a mesh element, and that is all that we need to know
• The std::map called m_historyLocalPointMap was removed because the information it encoded has been added to the tuple stored by m_historyList

Implementation

In addition to the points raised above, it is worth pointing out that all processes will read all history point coordinates during the setup phase. This is necessary because the processes must figure out if they are responsible for each point. Note that the coordinates are stored in the local arrays called GloCoords and LocCoords (global coordinate, and element-local coordinate). Later, if the process determines that it is responsible for a given history point, it will store a reference to that history point in m_historyList. This is perfectly fine, because this reference refers to an Array<OneD, const NekDouble> array, which is reference counted. Hence, even though the process will drop the arrays called GloCoords and LocCoords, it will not deallocate the history points which it is responsible for, because there is an additional reference to this point in the m_historyList array, and the reference count is thus not zero. This fact has been pointed out with comments in the code.

Tests

Notes

Please add any other information that could be useful for reviewers.

Checklist

• Functions and classes, or changes to them, are documented.
• User guide/documentation is updated.
• Changelog is updated.
• Suitable tests added for new functionality.
• Contributed code is correctly formatted. (See the contributing guidelines).
• License added to any new files.
• No extraneous files have been added (e.g. compiler output or test data files).

Warning

On the 19.07 the code formatting (code style) was standardised using clang-format, over the whole Nektar++ code. This means changes in your branch will conflict with formatting changes on the master branch. To resolve these conflicts , see #295 (closed)