Nektar merge requestshttps://gitlab.nektar.info/nektar/nektar/-/merge_requests2024-03-22T14:51:57Zhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1692Fix boundary conditions and initial condition in the MRF2024-03-22T14:51:57ZAnkang Gaoankanggao@ustc.edu.cnFix boundary conditions and initial condition in the MRF# Issue/feature addressed
The current framework to set boundary conditions in the incompressible solver is very complex. In the current code, all boundaries are treated in one function. It is very hard to add a new type of boundary condi...# Issue/feature addressed
The current framework to set boundary conditions in the incompressible solver is very complex. In the current code, all boundaries are treated in one function. It is very hard to add a new type of boundary condition. I wish to reorganise the boundary condition class (Extrapolate) and to treat each boundary separately. In the new framework, all velocity components and pressure in each piece of boundary are set together. The different boundary types are generated using a factory pattern to make it flexible. In the future, the partial-slip boundary condition and the turbulent wall model can also benefit from this framework.
Also, fix this issue. close #335
# Proposed solution
*A summary of the proposed changes and how they address the issue/feature at hand. Whenever possible, describe alternatives your considered and decisions you made.*
# Implementation
*A more detailed description of the changes. Please include any details necessary for reviewers to understand your work, and point out particular points would like them to pay particular attention to.*
## Tests
# Suggested reviewers
*Please suggest any people who would be appropriate to review your code.*
# Notes
*Please add any other information that could be useful for reviewers.*
# Checklist
- [x] Functions and classes, or changes to them, are documented.
- [x] User guide/documentation is updated.
- [x] Changelog is updated.
- [x] Suitable tests added for new functionality.
- [x] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- [x] License added to any new files.
- [x] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0Mohsen LahootiSpencer SherwinMohsen Lahootihttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1759Add support for Multiscale Universal Interface (MUI) library2024-02-26T11:26:18ZChris CantwellAdd support for Multiscale Universal Interface (MUI) library# Issue/feature addressed
This adds support for coupling using the Multiscale Universal Interface (MUI) library. This library allows data on grids with different resolutions to be exchanged between two solvers which may be advancing at d...# Issue/feature addressed
This adds support for coupling using the Multiscale Universal Interface (MUI) library. This library allows data on grids with different resolutions to be exchanged between two solvers which may be advancing at different time-steps. The coupling interface handles the interpolation between these grids and the different time-step sizes.
# Proposed solution
In this MR we add support for linking with the MUI library and demonstrate the interface through a new equation system in the DummySolver, extending the earlier work to add the Cwipi coupling library.
# Implementation
At the moment, the MUI interface is demonstrated only in the DummySolver, with the exchange being hard-coded in this solver. Details of how the exchange is managed (which application talks to which other application, which variables are exchanged, etc) are handled through a dedicated `<COUPLING>` section of the XML input file. In particular, this provides details about which variables are to be sent to another application, the names of the variables into which information should be received, as well as the original names of these variables.
## Tests
A test `Dummy_2DTestMUI` is provided which runs two separate instances of the DummySolver (each with their individual input files) and demonstrates the exchange of fields of data between them.
# Suggested reviewers
@dmoxey
# Notes
The majority of the implementation for this work was completed by Stefano Rolfo at STFC.
# Checklist
- [X] Functions and classes, or changes to them, are documented.
- [x] User guide/documentation is updated.
- [x] Changelog is updated.
- [X] Suitable tests added for new functionality.
- [X] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- [X] License added to any new files.
- [X] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1743Draft: Redesign of Nektar++ core data structures and algorithms2024-03-28T08:59:37ZChris CantwellDraft: Redesign of Nektar++ core data structures and algorithms# Issue/feature addressed
The existing Nektar++ design prevented the efficient use of vectorisation, GPUs and other current and future platforms. Assumptions made in the data structures did not allow for the reorganisation of memory to s...# Issue/feature addressed
The existing Nektar++ design prevented the efficient use of vectorisation, GPUs and other current and future platforms. Assumptions made in the data structures did not allow for the reorganisation of memory to support vectorisation, or the use of memory on attached devices. Algorithms were tightly coupled to the `ExpList` class, creating a bottleneck for the development of new solvers.
# Proposed solution
Redesign the core data structures and algorithms of Nektar++ to address the above concerns. A high-level `Field` class encapsulates the storage of solutions, tied to the nature of the representation (physical space, coefficient space, etc), tied to an abstraction of a memory back-end. Mathematical operations are represented as abstract `Operators`, with specific concrete implementations targeted to different platforms or programming models.
# Implementation
New implementation is currently captured in the `Operators` library.
## Tests
A range of unit tests have been added within the `UnitTests` directory.
# Suggested reviewers
Everyone
# Notes
It is anticipated that this MR will be merged by the release of v5.6, but will not be integrated with our solvers until a later release.
# 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](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- [ ] License added to any new files.
- [ ] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1737Fix memory leak with updated matrices and Block preconditioner2024-03-22T15:21:00ZHenrik WustenbergFix memory leak with updated matrices and Block preconditioner# Issue/feature addressed
The Block preconditioner initialises a GS mapping for communicating vertex data. This mapping is by default not deallocated when the preconditioner object is destroyed. The mappings do not change in time and can...# Issue/feature addressed
The Block preconditioner initialises a GS mapping for communicating vertex data. This mapping is by default not deallocated when the preconditioner object is destroyed. The mappings do not change in time and can be saved instead of re-initialised every time step.
# Proposed solution
Only initialise the gs mapping upon first creation of a `PreconditionerBlock` and save it in the `AssemblyMap`.
# Implementation
The `AssemblyMapCG` holds a vector with gs mapping(s) which are handed to any `PreconditionerBlock` upon initialisation. The first call to `PreconditionerBlock::BuildPreconditioner()` initialises the mapping and hands a copy to the `AssemblyMapCG`.
Additionally this merge fixes the `PreconditionerBlock` for low polynomial orders where Edges/Faces or the volume element have zero interior DoFs.
## Tests
- We do not have tests with memory-constraint environments. However, I added a test with the `BlockPreconditioner` specifically to make sure this change is not breaking any code.
# Suggested reviewers
@dmoxey
@ssherw
@CFD-Xing
# Notes
- This memory leak also occurs with the `LowEnergyBlock` preconditioner. However, freeing or saving the gs mappings alone does not fix the leak. Still need to work out what causes the memory leak.
# Checklist
- [x] Functions and classes, or changes to them, are documented.
- ~~[ ] User guide/documentation is updated.~~
- [x] Changelog is updated.
- [x] Suitable tests added for new functionality.
- [x] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- [x] License added to any new files.
- [x] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0Jacques XingJacques Xinghttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1675Draft: Use C++17 ::operator new instead of boost::aligned_alloc2024-01-12T14:35:05ZDave MoxeyDraft: Use C++17 ::operator new instead of boost::aligned_alloc# Issue/feature addressed
*Please provide a description of the problem your changes address. Be sure to link to any related items in the issue tracker.*
# Proposed solution
*A summary of the proposed changes and how they address the iss...# Issue/feature addressed
*Please provide a description of the problem your changes address. Be sure to link to any related items in the issue tracker.*
# Proposed solution
*A summary of the proposed changes and how they address the issue/feature at hand. Whenever possible, describe alternatives your considered and decisions you made.*
# Implementation
*A more detailed description of the changes. Please include any details necessary for reviewers to understand your work, and point out particular points would like them to pay particular attention to.*
## Tests
# Suggested reviewers
*Please suggest any people who would be appropriate to review your code.*
# 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](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- [ ] License added to any new files.
- [ ] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0https://gitlab.nektar.info/nektar/nektar/-/merge_requests/1627Matrix-Free operator for LinearAdvectionDiffusionReaction2024-03-26T21:28:42ZHenrik WustenbergMatrix-Free operator for LinearAdvectionDiffusionReaction# Issue/feature addressed
Enable `Collections` grouping for ADR operator to enable faster (Matrix-Free) runs for the Implicit Velocity-Correction scheme (`VCSImplicit`) in `IncNavierStokesSolver`.
# Proposed solution
Add the operator si...# Issue/feature addressed
Enable `Collections` grouping for ADR operator to enable faster (Matrix-Free) runs for the Implicit Velocity-Correction scheme (`VCSImplicit`) in `IncNavierStokesSolver`.
# Proposed solution
Add the operator similar to the `Helmholtz` implementations in Collections, however, including an `AdvectionKernel`. This new kernel requires time-dependent `varcoeffs` i.e. advection velocities. Therefore, this MR is based on !1701 which adds an interface for `varcoeffs` to `Collections`.
# Implementation
Most changes are analogous to the `Helmholtz` operator, however, the matrix-free routine requires interleaving of the advection velocities. The interleaving is done inside the `Collections` library for the matrix-free ADR operator.
## Tests
- Test based on existing VCSImplicit test which uses the Matrix-free routines instead of StdMatrix
# Suggested reviewers
@CFD-Xing (familiar with !1701)
@dmoxey
# Notes
# Checklist
- [x] Functions and classes, or changes to them, are documented.
- [x] User guide/documentation is updated.
- [x] Changelog is updated.
- [x] Suitable tests added for new functionality.
- [x] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- [x] License added to any new files.
- [x] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0Jacques XingJacques Xinghttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1588Draft: Generalize the use of SpaceComm to various solvers.2024-01-11T11:45:02ZJacques XingDraft: Generalize the use of SpaceComm to various solvers.# Issue/feature addressed
Various solvers have been updated to allow parallel-in-time execution and outputting.
# Proposed solution
- Update filters output for the `CardiacEPSolver` solver to allow parallel-in-time output.
- Update fil...# Issue/feature addressed
Various solvers have been updated to allow parallel-in-time execution and outputting.
# Proposed solution
- Update filters output for the `CardiacEPSolver` solver to allow parallel-in-time output.
- Update filters output for the `IncNavierStokesSolver` solver to allow parallel-in-time output.
- Update flow-rate output for the `IncNavierStokesSolver` solver to allow parallel-in-time output.
# Implementation
## Tests
# Suggested reviewers
*Please suggest any people who would be appropriate to review your code.*
# Notes
# Checklist
- [x] Functions and classes, or changes to them, are documented.
- ~~[ ] User guide/documentation is updated.~~
- [ ] Changelog is updated.
- ~~[ ] Suitable tests added for new functionality.~~
- [x] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- ~~[ ] License added to any new files.~~
- [x] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0https://gitlab.nektar.info/nektar/nektar/-/merge_requests/1411Draft: fix-Removing duplicate function GetMetricInfo2024-01-26T14:10:41ZMohsen LahootiDraft: fix-Removing duplicate function GetMetricInfo# Issue/feature addressed
In library/SpatialDomain/Geometry.h there are two functions defined which are exactly the same with different names. The first is GetGeomFactors and the second is GetMetricInfo. Both were used interchangeably an...# Issue/feature addressed
In library/SpatialDomain/Geometry.h there are two functions defined which are exactly the same with different names. The first is GetGeomFactors and the second is GetMetricInfo. Both were used interchangeably and such unnecessary duplication introduced inconsistency in naming across the code. for example in some places the member function is defined as m_geomFactors and in some m_metricInfo
# Proposed solution
Removed the GetMetricInfo function and replaced it with GetGeomFactors. Similar for m_metricInfo which is replaced by m_geomFactors
The reason that GetGeomFactors is used, aside from its origins in Geometry, is that there is a GetRefGeomFactors function in Geometry.h that is consistent with GetGeomFactors and using this name will reduce the number of changes. Otherwise, the GetRefGeomFactors should be renamed to GetRefMetricInfo for naming consistency and to revise the code accordingly.
# Implementation
----
## Tests
No need
# Notes
*Please add any other information that could be useful for reviewers.*
# Checklist
- [X] ~~Functions and classes, or changes to them, are documented.~~
- [X] ~~User guide/documentation is updated.~~
- [X] Changelog is updated.
- [X] ~~Suitable tests added for new functionality.~~
- [X] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- [X] ~~License added to any new files.~~
- [X] 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
https://gitlab.nektar.info/nektar/nektar/-/issues/295v5.6.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1375Draft: Changes to allow SessionReader (and MeshGraph) objects to be set up wi...2024-01-26T14:17:12ZOwen ParryDraft: Changes to allow SessionReader (and MeshGraph) objects to be set up without XML files.# Issue/feature addressed
Simplify the running of Nektar solvers from external code by allowing programmatic set up of session and mesh objects, bypassing the usual XML file(s).
# Proposed solution
Extract the XML-parsing functionality ...# Issue/feature addressed
Simplify the running of Nektar solvers from external code by allowing programmatic set up of session and mesh objects, bypassing the usual XML file(s).
# Proposed solution
Extract the XML-parsing functionality in SessionReader to a separate subclass, then add constructors and functions to populate session and mesh objects programmatically.
# Implementation
The main changes are:
1. ``SessionReader`` class renamed to ``Session``.
1. Several ``SessionReader`` member functions split up/rejigged in order to separate out XML-parsing from population of member variables.
1. Xml-parsing functionality from ``SessionReader`` moved to the ``SessionXmlReader`` class, which inherits from ``Session``.
1. ``Session`` constructors chained to reduce duplicate code.
1. New ``Session`` constructor added that performs initialisation based on various STL container arguments. e.g. a ``std::map<std::string,std::string>`` for solver settings.
1. New ``MeshGraphProgrammatic`` class added. This is a subclass of ``MeshGraphXml``, rather than``MeshGraph`` in order to allow hybrid set ups, wherein parameters describing the expansion(s) are set programmatically, but the mesh itself is still read from XML.
1. Constructors of ``EquationSystem`` and its subclasses modified to allow pre-existing boundary conditions to be passed in, meaning they can be set up externally.
See library/Demos/LibUtilities/SessionWithoutXMLDemo.cpp for demos/tests of 1D and 2D problem set up.
N.B. The above implementation incorporates the approach described in the first bullet of https://gitlab.nektar.info/nektar/nektar/-/merge_requests/1375#note_20057.
A description of the original implementation is retained below:
---
### Previous implementation
1. New SessionConfigurable class (subclass of SessionReader)
1. Several SessionReader member functions split up/rejigged in order to separate XML-parsing from population of member variables
1. SessionReader constructors chained to reduce duplicate code
1. New MeshGraphProgrammatic class (subclass of MeshGraph)
1. Constructors of EquationSystem and its subclasses modified to allow pre-existing boundary conditions to be passed in, meaning they can be set up externally.
This approach seemed like the least disruptive way to change things for now; one downside is that SessionConfigurable inherits the XML doc and associated member functions. To mitigate that, I've overridden most (all?) of those functions to throw exceptions.
The intent is for external code to call SessionConfigurable::CreateInstance([variable_names, parameters, solver_info etc. in the form of STL containers]) . At least one part of the session is populated later (using SessionConfigurable::AddFunction), but that could be moved into the constructor too.
## Tests
- (Demos/LibUtilities/Tests/)SessionWithoutXMLDemo_Helmholtz1D - mimics the Helmholtz1D_8nodes test, buts sets up the session and mesh programmatically.
- (Demos/LibUtilities/Tests/)SessionWithoutXMLDemo_Helmholtz2D_modal_DG - mimics the Helmholtz2D_modal_DG test, buts sets up the session programmatically (the mesh is still read from xml).
# Notes
- clang-format changes handled in accordance with https://gitlab.nektar.info/nektar/nektar/-/issues/295.
# Checklist
- [ ] Functions and classes, or changes to them, are documented.
- [ ] User guide/documentation is updated.
- [ ] Changelog is updated.
- [x] Suitable tests added for new functionality.
- [x] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- [x] License added to any new files.
- [x] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1334Draft: Add initial support for Saena AMG solver2024-01-16T22:33:14ZDave MoxeyDraft: Add initial support for Saena AMG solver# Todo before merge
- [ ] Test cases need to be added
- [ ] Documentation
- [ ] Changelog
# Issue/feature addressed
*Please provide a description of the problem your changes address. Be sure to link to any related items in the issue tr...# Todo before merge
- [ ] Test cases need to be added
- [ ] Documentation
- [ ] Changelog
# Issue/feature addressed
*Please provide a description of the problem your changes address. Be sure to link to any related items in the issue tracker.*
# Proposed solution
*A summary of the proposed changes and how they address the issue/feature at hand. Whenever possible, describe alternatives your considered and decisions you made.*
# Implementation
*A more detailed description of the changes. Please include any details necessary for reviewers to understand your work, and point out particular points would like them to pay particular attention to.*
## 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.
- [ ] Newly added files are correctly formatted.
- [ ] License added to any new files.
- [ ] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0Dave MoxeyJames SlaughterDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1325Draft: TensorRegions core data structures2024-01-16T22:36:12ZChris CantwellDraft: TensorRegions core data structures# Issue/feature addressed
Nektar++ currently supports solving PDEs in up to three dimensions. Some problems, such as the Vlasov-Poisson equation in modelling plasma kinetics, requires the solution of a higher-dimensional PDE in a potenti...# Issue/feature addressed
Nektar++ currently supports solving PDEs in up to three dimensions. Some problems, such as the Vlasov-Poisson equation in modelling plasma kinetics, requires the solution of a higher-dimensional PDE in a potentially six-dimensional position-velocity space. A natural solution to this is to construct a finite element space as a tensor-product of our existing lower-dimensional finite element spaces.
# Proposed solution
Implementation of a TensorRegions library, which represents a finite element space on a tensor-product of lower-dimensional finite element spaces (from MultiRegions). This MR provides the initial groundwork for this library, including the core data structures.
# Implementation
There are two core classes in the proposed TensorRegions library:
* `TensorRegion`, which encapsulates the high-dimensional finite element space;
* `TensorStorage`, which encapsulates the storage of a solution on such a space.
The `TensorStorage` class has a subclass `TensorStorage::View`, which allows one to operate on the data along a particular _slice_ of the high-dimensional space (corresponding to one of the lower-dimensional spaces). There is also the ability to extract the data (of type `Array`)from the view, as well as inject data back into the higher-dimensional storage.
## Tests
TODO
# Notes
This MR corresponds to deliverable D1.1 for the UKAEA project on solving high-dimensional plasma kinetics in Nektar++.
# Checklist
- [X] Functions and classes, or changes to them, are documented.
- [ ] User guide/documentation is updated.
- [ ] Changelog is updated.
- [ ] Suitable tests added for new functionality.
- [X] Newly added files are correctly formatted.
- [ ] License added to any new files.
- [ ] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1548Draft: Feature/cad reconstruction2024-01-12T14:44:57ZKaloyan KirilovDraft: Feature/cad reconstruction# Issue/feature addressed
*Please provide a description of the problem your changes address. Be sure to link to any related items in the issue tracker.*
# Proposed solution
*A summary of the proposed changes and how they address the iss...# Issue/feature addressed
*Please provide a description of the problem your changes address. Be sure to link to any related items in the issue tracker.*
# Proposed solution
*A summary of the proposed changes and how they address the issue/feature at hand. Whenever possible, describe alternatives your considered and decisions you made.*
# Implementation
*A more detailed description of the changes. Please include any details necessary for reviewers to understand your work, and point out particular points would like them to pay particular attention to.*
## Tests
# Suggested reviewers
*Please suggest any people who would be appropriate to review your code.*
# 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](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- [ ] License added to any new files.
- [ ] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1784Implement implicit time-discretization in SWE solvers2024-03-27T11:50:24ZJacques XingImplement implicit time-discretization in SWE solvers# Issue/feature addressed
- Implement implicit time-stepping (JFNK) for SWE
- Move `CopyBoundaryTrace` from base class to LinearSWE
- Add `const` keyword when appropriate
- Remove unused function `WallBoundary`
# Proposed solution
# ...# Issue/feature addressed
- Implement implicit time-stepping (JFNK) for SWE
- Move `CopyBoundaryTrace` from base class to LinearSWE
- Add `const` keyword when appropriate
- Remove unused function `WallBoundary`
# Proposed solution
# Implementation
## Tests
# Suggested reviewers
*Please suggest any people who would be appropriate to review your code.*
# Notes
*Please add any other information that could be useful for reviewers.*
# Checklist
- [x] Functions and classes, or changes to them, are documented.
- [ ] User guide/documentation is updated.
- [x] Changelog is updated.
- [ ] Suitable tests added for new functionality.
- [x] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- ~~[ ] License added to any new files.~~
- [x] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0https://gitlab.nektar.info/nektar/nektar/-/merge_requests/1757Draft: ProcessBL new implementation that retains both face(FaceNodes) and edg...2024-02-23T14:30:12ZKaloyan KirilovDraft: ProcessBL new implementation that retains both face(FaceNodes) and edge (EdgeNodes) curvature.# Issue/feature addressed
The legacy implementation of the ProcessBL directly threw away/deleted the face curvature (faceNodes) and relied on propagating only the edge curvature (EdgeNodes). This significantly deteriorates the geometrica...# Issue/feature addressed
The legacy implementation of the ProcessBL directly threw away/deleted the face curvature (faceNodes) and relied on propagating only the edge curvature (EdgeNodes). This significantly deteriorates the geometrical accuracy of the meshes, especially in regions with high or non-uniform curvature. Additionally, this creates a very high lower bound of the geometrical error of the isoparametric surface, that does not improve even if a very high-order polynomial mesh is chosen, since no face-nodes are present. The legacy implementation will also not warn the user if a pyramid is present in the mesh and will spit out a non-conformal mesh.
# Proposed solution
A completely new implementation of the module was developed, which retains the input same parameters and the fundamental methodology as proposed in Moxey et all (2015). A local split of the isoparametric prism is performed in the reference space of the element and curvature is propagated to the user-chosen settings. Both the EDGENODES, but now also the FACENODES are propagated according to the user-defined number of layers and progression ratio (r).
Summary from user perspective:
- The same user config options are retained (nq,r,surf,layers).
- The user should NOT see any difference between using this or the legacy ProcessBL for prisms.
3D:
- Supports complete O-type BLs prisms meshes for 3D.
- Warns the user if Pyramid is present.
- NO Hex splitting is implemented. I have not tested it but I believe the legacy module have it.
2D:
- NO CHANGE in the 2D implementation.
- Supports quad splitting, but also has some triangular splitting maps present ( no difference in the implementation.)
# Implementation
0. The first part of the legacy code, where the subset of elements relevant to the user chose composites is kept as the legacy code.
1. Create a copy vector of the edges inside the PrismLayer (remember this will be split).
2. Perform isoparametric edge splitting and fill the PrismEdgesCopy with the desired BL distribution and correct directionality
2.1 Create the edge expansion
2.2 Split the macro edge with the bl distribtion and create new child vertices
2.3 creates a copy of the Macro Edge that contains the new(split) vertices (on the curved master edge) as EdgeNodes having edgeType - eBoundaryLayerPoints/Rev
3. Loop over the prism elements on the surface and Split locally on the desired surfaces/composites (as per 0.)
3.0 Create the expansion of the Macro Prism Element
3.1 Identify the orientation of the prism with respect to the surface (face 1 or face 3 point the boundary)
3.2 Create Vector of Vertices for the Copy Edges - always starting from the Boundary/Curved Face !
3.3 Create HO Elements starting from m_n1 !!!
3.3.1. Create the NodeList
3.3.2 Create the Linear Element
3.3.3 For the inner layers create HO EdgeNodes, Populate edge nodes to the correct predefined new local edges OR reuse the existing macro edges if layer 0
3.3.4 Populate the facenodes to the new local faces by using the MACRO element expansion ( physeval) xp[1] comes from the bl settings.
3.3.5 For the first or last layer try to reuse edges and Face directly from el_macro
3.4. For the first layer - create the m_element[2] triag or quad and put in the correcct composite.
3.4 Add the element in m_mesh->m_element[3]
## Tests
All ProcessBL tests look for completion. A more precise test will be creating a composite test with the geometrical accuracy module created for ICOSAHOM, this will be TBD.
New tests c:
- Semi-sphere
- NACA0012
- IFW_extruded50mm
# Suggested reviewers
@mgreen , @dmoxey
# Notes
*Please add any other information that could be useful for reviewers.*
# Checklist
- [x] Functions and classes, or changes to them, are documented.
- [x] User guide/documentation is updated.
- [ ] Changelog is updated.
- [ ] Suitable tests added for new functionality.
- [ ] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- [x] License added to any new files.
- [x] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0Mohsen LahootiMohsen Lahootihttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1751New feature for ProcessJac in NekMesh. Output Jacobian information on the scr...2024-03-13T13:43:26ZJingtian ZhouNew feature for ProcessJac in NekMesh. Output Jacobian information on the screen and into the log file# Issue/feature addressed
*Histogram now can be plotted internally in ProcessJac of NekMesh. The Jacobian information, element IDs, connected boundary surface/edge IDs, coordinates of vertex are outputted into a text file*
# Proposed so...# Issue/feature addressed
*Histogram now can be plotted internally in ProcessJac of NekMesh. The Jacobian information, element IDs, connected boundary surface/edge IDs, coordinates of vertex are outputted into a text file*
# Proposed solution
*A new option called "histo" is available to the user, which takes three value: The maximum value of Jacobian to be plotted, the number of positive bins in the histogram, the number of negative bins in the histogram. The Jacobians below the threshold will be counted and a histogram will be plotted on the screen. This helps the user to check the quality of the mesh visually. The Jacobian information, element IDs, boundary surface/edge IDs, vertex coordinates, neighbor element IDs will also be outputted into a text file. The text file can also be further used to create a histogram picture by a python script.*
*Another option called "quality" is introduced, which will show the distribution of Jacobians on the screen including the percentage of each bin of on-screen histogram. This helps the user to check the quality of the mesh in detail.*
# Implementation
*The users can now use the following command to plot a histogram of Jacobian on the screen and output a text file with Jacobian information:*
![Command_histo](/uploads/caf33ccfb5a26cda3e25faa8c8514199/Command_histo.png)
*The x-axis of the histogram is the Jaobian, and the y-axis of the histogram is the number of elements. Option "histo" takes three values, separated by a comma. "value1" defines the maximum value of the Jacobian shown on the histogram. In other words, only elements with Jacobian below "value1" will be counted and will be shown on the histogram and will be outputted to a text file. "value2" is the number of bins with positive Jacobian values on the histogram. "value3" is the number of bins with negative Jacobian values on the histogram. The width of each bin is determined by "value1" and "value2": "value1/value2". The maximum value of the histogram is "value1", while the minimum value of the histogram is: "(value1/value2)\*value3". It should be noted that the elements with Jacobian smaller than the minimum value will also be counted and be classified into the left-most bin. By default, the three values are 1,10,1. This means that the default histogram shows the Jacobian between 0.0 and 1.0, with a interval 0.1, and all the other elements with a Jacobian smaller than 1 will be counted and shown on the left-most bin with a name "invalid".*
*"histofile" is an option to set the name of the outputted file with jacobian information. By default, the name of the text file with Jacobian and other elemental information is "jacs.txt"*
*"detail" is another option which will also calculate the composite name and ID of each element in the outputted text file. This process takes long time when the mesh is big and not all the user need this information. And therefore this function is added using another tag.*
*Note that the output.xml is now updated, only the elements with Jacobian smaller than the threshold "value1" will be outputted. This will further help the user to find the elements with a bad quality.*
*The users can now use the following command to show the distribution of jacobians on the screen:*
![Command_quality](/uploads/593d7aed09a6c8bef0d7084eec5b38d6/Command_quality.png)
*This function will list the distribution of the jacobian in the histogram, including the percentage of each bin. This can be regarded as the text description of the histogram, and therefore, the results of "quality" will correspond to the histogram. If "histo" is not set by user, the "quality" will follow the default value of "histo" and show the distribution between 0.0 and 1.0 with an interval 0.1.*
*"quality" also calculate the integration of Jacobians using the following equation:*
$$\frac{\sum_{i=1}^{N}\sum_{j=1}^{Q_i}w_jJ_j*J_{Scaled_i}}{\sum_{i=1}^{N}\sum_{j=1}^{Q_i}w_jJ_j}$$
*$N$ is the number of elements of the mesh and $Q_i$ is the number of quadrature points in each element, $\omega_j$ is the weight function and $J_j$ is the Jacobian of the mapping from reference space to the physical space. The denominator is the area(volume) of the mesh. The $J_{scaled}$ is the scaled Jacobian of each element, calculated by the ratio between the minimum Jacobian of all the quadrature points and the maximum Jacobian of all quadrature points. The $J_{scaled}$ is a variable below 1.0, and will be smaller than zero when tangled, and all the Jacobians on the histogram and the outputted file are also calculated this way. The more $J_{scaled}$ is closer to 1.0, the better the mesh quality is. Therefore the above ratio is a value between 0.0% and 100% which evaluate the quality of the mesh.*
## Tests
# 1. 2D half circle test
*The default results of this module is tested first, using the following command:*
<img src="/uploads/01937f32bf4623ee405d83d842469d4e/Command_ring_default.png">
*The results on the terminal screen are shown in the following picture, which is the default setting of option "histo" and "quality".It is seen that the histogram is shown on the screen, with a default scale between (0.0, 1.0). The elements with negative Jacobians are classified into one bin named as invalid. The information below the histogram is the results of quality, which is a text description of the histogram. It shows the percentage of each bin. At the end of the module, the Worst Jacobian is shown and the integration of the Jacobian over the whole mesh is calculated.*
<div align="center"><img src="/uploads/42313e6d842aed6d5bffb2439e9d46bd/histo_default.png" width="60%"></div>
*Below is the outputted Jacobian information file. The first three columns are ID of elements, Jacobian value of each element, element type. If this element is connected to a boundary, the boundary edge(face for 3D) ID will also be shown, following which is the vertex IDs and coordinates of each edge. When we have a bad element with a small Jacobian, these info can help the user to find the location of this element and find the edge and vertex IDs easily. As we set the "detail" option, the composite ID and name are also shown. The last column is the Id of the neighbor elements of each element. The information of each element is divided by "===" symbols for readability. As we set "histofile" to "output.txt", the name of the text file is modified instead of the default one.*
<div align="center"><img src="/uploads/b921d53f4dd07a5935fdc1f11860fa90/ring_default_output.png"></div>
*Another case with the same mesh using different "histo" values are also tested. The command we use is listed below. *
![Command_ring](/uploads/2e0f4621867883fdae7629d09d7b52c5/Command_ring.png)
*The maximum Jacobian we evaluated is set to 0.2, and the number of positive bins are 3, and the number of negative bins are 2. The screenshot is listed below. It is seen that only elements with a Jacobian below 0.2 is counted. There are 3 positive bins and 2 negative bins. The width of each bin is (0.2/3). The results of quality match that of the histogram.*
<div align="center"><img src="/uploads/aea52a33610939a4fa2fdd3b52a0a8a8/histo_ring.png" width="60%"></div>
*The output file of this command is also listed. Only the elements with Jacobian lower than 0.2 are outputted, which match the "histo" setting.*
![ring_output](/uploads/946a002ee218aea4c8f62f406bb042bc/ring_output.png)
# 2. 3D half sphere test
*The default results using the following command are as follows:*
![Command_sphere_default](/uploads/c71d5f67e477faceb5763f68c88f5001/Command_sphere_default.png)
*The screenshot is listed below. The results of 3D are similar to that of 2D half circle, and are not described in detail here.*
<div align="center"><img src="/uploads/75ab55dac4ae4ab68411a47a73a9a9b2/sphere_default.png" width="60%"></div>
*The output file is listed below. It can be seen that for 3D meshes, one more column with "boundary face ID" is added, for a tetrahedral element, the boundary face is a triangle and has three boundary edges, the boundary edge IDs and the vertex coordinates of them are also shown. In this case the composite name of the mesh is not set during generation, and is shown as NONE instead.*
<div align="center"><img src="/uploads/76b0152a364d0506e4a8dd6faa64d2fb/sphere_Output_default.png" width="80%"></div>
*Another case with the same mesh using different "histo" values are also tested. The command we use is listed below.*
![Command_sphere](/uploads/7bf88b74de4fd64a7e1136a424505f92/Command_sphere.png)
*The results on the screen are below. The histogram is separated with 3 positive bins and 2 negative bins. It is seen that we only have 2 elements which has a Jacobian below 0.5. The results of quality also match the histogram.*
![sphere_histo](/uploads/bdc635a3f9091cf9230323392d8d6ac9/sphere_histo.png)
*The output file is shown below. There are only two elements outputted and one of them is connected to a boundary and the boundary surface , edge, and vertex info are also outputted.*
![sphere_output](/uploads/8a130a65e3ccb9dd832573c1f7b3179c/sphere_output.png)
# Suggested reviewers
*Please suggest any people who would be appropriate to review your code.*
# Notes
*Please add any other information that could be useful for reviewers.*
# Checklist
- [x] Functions and classes, or changes to them, are documented.
- [x] User guide/documentation is updated.
- [x] Changelog is updated.
- [x] Suitable tests added for new functionality.
- [ ] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- [x] License added to any new files.
- [ ] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0Mashy Greenmashy.green@kcl.ac.ukMashy Greenmashy.green@kcl.ac.ukhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1740Fix windows warnings2024-01-27T16:28:20ZChris CantwellFix windows warnings# Issue/feature addressed
Clean up some compiler warnings from the Windows build.
# Proposed solution
Adjust code to avoid ambiguous statements, or adjust logic to avoid
# Checklist
- [X] Functions and classes, or changes to them, are...# Issue/feature addressed
Clean up some compiler warnings from the Windows build.
# Proposed solution
Adjust code to avoid ambiguous statements, or adjust logic to avoid
# Checklist
- [X] Functions and classes, or changes to them, are documented.
- [X] User guide/documentation is updated.
- [ ] Changelog is updated.
- [X] Suitable tests added for new functionality.
- [X] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- [X] License added to any new files.
- [X] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1725Draft: Remove dealiasing in UnsteadyAdvection solver2024-01-12T14:32:45ZJacques XingDraft: Remove dealiasing in UnsteadyAdvection solver# Issue/feature addressed
Dealiasing should not be necessary for linear advection. This MR suggest to remove the dealiasing provision in the UnsteadyAdvection solver.
# Proposed solution
# Implementation
## Tests
# Suggested reviewer...# Issue/feature addressed
Dealiasing should not be necessary for linear advection. This MR suggest to remove the dealiasing provision in the UnsteadyAdvection solver.
# Proposed solution
# Implementation
## Tests
# Suggested reviewers
*Please suggest any people who would be appropriate to review your code.*
# Notes
*Please add any other information that could be useful for reviewers.*
# Checklist
- [x] Functions and classes, or changes to them, are documented.
- ~~[ ] User guide/documentation is updated.~~
- [x] Changelog is updated.
- ~~[ ] Suitable tests added for new functionality.~~
- [x] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- ~~[ ] License added to any new files.~~
- [x] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0Spencer SherwinSpencer Sherwinhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1721Draft: Add AvectionVelocityWvaluator, enable time dependand and time interpol...2024-02-09T14:42:27ZStanislaw GepnerDraft: Add AvectionVelocityWvaluator, enable time dependand and time interpolated advection velocity# Issue/feature addressed
This enables time-dependent Advection Velocity in the ADR solver. Advection Velocity can be either typed in in a session file, marked as `USERDEFINEDTYPE="TimeDependent"`, or it can be read from a sequence of `...# Issue/feature addressed
This enables time-dependent Advection Velocity in the ADR solver. Advection Velocity can be either typed in in a session file, marked as `USERDEFINEDTYPE="TimeDependent"`, or it can be read from a sequence of `/fld` files.
# Proposed solution
Copy @ccantwel solution for the Floquet analysis from the Incompressible solver. Eventually, if the MR approved the same approach should be used there, so time interpolation is performed by the same class.
# Implementation
## Tests
# Suggested reviewers
@ccantwel @CFD-Xing
# Notes
# Checklist
* [x] Functions and classes, or changes to them, are documented.
* [x] User guide/documentation is updated.
* [x] Changelog is updated.
* [ ] Suitable tests added for new functionality.
* [ ] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
* [x] License added to any new files.
* [x] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0https://gitlab.nektar.info/nektar/nektar/-/merge_requests/1702PerAlign extension for all types of meshes2024-03-23T10:25:04ZKaloyan KirilovPerAlign extension for all types of meshes# Issue/feature addressed
This is an extension to the PerAlign module that allows running meshes with Nektar++ that need periodicity in the boundary conditions. The legacy module has some very strict limitations that practically do not ...# Issue/feature addressed
This is an extension to the PerAlign module that allows running meshes with Nektar++ that need periodicity in the boundary conditions. The legacy module has some very strict limitations that practically do not fully support runs with meshes other than Hex. If Tets or Prisms are in the mesh the Incompressible solver will correctly throw away an error on the initialization of solver run, whereas for full hex mesh, it will not stop the user to run, but the results will be noisy on the periodicities.
The legacy state is as follows:
- Fully Hex meshes
* Working fine for fully hex meshes.
* Can be called as two separate calls to the ProcessModule also directly on the HO mesh.
* The reason for that it that it does need the "orient" flag, which calls Module::ReorderPrisms.
* Guglielmo has already ran successfully LES/DNS cases with the module and GMSH.
- Fully Tetrahedral meshes
* Working fine with a single periodic pair only on the linear mesh. The module throws away all HO information of the Tets.
* NOT working if you would like to impose multiple periodic pairs in a single module call.
* NOT possible to give multiple inputs.
* NOT useful to run multiple times the command : you need to pass "orient" flag, hence ReorderPrisms will delete all vertex IDs.
- Hybrid Tet-Prism meshes
* Same as fully Tet +
* NOT working if ran on a wall that has prism quad faces attached to it and PerAlign ran on the linear mesh. After the prisms are split ( both with the legacy and the new ProcessBL) the expansion orientations are not consistent.
* NOT keeping the full HO-information. Keeps only the EdgeNodes ( Face Curvature nodes are thrown away in Module::ReorderPrism).
# Proposed solution
Current functionalities (New Functionalities)
* Added functionality to be able to add multiple surface pairs as an option to the module ProcessPerAlign.
* Added functionality to run with multiple surface pairs ( max 3 at the moment - we can make it a variable) in Module::ReorderPrisms()
* Fully Tetrahedral meshes
* Working fine with a single or multiple periodic pairs only on the linear mesh.
* Working if you would like to impose multiple periodic pairs in a single module call.
* Made it Possible to give multiple inputs.
* NOT useful to run multiple times the command : you need to pass "orient" flag, hence ReorderPrisms will delete all vertex IDs.
* Hybrid Tet-Prism meshes
* Same as fully Tet +
* Working if ran on a wall that has prism quad faces attached to it and PerAlign ran only on the FINAL HO Mesh.
* NOT keeping the full HO-information. Keeps only the EdgeNodes ( Face Curvature nodes are thrown away in Module::ReorderPrism) .
# Implementation
* ProcessPerAlign
* allow m_config to input a vectors of surface pairs in
* EXsurf1 = 2,3 : surf2=5,6 - It will create two periodic pairs than could have completely different periodicity configurations: EX: First pair between surfaces 2 and 5. Second pair between surfaces 3 and 6.
* In order to separate calls for the orient (rotational periodicity) or dir (translational) I have introduced a token separator "!". That is not ideal but the only one I could find working both in Bash (no separate variable created) and C++ since we need to allow the use of both "x,y" as directions and unit vector one "1.0,0.0,1.0" in a single m_config call.
* EX: -m peralign:surf1=3,8:surf2=5,9:dir=y!0.0,0.0,1.0 - This way the first pair(composites 3,5) will take direction "y" and the second pair (8,9) will take "z", but defined as .
* I tried to keep the core part of the module as it is. Hence the algorithm on pairing centroids of the boundary faces is not really changed.
* Splits the pair commands
* Creates a for loop around the periodic Surface Pairs (pIt) to push back in a single perFace, which is then passed as an argument to orient
* **I introduced a final entry to every perFace vector\<int\> list denoting the pairID, which allows me to filter the pairID afterwards in Module::ReorderPrisms().**
* In the end of the every surface pair Boundary composite is rearanged as required in Nektar++ ( no vID are changed here)
* Module::ReorderPrism(perFaces)
* As beforee all vertex IDs are -1 .
* As discussed in the meeting - first we give IDs to the periodic vertices( from perFaces) . However:
* Added an extra loop on top of the elements and running it sequentially based on the pairID. This is where the vertices Since this is a massive unoredered map, the pairID are mixed. Moreover, the corner vertices where the two pairs are done simultanously will become inconsistent if both pairID are giving vertex IDs. This way the expansion are consistent in my test-cases.
* Added a check in the end if there are vId=-1 . This will be useful if there are also to spot pyramids.
## Tests
I have a 3D NACA0012 mesh that I can run with the Incompressible solver for 10 timesteps in 4 (Hex/ Tet/ 2xTet-Prism) different configurations to ensure it is possible. I am not sure how to add these multistage test like:
1. Create the mesh
2. Run the solver
3. Analyze if results continuous
# Suggested reviewers
@mgreen @dmoxey
# Notes
In order to test that PerAlign works properly, a solver running on a produced periodic meshe is required. To accommodate this additional testing requirement, some changes to Tester were introduced that allow to run sequential tests from a .tst file. These changes are not directly related to issue this MR addresses and in hindsight could be seperated to another MR. If there is no objection it will stay here, however if it makes the review simpler to take them out and create a separate MR for Tester we could do that.
# Checklist
* [x] Functions and classes, or changes to them, are documented.
* [ ] User guide/documentation is updated.
* [x] Changelog is updated.
* [x] Suitable tests added for new functionality.
* [ ] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
* [x] License added to any new files.
* [x] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0Spencer SherwinDave MoxeySpencer Sherwinhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1664Draft: Add synthetic turbulence generation for the incompressible solver2024-02-06T10:40:00ZJoão IslerDraft: Add synthetic turbulence generation for the incompressible solver# Issue/feature addressed
In this merge request, the Synthetic Eddy Method (SEM) based on the source term formulation is implemented. In this formulation, the user can inject eddies in any part of the domain, not only in the inlet bounda...# Issue/feature addressed
In this merge request, the Synthetic Eddy Method (SEM) based on the source term formulation is implemented. In this formulation, the user can inject eddies in any part of the domain, not only in the inlet boundary condition as most methodologies do. The eddies are created by defining an synthetic eddy region (box of eddies) which the parameters are provided in the xml file.
# Proposed solution
The SEM was implemented as a forcing term. Firstly, the forcing term is applied taking into account all the eddies using the superposition principle, so that all eddies are injected in the first time step. Then, the eddies are convected downstream. When one or few eddies leave the domain, they are reintroduced in the inlet plane of the synthetic eddy region. In order to re-inject them, the forcing term is again applied only for the eddies that left the outlet plane of the box created. Thus, this mechanism re-energise the system. The number of eddies added in the domain are based on the parameters provided by the user.
# Implementation
The SEM forcing term was implemented as a derived class of the `Forcing` class. The name of the new derived class is `ForcingIncNSSyntheticEddy`. The main functions of this method are described below
- `ComputeStochasticSignal()` - This function computes the stochastic signal based on gaussian functions (shape functions).
- `ComputeVelocityFluctuation()` - This function calculates the velocity fluctuation by multiplying the Cholesky decomposition of the Reynolds Stresses and the stochastic signal.
- `UpdateEddiesPositions()` - This function updates the position of the eddy in each time step and checks if the eddy left the synthetic eddy region. In case the eddy leaves the eddy, it is reintroduced close to the inlet plane of the synthetic eddy region.
- `CalculateForcing()` - This function calculates the forcing term to be applied in the synthetic eddy region.
## Tests
The test case below was added
1. `solvers/IncNavierStokesSolver/Tests/ChanFlow3D_infTurb.xml`
- This test case checks the space-dependent Reynolds stresses, anisotropic synthetic turbulence generation and also the re-injection of eddies after they leave through the outlet plane of the synthetic eddy region (box of eddies). Note that additional code was implemented to deal with the test case since eddies could not be randomly generated in the synthetic eddy region for a test case.
# Notes
Most of the SEM code is similar for the incompressible and compressible solvers. So, when the compressible version is ready to be merged, the code that can be shared for both solvers must be moved to another class.
Note that, in the merge request, the SEM only supports fully three-dimensional incompressible simulations.
# Checklist
- [x] Functions and classes, or changes to them, are documented.
- [x] User guide/documentation is updated.
- [x] Changelog is updated.
- [x] Suitable tests added for new functionality.
- [ ] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- [ ] License added to any new files.
- [ ] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0Spencer SherwinSpencer Sherwin