Hi,

that's reassuring. Great that you found it!


Bernd


--
_________________________________________________________________

Bernd Flemisch
IWS, Universität Stuttgart               phone: +49 711 685 69162
Pfaffenwaldring 61              email: [email protected]
D-70569 Stuttgart           url: 
www.iws.uni-stuttgart.de/en/lh2/<http://www.iws.uni-stuttgart.de/en/lh2/>
_________________________________________________________________
________________________________
Von: DuMux <[email protected]> im Auftrag von Martin Utz 
<[email protected]>
Gesendet: Donnerstag, 27. Juli 2023 16:30:14
An: DuMux User Mailing List
Betreff: Re: [DuMux] Problem with linear solver residual computation

Leo and I found the reason. The differences in the residual, which we observed 
between dumux 3.6 and dumux 3.7, are not caused by the linear solver. They come 
from the changes in the friction laws between dumux 3.6 and 3.7 and an error 
which we had in our code using them.

Best regards,
Martin
[email protected] hat am 28.06.2023 08:51 CEST geschrieben:


Hi Bernd, hi Timo,

it looks like the problem occurs when a triangular mesh (e.g. ALUGrid) is used 
in combination with the ISTLSolverFactory. I've used the roughchannel test of 
DuMux without MPI to investigate the issue. I will make a test branch in DuMux 
with a new rough channel tests with a triangular geometry (dgf-file) in 
combination the ISTLSolverFactory. Maybe I need some help to get the 
OldIstlSolverFactoryBackend working.


Best regards

Leo

Timo Koch <[email protected]> hat am 26.06.2023 11:34 CEST geschrieben:


Hi Leo,

did you try parallel vs sequential and is there a difference? This would help 
narrowing down where a potential problem could come from?

Best
Timo

On 26 Jun 2023, at 11:13, [email protected] wrote:

Hi Bernd,

Thank you fro your advice. My code does not compile with the old interface 
OldIstlSolverFactoryBackend.

However, I've tested the Issue with the roughchannel test case of DuMux. There 
are no differences for the AMGBackend between DuMux 3.7 and DuMux 3.5. When 
switching from the AMGBackend to the ISTLSolverFactory there were also no 
differences. I will have to check this twice to ensure that I didn't made some 
mistake. The last big difference between our application and the DuMux test 
case is the mesh. We use a triangular mesh with ALUGrid, the test case uses a 
simple quad mesh.

I will write back when I've a reproducible test case for a standard DuMux 
example.

Best regards,

Leo


Flemisch, Bernd <[email protected]> hat am 23.06.2023 11:29 
CEST geschrieben:





Hi Leo,



Thank you for bringing this up. Indeed, the norm calculation changed from 
"manual" in the assembler to being handed to the parallel scalarproduct. This 
should rather fix things by avoiding multiple contributions from elements 
present on more than one process. And therefore decreasing the norm rather than 
increasing it.



I can't draw the connection to the source term at the moment.



Can you check that you get the 3.6 numbers with 3.7 using the 
OldIstlSolverFactoryBackend with the old interface?



Kind regards

Bernd





--
_________________________________________________________________

Bernd Flemisch
IWS, Universität Stuttgart               phone: +49 711 685 69162
Pfaffenwaldring 61              email: [email protected]
D-70569 Stuttgart           url: 
www.iws.uni-stuttgart.de/en/lh2/<http://www.iws.uni-stuttgart.de/en/lh2/>
_________________________________________________________________
________________________________
Von: DuMux <[email protected]> im Auftrag von 
[email protected] <[email protected]>
Gesendet: Freitag, 23. Juni 2023 11:24:53
An: DuMux User Mailing List
Betreff: Re: [DuMux] Problem with linear solver residual computation

Dear DuMux community,

Martin and I did some further testeing and it looks like the source term 
(friciton source) causes the differences in the residual computation. When we 
turn of the friction source, the residual becomes equal between DuMux 3.7 and 
DuMux 3.6.

So the question is how the source term can be correctly included into the 
residual computation?

Best regards,

Leo

[email protected] hat am 23.06.2023 09:55 CEST geschrieben:


Dear DuMux community,

in DuMux 3.7 there are some changes in the parallel linear solver. In DuMux 3.6 
we used the following code for the linear solver

using LinearSolver = IstlSolverFactoryBackend<LinearSolverTraits<GridGeometry>>;

for a parallel (MPI) shallow water equations model. In the new version DuMux 
3.7, the code/interface has changed and a second argument is needed

using LinearSolver = IstlSolverFactoryBackend<LinearSolverTraits<GridGeometry>, 
LinearAlgebraTraitsFromAssembler<Assembler>>;

We added the second argument and the code compiles and runs. However, the model 
runs much slower. It looks like the computation of the residual has changed. 
With DuMux 3.6 the output of the Newton solver was:

Newton iteration 1 done, maximum relative shift = 6.9188e-02, residual = 
1.3174e+01, residual reduction 1.0000e+00->2.0094e-02@lambda=1.0000
Newton iteration 2 done, maximum relative shift = 1.6123e-02, residual = 
2.5193e-01, residual reduction 2.0094e-02->3.8426e-04@lambda=1.0000
Newton iteration 3 done, maximum relative shift = 3.1727e-04, residual = 
4.9623e-03, residual reduction 3.8426e-04->7.5690e-06@lambda=1.0000
Assemble/solve/update time: 0.044(24.32%)/0.13(71.15%)/0.0082(4.53%)

With DuMux 3.7 the output has changed to

Newton iteration 1 done, maximum relative shift = 6.9188e-02, residual = 
1.4379e+02, residual reduction 1.0000e+00->2.1931e-01@lambda=1.0000
Newton iteration 2 done, maximum relative shift = 1.6123e-02, residual = 
3.6247e+01, residual reduction 2.1931e-01->5.5287e-02@lambda=1.0000
Newton iteration 3 done, maximum relative shift = 3.1751e-04, residual = 
9.2089e+00, residual reduction 5.5287e-02->1.4046e-02@lambda=1.0000
Newton iteration 4 done, maximum relative shift = 2.0686e-05, residual = 
2.2909e+00, residual reduction 1.4046e-02->3.4943e-03@lambda=1.0000
Newton iteration 5 done, maximum relative shift = 8.9205e-06, residual = 
5.6879e-01, residual reduction 3.4943e-03->8.6757e-04@lambda=1.0000
Newton iteration 6 done, maximum relative shift = 3.6801e-06, residual = 
1.3881e-01, residual reduction 8.6757e-04->2.1172e-04@lambda=1.0000
Newton iteration 7 done, maximum relative shift = 1.7669e-06, residual = 
3.1597e-02, residual reduction 2.1172e-04->4.8194e-05@lambda=1.0000
Assemble/solve/update time: 0.15(76.02%)/0.029(14.98%)/0.017(9.01%)

While the relative shift remains nearly the same during the first three Newton 
steps, the residual has increased. I guess that we have just missed to change 
some further parameters/options to ensure that the residual is computed 
correctly. Are there any hints and tips?

Best regards,

Leo


Im Auftrag

Dr.-Ing. Leopold Stadler

--
Referat Numerische Verfahren im Wasserbau
Abteilung Wasserbau im Binnenbereich

Bundesanstalt für Wasserbau
Federal Waterways Engineering and Research Institute
Kußmaulstraße 17 | 76187 Karlsruhe


_______________________________________________
DuMux mailing list
[email protected]
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux


Im Auftrag

Dr.-Ing. Leopold Stadler

--
Referat Numerische Verfahren im Wasserbau
Abteilung Wasserbau im Binnenbereich

Bundesanstalt für Wasserbau
Federal Waterways Engineering and Research Institute
Kußmaulstraße 17 | 76187 Karlsruhe



_______________________________________________
DuMux mailing list
[email protected]
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux


Im Auftrag

Dr.-Ing. Leopold Stadler

--
Referat Numerische Verfahren im Wasserbau
Abteilung Wasserbau im Binnenbereich

Bundesanstalt für Wasserbau
Federal Waterways Engineering and Research Institute
Kußmaulstraße 17 | 76187 Karlsruhe



_______________________________________________
DuMux mailing list
[email protected]
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
_______________________________________________
DuMux mailing list
[email protected]
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux


Im Auftrag

Dr.-Ing. Leopold Stadler

--
Referat Numerische Verfahren im Wasserbau
Abteilung Wasserbau im Binnenbereich

Bundesanstalt für Wasserbau
Federal Waterways Engineering and Research Institute
Kußmaulstraße 17 | 76187 Karlsruhe



_______________________________________________
DuMux mailing list
[email protected]
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux


Im Auftrag

Martin Utz

--
Referat Numerische Verfahren im Wasserbau
Abteilung Wasserbau im Binnenbereich

Bundesanstalt für Wasserbau
Federal Waterways Engineering and Research Institute
Kußmaulstraße 17 | 76187 Karlsruhe
E-Mail: [email protected]

Tel.: +49 721 9726-3575
Fax: +49 721 9726-4540
https://www.baw.de

_______________________________________________
DuMux mailing list
[email protected]
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux

Reply via email to