Trilinos
Replies: 5 comments 11 replies
|
Automatic mention of the @trilinos/muelu team |
|
When you say that the result is not correct: does MueLu fail to converge? I'm assuming you're using MueLu as a preconditioner in Belos. Does the solve achieve the desired tolerance? EDIT1: Also, what do you mean by "the simulations crashed immediately"? MueLu should not crash. EDIT2: Oh, this is Stokes. So you're effectively mushing together all degrees of freedom without regard for pressure or velocities. If the (2,2) block has a zero diagonal then a crash is not that surprising. |
|
Hi Christian, Yes, I'm using MueLu as a preconditioner within Belos. The GMRES solver converges well with MueLu — the relative residuals reach around 1.e-9. However, when I visualize the results, I notice a strange behavior in the pressure field (as shown in the figure). In contrast, using the ILU preconditioner from IFPACK produces a much smoother pressure profile, without any noticeable overshoots or undershoots. So I suspect the issue might be related to the MueLu preconditioner.
Just to add, I'm using SUPG stabilization, so the matrix diagonal is not zero. |
|
A priori this doesn't sound like a problem with the solver. If the linear system is solved to tolerance the error might be elsewhere. However, I would suggest to double check the residual in case Belos only prints out an implicit residual. It might also be worth checking whether you're using left or right preconditioning. |
|
Dear Christian, Thank you very much for your support. I am using a right preconditioner with Flexible GMRES, and I compute the residual error explicitly as follows: typedef Belos::MultiVecTraits<ST, MV> MVT;
typedef Belos::OperatorTraits<ST, MV, OP> OPT;
std::vector<double> rhs_norm(1);
MVT::MvNorm( *b, rhs_norm );
Epetra_MultiVector resid(A->RowMap(), 1);
OPT::Apply( *A, *x, resid );
MVT::MvAddMv( -1.0, resid, 1.0, *b, resid );
std::vector<double> res_error(1);
MVT::MvNorm( resid, res_error);
abs_res_err_ = res_error[0];
rel_res_err_ = res_error[0]/rhs_norm[0]; In my simulation, the pressure is on the order of I have used the same MueLu preconditioner on problems where both pressure and velocity are small and comparable in scale, and in those cases, the solution is accurate. |
|
So, to recap:
Before rescaling your system, you could reduce the solver tolerance and check if that indeed restores correct behavior. Otherwise we'd need to look at MueLu parameters to see if any of the dropping thresholds need to be adjusted. |
|
|
Yes, I would reduce that further for testing the conjecture. If that is indeed successful you can look into rescaling the velocity or using a norm that is more appropriate. |
|
Hi Christian, following your suggestion, we tried to reduce the solver tolerance to Do you have suggestion on what can be tried next? |
|
Have you tried other preconditioners? I'm wondering whether it's something specific in MueLu that fails due to the scaling. You could also try to equilibrate the system, see e.g. |
|
The red line corresponds to GMRES with an ILU preconditioner from IFPACK, which produced correct results. However, the drawback was that the linear solver required a large number of iterations, resulting in increased computation time. To address this, we attempted to accelerate the solution process using MueLu, but we are currently encountering issues with it. |
|
@dgmaths9 I wonder if the ILU settings are different between the GMRES/RILUK and GMRES/MueLu results. Please post the multigrid summary (section labeled "Summary") from the GMRES/MueLu/ILU run. If you have setup output from the successful GMRES/RILUK output, please post that as well, thanks. |
|
Hi @jhux2, thanks for chiming in, here is the multigrid summary section from the GMRES/MueLu/ILU run: --- Multigrid Summary ---Scalar = double and here is GMRES/RILUK setup output: Block Size = 1 [unused] |
|
And what does MueLu + RILUK from Ifpack2 look like? |
|
verbosity = high Clearing old data (if any) Level 0 Level 1 --- Multigrid Summary ---Scalar = double level rows nnz nnz/row c ratio procs Smoother (level 0) both : Ifpack_AdditiveSchwarz, ov = 0, local solver = Smoother (level 1) both : Ifpack_AdditiveSchwarz, ov = 0, local solver = Smoother (level 2) both : Ifpack_AdditiveSchwarz, ov = 0, local solver = Smoother (level 3) both : Ifpack_AdditiveSchwarz, ov = 0, local solver = Smoother (level 4) both : Ifpack_AdditiveSchwarz, ov = 0, local solver = Smoother (level 5) pre : MueLu::AmesosSmoother{type = Klu} |
|
Hmmm, that's not very revealing. You could check against the converging GMRES/RILUK (no AMG) to see if there's an obvious difference in the settings. |
Uh oh!
There was an error while loading. Please reload this page.
Hi @jhux2,
I am trying to solve the Stokes flow equations accounting change in density due to pressure. The application is the magma flow in the underground reservoir with initial pressure around 30 MPa. For discretization I use stabilized finite element method with linear elements (P1 or Q1). In my code, the DOFs are arranged as p, v1, v2 for each node i.e.
p, v1, v2, p,v1, v2, ...
The global matrix is unsymmetric.
I first tried with
GMRESfromBelosandRILUKpreconditioner fromIFPACK2that produced right results although taking too many iterations and thus more computational time. As an improvement I wanted to use MUELU for faster computations, however, with MUELU the results are not correct. I see that pressure largely oscilates (see attached figure).So far I have tried these options
unsmoothedand smoother:ILUpgand smoother:ILUIn smoother I also tried the
level of fill0 and 1. WIth both options the results (with minor difference) were incorrect.I also tried
Relaxation: Jacobiwith sweeps 1 and damping 0.9, but the simulations crashed immediately.Here is the MueLu precondition configuration I used for the unsmoothed case:
I would appreciate If you can suggest what to try to get the correct results.
Many thanks,
Deepak
All reactions