BUG: ALE Stiffness Matrix Reconstruction
Closed this issue · 5 comments
Apparently, I should be using gesvd instead of the default option.
See https://discourse.julialang.org/t/svd-better-default-to-gesvd-instead-of-gesdd/20603
Gooooooosh, this bug is so weird!
I have tried to reduce only the laplacian contribution and that went smooth and well.
It is the reduction of the convective term the one that is problematic.
Looking at the examples I found in https://people.math.sc.edu/Burkardt/fenics_src/fenics_src.html, I think I might not be coding the weak formulation correctly, and this is causing numerical errors.
The problem is with the elimination of zero entries.
For the non-symmetric operator (-w du/dx, v) this was causing different shapes in the CSR matrix.
I think I need to better eliminate those zeroes myself.
I finally got around this problem. There were many factors coming into play:
- Incorrect zeroes elimination.
- Difficulties when reducing the laplacian and the convection terms together.
To overcome the first one I implemented the procedure to eliminate zeroes myself.
To overcome the second one I have done a split within the stiffness matrix to have the laplacian term and the convection term on different operators.
Interestingly, although in the online stage the convection term is fully reconstructed, using its MDEIM approximation increases the error in the HROM model.
OperatorType.MASS
OperatorType.STIFFNESS
OperatorType.CONVECTION
OperatorType.RHS
TTFT, -5.910925794131453
FTFT, -5.910925843871892
TTFF, -5.910925908660145
TFFT, -5.910925840396172
FTFF, -5.91092577895072
TFFF, -5.9109258281376045
FFFT, -5.910925818822577
FFFF, -5.910925827049283
TTTT, -3.4553687713080747
TTTF, -3.455368766464446
FTTT, -3.4553687724609308
FTTF, -3.4553687560189608
TFTT, -3.455368770111029
TFTF, -3.4553687652094576
FFTT, -3.4553687757452756
FFTF, -3.455368760608829