Re: [petsc-users] Use previous solution when encountering "DIVERGED_LINE_SEARCH"

[Barry Smith]

  Justin,

   Could you provide more details or an example how 

> "DIVERGED_LINE_SEARCH" which essentially "resets" my solution to zero and 
> messes everything up

In the VI RSLS solver the code looks like

if (lssucceed) {
  if (++snes->numFailures >= snes->maxFailures) {
PetscBool ismin;
snes->reason = SNES_DIVERGED_LINE_SEARCH;
ierr = 
SNESVICheckLocalMin_Private(snes,snes->jacobian,F,X,gnorm,);CHKERRQ(ierr);
if (ismin) snes->reason = SNES_DIVERGED_LOCAL_MIN;
break;
  }
   }

  so it essentially just breaks out if the line search failed, I think it 
should leave whatever the "current" solution is and shouldn't "reset" the 
solution to zero. That is if it made some progress to the solution and then had 
a line search failure the "progress" to the solution should still be in the 
solution vector. 

  Barry

Of course the "current solution" may not be a good solution but the intention 
is that it contains whatever progress it did make and not zero so if you could 
provide something that helps us debug why it was zero we could hopefully fix 
the problem for you.


> On Nov 30, 2016, at 8:27 PM, Justin Chang  wrote:
> 
> Hi all,
> 
> I am running some transient simulations using SNESVINEWTONRSLS. At certain 
> timesteps, I get a "DIVERGED_LINE_SEARCH" which essentially "resets" my 
> solution to zero and messes everything up. I notice that this happens when 
> the SNES Function norm no longer decreases, and if I were to manually 
> terminate the solver right before the final iteration I get the answer I 
> want. 
> 
> Is there a way to "detect" this error and use the solution from the previous 
> non-failing iteration? Setting a fixed maximum iteration doesn't seem 
> reasonble because every time level will require different numbers of 
> iterations to converge.
> 
> Thanks,
> Justin

Re: [petsc-users] Use previous solution when encountering "DIVERGED_LINE_SEARCH"

[Matthew Knepley]

On Wed, Nov 30, 2016 at 8:54 PM, Justin Chang  wrote:

> Generally speaking, yes. But this is VIRS where I am enforcing maximum
> principles. From what I have seen, the residual typically exhibit this
> behavior if there are very few violations in the first place.
>

So you are saying that if you have some constraints, you can have a
situation where you cannot satisfy F(u) = 0? This seems wrong to me, but
maybe I do not understand something.


> How would I "terminate on stagnation"?
>

This is what I do not want.

   Matt


> On Wed, Nov 30, 2016 at 8:48 PM, Matthew Knepley 
> wrote:
>
>> On Wed, Nov 30, 2016 at 8:38 PM, Justin Chang 
>> wrote:
>>
>>> By manually terminating I meant setting -snes_max_it to 5 if I know 
>>> DIVERGED_LINE_SEARCH
>>> occurs after 6 iterations. In a transient simulation I cannot do this
>>>
>>
>> Let me elaborate. I mean that using DIVERGED_LINE_SEARCH as an indication
>> of convergence is dicey. It may be that in the problem
>> you looked at this was true, but I see no reason to believe its true in
>> general. Why does your residual quit decreasing?
>>
>>   Thanks,
>>
>>  Matt
>>
>>
>>> On Wed, Nov 30, 2016 at 8:35 PM, Matthew Knepley 
>>> wrote:
>>>
 On Wed, Nov 30, 2016 at 8:27 PM, Justin Chang 
 wrote:

> Hi all,
>
> I am running some transient simulations using SNESVINEWTONRSLS. At
> certain timesteps, I get a "DIVERGED_LINE_SEARCH" which essentially
> "resets" my solution to zero and messes everything up. I notice that this
> happens when the SNES Function norm no longer decreases, and if I were to
> manually terminate the solver right before the final iteration I get the
> answer I want.
>

 Yes, its possible, however isn't that a dangerous way to terminate?
 Couldn't you terminate on stagnation?

   Thanks,

  Matt


> Is there a way to "detect" this error and use the solution from the
> previous non-failing iteration? Setting a fixed maximum iteration doesn't
> seem reasonble because every time level will require different numbers of
> iterations to converge.
>
> Thanks,
> Justin
>



 --
 What most experimenters take for granted before they begin their
 experiments is infinitely more interesting than any results to which their
 experiments lead.
 -- Norbert Wiener

>>>
>>>
>>
>>
>> --
>> What most experimenters take for granted before they begin their
>> experiments is infinitely more interesting than any results to which their
>> experiments lead.
>> -- Norbert Wiener
>>
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

Re: [petsc-users] Use previous solution when encountering "DIVERGED_LINE_SEARCH"

[Justin Chang]

Also, -snes_stol does not seem to work for vinewtonrsls?

On Wed, Nov 30, 2016 at 8:54 PM, Justin Chang  wrote:

> Generally speaking, yes. But this is VIRS where I am enforcing maximum
> principles. From what I have seen, the residual typically exhibit this
> behavior if there are very few violations in the first place.
>
> How would I "terminate on stagnation"?
>
> On Wed, Nov 30, 2016 at 8:48 PM, Matthew Knepley 
> wrote:
>
>> On Wed, Nov 30, 2016 at 8:38 PM, Justin Chang 
>> wrote:
>>
>>> By manually terminating I meant setting -snes_max_it to 5 if I know 
>>> DIVERGED_LINE_SEARCH
>>> occurs after 6 iterations. In a transient simulation I cannot do this
>>>
>>
>> Let me elaborate. I mean that using DIVERGED_LINE_SEARCH as an indication
>> of convergence is dicey. It may be that in the problem
>> you looked at this was true, but I see no reason to believe its true in
>> general. Why does your residual quit decreasing?
>>
>>   Thanks,
>>
>>  Matt
>>
>>
>>> On Wed, Nov 30, 2016 at 8:35 PM, Matthew Knepley 
>>> wrote:
>>>
 On Wed, Nov 30, 2016 at 8:27 PM, Justin Chang 
 wrote:

> Hi all,
>
> I am running some transient simulations using SNESVINEWTONRSLS. At
> certain timesteps, I get a "DIVERGED_LINE_SEARCH" which essentially
> "resets" my solution to zero and messes everything up. I notice that this
> happens when the SNES Function norm no longer decreases, and if I were to
> manually terminate the solver right before the final iteration I get the
> answer I want.
>

 Yes, its possible, however isn't that a dangerous way to terminate?
 Couldn't you terminate on stagnation?

   Thanks,

  Matt


> Is there a way to "detect" this error and use the solution from the
> previous non-failing iteration? Setting a fixed maximum iteration doesn't
> seem reasonble because every time level will require different numbers of
> iterations to converge.
>
> Thanks,
> Justin
>



 --
 What most experimenters take for granted before they begin their
 experiments is infinitely more interesting than any results to which their
 experiments lead.
 -- Norbert Wiener

>>>
>>>
>>
>>
>> --
>> What most experimenters take for granted before they begin their
>> experiments is infinitely more interesting than any results to which their
>> experiments lead.
>> -- Norbert Wiener
>>
>
>

Re: [petsc-users] Use previous solution when encountering "DIVERGED_LINE_SEARCH"

[Justin Chang]

Generally speaking, yes. But this is VIRS where I am enforcing maximum
principles. From what I have seen, the residual typically exhibit this
behavior if there are very few violations in the first place.

How would I "terminate on stagnation"?

On Wed, Nov 30, 2016 at 8:48 PM, Matthew Knepley  wrote:

> On Wed, Nov 30, 2016 at 8:38 PM, Justin Chang  wrote:
>
>> By manually terminating I meant setting -snes_max_it to 5 if I know 
>> DIVERGED_LINE_SEARCH
>> occurs after 6 iterations. In a transient simulation I cannot do this
>>
>
> Let me elaborate. I mean that using DIVERGED_LINE_SEARCH as an indication
> of convergence is dicey. It may be that in the problem
> you looked at this was true, but I see no reason to believe its true in
> general. Why does your residual quit decreasing?
>
>   Thanks,
>
>  Matt
>
>
>> On Wed, Nov 30, 2016 at 8:35 PM, Matthew Knepley 
>> wrote:
>>
>>> On Wed, Nov 30, 2016 at 8:27 PM, Justin Chang 
>>> wrote:
>>>
 Hi all,

 I am running some transient simulations using SNESVINEWTONRSLS. At
 certain timesteps, I get a "DIVERGED_LINE_SEARCH" which essentially
 "resets" my solution to zero and messes everything up. I notice that this
 happens when the SNES Function norm no longer decreases, and if I were to
 manually terminate the solver right before the final iteration I get the
 answer I want.

>>>
>>> Yes, its possible, however isn't that a dangerous way to terminate?
>>> Couldn't you terminate on stagnation?
>>>
>>>   Thanks,
>>>
>>>  Matt
>>>
>>>
 Is there a way to "detect" this error and use the solution from the
 previous non-failing iteration? Setting a fixed maximum iteration doesn't
 seem reasonble because every time level will require different numbers of
 iterations to converge.

 Thanks,
 Justin

>>>
>>>
>>>
>>> --
>>> What most experimenters take for granted before they begin their
>>> experiments is infinitely more interesting than any results to which their
>>> experiments lead.
>>> -- Norbert Wiener
>>>
>>
>>
>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>

Re: [petsc-users] Use previous solution when encountering "DIVERGED_LINE_SEARCH"

[Matthew Knepley]

On Wed, Nov 30, 2016 at 8:38 PM, Justin Chang  wrote:

> By manually terminating I meant setting -snes_max_it to 5 if I know 
> DIVERGED_LINE_SEARCH
> occurs after 6 iterations. In a transient simulation I cannot do this
>

Let me elaborate. I mean that using DIVERGED_LINE_SEARCH as an indication
of convergence is dicey. It may be that in the problem
you looked at this was true, but I see no reason to believe its true in
general. Why does your residual quit decreasing?

  Thanks,

 Matt


> On Wed, Nov 30, 2016 at 8:35 PM, Matthew Knepley 
> wrote:
>
>> On Wed, Nov 30, 2016 at 8:27 PM, Justin Chang 
>> wrote:
>>
>>> Hi all,
>>>
>>> I am running some transient simulations using SNESVINEWTONRSLS. At
>>> certain timesteps, I get a "DIVERGED_LINE_SEARCH" which essentially
>>> "resets" my solution to zero and messes everything up. I notice that this
>>> happens when the SNES Function norm no longer decreases, and if I were to
>>> manually terminate the solver right before the final iteration I get the
>>> answer I want.
>>>
>>
>> Yes, its possible, however isn't that a dangerous way to terminate?
>> Couldn't you terminate on stagnation?
>>
>>   Thanks,
>>
>>  Matt
>>
>>
>>> Is there a way to "detect" this error and use the solution from the
>>> previous non-failing iteration? Setting a fixed maximum iteration doesn't
>>> seem reasonble because every time level will require different numbers of
>>> iterations to converge.
>>>
>>> Thanks,
>>> Justin
>>>
>>
>>
>>
>> --
>> What most experimenters take for granted before they begin their
>> experiments is infinitely more interesting than any results to which their
>> experiments lead.
>> -- Norbert Wiener
>>
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

Re: [petsc-users] Use previous solution when encountering "DIVERGED_LINE_SEARCH"

[Justin Chang]

By manually terminating I meant setting -snes_max_it to 5 if I know
DIVERGED_LINE_SEARCH
occurs after 6 iterations. In a transient simulation I cannot do this

On Wed, Nov 30, 2016 at 8:35 PM, Matthew Knepley  wrote:

> On Wed, Nov 30, 2016 at 8:27 PM, Justin Chang  wrote:
>
>> Hi all,
>>
>> I am running some transient simulations using SNESVINEWTONRSLS. At
>> certain timesteps, I get a "DIVERGED_LINE_SEARCH" which essentially
>> "resets" my solution to zero and messes everything up. I notice that this
>> happens when the SNES Function norm no longer decreases, and if I were to
>> manually terminate the solver right before the final iteration I get the
>> answer I want.
>>
>
> Yes, its possible, however isn't that a dangerous way to terminate?
> Couldn't you terminate on stagnation?
>
>   Thanks,
>
>  Matt
>
>
>> Is there a way to "detect" this error and use the solution from the
>> previous non-failing iteration? Setting a fixed maximum iteration doesn't
>> seem reasonble because every time level will require different numbers of
>> iterations to converge.
>>
>> Thanks,
>> Justin
>>
>
>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>

Re: [petsc-users] Use previous solution when encountering "DIVERGED_LINE_SEARCH"

[Matthew Knepley]

On Wed, Nov 30, 2016 at 8:27 PM, Justin Chang  wrote:

> Hi all,
>
> I am running some transient simulations using SNESVINEWTONRSLS. At
> certain timesteps, I get a "DIVERGED_LINE_SEARCH" which essentially
> "resets" my solution to zero and messes everything up. I notice that this
> happens when the SNES Function norm no longer decreases, and if I were to
> manually terminate the solver right before the final iteration I get the
> answer I want.
>

Yes, its possible, however isn't that a dangerous way to terminate?
Couldn't you terminate on stagnation?

  Thanks,

 Matt


> Is there a way to "detect" this error and use the solution from the
> previous non-failing iteration? Setting a fixed maximum iteration doesn't
> seem reasonble because every time level will require different numbers of
> iterations to converge.
>
> Thanks,
> Justin
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

[petsc-users] Use previous solution when encountering "DIVERGED_LINE_SEARCH"

[Justin Chang]

Hi all,

I am running some transient simulations using SNESVINEWTONRSLS. At certain
timesteps, I get a "DIVERGED_LINE_SEARCH" which essentially "resets" my
solution to zero and messes everything up. I notice that this happens when
the SNES Function norm no longer decreases, and if I were to manually
terminate the solver right before the final iteration I get the answer I
want.

Is there a way to "detect" this error and use the solution from the
previous non-failing iteration? Setting a fixed maximum iteration doesn't
seem reasonble because every time level will require different numbers of
iterations to converge.

Thanks,
Justin

Re: [petsc-users] Check PETSc's saddle point structure

[Matthew Knepley]

On Wed, Nov 30, 2016 at 7:27 AM, Karin  wrote:

> Dear PETSc team,
>
> I am using the "-pc_fieldsplit_detect_saddle_point" feature of fieldsplit
> in order to solve a Stokes-like problem.
>
> I would like to check the saddle point structure automatically detected by
> PETSc.
> o Is there a way of printing the automatically built IS?
>

The -ksp_view will give you the sizes. If you want the actual IS you can
use
http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/PC/PCFieldSplitGetIS.html
after the solve.

  Matt


> o Are there some printings with "-ksp_view" that could give some
> insight on the fields built by PETSc?
>
> Thanks in advance,
> Nicolas
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

[petsc-users] Check PETSc's saddle point structure

[Karin]

Dear PETSc team,

I am using the "-pc_fieldsplit_detect_saddle_point" feature of fieldsplit
in order to solve a Stokes-like problem.

I would like to check the saddle point structure automatically detected by
PETSc.
o Is there a way of printing the automatically built IS?
o Are there some printings with "-ksp_view" that could give some
insight on the fields built by PETSc?

Thanks in advance,
Nicolas

Re: [petsc-users] Petsc with Windows

[E. Tadeu]

On Wed, Nov 30, 2016 at 6:03 AM, Boris Kaus  wrote:

>
> > This is probably a better choice than Cygwin going forward.
> >
> > https://msdn.microsoft.com/en-us/commandline/wsl/about
> >
> > I don't know to what extent PETSc users have experimented with this
> > feature, but it should make it easier to build and distribute PETSc.
> We have tried this in Mainz, and PETSc (with MUMPS/SUPERLU_DIST/mpich)
> compiles out of the box with the new command-line option under windows 10.
> It’s not as fast as linux/mac, but does the job
>

Good to hear this, Boris :)
I'm very interested, do you know how much the performance hit is? Perhaps
by using BLAS from MKL it could be faster? Do you know what compiler is
being used?

Thanks!

Re: [petsc-users] Petsc with Windows

[E. Tadeu]

Hi Elaine,

  The PETSc configured/built in Cygwin can be normally used outside of it.
It can either be statically linked with your software, or linked as a .DLL
and deployed normally :).


On Mon, Nov 28, 2016 at 1:49 PM, Elaine Tang  wrote:

> Hi,
>
> I am developing some software on windows that would like to utilize petsc
> library. Currently I have petsc library configured on cygwin on my windows
> machine.
>
> Is there any binary of petsc for windows so that the software that I
> develop will be more portable and can be run on other windows machine as
> well?
>
> Thanks!
> --
> Elaine Tang
>

Re: [petsc-users] Petsc with Windows

[Boris Kaus]

> This is probably a better choice than Cygwin going forward.
> 
> https://msdn.microsoft.com/en-us/commandline/wsl/about
> 
> I don't know to what extent PETSc users have experimented with this
> feature, but it should make it easier to build and distribute PETSc.
We have tried this in Mainz, and PETSc (with MUMPS/SUPERLU_DIST/mpich) compiles 
out of the box with the new command-line option under windows 10.
It’s not as fast as linux/mac, but does the job

This won’t make me give up my mac yet, but windows seems to head in the right 
direction.

Boris


___

Boris J.P. Kaus

Institute of Geosciences, 
Center for Computational Sciences & 
Center for Volcanoes and Atmosphere in Magmatic Open Systems
Johannes Gutenberg University of Mainz, Mainz, Germany
Office: 00-285
Tel:+49.6131.392.4527

http://www.geo-dynamics.eu
___

Re: [petsc-users] Petsc with Windows

[Mohammad Mirzadeh]

May I propose docker as an alternative approach? https://www.docker.com

There are already petsc images and creating your own environment is not
that hard. As a bonus you get a cross platform solution ... unless your
application is windows specific in which case docker might not be the best
way to go.

On Wed, Nov 30, 2016 at 1:45 AM Jed Brown  wrote:

> Elaine Tang  writes:
>
> > I am developing some software on windows that would like to utilize petsc
> > library. Currently I have petsc library configured on cygwin on my
> windows
> > machine.
>
> This is probably a better choice than Cygwin going forward.
>
> https://msdn.microsoft.com/en-us/commandline/wsl/about
>
> I don't know to what extent PETSc users have experimented with this
> feature, but it should make it easier to build and distribute PETSc.
>
> > Is there any binary of petsc for windows so that the software that I
> > develop will be more portable and can be run on other windows machine as
> > well?
>
> Are you developing an application or a library?
>
-- 
Sent from Gmail Mobile