<div dir="ltr">Thank you Barry. I will see if I can make the changes to the incorporate re-building the Jacobian(s). <br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 5, 2017 at 2:30 PM, Smith, Barry F. <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
> On Nov 3, 2017, at 3:34 PM, Bikash Kanungo <<a href="mailto:bikash@umich.edu">bikash@umich.edu</a>> wrote:<br>
><br>
> Hi Barry,<br>
><br>
> So for Newton solvers that would work by explicitly setting the boundary conditions in my gradient(function) and Jacobian vectors. But in quasi-Newton solvers where the Jacobian is built from a history of previous Jacobians and current gradient vector, I can't enforce a new boundary condition. I can change the current gradient vector appropriately but I don't see a way handle the the Jacobian.<br>
<br>
</span>   There is no way to handle the "Jacobian" because it comes from the history which presumably includes different boundary conditions. So if you are changing the boundary conditions in your form function within the same nonlinear solve the only thing I can see that you could do is each time you change the boundary conditions you tell the quasi-Newton method to remove any current approximation to the Jacobian and start building it again. Of course this assumes you only change the boundary conditions after a bunch of function evaluations and that the Quasi-Newton implementation has support for removing the current approximation (you may need to add this option to the implementation and make a pull request).<br>
<span class="HOEnZb"><font color="#888888"><br>
  Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Thanks,<br>
> Bikash<br>
><br>
><br>
><br>
> On Fri, Nov 3, 2017 at 6:20 PM, Smith, Barry F. <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
><br>
>   You should not need to "tamper" with the solution process to achieve this.<br>
><br>
>   I would just change how my FormFunction and FormJacobian behave to implement the different boundary conditions. Why would that not work?<br>
><br>
>    Barry<br>
><br>
> > On Nov 3, 2017, at 4:39 PM, Bikash Kanungo <<a href="mailto:bikash@umich.edu">bikash@umich.edu</a>> wrote:<br>
> ><br>
> > Hi Matt,<br>
> ><br>
> > I want to update the Dirichlet boundary condition on the solution vector on-the-fly. One way to do it is to destroy the current snes solver and create a new one with the new Dirichlet boundary condition (which means setting a new solution vector with a different size, size  = # of non-Dirichlet rows). But is it possible to work with the current snes and instead enforce the new Dirichlet boundary condition on the current solution vector?<br>
> ><br>
> > Thanks,<br>
> > Bikash<br>
> ><br>
> > On Fri, Nov 3, 2017 at 5:19 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> > What do you want to do to it?<br>
> ><br>
> >   Matt<br>
> ><br>
> > On Fri, Nov 3, 2017 at 5:14 PM, Bikash Kanungo <<a href="mailto:bikash@umich.edu">bikash@umich.edu</a>> wrote:<br>
> > Hi,<br>
> ><br>
> > I'm trying to solve a nonlinear problem using BFGS Quasi-Newton solver. I would like to tamper the solution vector x on-the-fly, based on some criterion. Is there a way to do so? Will SNESGetSolution(SNES snes, Vec * x) allow me to do so for each SNES iteration?<br>
> ><br>
> > Thanks,<br>
> > Bikash<br>
> ><br>
> > --<br>
> > Bikash S. Kanungo<br>
> > PhD Student<br>
> > Computational Materials Physics Group<br>
> > Mechanical Engineering<br>
> > University of Michigan<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> > -- Norbert Wiener<br>
> ><br>
> > <a href="https://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">https://www.cse.buffalo.edu/~<wbr>knepley/</a><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Bikash S. Kanungo<br>
> > PhD Student<br>
> > Computational Materials Physics Group<br>
> > Mechanical Engineering<br>
> > University of Michigan<br>
> ><br>
><br>
><br>
><br>
><br>
> --<br>
> Bikash S. Kanungo<br>
> PhD Student<br>
> Computational Materials Physics Group<br>
> Mechanical Engineering<br>
> University of Michigan<br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div><div><div><font color="#666666">Bikash S. Kanungo<br></font></div><font color="#666666">PhD Student<br></font></div><font color="#666666">Computational Materials Physics Group<br></font></div><font color="#666666">Mechanical Engineering <br></font></div><font color="#666666">University of Michigan<br><br></font></div></div>
</div>