Provide an optimal expansion list ordering for collection operation

Issue/feature addressed

Currently the expansion for the solution domain, boundaries and trace space are ordered according to either the mesh file or how we load elements into the ExpList. We are hoping that this leads to a reasonable number of consecutive elements that are of the same order, have the same quadrature type and are either deformed or regular in shape. For many cases this is not true leading to a very high number of collections in any given expansion list.

Proposed solution

Since we do not make any assumptions on the ordering of the expansion within the library we can optimise the ordering on initialisation so that we make a series of bins containing expansions of the same order, quadrature type and whether they are deformed or regular. We then search through the expansion info which cantains the basiskeys and geometry information and put different elements into bins of similar type. Finally we then define the expansion list by running over the bins of elements we have collected making an optimal expansion ordering.

Implementation

The main developments are in ExpList.cpp. Many of the solution domain expansions use a common routine ExpList::InitialiseExpVector where we the optimisation routine more centrally. We however also have specliaised constructors for the boundary condtion expansions and the trace expansion so similar modifications have also been made to these constructors.

To maintain backwards compatibility I have added a command line option --no-exp-opt to turn off the optimisation.

Finally to evaluate the consequence of the optimisation I have added some output in verbose mode that writes out the number of collections, mean collection size and min/max collection size.

Tests

Some tests are changing slightly which i believe arises when the boundary expansion is changed and we therefore have a situation when enforcing Dirichet BCs as we cannot gaurantee which elements will enforce a BC between two neighbouring elements. I have run convergence checks to see that the tests still converge exponentially.

Suggested reviewers

It woudl be good if Chris, Dave and Jacquez could look over this update.

Notes

I think in general the optimization is OK but do wonder if the CI system might be affected by the optimisation step. Also need to consider if there is a better approach to doing the optimisation sorting? From initial runs through CI system most tests are performing similarly. Three test ran faster and one slower. Possibly the slower case was due to intialisation since it was not executing for many timesteps.

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).