Nektar merge requestshttps://gitlab.nektar.info/nektar/nektar/-/merge_requests2024-03-27T11:18:35Zhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1761Some further tidy-up in linear solver and complete second Frechet derivative ...2024-03-27T11:18:35ZJacques XingSome further tidy-up in linear solver and complete second Frechet derivative implementation# Issue/feature addressed
- This MR complete the implementation of second-order Frechet derivate for the JFNK solver of the compressible flow solver
- Use (consistently) minimum tolerance of 1.0E-16 in linear solve.
- Use `JacobiFreeEps ...# Issue/feature addressed
- This MR complete the implementation of second-order Frechet derivate for the JFNK solver of the compressible flow solver
- Use (consistently) minimum tolerance of 1.0E-16 in linear solve.
- Use `JacobiFreeEps = sqrt(NekConstants::kNekMachineEpsilon)` for consistency with publication
- Rename `blas.cpp` as `Blas.cpp`
- Remove unused argument `const NekDouble factor` from `NekSys.h` class and subclasses
- Move member variables specific to GMRES from `NekLinSysIter.h` to `NekLinSysIterGMRES.h` and `NekLinSysIterGMRESLoc.h`
- Output both `Res/Res0` and `Res/DtRHS` in Newton solver
- Use member variable `m_converged` in `ConvergenceCheck`
# 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.
- [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)).
- ~~[ ] 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/1770Provide an optimal expansion list ordering for collection operation2024-03-26T15:15:04ZSpencer SherwinProvide 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 n...# 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
- [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)).
- ~~[ ] 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/1380Add some functions to SessionReader's Python interface2024-03-25T08:24:12ZOwen ParryAdd some functions to SessionReader's Python interface# Issue/feature addressed
When analysing a simulation in Python, it's useful to be able to retrieve the variable names and parameter values that were set in a session.
# Proposed solution
Add 'GetParameters' and 'GetVariables' functions...# Issue/feature addressed
When analysing a simulation in Python, it's useful to be able to retrieve the variable names and parameter values that were set in a session.
# Proposed solution
Add 'GetParameters' and 'GetVariables' functions to SessionReader's Python interface.
# Implementation
The two functions populate a boost::python::dict and a boost::python::list respectively, rather than using map_indexing_suite and map_indexing_suite to do the conversions. I'd argue that having slightly uglier code on the c++ side is a price worth paying for returning native Python containers (that come with a sensible \_\_str\_\_() method built in, for example), but I'm happy to change it if others disagree!
## Tests
None added.
# 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.
- [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/1779Fix Summary output2024-03-22T14:10:26ZJacques XingFix Summary output# Issue/feature addressed
Fix Summary output in EquationSystem. Bug was introduced during MR !1605.
# Proposed solution
# Implementation
## Tests
# Suggested reviewers
*Please suggest any people who would be appropriate to review you...# Issue/feature addressed
Fix Summary output in EquationSystem. Bug was introduced during MR !1605.
# 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
- ~~[ ] 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.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1605Add sliding mesh capability2024-03-21T15:39:23ZChris CantwellAdd sliding mesh capability# Issue/feature addressed
Implement the ALE method for sliding mesh with rotating, sliding, and prescribed motions in `ADRSolver` and `CompressibleFlowSolver`.
# Proposed solution
- `Nektar::SolverUtils::ALEHelper` was added to implemen...# Issue/feature addressed
Implement the ALE method for sliding mesh with rotating, sliding, and prescribed motions in `ADRSolver` and `CompressibleFlowSolver`.
# Proposed solution
- `Nektar::SolverUtils::ALEHelper` was added to implement the ALE method.
- New class members `m_gridVelocity` and `m_gridVelocityTrace` were introduced.
- Add a flag `m_ALESolver` for the ALE method.
# Implementation
In order to introduce grid velocity, the function `ALEHelper::InitObject` was utilized to initialize the variables `m_gridVelocity` and `m_gridVelocityTrace`. As the mass matrix undergoes changes during the ALE process, the function `ALEHelper::ALEPreMultiplyMass` is employed to perform mass matrix multiplication. `ALEHelper::ALEDoElmtInvMass` and `ALEHelper::ALEDoElmtInvMassBwdTrans` were used to attain the variables in coefficient and physical space, respectively. To perform movement, `ALEHelper::MoveMesh` was used to call `Movement::PerformMovement`.
## Tests
In `ADRSolver`
- Movement_rotate_3D_stacked_cylinders_curved_par
- Movement_translate_interfaces232_dirichlet
In `CompressibleFlowSolver`
- Movement_rotate_couette
# Suggested reviewers
Chris, David
# Notes
- There are issues with `ALEHelper::InitObject` called in `SolverUtils::UnsteadySystem` when using CG projection and the pulse wave solver. There needs to be a redesign to address this problem.
- Changes in `SolverUtils::Advection::AdvectionWeakDG` and `CompressibleFlowSolver::Diffusion::DiffusionLDGNS` to avoid implicit solver errors may also need to be redesigned.
# 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/1771Removed m_coll_offsets and tidied up UpdateFactor method2024-03-14T14:19:12ZSpencer SherwinRemoved m_coll_offsets and tidied up UpdateFactor method# Issue/feature addressed
Array of offsets for collections are no longer required in ExpList
# Proposed solution
Remove m_coll_phys_offset and m_coll_coeffs_offset arrays in ExpList. It was also being used in UpdateFactor in Collections...# Issue/feature addressed
Array of offsets for collections are no longer required in ExpList
# Proposed solution
Remove m_coll_phys_offset and m_coll_coeffs_offset arrays in ExpList. It was also being used in UpdateFactor in Collections so have removed that argument from this function. Finally there were alot of unnecssary virtual instances of UpdateFactor so removed these and changed the function pure virtual to an ordinary virtual function
# Implementation
As above
## Tests
# Suggested reviewers
Dave wanted this done so have put him down.
# 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.0Jacques XingJacques Xinghttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1379Add VTK links to Python bindings2024-03-14T11:26:11ZDave MoxeyAdd VTK links to Python bindings# Issue/feature addressed
This branch adds VTK support to the Python bindings, which necessitates adjustment of `FieldUtils` modules. A `Filter` wrapper is also added as a method to demonstrate and test the additions.
# Proposed solutio...# Issue/feature addressed
This branch adds VTK support to the Python bindings, which necessitates adjustment of `FieldUtils` modules. A `Filter` wrapper is also added as a method to demonstrate and test the additions.
# Proposed solution
Following from !1343, a function `GetVtkGrid` has been added to the Python wrapper for `Module`. This then allows the VTK grid to be returned when the module object is a `OutputVtk` module. An exception is thrown if either not compiled for VTK or the module is not an instance of `OutputVtk`.
# Implementation
For the VTK output:
- A `prohibitWrite` option has been added to the OutputModule class. This indicates that files should not be written out, but that any processing up to the point of writing should be done. This is done so that Python modules can control when output occurs when calling the `Run` function after a module.
- The `ConvertCommandLine` function, used in several places in the Python wrappers, has been refactored into a helper `CppCommandLine` class. This also ensures memory cleanup is done from the C pointers for `argv`.
- A `VTK_PYTHON_CONVERSION` macro has been adapted from the VTK documentation to enable the wrapping of vtk objects within boost.python. This is defined in the `VtkWrapper.hpp` file.
- The `Field` class has a new function `SetupFromExpList` which facilitates easier construction of Field objects programatically from both Python and C++.
For Filters:
- Filter wrapper has been added in a way such that filters can be defined in Python as a subclass, and registered with the C++ factory. This follows the same approach used in `NekMesh` and `FieldUtils`.
- Minimal wrappers have been added for `EquationSystem`, since this is passed as a `weak_ptr` to the `Filter` constructor.
- To get `weak_ptr` to work with boost.python, a block of code has been added in `NekPyConfig.hpp`: this adjusts the mechanism which uses `shared_ptr<void>` with customer deleter, since this doesn't then allow for conversion from `weak_ptr`.
- A `FilterPython` has been added which serves as a way to usefully use the Filter wrappers. This is documented in the user guide.
## Tests
- Unit tests have been added for the new `Filter` wrappers.
- A `FilterPython` test has been added to ADRSolver, which uses the `FieldUtils` wrapper and the `Filter` wrapper to write VTK files as checkpoints.
- A demo for reading a mesh and creating an image using the VTK Python bindings has been included.
# 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).
**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.0Jacques XingJacques Xinghttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1766Faster matrix (re)-building for LinearADR problems2024-02-23T14:13:50ZHenrik WustenbergFaster matrix (re)-building for LinearADR problems# Issue/feature addressed
Currently, a LinearADR problem always rebuilds elemental Mass and Laplacian matrices. This causes an overhead of about 30% for VCSImplicit simulations at large scale and is only required if Mass and Laplacian ma...# Issue/feature addressed
Currently, a LinearADR problem always rebuilds elemental Mass and Laplacian matrices. This causes an overhead of about 30% for VCSImplicit simulations at large scale and is only required if Mass and Laplacian matrices are time-dependent through `varcoeffs`.
# Proposed solution
This fix adds a check for conditional updating of Mass and Laplacian matrices to the LinearADR option in the CreateMatrix function for `Expansion2D` and `Expansion3D`.
# Implementation
An if condition that checks whether the massVarcoeffs or laplacianVarcoeffs map is empty.
## Tests
- We would need to have a memory-constraint test environment. Still, I am running this fix on large-scale simulations and do not encounter any memory issues.
# Suggested reviewers
@mlahooti
@CFD-Xing
# 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/1762Add 2d projection demo and tests2024-02-16T14:15:08ZTed StokesAdd 2d projection demo and tests# Issue/feature addressed
Previously no test for 2d h-type convergence.
# Proposed solution
Add a demo and test of h-type convergence of a 2d continuous Galerkin projection.
# Implementation
Following MR !1738, the 1D Demos/MultiReg...# Issue/feature addressed
Previously no test for 2d h-type convergence.
# Proposed solution
Add a demo and test of h-type convergence of a 2d continuous Galerkin projection.
# Implementation
Following MR !1738, the 1D Demos/MultiRegions/Project.cpp has been renamed to Project1D.cpp, and Project2D.cpp has been added, which can use either triangle or quadrilateral elements.
## Tests
Triangle and quadrilateral tests added.
# Suggested reviewers
@dmoxey
# Notes
# 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/1701Add interface for variable coefficients to Collections2024-02-14T13:10:35ZHenrik WustenbergAdd interface for variable coefficients to Collections# Issue/feature addressed
Variable coefficients (`varcoeffs`) can currently not be given to `Collections`-type operators for grouped processing and, also, the `GetInputSize` (and `GetOutputSize`) routine for collections requires a boolea...# Issue/feature addressed
Variable coefficients (`varcoeffs`) can currently not be given to `Collections`-type operators for grouped processing and, also, the `GetInputSize` (and `GetOutputSize`) routine for collections requires a boolean to return the input size in `PhysSpace` or `CoeffSpace` which is necessary for the `varcoeffs`.
# Proposed solution
This branch adds `varcoeffs` to via a `UpdateVarcoeffs` routine which needs to be re-implemented in each operator. Since mostly the Helmholtz operator requires `varcoeffs` this does not require changes in all other operators.
# Implementation
- Renamed `CheckFactors` to `UpdateFactors` because it reflects the action better
- Added `UpdateVarcoeffs` as routine in the `Collections` class and a virtual routine in the `Operator` class
## Tests
Most previous tests that use varcoeffs. In particular the Helmholtz3D tests with variable diffusion
# Suggested reviewers
@CFD-Xing
# 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/1722Tidy up tolerance in NekLinSystIter and NekNonlinSysIter solvers2024-02-14T11:07:25ZJacques XingTidy up tolerance in NekLinSystIter and NekNonlinSysIter solvers# Issue/feature addressed
The main objective of this MR to remove the tolerance argument in `v_SolveSystem` function call in order to use parameters provided from NekSysKey during construction. This reduce confusion about who is responsi...# Issue/feature addressed
The main objective of this MR to remove the tolerance argument in `v_SolveSystem` function call in order to use parameters provided from NekSysKey during construction. This reduce confusion about who is responsible of setting/controlling tolerance and iteration parameters for the linear solvers. Related changes are summarized as follow:
- Remove `GetIterativeTolerance` and related code from `AssemblyMap`
- Rename `NekNonlinSys` as `NekNonlinSysIter` for consistency
- Rename `NekNonlinSysNewton` as `NekNonlinSysIterNewton` for consistency
- Remove virtual functions `ConvergenceCheck` from NekSys.h base class.
- Add specialized (with specific signature) `ConvergenceCheck` function to `NekLinSysIter.h` subclass.
- Add specialized (with specific signature) `ConvergenceCheck` function to `NekNonLinSysIter.h` subclass.
- Remove `m_maxiter` and `m_tolerance` from NekSys.h base class.
- Add `m_NekLinSysMaxIterations` and `m_NekLinSysTolerance ` member variable to `NekLinSysIter.h` subclass.
- Add `m_NekNonLinSysMaxIterations` and `m_NekNonLinSysTolerance ` member variable to `NekNonLinSysIter.h` subclass.
- Move `m_rhs_magnitude` and `SetRhsMagnitude` from `NekLinSysIter.h` to NekSys.h base class.
- Remove redundant `m_LinSysRelativeTolInNonlin` variable.
# 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.
- ~~[ ] 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.0Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1749Fix PFASST I/O and pre-initialize coarse preconditioner for Parareal2024-02-14T10:41:20ZJacques XingFix PFASST I/O and pre-initialize coarse preconditioner for Parareal# Issue/feature addressed
For Parareal, the initialization of the preconditioner on the serial-in-time coarse solver cause significant overhead proportional to the number of time step. This MR also fixes an I/O bug with PFASST.
# Propos...# Issue/feature addressed
For Parareal, the initialization of the preconditioner on the serial-in-time coarse solver cause significant overhead proportional to the number of time step. This MR also fixes an I/O bug with PFASST.
# Proposed solution
Artificially run one step on the coarse solver to initialize the preconditioner for Parareal.
# 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.0Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1756Fix segmentation fault in IncNavierStokesSolver performance test2024-02-11T22:11:35ZJacques XingFix segmentation fault in IncNavierStokesSolver performance test# Issue/feature addressed
The IncNavierStokesSolver performance test segfaults when iolevel is not specified. The reason for this segfault is that the performance test file
`IncNavierStokesSolver/Tests/Perf_ChanStability.tst` is looking ...# Issue/feature addressed
The IncNavierStokesSolver performance test segfaults when iolevel is not specified. The reason for this segfault is that the performance test file
`IncNavierStokesSolver/Tests/Perf_ChanStability.tst` is looking for a regular expression:
```
<metric type="ExecutionTime" id="1">
<regex>^.*Execute\s*(\d+\.?\d*).*</regex>
<value tolerance="5e-1" hostname="42.debian-bullseye-performance-build-and-test">8.96658</value>
</metric>
```
The execution is not outputted when the iolevel is set to the current default value of -1:
# Proposed solution
Set the default iolevel to zero. This will produce the flollowing output
```
Region Elapsed time Avg (s) Min (s) Max (s) Count IO Level
Execute 7.12419 7.12419 7.12419 1 0
Advection Terms 0.455392 0.455392 0.455392 2484 0
Pressure BCs 0.357049 0.357049 0.357049 2484 0
Pressure Forcing 0.350425 0.350425 0.350425 2304 0
Pressure Solve 1.71348 1.71348 1.71348 2304 0
Viscous Forcing 0.324433 0.324433 0.324433 2304 0
Viscous Solve 3.15369 3.15369 3.15369 2304 0
```
## Tests
There is already a test which tests for this regression.
# 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.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1755Add `IsValid` method to NekPy interface2024-02-11T17:41:46ZChris MacMackinAdd `IsValid` method to NekPy interface# Issue/feature addressed
I wanted to be able to check whether a Geometry object is valid (i.e., has a non-negative Jacobian) from Python.
# Proposed solution
A method has been added to the Geometry class exported by NekPy which can pe...# Issue/feature addressed
I wanted to be able to check whether a Geometry object is valid (i.e., has a non-negative Jacobian) from Python.
# Proposed solution
A method has been added to the Geometry class exported by NekPy which can perform this check.
# Implementation
The `GeomFactors` class which actually performs this test is not currently exposed to Python. Rather than implement an entire binding for this, I have just added a small `IsValid` function to the `Geometry` class, which performs the necessary call to `Geometry::GetGeomFactors()`.
## Tests
Calls to this method have been added to the `CreateMesh.py` demo script.
# Suggested reviewers
@dmoxey
# 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.0Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1748Consistently use template parameters in VmathArray2024-02-07T11:21:30ZJacques XingConsistently use template parameters in VmathArray# Issue/feature addressed
The `Vmul` and `Vvtvp` functions in VmathArray assume `NekDouble` variable type for the 2D array argument instead of using the template parameter `T`. This MR fixes this issue.
# Proposed solution
# Implementa...# Issue/feature addressed
The `Vmul` and `Vvtvp` functions in VmathArray assume `NekDouble` variable type for the 2D array argument instead of using the template parameter `T`. This MR fixes this issue.
# 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.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1666Add a new feature of Lagrangian points tracking2024-01-27T13:11:24ZAnkang Gaoankanggao@ustc.edu.cnAdd a new feature of Lagrangian points tracking# Issue/feature addressed
A new filter feature of tracking many Lagrangian points in parallel is implemented. The points are distributed among different threads. MPI communication is used when the Lagrangian point is not found in the loc...# Issue/feature addressed
A new filter feature of tracking many Lagrangian points in parallel is implemented. The points are distributed among different threads. MPI communication is used when the Lagrangian point is not found in the local mesh partition.
This feature can be developed into a particle-laden force. So not sure whether this feature should be placed in the filter or the forcing folder.
# Proposed solution
Points are stored twice. One copy is the stationary points, which are fixed in the thread. Another copy is the mobile points, which can move based on the mesh partition.
When evaluating the physics values on the mobile points, we first search the local mesh partition. For the points that are not found in the local partition, do a global search. Once the thread whose mesh partition contains some unfound mobile points, move these points to the corresponding thread.
After evaluation the physics values on the mobile points, send the data back to thread which contains the corresponding stationary points.
# Implementation
Design of the filter!
![design](/uploads/25b71b7a0e2d44018b97d272dbe709ce/design.jpg)
## Tests
2-D, 3DH1D and 3D tests have been added.
A 2-D example (plunging airfoil with 256 X 128 points) is as follows
![Points_R0000_T000.000000](/uploads/b9e18cb743bf898e3a3313706029b5dc/Points_R0000_T000.000000.png)
![Points_R0000_T001.570796](/uploads/578dcbe60fe70e3bd9a0e98073825dc8/Points_R0000_T001.570796.png)
A 3DH1D example (plunging airfoil with 32 X 32 X 64 points) is as follows
![Points_R00000_T000.000000](/uploads/9d072cbdad3b507f01f1d6815dc52d5d/Points_R00000_T000.000000.png)
![Points_R00000_T000.950000](/uploads/0cf175996631e7984ca411a8b1b4e31a/Points_R00000_T000.950000.png)
The trajectories of sample points are
![trajectory2](/uploads/7da479818a57c397e0d396c09ac16d41/trajectory2.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.
- [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.5.0Spencer SherwinMohsen LahootiSpencer Sherwinhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1672Remove uncompiled C++ files and add CI script to detect2024-01-13T09:11:48ZDave MoxeyRemove uncompiled C++ files and add CI script to detect# Issue/feature addressed
As part of the larger C++17 MR !1427, some uncompiled files were detected. This MR removes these and adds a script to the CI to detect them. This picked up some recently merged files, e.g. those in !1398.
# Pro...# Issue/feature addressed
As part of the larger C++17 MR !1427, some uncompiled files were detected. This MR removes these and adds a script to the CI to detect them. This picked up some recently merged files, e.g. those in !1398.
# Proposed solution
The relevant files have been removed, and a new script `check-compiled-files.py` has been added that uses `compile_commands.json` (used to drive `clang-tidy`) to detect uncompiled files.
# Implementation
The script will search for all C++ and C files with extensions `.cpp` and `.c` within the `library`, `tests`, `solvers` and `utilities` directories. It ignores the following files:
```python
ignore_sources = [
# CADfix API
"library/NekMesh/CADSystem/CFI/CADSystemCFI.cpp",
"library/NekMesh/CADSystem/CFI/CADSurfCFI.cpp",
"library/NekMesh/CADSystem/CFI/CADCurveCFI.cpp",
"library/NekMesh/CADSystem/CFI/CADVertCFI.cpp",
"library/NekMesh/Module/InputModules/InputCADfix.cpp",
"library/NekMesh/Module/OutputModules/OutputCADfix.cpp",
# Likwid
"solvers/CompressibleFlowSolver/Utilities/TimeRiemann.cpp",
"solvers/CompressibleFlowSolver/Utilities/TimeRoeKernel.cpp",
# Template for PWS
"solvers/PulseWaveSolver/EquationSystems/TemplatePressureArea.cpp",
]
```
## Tests
A new runner has been added, and a CI `uncompiled-files-template` has been added (runs on Ubuntu Jammy by default).
# Suggested reviewers
@ccantwel @CFD-Xing
# Checklist
- ~[ ] 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.5.0Jacques XingJacques Xinghttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1351Lower memory footprint when reading field files in HDF5 format for massively ...2024-01-12T14:47:21ZDaniel LindbladLower memory footprint when reading field files in HDF5 format for massively parallel runs# Issue/feature addressed
The HDF5 format for field files (`.fld` files) stores the data in decompositions. Each decomposition represents the data written by one parallel process. Therefore, if the field file was written by 10 processes,...# Issue/feature addressed
The HDF5 format for field files (`.fld` files) stores the data in decompositions. Each decomposition represents the data written by one parallel process. Therefore, if the field file was written by 10 processes, then there will be 10 decompositions. When the field file is read using `FieldIOHdf5::v_Import()`, each process checks which decompositions that it needs to read, and then reads the entire decomposition. Later, the data is filtered such that only elements which are actually needed by the process are retained. If the number of processes that wrote the field file is in the same order as the number of processes that reads it, this strategy works quite well. If, on the other hand, a few processes have written the file, and a very large number of processes reads the file, we run into problems. This is because all processes essentially will read all the data. Hence, the memory consumption scales proportionally to the number of parallel processes that reads the field file. This causes memory problems in massively parallel runs, especially if the amount of memory per node is rather limited, and the field file contains a very large number of degrees of freedom.
# Proposed solution
To solve the above issue, we propose to only read the data that is needed by the process, rather than all the data in one decomposition. In the current file format, the entire solution is stored in a large flat array. This array does in turn contain all the polynomial coefficients for all the elements and variables stored. As noted previously, the data is currently divided into decompositions (by providing offset metadata). Each decomposition does in turn contain the modal data (polynomial coefficients) for each element in that decomposition. If several variables are used (such as the compressible flow solver), then the decomposition will also contain data for each variable. This gives a total of N_variables * N_coeffs_per_element * N_elements_per_decomposition floating point numbers per decomposition. To avoid reading the entire array, which will be quite large if the file was written by a few processes, we use a feature in HDF5 where you only read a selected set of indices. To figure out which indices we should read, we look at the array which the user provides to `v_Import()`, called `ElementIDs`. Previously, this away was only used to decide which decompositions to read, but not to select the elements inside each decomposition to read. In this MR, we solve this issue. This requires us to figure out the offsets into the flat array where the element data is stored. To do this, we first compute the number of modes in each element inside each decomposition. This is done by making a small modification to the routine `FieldIO::CheckFieldDefinition`. Once we know how many modes (polynomial coefficients) that are stored inside each element, we can easily compute the offset. By using the offsets, we can create an array with indices to read. This array is then passed to the HDF5 routines.
# Implementation
Most changes have been added to `FieldIOHdf5::v_Import()` and `FieldIO::CheckFieldDefinition`. In the first routine, the main change is that we have added an if-statement that checks if the user provided an array of element IDs that should be read. If this is the case, then the number of modes in each element is computed using `FieldIO::CheckFieldDefinition`. This requires that the user passes a non-const array to this routine (this was not done before, so it was added), where the number of modes per element is added for each element in the decomposition. Once the number of modes per element is known, it is a matter of computing some offsets, and then read the data. The code that does this should be self-explanatory.
A couple of final notes should be made:
- We currently assume that each variable is stored with the same polynomial order. This might have to be fixed
- If we think that the updated version of `FieldIO::CheckFieldDefinition` is good, we can simplify this routine because we no longer need to differentiate between uniform and variable polynomial order in the new implementation.
- After we did the filtering, we update the local variable `fielddef->m_elementIDs`. However, we don't update the remaining metadata stored in `fielddef`. It might be necessary to do this, especially if a variable polynomial order is used (see comment).
- Before merging, we need to do some cleanup of the code, especially remove redundant parameters to some functions.
## Tests
TBD
# 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.
- [x] Suitable tests added for new functionality.
- ~~[ ] Newly added files are correctly formatted~~.
- ~~[ ] License added to any new files~~.
- [x] No extraneous files have been added (e.g. compiler output or test data files).v5.5.0Daniel LindbladDaniel Lindbladhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1700Some tidy-up in CompressibleFlowSolver and LinearAlgebra2024-01-10T11:18:26ZJacques XingSome tidy-up in CompressibleFlowSolver and LinearAlgebra# Issue/feature addressed
This is an overall tidy-up of CompressibleFlowSolver and LinearAlgebra. Here is a summary of the changes:
- Reorganize `CompressibleFlowSystemImplicit.cpp` for a more consistent file structure.
- Use default key...# Issue/feature addressed
This is an overall tidy-up of CompressibleFlowSolver and LinearAlgebra. Here is a summary of the changes:
- Reorganize `CompressibleFlowSystemImplicit.cpp` for a more consistent file structure.
- Use default keyword for constructor
- ~~Remove unnecessary `SetupNekNonlinSystem` accessors and virtual functions `v_SetupNekNonlinSystem` (see !1709)~~
- ~~Remove unused variable `NekNonlinSysTolerance"` from `NekNonlinSys.h`(see !1708)~~
- Make relevant public functions in `CompressibleFlowSystemImplicit.h` protected
- Change `NewtonAbsoluteIteTol` parameter to `NewtonRelativeIteTol` for consistency
- ~~Remove redundant tolerance limiter in GMRES (see !1707)~~
- Simplify code
# 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
- ~~[ ] 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.5.0Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1728Remove unused file NekLinAlgAlgorithms.hpp2024-01-10T11:07:05ZJacques XingRemove unused file NekLinAlgAlgorithms.hpp# Issue/feature addressed
The `GramSchmidtOrthogonalization` function in `NekLinAlgAlgorithms.hpp` is not used anymore. This MR proposed to remove the unused code.
Note: The modified Gram-Schmidt algorithm is used in the GMRES iterative...# Issue/feature addressed
The `GramSchmidtOrthogonalization` function in `NekLinAlgAlgorithms.hpp` is not used anymore. This MR proposed to remove the unused code.
Note: The modified Gram-Schmidt algorithm is used in the GMRES iterative solver.
# 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.
- ~~[ ] 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.5.0Dave MoxeyDave Moxey