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
