<div dir="ltr">Hey Barry,<div><br></div><div>thanks for the offer to have a look at the code. I ran SNESTEST today: user-defined failed, 1.0 and -1.0 seemed to work fine. My first step will have to be to find out what's wrong with my jacobian. If I've still got issues after that, I'll try to set up an easy-to-experiment code</div><div><br></div><div>The code is a DG0 FVM formulation set up in Firedrake (a "fork" of FEniCS). I was assuming UFL would sort the Jacobian for me.</div><div>Lesson learnt: always do a SNESTEST.</div><div><br></div><div><br></div><div>Ozzy</div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, 29 May 2015 at 19:21 Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On May 29, 2015, at 4:19 AM, Asbjørn Nilsen Riseth <<a href="mailto:riseth@maths.ox.ac.uk" target="_blank">riseth@maths.ox.ac.uk</a>> wrote:<br>
><br>
> Barry,<br>
><br>
> I changed the code, but it only makes a difference at the order of 1e-10 - so that's not the cause. I've attached (if that's appropriate?) the patch in case anyone is interested.<br>
><br>
> Investigating the function values, I see that the first Newton step goes towards the expected solution for my function values. Then it shoots back close to the initial conditions.<br>
<br>
   When does it "shoot back close to the initial conditions"? At the second Newton step? If so is the residual norm still smaller at the second step?<br>
<br>
> At the time the solver hits tolerance for the inactive set; the function value is 100-1000 at some of the active set indices.<br>
> Reducing the timestep by an order of magnitude shows the same behavior for the first two timesteps.<br>
><br>
> Maybe VI is not the right approach. The company I work with seem to just be projecting negative values.<br>
<br>
   The VI solver is essentially just a "more sophisticated" version of "projecting negative values" so should not work worse then an ad hoc method and should generally work better (sometimes much better).<br>
<br>
   Is your code something simple you could email me to play with or is it a big application that would be hard for me to experiment with?<br>
<br>
<br>
<br>
  Barry<br>
<br>
><br>
> I'll investigate further.<br>
><br>
> Ozzy<br>
><br>
><br>
> On Thu, 28 May 2015 at 20:26 Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
>   Ozzy,<br>
><br>
>      I cannot say why it is implemented as >=  (could be in error). Just try changing the PETSc code (just run make gnumake in the PETSc directory after you change the source to update the library) and see how it affects your code run.<br>
><br>
>    Barry<br>
><br>
> > On May 28, 2015, at 3:15 AM, Asbjørn Nilsen Riseth <<a href="mailto:riseth@maths.ox.ac.uk" target="_blank">riseth@maths.ox.ac.uk</a>> wrote:<br>
> ><br>
> > Dear PETSc developers,<br>
> ><br>
> > Is the active set in NewtonRSLS defined differently from the reference* you give in the documentation on purpose?<br>
> > The reference defines the active set as:<br>
> > x_i = 0 and F_i > 0,<br>
> > whilst the PETSc code defines it as x_i = 0 and F_i >= 0 (vi.c: 356) :<br>
> > !((PetscRealPart(x[i]) > PetscRealPart(xl[i]) + 1.e-8 || (PetscRealPart(f[i]) < 0.0)<br>
> > So PETSc freezes the variables if f[i] == 0.<br>
> ><br>
> > I've been using the Newton RSLS method to ensure positivity in a subsurface flow problem I'm working on. My solution stays almost constant for two timesteps (seemingly independent of the size of the timestep), before it goes towards the expected solution.<br>
> > From my initial conditions, certain variables are frozen because x_i = 0 and f[i] = 0, and I was wondering if that could be the cause of my issue.<br>
> ><br>
> ><br>
> > *:<br>
> > - T. S. Munson, and S. Benson. Flexible Complementarity Solvers for Large-Scale Applications, Optimization Methods and Software, 21 (2006).<br>
> ><br>
> ><br>
> > Regards,<br>
> > Ozzy<br>
><br>
> <0001-Define-active-and-inactive-sets-correctly.patch><br>
<br>
</blockquote></div></div></div>