GitLab

Updated the comment to OrthoPyr_C to reflect issue of the space of the orthogonal expansion with regard to the modified expansion

Updated the StdRegions demos and regression tests to be consistent with new numbering of Basis Types

Updates to add in SVV capability to Pyramids using the modified expansion. This also required the introduction of IProductWRTDerivBasis into PyrExp.cpp. A regression test was also included

Modified LocProject3D tests to be consistent with introduction of Pyramid expansion. All seem OK except Hex and Lagrange changes which were rather large in a relative sense if or order 10e-11

Adjusted BL thickness in corners.

Only applies to 2D mesher.

See merge request !739

Updated regressiont tests to account for the introduction of two new bases types OrthoPyr_C and ModifeidPyr_C

Added Modified_C basis that can be used with pyramids and also works with a modified and orothoogonal expansion. Currently orthogonal expansion produced diagonal but with non-unit values

Conflicts:
	CHANGELOG.md

Fix documentation issues.

This MR just fixes a few minor errors in the doxygen docs and adds an extra pdflatex run to the user guide to ensure references are properly included.

See merge request !749

Switch to MPI_lang_... variables

This MR switches the CMake configuration to use `MPI_<lang>_...` variables instead of the existing `MPI_...` variables. Currently Nektar++ uses `MPI_LIBRARY` and `MPI_EXTRA_LIBRARY`, which have been deprecated for some time. In recent versions of CMake, at least on OS X, `MPI_EXTRA_LIBRARY` is no longer set, meaning that Nektar++ fails to configure if MPI is enabled. A similar fix has also been applied to gsmpi which has the same issue.

See merge request !725

Fix: Dont read the same files again for every variable

This branch adds a check to prevent EquationSystem from reading the same fld/pts files again for each variable. This gives a huge speedup in some cases.

I also split the EquationSystem::EvaluateFunction method into three new methods: one for expressions, one for fld files and one for pts files to make the code more readable.

However, i think its still a mess with lots of duplicate code and even more things that would make much more sense in some other class. Even worse is that the Forcing base class holds a complete copy of this code.  I would like to move the whole Function logic from Forcing and EquationSystem into a new class that lives in SolverUtils in the future. Should we discuss that here or do you want me to write to the mailing list?

See merge request !670