Nektar merge requestshttps://gitlab.nektar.info/nektar/nektar/-/merge_requests2023-02-22T12:03:44Zhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1498Remove redundant functors typedef2023-02-22T12:03:44ZJacques XingRemove redundant functors typedef# Issue/feature addressed
Remove redundant (doubly defined) functors typedef.
## Tests
# Suggested reviewers
*Please suggest any people who would be appropriate to review your code.*
# Notes
*Please add any other information that coul...# Issue/feature addressed
Remove redundant (doubly defined) functors typedef.
## 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.3.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1496Slightly tidy-up time integration algorithms2023-02-25T14:16:51ZJacques XingSlightly tidy-up time integration algorithms# Issue/feature addressed
Slightly tidy-up the implementation of the time-integration algorithm.
## Tests
# Suggested reviewers
*Please suggest any people who would be appropriate to review your code.*
# Notes
*Please add any other in...# Issue/feature addressed
Slightly tidy-up the implementation of the time-integration algorithm.
## 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.3.0Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1493Fix CNAB/MCNAB time-integration schemes2023-02-22T12:05:31ZJacques XingFix CNAB/MCNAB time-integration schemes# Issue/feature addressed
The CNAB/MCNAB time-integration schemes are multi-step IMEX schemes that use previous computed residuals/derivatives to provide a second-order solution in time. As multi-step schemes, CNAB/MCNAB require a startu...# Issue/feature addressed
The CNAB/MCNAB time-integration schemes are multi-step IMEX schemes that use previous computed residuals/derivatives to provide a second-order solution in time. As multi-step schemes, CNAB/MCNAB require a startup process. However, as IMEX schemes, the explicit and implicit residuals/derivatives must be stored separately.
## Tests
Convergence studies have been performed:
Second-order convergence have been obtained with CNAB
```
2.001790262556334
2.00086804216596
2.000677507737796
```
Second-order convergence have been obtained with MCNAB
```
2.0001811406921695
1.9981824806748891
1.9977267364550606
```
# 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.3.0Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1491Minor changes in DisContField to let v_HelmSolve work normally2023-03-19T09:45:28ZBOYANG XIAMinor changes in DisContField to let v_HelmSolve work normally# Issue/feature addressed
1. `DisContField::v_HelmSolve()` cannot work normally for periodic boundary conditions.
2. When enable `SetupJustDG`, adjacent elements are not set for `m_bndcondExpansions`, which may be used later.
3. Inconsis...# Issue/feature addressed
1. `DisContField::v_HelmSolve()` cannot work normally for periodic boundary conditions.
2. When enable `SetupJustDG`, adjacent elements are not set for `m_bndcondExpansions`, which may be used later.
3. Inconsistent treatment of 1D and 2D/3D expansions in `DisContField::v_GetBoundaryToElmtMap` may cause error when setting up adjacent elements for `m_bndcondExpansions`. See #318 .
# Proposed solution
See below.
# Implementation
1. During the BCs treatment in v_HelmSolve, skip the increment of `cnt` if current BC is periodic, so that `cnt + j` correctly point to the desired location in `bndCondMap`.
2. Place the code block which sets up `m_bndcondExpansions`'s adjacent elements before the `if (SetUpJustDG)` block.
3. Make 1D exp treatment consistent with 2D and 3D exp treatment in `DisContField::v_GetBoundaryToElmtMap`.
## Tests
Current HDG Helmholtz solver still cannot accept periodic boundary conditions, due to the absence of periodic BC treatment for HDG. So, no relevant tests are added yet.
# Suggested reviewers
David Moxey
# Notes
These modification enables further application of HDG helmholtz solver. For example, a HDG incNS solver.
# 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.3.0Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1490Fix: add v_ and override to bodyFittedVelocity filter function. Obtain the ma...2023-03-10T14:45:16ZGanlinFix: add v_ and override to bodyFittedVelocity filter function. Obtain the max for temperature field.# Issue/feature addressed
*The boduFittedVelocity filter will not be called since the upstream function Proess() becomes v_Process().*
*The temperature eienfunction in the boundary layer cannot be obtained when perturb the steady compres...# Issue/feature addressed
*The boduFittedVelocity filter will not be called since the upstream function Proess() becomes v_Process().*
*The temperature eienfunction in the boundary layer cannot be obtained when perturb the steady compressible flow.*
# Proposed solution
*Bug fix: add the v_ and override to respective functions.*
*Also record the max/min/original for density, pressure, and temperature.*
# 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.
- ~~[ ] 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.3.0Jacques XingChris CantwellJacques Xinghttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1489Fix IMEX Gear time-integration approach2023-02-03T14:09:47ZJacques XingFix IMEX Gear time-integration approach# Issue/feature addressed
The original IMEX Gear time-integration approach is advertised as second-order. However, only the implicit part was second-order, while the explicit part was treated by a first-order approximation resulting in a...# Issue/feature addressed
The original IMEX Gear time-integration approach is advertised as second-order. However, only the implicit part was second-order, while the explicit part was treated by a first-order approximation resulting in an overall first-order scheme.
# Proposed solution
The proposed solution is to consider both the explicit and the implicit terms as second-order. I am not familiar with the IMEX Gear approach, however the proposed approach is also known as "extrapolated Gear" method. (see (p.803) https://www.jstor.org/stable/pdf/2158449.pdf)
## Tests
Here is the original convergence rate:
```
IMEXGear:
1.0048374666093653
1.0024170009943802
1.0012061031178545
```
Here is the convergence rate of the updated scheme:
```
IMEXGear:
2.002880533431922
2.0014606941621973
2.000714655758547
```
# 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.
- [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.~~
- ~~[ ] No extraneous files have been added (e.g. compiler output or test data files).~~v5.3.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1488Add Generalized Extrapolation Method (GEM) time integration schemes2023-03-14T11:10:59ZJacques XingAdd Generalized Extrapolation Method (GEM) time integration schemes# Issue/feature addressed
Add explicit and implicit extrapolation time-integration method. Extrapolation methods allow the construction of arbitrarily high-order time-integration methods based on a series for low-order approximations. In...# Issue/feature addressed
Add explicit and implicit extrapolation time-integration method. Extrapolation methods allow the construction of arbitrarily high-order time-integration methods based on a series for low-order approximations. Interested reader can look at the following references:
```
https://epubs.siam.org/doi/pdf/10.1137/1027140
https://epubs.siam.org/doi/epdf/10.1137/080732833
https://msp.org/camcos/2014/9-2/camcos-v9-n2-p01-p.pdf
```
## Tests
The following test files have been added to the CI
```
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMExplicitOrder1.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMExplicitOrder2.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMExplicitOrder3.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMExplicitOrder4.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMExplicitOrder5.tst
```
```
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMExplicitMidpointOrder2.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMExplicitMidpointOrder4.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMExplicitMidpointOrder6.tst
```
```
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMImplicitOrder1.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMImplicitOrder2.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMImplicitOrder3.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMImplicitOrder4.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMImplicitOrder5.tst
```
```
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMImplicitMidpointOrder2.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMImplicitMidpointOrder4.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMImplicitMidpointOrder6.tst
```
```
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMIMEXOrder1.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMIMEXOrder2.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMIMEXOrder3.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMIMEXOrder4.tst
library/Demos/LibUtilities/Tests/TimeIntegrationDemoGEMIMEXOrder5.tst
```
In addition, validation of the convergence of the numerical schemes have been realized
1. The explicit Euler GEM scheme has been validated for order (1-6):
```
GEMEulerExplicitOrder1:
1.0002213408208864
GEMEulerExplicitOrder2:
2.000071255463732
GEMEulerExplicitOrder3:
3.0130960439559917
GEMEulerExplicitOrder4:
4.026899801460759
GEMEulerExplicitOrder5:
4.9584108709601775
GEMEulerExplicitOrder6:
5.971316749439216
```
2. The explicit midpoint GEM scheme has been validated for order (2,4,6):
```
GEMMidpointExplicitOrder2:
2.000071255463732
GEMMidpointExplicitOrder4:
4.026899801460759
GEMMidpointExplicitOrder6:
5.971316749439216
```
3. The implicit Euler GEM scheme has been validated for order (1-4):
```
GEMEulerImplicitOrder1:
0.9987680285674233
GEMEulerImplicitOrder2:
1.97898607303774
GEMEulerImplicitOrder3:
2.9412369884261667
GEMEulerImplicitOrder4:
3.8571772952155055
```
4. The implicit "midpoint" GEM scheme has been validated for order (2,4,6):
```
GEMMidpointImplicitOrder2:
1.9941954378795832
GEMMidpointImplicitOrder4:
3.8664357920254795
GEMMidpointImplicitOrder6:
5.760570713650503
```
4. The IMEX Euler GEM scheme has been implemented but its use is not recommended as the approach is affected by order-reduction problems.
# 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.
- [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.3.0Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1487Fix fld file import with singlemode expansion2023-03-17T14:09:09ZAnkang Gaoankanggao@ustc.edu.cnFix fld file import with singlemode expansion# Issue/feature addressed
In function `void ExpListHomogeneous1D::v_ExtractDataToCoeffs`, the `offset`, which is 2 for single mode expansion, is not added when building the `m_zIdToPlane`.
This causes the restart file and the bodyforce f...# Issue/feature addressed
In function `void ExpListHomogeneous1D::v_ExtractDataToCoeffs`, the `offset`, which is 2 for single mode expansion, is not added when building the `m_zIdToPlane`.
This causes the restart file and the bodyforce file cannot be properly imported, since the planes they contained are IDs 2 and 3.
On the other hand, the baseflow file is on plane ID 0. If we added the `offset=2` to `m_zIdToPlane`, the baseflow will not be corrected imported.
close issue #320
When importing the baseflow, the code assumes that the variables and their orders in the baseflow and in the session files are the same. Sometimes, the baseflow is computed from another solver or generated by combining several files. These situations are not considered in the current code.
# Proposed solution
An argument `std::unordered_map<int, int> zIdToPlane` is added to functions `ExtractDataToCoeffs` and `v_ExtractDataToCoeffs`. The default value of `zIdToPlane` is an empty map. If `zIdToPlane` is unempty, it will be used to replace the origional `m_zIdToPlane`.
# Implementation
## Tests
A test has been added.
# 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).
fix issue #310v5.3.0Dave MoxeySpencer SherwinDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1485Fix TimeIntegrationDemo.cpp and add ESDIRK tst files to the CI2023-02-03T15:12:53ZJacques XingFix TimeIntegrationDemo.cpp and add ESDIRK tst files to the CI# Issue/feature addressed
The TimeIntegrationDemo.cpp was apparently originally designed to solve the advection-diffusion problem by an explicit discretization of the advection term and a implicit discretization of the diffusion term. Us...# Issue/feature addressed
The TimeIntegrationDemo.cpp was apparently originally designed to solve the advection-diffusion problem by an explicit discretization of the advection term and a implicit discretization of the diffusion term. Using the Demo for the validation of pure explicit scheme is not adequate. Also, the original code is not suitable for ESDIRK schemes.
# Proposed solution
A few flags have been added to the code to properly deal with the various time-integration schemes.
## 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.~~
- ~~[ ] No extraneous files have been added (e.g. compiler output or test data files).~~v5.3.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1484Fix ESDIRK scheme2023-02-03T14:23:46ZJacques XingFix ESDIRK scheme# Issue/feature addressed
There seems to be some issue with the DIRKOrder3_ES5 and DIRKOrder4_ES6 schemes. The beta coefficients are not even set for the DIRKOrder4_ES6 schemes. Second, there seems to be some typo in the coefficients of ...# Issue/feature addressed
There seems to be some issue with the DIRKOrder3_ES5 and DIRKOrder4_ES6 schemes. The beta coefficients are not even set for the DIRKOrder4_ES6 schemes. Second, there seems to be some typo in the coefficients of the DIRKOrder3_ES5 schemes.
# 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.~~
- ~~[ ] No extraneous files have been added (e.g. compiler output or test data files).~~v5.3.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1483Add IProductWRTDerivBase operator to ExpListHomogeneous1D2023-09-01T13:46:26ZHenrik WustenbergAdd IProductWRTDerivBase operator to ExpListHomogeneous1D# Issue/feature addressed
The `IProductWRTDerivBase` operator is not implemented for `3DH1D` problems. It is used in the `IncNavierStokesSolver` for the `EQTYPE` `VCSWeakPressure` and required for `VCSImplicit` (see !1475).
# Proposed s...# Issue/feature addressed
The `IProductWRTDerivBase` operator is not implemented for `3DH1D` problems. It is used in the `IncNavierStokesSolver` for the `EQTYPE` `VCSWeakPressure` and required for `VCSImplicit` (see !1475).
# Proposed solution
Define the operator as `virtual` in the `ExpList` class and re-implement it in the child class `ExpListHomogeneous1D` (the base class one homogeneous direction).
# Implementation
The function is based on the `ExpListHomogeneous1D::PhysDeriv` and `IProductWRTBase` implementation. It uses the 2D (PhysSpace) `IProductWRTDerivBase` operator on individual `m_planes` for the x- and y-direction. Subsequently, it adds the homogeneous derivative via a call to `IProductWRTBase`, multiplies by the Fourier coefficient i \beta k and switches Real-Imaginary modes to account for multiplication by imaginary unit i.
## Tests
- 3DH1D Kovasznay flow flipped on side i.e. pressure varies in (homogeneous) z-direction
# Suggested reviewers
- Dave Moxey
- Spencer Sherwin
- Mohsen Lahooti
# Notes
- The function is tested for `ContField` classes, however, not on the parent classes `DisContField` (Do we use 3DH1D with DisContField somewhere?)
# 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.4.0Henrik WustenbergHenrik Wustenberghttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1482Fix/rk5 time integration scheme2023-01-27T19:50:37ZJacques XingFix/rk5 time integration scheme# Issue/feature addressed
The RK5 time integration scheme is not properly implemented. This merge request solve this issue.
The solution norm for RK2, RK3, and RK4 are `6.20025`, `6.19839`, and `6.19886`, respectively. The original solu...# Issue/feature addressed
The RK5 time integration scheme is not properly implemented. This merge request solve this issue.
The solution norm for RK2, RK3, and RK4 are `6.20025`, `6.19839`, and `6.19886`, respectively. The original solution norm for RK5 was `6.61221`. With the correct scheme, the solution norm is `6.198859`.
# 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)).
- ~~[ ] License added to any new files.~~
- [x] No extraneous files have been added (e.g. compiler output or test data files).v5.3.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1481Add Spectral Deferred Correction (SDC) time-stepping scheme2023-03-14T18:53:31ZJacques XingAdd Spectral Deferred Correction (SDC) time-stepping scheme# Issue/feature addressed
Add Spectral Deferred Correction (SDC) time-integration method. SDC methods allow the construction of arbitrarily high-order time-integration methods based on a series for low-order approximations. Interested re...# Issue/feature addressed
Add Spectral Deferred Correction (SDC) time-integration method. SDC methods allow the construction of arbitrarily high-order time-integration methods based on a series for low-order approximations. Interested reader can look at the following references:
```
https://link.springer.com/content/pdf/10.1023/A:1022338906936.pdf
https://msp.org/camcos/2014/9-2/camcos-v9-n2-p01-p.pdf
https://arxiv.org/pdf/1706.06245.pdf
https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=73d1f8040544da722eac48398b851cb4ed5a06e8
```
The implemented approach include equidistant, Gauss-Lobatto-Legendre, Gauss-Radau-Legendre, Gauss-Lobatto-Chebyshev, and Gauss-Radau-Chebyshev quadrature combined with first-order explicit time-integration method and Gauss-Radau-Legendre quadrature combined with implicit time-integration method.
## Tests
The following tests have been added to the CI:
```
TimeIntegrationDemoSDCExplicitEquidistantOrder2.tst
TimeIntegrationDemoSDCExplicitEquidistantOrder4.tst
TimeIntegrationDemoSDCExplicitEquidistantOrder6.tst
TimeIntegrationDemoSDCExplicitEquidistantOrder8.tst
```
```
TimeIntegrationDemoSDCExplicitGaussLobattoChebyshevOrder2.tst
TimeIntegrationDemoSDCExplicitGaussLobattoChebyshevOrder4.tst
TimeIntegrationDemoSDCExplicitGaussLobattoChebyshevOrder6.tst
TimeIntegrationDemoSDCExplicitGaussLobattoChebyshevOrder8.tst
```
```
TimeIntegrationDemoSDCExplicitGaussLobattoLegendreOrder2.tst
TimeIntegrationDemoSDCExplicitGaussLobattoLegendreOrder4.tst
TimeIntegrationDemoSDCExplicitGaussLobattoLegendreOrder6.tst
TimeIntegrationDemoSDCExplicitGaussLobattoLegendreOrder8.tst
```
```
TimeIntegrationDemoSDCImplicitGaussRadauLegendreOrder1.tst
TimeIntegrationDemoSDCImplicitGaussRadauLegendreOrder3.tst
TimeIntegrationDemoSDCImplicitGaussRadauLegendreOrder5.tst
TimeIntegrationDemoSDCImplicitGaussRadauLegendreOrder7.tst
```
In addition, the following convergence studies have been performed:
1) The explicit SDC scheme has been validated with `Equidistant` quadrature nodes (2-5), corresponding to orders (2-5):
```
SDCExplicitOrder2:
2.0001849404258447
SDCExplicitOrder3:
2.998112275443462
SDCExplicitOrder4:
3.9072768262992614
SDCExplicitOrder5:
4.5995837300978915
```
2) The explicit SDC scheme has been validated with `GaussLobattoLegendre` quadrature nodes (2-4), corresponding to orders (2,4,6):
```
SDCExplicitOrder2:
2.0000896766198726
SDCExplicitOrder4:
3.9723855124165213
SDCExplicitOrder6:
5.938139326221622
```
3) The explicit SDC scheme has been validated with `GaussRadauLegendre` quadrature nodes (1-3), corresponding to orders (1,3,5):
```
SDCExplicitOrder1:
1.0069863770994856
SDCExplicitOrder3:
3.1122545359905596
SDCExplicitOrder5:
5.175226949995819
```
4) The explicit SDC scheme has been validated with `GaussLobattoChebyshev` quadrature nodes (2-4), corresponding to orders (2,4,6):
```
SDCExplicitOrder2:
2.0001849404258447
SDCExplicitOrder4:
3.9851582816338422
SDCExplicitOrder6:
6.293402621379888
```
5) The explicit SDC scheme has been validated with `GaussRadauChebyshev` quadrature nodes (2-4), corresponding to orders (2,4,6):
```
SDCExplicitOrder2:
2.0015302412770626
SDCExplicitOrder4:
4.164020377045453
SDCExplicitOrder6:
6.224349110295919
```
6) The implicit SDC scheme has been validated with `GaussRadauLegendre` quadrature nodes (1-4), corresponding to orders (1,3,5,7):
```
SDCImplicitOrder1:
0.9972045679750912
SDCImplicitOrder3:
2.734499327650926
SDCImplicitOrder5:
4.598134392581629
SDCImplicitOrder7:
6.423925369611658
```
7) The IMEX SDC scheme has been implemented but its use is not recommended as the approach is affected by order-reduction problems.
# Suggested reviewers
*Please suggest any people who would be appropriate to review your code.*
# Notes
!1488 have to be merge first
# 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.3.0Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1480Fix description typos in Vmath and VDmath2023-01-25T11:05:24ZJacques XingFix description typos in Vmath and VDmath# Issue/feature addressed
Fixing some typos in the description of `Vmath` and `VDmath` class.
# Checklist
- ~~[ ] Functions and classes, or changes to them, are documented.~~
- ~~[ ] User guide/documentation is updated.~~
- [x] Changelo...# Issue/feature addressed
Fixing some typos in the description of `Vmath` and `VDmath` class.
# 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.~~
- ~~[ ] 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.3.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1476Fix minor typo and removed unused functions in LibUtilities/TimeIntegration2023-01-27T14:44:36ZJacques XingFix minor typo and removed unused functions in LibUtilities/TimeIntegration# Issue/feature addressed
Just fixing some typo and remove some unused functions.
# Checklist
- ~~[ ] Functions and classes, or changes to them, are documented.~~
- ~~[ ] User guide/documentation is updated.~~
- [x] Changelog is updated...# Issue/feature addressed
Just fixing some typo and remove some unused functions.
# 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.~~
- ~~[ ] No extraneous files have been added (e.g. compiler output or test data files).~~v5.3.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1472Fix uninitialized coordinates in ForcingBody2023-03-24T14:29:10ZAnkang Gaoankanggao@ustc.edu.cnFix uninitialized coordinates in ForcingBody# Issue/feature addressed
If equation variables are used in the ForcingBody function, the coordinate Arrays are allocated but uninitialized. The default value, 0, is used for all coordinate variables. As a result, the spatial coordinate ...# Issue/feature addressed
If equation variables are used in the ForcingBody function, the coordinate Arrays are allocated but uninitialized. The default value, 0, is used for all coordinate variables. As a result, the spatial coordinate is not correctly passed to the body force.
In addition, the number and order of variables listed in the EVASR property must be the same as the solver variables, which is inconvenient in applications when only one variable is involved. For example, in the heating problem, the body force should be defined as
```
<FUNCTION NAME="BodyForce">
<E VAR="u" VALUE="0" EVARS="u v teta p" />
<E VAR="v" VALUE="teta*Ra_uni/Pr" EVARS="u v teta p" />
<E VAR="teta" VALUE="0" EVARS="u v teta p"/>
</FUNCTION>
```
whereas `u v` are not used in the equation.
Besides, `p` is not an advective variable and cannot be used in the body force expression.
# Proposed solution
The body force function can be defined as
```
<FUNCTION NAME="BodyForce">
<E VAR="v" VALUE="teta*Ra_uni/Pr" EVARS="teta" />
<E VAR="teta" VALUE="0"/>
</FUNCTION>
```
In the v_InitObject function, automatically find which variable is defined in EVARS and cache the equation variables list in a map `std::map<int, std::vector<int>> m_evarsList`. In this example, `m_evarsList` is
| key | value |
| ------ | ------ |
| 1 | 2 |
| 2 | |
- If `m_evarsList[i]` is not defined, the force function will not be evaluated.
- If `m_evarsList[i]` is defined but empty, the expression or file function is evaluated.
- If `m_evarsList[i]` is not empty, equation variables is used.
# Implementation
A map `m_evarsList`, which contains the equation variables used in the i-th body force, is generated first in the v_InitObject. This map is then used to decide how to evaluate the force in the `Update` function.
## Tests
# 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] 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).
fix issue #310v5.3.0Dave MoxeyDave Moxeyhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1469Make virtual functions protected consistently2022-12-30T13:45:26ZJacques XingMake virtual functions protected consistently# Issue/feature addressed
Derived classes are frequently accessed through a base class pointer in the code. The *template pattern* provides a public API through the base class and provides virtual functions which can be overloaded in der...# Issue/feature addressed
Derived classes are frequently accessed through a base class pointer in the code. The *template pattern* provides a public API through the base class and provides virtual functions which can be overloaded in derived classes to specialise functionality. These virtual functions should not be publicly accessible themselves, but may need to be used explicitly by further derived classes in order to extend functionality and minimise code duplication. As such they should be made `protected`, rather than `public` or `private`.
## Tests
# Suggested reviewers
@ccantwel
# 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.3.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1462Enable ARM macOS runner, fixes for SCOTCH allocation and PETSc detection on m...2022-12-14T19:02:49ZDave MoxeyEnable ARM macOS runner, fixes for SCOTCH allocation and PETSc detection on macOS# Issue/feature addressed
This MR enables a macOS ARM-based M1 runner. It also addresses two macOS-related issues with Scotch graph allocation and PETSc detection.
# Proposed solution
Most of the work in this branch has been in setting ...# Issue/feature addressed
This MR enables a macOS ARM-based M1 runner. It also addresses two macOS-related issues with Scotch graph allocation and PETSc detection.
# Proposed solution
Most of the work in this branch has been in setting up the runner itself. However two regressions were identified. Firstly, `SCOTCH_Graph` behaviour seems to be different in newer versions of Scotch. Secondly, PETSc detection recently moved to use `pkg-config` in !1454, but when the library is not in the main linker path, linking fails.
# Implementation
Scotch graph allocation now uses the `SCOTCH_graphAlloc` function in `SubStructuredGraph.cpp`:
```c++
SCOTCH_graphAlloc *scGraph = SCOTCH_graphAlloc();
```
PETSc detection now uses the `PETSC_LINK_LIBRARIES` variable, if available:
```cmake
# Prefer to use absolute paths to avoid separate link directories on
# some platforms (e.g. macOS). However not available in all CMake
# versions.
IF (DEFINED PETSC_LINK_LIBRARIES)
SET(PETSC_LIBRARIES ${PETSC_LINK_LIBRARIES} CACHE INTERNAL "")
ENDIF()
```
## Tests
No new tests, but macOS runner now enabled.
# Suggested reviewers
@ccantwel @mgreen
# Notes
@mgreen I think this is the thing that was causing runtime errors for you, might be worth checking this now works for you.
# 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)).
- ~~[ ] License added to any new files.~~
- [x] No extraneous files have been added (e.g. compiler output or test data files).v5.3.0Chris CantwellChris Cantwellhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1459Add missing override keyword to virtual functions in LibUtilities2022-12-28T19:23:29ZJacques XingAdd missing override keyword to virtual functions in LibUtilities# Issue/feature addressed
Many virtual functions in derived class of the LibUtilities directory do not have the `override` keyword. This make the code unsafe if someone changes the definition of the base class.
# Proposed solution
Add...# Issue/feature addressed
Many virtual functions in derived class of the LibUtilities directory do not have the `override` keyword. This make the code unsafe if someone changes the definition of the base class.
# Proposed solution
Add the `override` keyword to the relevant functions in the LibUtilities directory. The `virtual` keyword is also explicitly added to all virtual functions.
## 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.3.0https://gitlab.nektar.info/nektar/nektar/-/merge_requests/1457Update of Parareal algorithm2023-03-21T15:52:26ZJacques XingUpdate of Parareal algorithm# Issue/feature addressed
Update to Parareal:
1. Add convergence criteria to Parareal loop.
2. Fixed Hdf5 IO Issue (see MR !1512).
3. Generalize the use of `GetSpaceComm()` communicator (see MR !1518).
4. ~~MeshGraph is updated to creat...# Issue/feature addressed
Update to Parareal:
1. Add convergence criteria to Parareal loop.
2. Fixed Hdf5 IO Issue (see MR !1512).
3. Generalize the use of `GetSpaceComm()` communicator (see MR !1518).
4. ~~MeshGraph is updated to create coarse partition files (see MR !1516).~~
5. Modify SessionReader to read restart/exact solution files parallel-in-time (see MR !1521).
6. Add new interpolation function (see MR !1514).
7. Remove m_root to avoid potential confusion (see MR !1515).
8. Remove unused function SetUpXmlDoc (see MR !1513).
9. Update to Parareal file output (See MR !1517).
10. Add parallel-in-time capabilities to FieldConvert (See MR !1520)
## Tests
# 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)).
- [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.3.0Dave MoxeyDave Moxey