Nektar merge requestshttps://gitlab.nektar.info/nektar/nektar/-/merge_requests2024-03-27T00:19:43Zhttps://gitlab.nektar.info/nektar/nektar/-/merge_requests/1774Draft: Addition of general MemoryRegion2024-03-27T00:19:43ZAllen SandersonDraft: Addition of general MemoryRegion# Issue/feature addressed
*Currently the Field class has member variable that is a MemoryRegionCPU with several ancillary methods that work on the variable. This member variable and the associated ancillary methods need to be generalized...# Issue/feature addressed
*Currently the Field class has member variable that is a MemoryRegionCPU with several ancillary methods that work on the variable. This member variable and the associated ancillary methods need to be generalized for general host/device usage.*
# Proposed solution
*A new class MemoryRegion has been introduced which the Field inherits from. At the same time this class is used in the operators so allow host/device usage.
Importantly this class uses the notion of valid host/device data rather than the notion of whether the data is "on" the device which will not work.
At the same time I have introduced the concept of execution and memory spaces which is ubiquitous in Kokkos and I believe should be moved into the base operator class. It allows for a more general way of understanding where an functor is executing and the location of the memory.
When combined with the MemoryRegion one generically asks for a pointer to memory. Depending on the memory space of the operator the appropriate data is returned.
I have utilized and tested the above paradigm in the BwdTransMatFree for the Field and Basis data. One can see it via the USE_MEMORY_REGION macro in library/Operators/BwdTrans/BwdTransMatFree.hpp and library/Operators/BwdTrans/BwdTransMatFreeKernel.hpp
I have utilized but not tested the above paradigm in the BwdTransCUDA for the Field and Basis data.
I have also introduced storing the basis data via the BasisKey which is similar to what is done in the CUDA implementations.
Note the MemoryRegion in BwdTransMatFree uses a vec_t whereas the BwdTransCUDA uses a TData (double).
I have also done some cleanup in the *MatFree* so to remove m_basis which was redundant given the expansion list is also stored.
*
# Implementation
*A more detailed description of the changes. Please include any details necessary for reviewers to understand your work, and point out particular points would like them to pay particular attention to.*
## Tests
# Suggested reviewers
*Please suggest any people who would be appropriate to review your code.*
# Notes
*Please add any other information that could be useful for reviewers.*
# Checklist
- [ ] Functions and classes, or changes to them, are documented.
- [ ] User guide/documentation is updated.
- [ ] Changelog is updated.
- [ ] Suitable tests added for new functionality.
- [ ] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- [ ] License added to any new files.
- [ ] No extraneous files have been added (e.g. compiler output or test data files).https://gitlab.nektar.info/nektar/nektar/-/merge_requests/1778Separate MeshGraph input/output functions into a new class2024-03-26T14:22:58ZTed StokesSeparate MeshGraph input/output functions into a new class# Issue/feature addressed
Once created, it shouldn't matter which file format a MeshGraph instance was loaded from. However because the format specific subclasses inherit from MeshGraph, it isn't trivial to read from an XML then write t...# Issue/feature addressed
Once created, it shouldn't matter which file format a MeshGraph instance was loaded from. However because the format specific subclasses inherit from MeshGraph, it isn't trivial to read from an XML then write to an HDF5 file.
# Proposed solution
Extract MeshGraph's input/output functions and put them in a new base class MeshGraphIO which has a subclass for each file format, so that MeshGraph is agnostic to the file format it is read from or written to.
# Implementation
The MeshGraph class has had its IO functions trimmed out, and instead of MeshGraphXml, MeshGraphXmlCOmpressed and MeshGraphHDF5 there is MeshGraphIOXml, MeshGraphIOXmlCompressed and MeshGraphIOHDF5, which inherit from MeshGraphIO. A MeshGraph is now read by calling MeshGraph**_IO_**\[format\]::Read.
# Tests
# Suggested reviewers
@dmoxey
# Notes
# 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)).
- [x] License added to any new files.
- [x] No extraneous files have been added (e.g. compiler output or test data files).https://gitlab.nektar.info/nektar/nektar/-/merge_requests/1780Draft: Feature/scaling mesh2024-03-21T13:31:25ZKaloyan KirilovDraft: Feature/scaling mesh# Issue/feature addressed
*Scales the coordinates of the mesh (Linear or High-order) with user-defined scaled coefficient. This is useful when users have CAD or have created the high-order/linear mesh with the wrong dimensions (mm vs m)....# Issue/feature addressed
*Scales the coordinates of the mesh (Linear or High-order) with user-defined scaled coefficient. This is useful when users have CAD or have created the high-order/linear mesh with the wrong dimensions (mm vs m). Several users have requested such functionality. *
# Proposed solution
*A very simple module that takes X Y Z coefficients and scales the coordinates (vertices, edgeNodes, FaceNodes). *
# Implementation
*A very simple module that takes scaleX scaleY scaleZ coefficients as an input and scales the coordinates of the (vertices, edgeNodes, FaceNodes). It has 3 loops over vertexSet, edgeSet, faceSet. If no coefficient is given by the user, no scaling is performed in this direction.*
## Tests
# Suggested reviewers
**
# 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.
- [ ] 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).https://gitlab.nektar.info/nektar/nektar/-/merge_requests/1783Remove copy entire input and output to padded aligned arrays in MatrixFree op...2024-03-26T10:42:16ZBOYANG XIARemove copy entire input and output to padded aligned arrays in MatrixFree operators# Issue/feature addressed
_In the previous design, the matrix-free operator `Helmholtz_MatrixFree` copies the input array into the internal padded aligned storage `MatrixFreeOneInOneOut::m_input` before the real task starts. This redund...# Issue/feature addressed
_In the previous design, the matrix-free operator `Helmholtz_MatrixFree` copies the input array into the internal padded aligned storage `MatrixFreeOneInOneOut::m_input` before the real task starts. This redundant large copy significantly slows down the speed._
# Proposed solution
_Remove the copy operation and let operators in MatrixFreeOps support unaligned memory. After this change, the legacy collection matrix-free operators should achieve comparable performance as the redesign matrix-free operators._
# Implementation
The initial design is:
* _Use an aligned local array as an intermediate storage._
* _Always copy data to aligned local storage before `load_interleave` and `deinterleave`_
* _The last sub-block, which may contain paddings, will be processed in a separate code block._
An updated design is:
* Add a new function `load_unalign_interleave`, which can directly access unaligned memory. So we don't need to copy to an aligned local array.
Here are the benchmark results:
![image.png](/uploads/acfc1d9765c517ff47a1bf48b052d1a9/image.png){width="389" height="259"}![image.png](/uploads/920333c71b6fef8c93f055f0ecc783d5/image.png){width=380 height=249}
Although there are noises or errors, we can still get some general conclusions:
* The legacy collection matrix-free is much slower than the redesign, except for hex-7, which requires no padding (no copy) by coincidence.
* The update design is slightly faster than the initial design by further reducing the memory loads.
## Tests
No new tests are required.
# Suggested reviewers
@dmoxey @ccantwel
# Notes
_A complete change for all operators takes a lot of effort. So we first apply changes to `Helmholtz` then to the others._
_Everyone especially the MatrixFreeOps contributors are welcome to join in this MR._
_The`MatrixFreeBase` the class can be removed after all the operators are updated._
# 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).https://gitlab.nektar.info/nektar/nektar/-/merge_requests/1784Implement implicit time-discretization in SWE solvers2024-03-27T11:50:24ZJacques XingImplement implicit time-discretization in SWE solvers# Issue/feature addressed
- Implement implicit time-stepping (JFNK) for SWE
- Move `CopyBoundaryTrace` from base class to LinearSWE
- Add `const` keyword when appropriate
- Remove unused function `WallBoundary`
# Proposed solution
# ...# Issue/feature addressed
- Implement implicit time-stepping (JFNK) for SWE
- Move `CopyBoundaryTrace` from base class to LinearSWE
- Add `const` keyword when appropriate
- Remove unused function `WallBoundary`
# Proposed solution
# Implementation
## Tests
# Suggested reviewers
*Please suggest any people who would be appropriate to review your code.*
# Notes
*Please add any other information that could be useful for reviewers.*
# Checklist
- [x] Functions and classes, or changes to them, are documented.
- [ ] User guide/documentation is updated.
- [x] Changelog is updated.
- [ ] Suitable tests added for new functionality.
- [x] Contributed code is correctly formatted. (See the [contributing guidelines](https://gitlab.nektar.info/nektar/nektar/-/blob/master/CONTRIBUTING.md#using-clang-format)).
- ~~[ ] License added to any new files.~~
- [x] No extraneous files have been added (e.g. compiler output or test data files).v5.6.0