fem merge requestshttps://gitlab.onelab.info/gmsh/fem/-/merge_requests2023-01-19T09:33:24Zhttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/60Code modernization: unique_ptrs in objects owned by a Formulation2023-01-19T09:33:24ZBoris MartinCode modernization: unique_ptrs in objects owned by a FormulationSimplified memory management: for objects owned by a formulation (`_solver, _A, _b`), the C-style pointer is replaced by `unique_ptr`, which removes the need for manual deletion.
When possible, some functions reading pointers were change...Simplified memory management: for objects owned by a formulation (`_solver, _A, _b`), the C-style pointer is replaced by `unique_ptr`, which removes the need for manual deletion.
When possible, some functions reading pointers were changed to use references instead. Otherwise, backwards compatibility is kept through `unique_ptr::get()`.
A tricky case is the one concerning a Solver's pointers to _A and _b. Currently they use direct pointers, which makes ownership ambiguous. An option would to use shared/weak pointers. Otherwise we could also have the solver keep a reference to its "parent" formulation and ask directly for the formulation's A/b. But it could be less generic if at some point a Solver becomes less coupled to a Formulation.
Poke @geuzaine since you're interested in modern C++Boris MartinBoris Martinhttps://gitlab.onelab.info/gmsh/fem/-/merge_requests/62Seg. fault when reusing the factorization2023-01-24T12:21:54ZNicolas 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/63Solution vector from Formulation::solve()2023-01-19T09:34:14ZNicolas 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 Martin