Nektar merge requestshttps://gitlab.nektar.info/nektar/nektar/-/merge_requests2024-03-21T23:49:14Zhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1626Draft: Some tidy-up for ShallowWaterSolver, CompressibleFlowSolver, and ADRSo...2024-03-21T23:49:14ZJacques XingDraft: Some tidy-up for ShallowWaterSolver, CompressibleFlowSolver, and ADRSolver# Issue/feature addressed
Some tidy-up. Partially split from MR !1613.
# Proposed solution
- Move `SVVVarDiffCoeff` from `UnsteadySystem.h` to `UnsteadyViscousBurgers.cpp`
- Delete unused function in `NonlinearPeregrine.cpp`
# Implemen...# Issue/feature addressed
Some tidy-up. Partially split from MR !1613.
# Proposed solution
- Move `SVVVarDiffCoeff` from `UnsteadySystem.h` to `UnsteadyViscousBurgers.cpp`
- Delete unused function in `NonlinearPeregrine.cpp`
# 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/1705Fix to allow the specification of different number of iterations for differen...2023-12-13T13:11:32ZJacques XingFix to allow the specification of different number of iterations for different variable# Issue/feature addressed
In the `NekLinSysIter.cpp` class and subclasses, if `GlobalSysSolnInfo` is use to specify different parameters for different variable, only the parameters corresponding to the first variables blocks are used to ...# Issue/feature addressed
In the `NekLinSysIter.cpp` class and subclasses, if `GlobalSysSolnInfo` is use to specify different parameters for different variable, only the parameters corresponding to the first variables blocks are used to initialize the object in the constructor.
# Proposed solution
Pass as an argument parameter a string containing the variable name in the constructors of `NekLinSysIter.cpp` class and subclasses.
# Implementation
## Tests
The following test has been updated to test the possibility to use different maximum iteration number for different variables
`solvers/IncNavierStokesSolver/Tests/KovaFlow_m10_taylorHood_VCSImplicitLoc.xml`
# 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.5.0Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1339ALE implementation for sliding mesh2023-10-20T13:22:54ZEdward LaughtonALE implementation for sliding mesh# Issue/feature addressed
Movement for sliding mesh.
# Proposed solution
# Implementation
*A more detailed description of the changes. Please include any details necessary for reviewers to understand your work, and point out particula...# Issue/feature addressed
Movement for sliding mesh.
# Proposed solution
# 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).Mohsen LahootiMohsen Lahootihttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1385Draft: Disable use of SetRhsMagnitude for iterative static cond.2023-10-06T13:29:01ZChris CantwellDraft: Disable use of SetRhsMagnitude for iterative static cond.# Issue/feature addressed
When using IterativeStaticCond with a highly anisotropic elliptic solve, the iterative solver would no converge. This behaviour was inconsistent with other solvers (e.g. IterativeFull). The SetRhsMagnitude funct...# Issue/feature addressed
When using IterativeStaticCond with a highly anisotropic elliptic solve, the iterative solver would no converge. This behaviour was inconsistent with other solvers (e.g. IterativeFull). The SetRhsMagnitude function appears to be the culprit.
# Proposed solution
Disable SetRhsMagnitude for the IterativeStaticCond solver.
# Implementation
Currently just commented out.
## Tests
# Notes
None
# 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.
- [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/295
Closes #123v5.5.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1321Implementation in Collections library of CUDA operators for key operators.2023-06-08T10:43:13ZBin LiuImplementation in Collections library of CUDA operators for key operators.## Issue addressed
Nektar++ cannot yet be used with GPU co-processors. This MR enables the evaluation of these operators on NVIDIA GPUs.
## Proposed solution
This MR incorporates a CUDA implementation of the key operator kernels: Helmho...## Issue addressed
Nektar++ cannot yet be used with GPU co-processors. This MR enables the evaluation of these operators on NVIDIA GPUs.
## Proposed solution
This MR incorporates a CUDA implementation of the key operator kernels: Helmholtz, BwdTrans, PhysDeriv and IProduct into the Collections library.
## Detail on implementation
The kernels are integrated with the existing factory-pattern in Collections which decouples the code from the rest of the library kernels and other Nektar++ libraries. This enables it to be easily enabled using a CMake option, compiling the CUDA modules only if requested, and avoiding any direct dependency on them elsewhere in the code.
The kernels support two CUDA vector-widths: 1 and 32.
## Notes
* In order to install CUDA operators at this stage, the Scotch library should be installed with double-precision support by including the flag `-IDXSIZE64` in the file `/cmake/ThirdPartyScotch.cmake`. Therefore, it is recommended to request that Nektar++ compile Scotch, rather than using a system-installed version.
* If METIS is used, the `#define REALTYPEWIDTH 32` should be manually changed to `#define REALTYPEWIDTH 64` in the file `/build/ThirdParty/metis-5.1.0/include/metis.h` for double precision.Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1249WIP: Fix compile errors when AVX512 enabled.2023-03-21T15:42:45ZChris CantwellWIP: Fix compile errors when AVX512 enabled.This MR fixes issues with the use of AVX512 intrinsics in the SIMD library.This MR fixes issues with the use of AVX512 intrinsics in the SIMD library.Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1242WIP: Resolve segfault when missing TimeIntegrationMethod for unsteady problem...2023-03-21T15:41:45ZJeremy CohenWIP: Resolve segfault when missing TimeIntegrationMethod for unsteady problem - Fixes #260This MR adds an assertion to ensure that the code fails cleanly with a helpful error message when the TimeIntegrationMethod is not specified in the `<SOLVERINFO>` section of the input file for an unsteady problem.
Since the `if` stateme...This MR adds an assertion to ensure that the code fails cleanly with a helpful error message when the TimeIntegrationMethod is not specified in the `<SOLVERINFO>` section of the input file for an unsteady problem.
Since the `if` statement that previously wrapped the block of code undertaking the time integration initialisation has been removed, additional comments have been added to mark the start and end of this code block. This is intended to aid understanding and future maintainability of this section of code.
This resolves issue #260Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1222WIP: Add m_state to Array<OneD, T>2022-12-02T14:52:25ZSpencer SherwinWIP: Add m_state to Array<OneD, T>Add a state identifier to Array<OneD, T> which has he following characteristics:
Array<OneD, NekDouble> myArray;
myArray.SetState(eCoeffState); (set one of the states listed below to 1)
myArray.HasState(eCoeffState); (check the Sta...Add a state identifier to Array<OneD, T> which has he following characteristics:
Array<OneD, NekDouble> myArray;
myArray.SetState(eCoeffState); (set one of the states listed below to 1)
myArray.HasState(eCoeffState); (check the State and return a book. I have setup options with 1,2 and 3 arguments).
myArray.ResetState(eCoeffState); (reset this state back to 0).
The current enum states I have set up in SharedArray are:
enum States
{
eCoeffState, // In Coeff spae otherwise in Physical space
eFourierState, // In Fourier space
eGlobalState, // Global coefficient space otherwise local coeff space
eInterlacedState, // Data is in interlaced format
ePaddedState, // Data is padded
eCollPaddedState, // Data is padded for collection usage.
SIZE_States
};v5.3.0Dave MoxeyChris CantwellAnkang Gaoankanggao@ustc.edu.cnDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1421DRAFT: Modification of the parareal driver to solve for system of equations2022-10-24T21:10:32ZJacques XingDRAFT: Modification of the parareal driver to solve for system of equations# Issue/feature addressed
There is a division by 0 error when IO_InfoSteps = 0.
# Proposed solution
The solution is to add an additional check in the if condition to avoid division by zero when modulo is used to determine if I/O informa...# Issue/feature addressed
There is a division by 0 error when IO_InfoSteps = 0.
# Proposed solution
The solution is to add an additional check in the if condition to avoid division by zero when modulo is used to determine if I/O information need to be printed.
# Checklist
- [ ] 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).
**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/295Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1357Feature/avx512 float2022-08-26T14:42:49ZGiacomo CastiglioniFeature/avx512 float# Issue/feature addressed
We have only implemented scalar and avx2 backends for floats
# Proposed solution
Implements avx512 backend for floats
# Implementation
...
## Tests
Minor modifications to the existing unit tests was needed
#...# Issue/feature addressed
We have only implemented scalar and avx2 backends for floats
# Proposed solution
Implements avx512 backend for floats
# Implementation
...
## Tests
Minor modifications to the existing unit tests was needed
# Notes
This MR depends on !1255
SVE and SSE2 still need to be implemented
# 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] Newly added files are correctly formatted.
- [x] License added to any new files.
- [x] No extraneous files have been added (e.g. compiler output or test data files).v5.3.0Giacomo CastiglioniGiacomo Castiglionihttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1353Reformat all Nektar++ libraries using clang-format2022-07-18T06:35:14ZDave MoxeyReformat all Nektar++ libraries using clang-format# Issue/feature addressed
The formatting of the code is inconsistent and does not comply with the documented coding guidelines. The formatting of new additions or modifications is challenging as it is desirable to have consistent formatt...# Issue/feature addressed
The formatting of the code is inconsistent and does not comply with the documented coding guidelines. The formatting of new additions or modifications is challenging as it is desirable to have consistent formatting within a file, yet different files follow different styles. This therefore prevents us transitioning to a well-defined coding standard.
# Proposed solution
Reformat the whole library in one go and require new merge requests to also complete code formatting on the library.
# Implementation
The code was reformatted using clang-format v11. A new CI job has been added to verify that the code format is compliant (i.e. no further changes are proposed by running clang-format on it).
## Tests
Not applicable.
# Notes
There is a potential risk that different versions of clang-format will lead to slightly different formatting. We may need to revisit this if it causes an issue.
# 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] Newly added files are correctly formatted.
- [X] License added to any new files.
- [X] No extraneous files have been added (e.g. compiler output or test data files).v5.2.0Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1308Added the workspace check, all cpp files are created via CMake and an...2022-05-17T17:30:17ZAllen SandersonAdded the workspace check, all cpp files are created via CMake and an...Highlight: Added the workspace check, all cpp files are created via CMake and an implementation file and a macro
1. Each operator now has a workspace function which returns the size of the workspace(s) needed. This function allows other...Highlight: Added the workspace check, all cpp files are created via CMake and an implementation file and a macro
1. Each operator now has a workspace function which returns the size of the workspace(s) needed. This function allows other operators (Helmholtz) to obtain the maximum workspace size for all operators used.
Note the implementation is based on passing the shape type, there are operators for each dimension. Previously I used the workspace function as a way to check the preconditions. That is now commented out but could still be used.
2. I created a macro for the instantiation of each operator and shape type. This makes it much easy for future maintenance.
3. Because of the long compile times cpp files were being created for each operator and shape type. To reduce the code maintenance I created an implementation file, OperatorImp.cpp.in which via CMakeList.txt now creates these files automatically using the macro above.v5.2.0Spencer SherwinDave MoxeyGiacomo CastiglioniSpencer Sherwinhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1265WIP: Add Feature/moment2022-04-23T15:49:40ZAnkang Gaoankanggao@ustc.edu.cnWIP: Add Feature/momentv5.2.0Ankang Gaoankanggao@ustc.edu.cnAnkang Gaoankanggao@ustc.edu.cnhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1316Draft: Fix PhysDeriv_SumFac_Hex2022-03-02T08:34:26ZDaniel LindbladDraft: Fix PhysDeriv_SumFac_HexThe previous implementation of the `operator()` in the class `PhysDeriv_SumFac_Hex` has a bug. The bug is located on line 1423, where the first index into the two dimensional array `m_derivFac` was set to `[i*e+j]`. This has now been cor...The previous implementation of the `operator()` in the class `PhysDeriv_SumFac_Hex` has a bug. The bug is located on line 1423, where the first index into the two dimensional array `m_derivFac` was set to `[i*e+j]`. This has now been corrected to `[i*3+j]`.
It should be noted that the code may still run with this bug, but the results will of course not be 100% correct. If the code is compiled in debug mode, an error is raised by boost due to index out of bounds (the 2D array is a boost class).
A simple way to test whether the code produces correct results is to create a uniform flow through a cube with a few elements. If the physical derivative is wrong, then the vertical velocity (which should be identically 0), is in the order of 1E-13.Spencer SherwinSpencer Sherwinhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/884WIP: Add support for weak Dirichlet boundary conditions.2021-05-07T14:07:45ZMartin VymazalWIP: Add support for weak Dirichlet boundary conditions.v5.1.0https://gitlab.nektar.info/nektar/nektar/-/merge_requests/1186Fix/fix CWIPI virtual function specifiers2020-11-14T19:38:27ZEdward LaughtonFix/fix CWIPI virtual function specifiersThis fixes the override/final specifiers in CommMPI and CommCWIPI to allow for compilation with CWIPI enabled.This fixes the override/final specifiers in CommMPI and CommCWIPI to allow for compilation with CWIPI enabled.v5.0.1Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1148Fix/mesh graph multi domain2020-09-16T09:43:12ZCharles HoustonFix/mesh graph multi domainWrites composites into separate domains in XML for multi-domain simulations.
Adds map storage (and getter) for domains to keep IDs consistent in multi-domain parallel simulations.Writes composites into separate domains in XML for multi-domain simulations.
Adds map storage (and getter) for domains to keep IDs consistent in multi-domain parallel simulations.v5.0.2Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/845Add support for SHARPy2020-08-10T07:27:01ZDouglas SersonAdd support for SHARPyThis MR adds support for the SHARPy package.This MR adds support for the SHARPy package.v5.1.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/730Handle auxiliary fields in EquationSystem and pass them into the filters2019-08-08T10:37:56ZKilian LackhoveHandle auxiliary fields in EquationSystem and pass them into the filtersThis MR is my latest approach to passing aux fields into the filters. This is useful because it allows access o additional fields, such as the velocity in the ADRSolver or the forcing fields of the various forcings. See !548 and !559 fo...This MR is my latest approach to passing aux fields into the filters. This is useful because it allows access o additional fields, such as the velocity in the ADRSolver or the forcing fields of the various forcings. See !548 and !559 for earlier implementations.
The basic idea is to pass the coefficients, expansions and metadata separately into the filters. This should be compatible with the planned data/logic split of the ExpLists, @ccantwel mentioned in !548. The v_ExtraFldOutput method is fully replaced by this new implementation and all solvers were adjusted accordingly.
Currently, the HistoryPoints and CheckPoint filters are fully ported and extended to handle the auxFields. Since it has all the metadata available, the Checkpoints filter now has all the features the checkpoint handling of UnsteadySystem has. The FieldConvert filter was adjusted to demonstrate how the other filters might be ported. At this time, it does ignore the auxFields, but that can be added in the future.
The other filters now derive from an abstract LegacyFilter class which provides backwards functionality and work just as before.
the only part i am not that happy with is the string based fieldMetaDataMap.I hope we can replace that with something more flexible once the new structure of the ExpList is clearer.
Until now, i have been maintaining my own copy of the HistoryPoints filter in the APESolver, similar to what is done in the CardiacEPSolver, but i feel like libSolverUtils is a better place for this functionality as it reduces code duplication and can be used to simplify the Chekpointing in the future.Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/929WIP: Feature gmres2019-02-01T11:19:03ZZhen-Guo Yanyanzhg@mail.ustc.edu.cnWIP: Feature gmresDeveloped the first version of GMRES.
Improvements are still under development for GMRES.
Please remind me if my coding have anything that is not proper.Developed the first version of GMRES.
Improvements are still under development for GMRES.
Please remind me if my coding have anything that is not proper.v5.0.0Chris CantwellChris Cantwell