Re: [DuMux] Problem with linear solver residual computation
Hi, that's reassuring. Great that you found it! Bernd -- _ Bernd Flemisch IWS, Universität Stuttgart phone: +49 711 685 69162 Pfaffenwaldring 61 email: be...@iws.uni-stuttgart.de D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/<http://www.iws.uni-stuttgart.de/en/lh2/> _ Von: DuMux im Auftrag von Martin Utz 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 leopold.stad...@baw.de 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 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, leopold.stad...@baw.de 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 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: be...@iws.uni-stuttgart.de D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/<http://www.iws.uni-stuttgart.de/en/lh2/> _ Von: DuMux im Auftrag von leopold.stad...@baw.de 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 leopold.stad...@baw.de 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>; 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, LinearAlgebraTraitsFromAssembler>; 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.e+00->2.0094e-02@lambda=1. Newton iteration 2 done, m
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 > leopold.stad...@baw.de 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 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, leopold.stad...@baw.de 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 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: be...@iws.uni-stuttgart.de > > > > D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/ > > > > http://www.iws.uni-stuttgart.de/en/lh2/ > > > > _ > > > > > > > > - > > > > Von: DuMux im Auftrag von > > > > leopold.stad...@baw.de > > > > 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 > > &
Re: [DuMux] Problem with linear solver residual computation
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 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, leopold.stad...@baw.de 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 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: be...@iws.uni-stuttgart.de > > > D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/ > > > http://www.iws.uni-stuttgart.de/en/lh2/ > > > _ > > > > > > - > > > Von: DuMux im Auftrag von > > > leopold.stad...@baw.de > > > 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 > > > > > > > > > > leopold.stad...@baw.de 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>; > > > > > > > > for a parallel (MPI) sh
Re: [DuMux] Problem with linear solver residual computation
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?BestTimoOn 26 Jun 2023, at 11:13, leopold.stad...@baw.de 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 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: be...@iws.uni-stuttgart.de D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/ _ Von: DuMux im Auftrag von leopold.stad...@baw.de Gesendet: Freitag, 23. Juni 2023 11:24:53An: DuMux User Mailing ListBetreff: 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 leopold.stad...@baw.de 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>; 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, LinearAlgebraTraitsFromAssembler>; 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.e+00->2.0094e-02@lambda=1. Newton iteration 2 done, maximum relative shift = 1.6123e-02, residual = 2.5193e-01, residual reduction 2.0094e-02->3.8426e-04@lambda=1. Newton iteration 3 done, maximum relative shift = 3.1727e-04, residual = 4.9623e-03, residual reduction 3.8426e-04->7.5690e-06@lambda=1. 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.e+00->2.1931e-01@lambda=1. Newton iteration 2 done, maximum relative shift = 1.6123e-02, residual = 3.6247e+01, residual reduction 2.1931e-01->5.5287e
Re: [DuMux] Problem with linear solver residual computation
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 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: be...@iws.uni-stuttgart.de > D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/ > http://www.iws.uni-stuttgart.de/en/lh2/ > _ > > - > Von: DuMux im Auftrag von > leopold.stad...@baw.de > 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 > > > > leopold.stad...@baw.de 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>; > > > > 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, > > LinearAlgebraTraitsFromAssembler>; > > > > 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.e+00->2.0094e-02@lambda=1. > > Newton iteration 2 done, maximum relative shift = 1.6123e-02, residual = > > 2.5193e-01, residual reduction 2.0094e-02->3.8426e-04@lambda=1. > > Newton iteration 3 done, maximum relative shift = 3.1727e-04, residual = > > 4.9623e-03, residual reduction 3.8426e-04->7.5690e-06@lambda=1. > > 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.e+00->2.1931e-01@lambda=1. > > Newton iteration 2 done, maximum relative shift = 1.6123e-02, residual = > > 3.6247e+01, residual reduction 2.1931e-01->5.5287e-02@lambda=1. > > Newton iteration 3 done, maximum relative shift = 3.1751e-04, residual = > > 9.2089e+00, residual reduction 5.5287e-02->1.4046e-02@lambda=1. > > Newton iteration 4 done, maximum relative shift = 2.0686e-05, residual = > > 2.2909e+00, residual reduction 1.4046e-02->3.4943e-03@lambda=1. > > Newton iteratio
Re: [DuMux] Problem with linear solver residual computation
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: be...@iws.uni-stuttgart.de D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/<http://www.iws.uni-stuttgart.de/en/lh2/> _ Von: DuMux im Auftrag von leopold.stad...@baw.de 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 leopold.stad...@baw.de 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>; 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, LinearAlgebraTraitsFromAssembler>; 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.e+00->2.0094e-02@lambda=1. Newton iteration 2 done, maximum relative shift = 1.6123e-02, residual = 2.5193e-01, residual reduction 2.0094e-02->3.8426e-04@lambda=1. Newton iteration 3 done, maximum relative shift = 3.1727e-04, residual = 4.9623e-03, residual reduction 3.8426e-04->7.5690e-06@lambda=1. 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.e+00->2.1931e-01@lambda=1. Newton iteration 2 done, maximum relative shift = 1.6123e-02, residual = 3.6247e+01, residual reduction 2.1931e-01->5.5287e-02@lambda=1. Newton iteration 3 done, maximum relative shift = 3.1751e-04, residual = 9.2089e+00, residual reduction 5.5287e-02->1.4046e-02@lambda=1. Newton iteration 4 done, maximum relative shift = 2.0686e-05, residual = 2.2909e+00, residual reduction 1.4046e-02->3.4943e-03@lambda=1. Newton iteration 5 done, maximum relative shift = 8.9205e-06, residual = 5.6879e-01, residual reduction 3.4943e-03->8.6757e-04@lambda=1. Newton iteration 6 done, maximum relative shift = 3.6801e-06, residual = 1.3881e-01, residual reduction 8.6757e-04->2.1172e-04@lambda=1. Newton iteration 7 done, maximum relative shift = 1.7669e-06, residual = 3.1597e-02, residual reduction 2.1172e-04->4.8194e-05@lambda=1. 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 DuMux@listserv.uni-stuttgart.de 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 DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
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 > leopold.stad...@baw.de 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>; > > 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, > LinearAlgebraTraitsFromAssembler>; > > 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.e+00->2.0094e-02@lambda=1. > Newton iteration 2 done, maximum relative shift = 1.6123e-02, residual = > 2.5193e-01, residual reduction 2.0094e-02->3.8426e-04@lambda=1. > Newton iteration 3 done, maximum relative shift = 3.1727e-04, residual = > 4.9623e-03, residual reduction 3.8426e-04->7.5690e-06@lambda=1. > 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.e+00->2.1931e-01@lambda=1. > Newton iteration 2 done, maximum relative shift = 1.6123e-02, residual = > 3.6247e+01, residual reduction 2.1931e-01->5.5287e-02@lambda=1. > Newton iteration 3 done, maximum relative shift = 3.1751e-04, residual = > 9.2089e+00, residual reduction 5.5287e-02->1.4046e-02@lambda=1. > Newton iteration 4 done, maximum relative shift = 2.0686e-05, residual = > 2.2909e+00, residual reduction 1.4046e-02->3.4943e-03@lambda=1. > Newton iteration 5 done, maximum relative shift = 8.9205e-06, residual = > 5.6879e-01, residual reduction 3.4943e-03->8.6757e-04@lambda=1. > Newton iteration 6 done, maximum relative shift = 3.6801e-06, residual = > 1.3881e-01, residual reduction 8.6757e-04->2.1172e-04@lambda=1. > Newton iteration 7 done, maximum relative shift = 1.7669e-06, residual = > 3.1597e-02, residual reduction 2.1172e-04->4.8194e-05@lambda=1. > 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 > DuMux@listserv.uni-stuttgart.de > 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 DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
[DuMux] Problem with linear solver residual computation
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>; 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, LinearAlgebraTraitsFromAssembler>; 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.e+00->2.0094e-02@lambda=1. Newton iteration 2 done, maximum relative shift = 1.6123e-02, residual = 2.5193e-01, residual reduction 2.0094e-02->3.8426e-04@lambda=1. Newton iteration 3 done, maximum relative shift = 3.1727e-04, residual = 4.9623e-03, residual reduction 3.8426e-04->7.5690e-06@lambda=1. 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.e+00->2.1931e-01@lambda=1. Newton iteration 2 done, maximum relative shift = 1.6123e-02, residual = 3.6247e+01, residual reduction 2.1931e-01->5.5287e-02@lambda=1. Newton iteration 3 done, maximum relative shift = 3.1751e-04, residual = 9.2089e+00, residual reduction 5.5287e-02->1.4046e-02@lambda=1. Newton iteration 4 done, maximum relative shift = 2.0686e-05, residual = 2.2909e+00, residual reduction 1.4046e-02->3.4943e-03@lambda=1. Newton iteration 5 done, maximum relative shift = 8.9205e-06, residual = 5.6879e-01, residual reduction 3.4943e-03->8.6757e-04@lambda=1. Newton iteration 6 done, maximum relative shift = 3.6801e-06, residual = 1.3881e-01, residual reduction 8.6757e-04->2.1172e-04@lambda=1. Newton iteration 7 done, maximum relative shift = 1.7669e-06, residual = 3.1597e-02, residual reduction 2.1172e-04->4.8194e-05@lambda=1. 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 DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
