Re: [deal.II] catching SolverControl::NoConvergence
On 7/31/20 3:44 AM, Alberto Salvadori wrote: By the way, I noticed that there is no Trilinos wrapper for GMRES, yet the implementation of LA::MPI::SolverGMRES provides no error when the trilinos flag is set. Is there any redirection to another solver? Is this a potential source of the unexpected behavior mentioned above? Good question. Can you create a minimal test case for that as well? Best W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/365d58c8-9912-0ef1-961e-2dce77bd42e3%40colostate.edu.
Re: [deal.II] catching SolverControl::NoConvergence
Wolfgang,
I am going to provide the small test case as soon as I can make it. In the
meanwhile, it turned out that
*catch* ( *const* std::exception )
rather than SolverControl::NoConvergence works fine.
By the way, I noticed that there is no Trilinos wrapper for GMRES, yet the
implementation of LA::MPI::SolverGMRES provides no error when
the trilinos flag is set. Is there any redirection to another solver? Is
this a potential source of the unexpected behavior mentioned above?
Thank you.
Alberto
Il giorno giovedì 30 luglio 2020 alle 02:15:16 UTC+2 Wolfgang Bangerth ha
scritto:
> On 7/29/20 5:37 AM, Alberto Salvadori wrote:
> >
> > try
> > {
> > iterate_on_tolerance = false ;
> > this->pcout << " AMG - Bicgstab " << std::flush ;
> >
> > bicgstab.solve (this->system_matrix,
> distributed_incremental_displacement,
> > this->system_rhs, preconditioner);
> > solver_control_last_step = bicgstab_solver_control.last_step();
> > }
> >
> > catch ( SolverControl::NoConvergence )
> > {
> > iterate_on_tolerance = true ;
> > try
> > {
> > ... whatever ...
> > }
> >
> > My idea is: whenever bicgstab.solve fails, for instance because the
> accuracy
> > is higher than the tolerance, I want to catch the exception
> > SolverControl::NoConvergence and do something else. I am insecure if
> the
> > above code is fine for this purpose, could you please address me to a
> broader
> > explanation ?
>
> Yes, this is the equivalent code of what we have here in ASPECT:
>
> https://github.com/geodynamics/aspect/blob/master/source/simulator/solver.cc#L502-L520
> or more tailored to your situation:
>
> https://github.com/geodynamics/aspect/blob/master/source/simulator/solver.cc#L838-L913
>
>
> > At any rate, it turns out that the code above works OK for PETSc, but
> not for
> > trilinos - I do would like to use trilinos for the sake of memory leaks.
> > Apparently , errors of kind
> >
> > aztec00 error code #
> >
> > take the lead with trilinos and the exception is not caught properly. I
> must
> > have done something wrong.
> Interesting. Can you again construct a small test case so we can see how
> to
> fix this?
>
> Best
> W.
>
> --
>
> Wolfgang Bangerth email: bang...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
>
--
Informativa sulla Privacy: http://www.unibs.it/node/8155
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/51db88db-ae30-4888-a0b6-e66cd7e60192n%40googlegroups.com.
Re: [deal.II] catching SolverControl::NoConvergence
On 7/29/20 5:37 AM, Alberto Salvadori wrote:
try
{
iterate_on_tolerance = false ;
this->pcout << " AMG - Bicgstab " << std::flush ;
bicgstab.solve (this->system_matrix, distributed_incremental_displacement,
this->system_rhs, preconditioner);
solver_control_last_step = bicgstab_solver_control.last_step();
}
catch ( SolverControl::NoConvergence )
{
iterate_on_tolerance = true ;
try
{
... whatever ...
}
My idea is: whenever bicgstab.solve fails, for instance because the accuracy
is higher than the tolerance, I want to catch the exception
SolverControl::NoConvergence and do something else. I am insecure if the
above code is fine for this purpose, could you please address me to a broader
explanation ?
Yes, this is the equivalent code of what we have here in ASPECT:
https://github.com/geodynamics/aspect/blob/master/source/simulator/solver.cc#L502-L520
or more tailored to your situation:
https://github.com/geodynamics/aspect/blob/master/source/simulator/solver.cc#L838-L913
At any rate, it turns out that the code above works OK for PETSc, but not for
trilinos - I do would like to use trilinos for the sake of memory leaks.
Apparently , errors of kind
aztec00 error code #
take the lead with trilinos and the exception is not caught properly. I must
have done something wrong.
Interesting. Can you again construct a small test case so we can see how to
fix this?
Best
W.
--
Wolfgang Bangerth email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/7e852110-5dfe-4d1e-ef50-8fadd7a1e839%40colostate.edu.
