fem merge requestshttps://gitlab.onelab.info/gmsh/fem/-/merge_requests2024-03-27T12:47:50Zhttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/80Various fixes2024-03-27T12:47:50ZBoris MartinVarious fixes- Fixed an error in solveDistributed where the local size on rank 0 is printed, instead of the global size
- Fixed missing casts from unsigned to signed types
- Replaced a lambda with structured binding by an explicit function object for...- Fixed an error in solveDistributed where the local size on rank 0 is printed, instead of the global size
- Fixed missing casts from unsigned to signed types
- Replaced a lambda with structured binding by an explicit function object for compatibility reasons.https://gitlab.onelab.info/gmsh/fem/-/merge_requests/79Fixed error when field tag is non-zero2024-03-25T21:40:36ZBoris MartinFixed error when field tag is non-zerohttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/78Final MR for distributed solves2024-03-22T13:31:33ZBoris MartinFinal MR for distributed solveshttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/77Distributed Field and Basic MPI support2024-03-22T12:26:46ZBoris MartinDistributed Field and Basic MPI supportSubset of the distributed gmshFEM update: Distributed field.
TODO later: distibuted compound fieldsSubset of the distributed gmshFEM update: Distributed field.
TODO later: distibuted compound fieldshttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/75Minor changes before distributed DOFs2024-03-21T10:34:08ZBoris MartinMinor changes before distributed DOFs- A "Dof" object now has a global index (for future use)
- "-info" command renamed to "-feminfo" to avoid conflict with PETSc
- Added an option to override the index of a RHS (needed for gmshDDM with multiple RHS)- A "Dof" object now has a global index (for future use)
- "-info" command renamed to "-feminfo" to avoid conflict with PETSc
- Added an option to override the index of a RHS (needed for gmshDDM with multiple RHS)https://gitlab.onelab.info/gmsh/fem/-/merge_requests/74Distributed (MPI) problems2024-03-21T10:37:07ZBoris MartinDistributed (MPI) problemshttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/73Update README.md2023-11-03T18:01:40ZPhilippe MarchnerUpdate README.mdChristophe GeuzaineChristophe Geuzainehttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/72Update README.md2023-10-16T18:56:41ZPhilippe MarchnerUpdate README.mdChristophe GeuzaineChristophe Geuzainehttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/71Update Helmholtz flow examples - Pierce operator2023-10-14T07:08:15ZPhilippe MarchnerUpdate Helmholtz flow examples - Pierce operator- update and document point source in freefield example
- add validation benchmark for the Pierce operator- update and document point source in freefield example
- add validation benchmark for the Pierce operatorChristophe GeuzaineChristophe Geuzainehttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/69Multiple RHS support (+ Solve with HPDDM)2023-09-22T13:27:19ZBoris MartinMultiple RHS support (+ Solve with HPDDM)A formulation now stores a vector of RHS, and all can be solved at once through HPDDM's KSPMatSolve.
- [x] Completely remove the old "b" vector
- [x] Cleanup of the config
- [ ] Proper tutorial and benchmark
- [ ] Possibility of solving...A formulation now stores a vector of RHS, and all can be solved at once through HPDDM's KSPMatSolve.
- [x] Completely remove the old "b" vector
- [x] Cleanup of the config
- [ ] Proper tutorial and benchmark
- [ ] Possibility of solving all without HPDDM (slow but portable)
- [x] Is a new prepro needed ?
Some day: work on BLAS parallelizationhttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/65Gmsh fem gmsh opti2023-02-21T11:08:02ZChristophe GeuzaineGmsh fem gmsh optiSpeed up Domain creation with physical name with new `getEntitiesForPhysicalName` Gmsh API call.Speed up Domain creation with physical name with new `getEntitiesForPhysicalName` Gmsh API call.Christophe GeuzaineChristophe Geuzainehttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/63Solution vector from Formulation::solve()2023-02-15T16:41:44ZNicolas MarsicSolution vector from Formulation::solve()Hi everyone,
I'd like to access the whole solution vector of a `Formulation`.
Is there already a handy way to do so?
I know we can play with `FieldInterface::getUnknownValues()` and `FieldInterface::getUnknownIndices()`, but that's not...Hi everyone,
I'd like to access the whole solution vector of a `Formulation`.
Is there already a handy way to do so?
I know we can play with `FieldInterface::getUnknownValues()` and `FieldInterface::getUnknownIndices()`, but that's not very convenient when there's more than one field.
If there's no simpler way to do so, this MR proposes to expose the solution vector by adding a `Formulation::solve(bool, Vector)` method.
Any comments or changes are of course more than welcome :).
Cheers,
Nicolas.Boris MartinBoris Martinhttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/62Seg. fault when reusing the factorization2023-02-15T16:42:41ZNicolas MarsicSeg. fault when reusing the factorizationHi everyone,
First of all, let me wish you a happy new year :)!
Reusing the factorization with `Solver::solve(true)` leads to a segmentation fault.
I guess the cause is
```
_A->removePetscData();
_b->removePetscData();
```
at the end ...Hi everyone,
First of all, let me wish you a happy new year :)!
Reusing the factorization with `Solver::solve(true)` leads to a segmentation fault.
I guess the cause is
```
_A->removePetscData();
_b->removePetscData();
```
at the end of `solve()` (lines [153-154](https://gitlab.onelab.info/gmsh/fem/-/blob/master/src/system/Solver.cpp#L153)), which kills the operator, making thus the reuse impossible.
My impression was that it worked a while ago, so I dig a bit: these lines were introduced in commit 49a1a43e, which fixes some memory leaks.
So I'm not sure how to fix this bug without breaking other stuffs...
This MR suggests to simply remove the two `removePetscData()`, as it seems that this task is already handled by `MatrixFactory<>::~MatrixFactory()`.
It works (no leak and no seg. fault) in the simple case
```
// [...]
formulation.solve(false);
formulation.solve(true);
// [...]
```
but I'm perhaps missing something?
Any thoughts?
Cheers,
Nicolas.Boris MartinBoris Martinhttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/61add FieldInterface<>::numberOfLinkedDofs()2022-12-13T12:02:44ZNicolas Marsicadd FieldInterface<>::numberOfLinkedDofs()Hi everyone,
Seems that the implementation of `FieldInterface<>::numberOfLinkedDofs()` is missing.
This patch adds it, by following the same strategy than `FieldInterface<>::numberOfFixedDofs()`
Cheers,
Nicolas.Hi everyone,
Seems that the implementation of `FieldInterface<>::numberOfLinkedDofs()` is missing.
This patch adds it, by following the same strategy than `FieldInterface<>::numberOfFixedDofs()`
Cheers,
Nicolas.https://gitlab.onelab.info/gmsh/fem/-/merge_requests/59Added warning when trying to use high order Lagrange elements2022-12-08T12:48:42ZBoris MartinAdded warning when trying to use high order Lagrange elementsWhen using Lagrange elements, only order 1 and 2 are supported. Furthermore, order 2 requires the mesh to be itself second order (I think). This PR adds a warning when trying to use higher order and recommends using hierarchical H1 basis...When using Lagrange elements, only order 1 and 2 are supported. Furthermore, order 2 requires the mesh to be itself second order (I think). This PR adds a warning when trying to use higher order and recommends using hierarchical H1 basis instead.
I guess a similar warning should be used for all function spaces where the order isn't arbitrary, but I'm not confident enough to be sure.https://gitlab.onelab.info/gmsh/fem/-/merge_requests/58New example: Helmholtz reflection of a plane wave2022-12-07T10:01:48ZBoris MartinNew example: Helmholtz reflection of a plane waveAdds an example where an incident plane wave is reflected over a plane surface. The reflected wave is computed. With periodic BCs and appropriate absorbing conditons, the exact analytical solution is recovered (up to a tolerance).Adds an example where an incident plane wave is reflected over a plane surface. The reflected wave is computed. With periodic BCs and appropriate absorbing conditons, the exact analytical solution is recovered (up to a tolerance).https://gitlab.onelab.info/gmsh/fem/-/merge_requests/57Win32: CYGWIN/MSYS flag not set by the Ninja CMake Generator --> check for WI...2022-12-07T10:00:34ZNicolas MarsicWin32: CYGWIN/MSYS flag not set by the Ninja CMake Generator --> check for WIN32 only...Little patch for using the Ninja CMake Generator with ms-winLittle patch for using the Ninja CMake Generator with ms-winhttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/56Vibro-elastic first example2022-12-07T10:00:07ZBoris MartinVibro-elastic first exampleEasy test case of vibro-elastic coupling, with elastic displacement forced to be 1D and a potential formulation on the acoustic side.
An incoming acoustic wave comes from top and reaches a perpendicular interface between the acoustic reg...Easy test case of vibro-elastic coupling, with elastic displacement forced to be 1D and a potential formulation on the acoustic side.
An incoming acoustic wave comes from top and reaches a perpendicular interface between the acoustic region and the elastic region. Depending on the material properties, some reflection and transmission occur. The code computes the analytical solution (i.e. reflection and transmission coefficients given the material properties) and checks they are reproduced, up to tolerance.
I put it as an example, but in the long run it should probably be put inside some CI, as the code checks correctness explicitlyhttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/55removeConstraints2022-11-25T13:31:42ZTim GabrielremoveConstraintshttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/54std::aligned_alloc() and ms-windows2022-10-27T08:54:51ZNicolas Marsicstd::aligned_alloc() and ms-windowsDear all,
The current gmshfem does not compile with mingw.
One reason is that `std::aligned_alloc()` is apparently not compatible with ms-windows internals [1]!
The problem seems to affect msvc[1, 2] as well.
One bypass is to call `_al...Dear all,
The current gmshfem does not compile with mingw.
One reason is that `std::aligned_alloc()` is apparently not compatible with ms-windows internals [1]!
The problem seems to affect msvc[1, 2] as well.
One bypass is to call `_aligned_malloc()` and `_aligned_free()` [3].
That works with mingw (tested) and apparently with msvc >= 2015 (untested).
In its current form, the merge request replaces the `std::aligned_alloc()` calls with a macro.
This macro is `_aligned_malloc()` with a win32 compiler and `std::aligned_alloc()` otherwise.
The same goes for `free()`.
One could also do it at runtime, but I don't know how critical `function/executionTree/FunctionAllocator.cpp` is.
By the way, the `CMakeLists` manipulates `WIN32`, but that's an internal variable of cmake [4].
I suggest to use `HAVE_WIN32` instead (also in this MR).
There's another unrelated problem with `MessageModificator` and ms-win, but that will be in another MR ;).
Cheers,
Nicolas.
[1] https://stackoverflow.com/questions/62962839/stdaligned-alloc-missing-from-visual-studio-2019
[2] !!! https://visualstudio.microsoft.com/vs/pricing-details/ !!!
[3] https://stackoverflow.com/questions/32133203/what-can-i-use-instead-of-stdaligned-alloc-in-ms-visual-studio-2013
[4] https://cmake.org/cmake/help/latest/variable/WIN32.html