<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 28, 2017 at 5:15 AM, Maximilian Hartig <span dir="ltr"><<a href="mailto:imilian.hartig@gmail.com" target="_blank">imilian.hartig@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Sorry to bother you again, but I have checked and rechecked my formulation and it corresponds to what I have found in literature. The only difference is that my flow criteria is not evaluated using the trial stress and the current yield stress but rather the corrected stress and the updated yield stress. I am convinced this is what causes the problem.<div>Unfortunately I do not have any idea on how to go about implementing this. First I don’t know how to access the solution from the past iteration</div></div></blockquote><div><br></div><div>I think you can do what you want using</div><div><br></div><div> <a href="http://www.mcs.anl.gov/petsc/petsc-master/docs/manualpages/TS/TSSetPostStep.html">http://www.mcs.anl.gov/petsc/petsc-master/docs/manualpages/TS/TSSetPostStep.html</a></div><div><br></div><div>In your function, you would TSGetSolution() and then copy it into an auxiliary vector you</div><div>set. This avoids the problem of composition you had before.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div> and secondly I don’t know how to do the elastic predictor step.</div></div></blockquote><div><br></div><div>You can always create another SNES and do a subsolve, maybe in</div><div><br></div><div> <a href="http://www.mcs.anl.gov/petsc/petsc-master/docs/manualpages/TS/TSSetPreStep.html#TSSetPreStep">http://www.mcs.anl.gov/petsc/petsc-master/docs/manualpages/TS/TSSetPreStep.html#TSSetPreStep</a></div><div><br></div><div>which you then copy into an auxiliary vector, just as above.</div><div><br></div><div>Tell me if I am missing something.</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div> I tried doing it with auxiliary fields that get updated every timestep but I gather that is not a good idea. Could you please point me in some direction? </div><div><br></div><div>I appreciate you patience with my questioning.</div><div><br></div><div>Thanks,</div><div>Max</div><div><div class="gmail-h5"><div><br></div><div><div><blockquote type="cite"><div>On 22. Aug 2017, at 13:52, Maximilian Hartig <<a href="mailto:imilian.hartig@gmail.com" target="_blank">imilian.hartig@gmail.com</a>> wrote:</div><br class="gmail-m_2793265001548261999Apple-interchange-newline"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><div><br class="gmail-m_2793265001548261999Apple-interchange-newline">On 17. Aug 2017, at 13:51, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:</div><br class="gmail-m_2793265001548261999Apple-interchange-newline"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 17, 2017 at 3:13 AM, Maximilian Hartig<span class="gmail-m_2793265001548261999Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:imilian.hartig@gmail.com" target="_blank">imilian.hartig@gmail.<wbr>com</a>></span><span class="gmail-m_2793265001548261999Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Thanks for your help Matt.<br><div><blockquote type="cite"><div>On 16. Aug 2017, at 16:17, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:</div><br class="gmail-m_2793265001548261999gmail-m_-3501194453730676254Apple-interchange-newline"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 16, 2017 at 8:56 AM, Maximilian Hartig<span class="gmail-m_2793265001548261999gmail-m_-3501194453730676254Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:imilian.hartig@gmail.com" target="_blank">imilian.hartig@gmail.c<wbr>om</a>></span><span class="gmail-m_2793265001548261999gmail-m_-3501194453730676254Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br><br>I have a problem with several fields that I solve with PetscFE and TS. I now need to access the solution from the previous timestep to compute the residual for the current timestep.<br>I tried a TSMonitor with the following code in it:<br><br>TSGetDM(ts,&dm);<br>DMClone(dm,&dm_aux);<br>DMGetDS(dm,&prob_aux);<br>DMSetDS(dm_aux,prob_aux);<br>DMCreateGlobalVector(dm_aux,&o<wbr>ld_solution);<br>VecCopy(u,oldsolution);<br>PetscObjectCompose((PetscObjec<wbr>t) dm, “A”, (PetscObject) old_solution);<br><br>VecDestroy(&old_solution);<br>DMDestroy(&dm_aux);<br><br>hoping that it would create an auxiliary field that I could access in the evaluation of the residual. It did that but messed with the discretisation of the initial problem in some way. So I figure that adding auxiliary fields to a dm after having fed it to a TS context is not something you should be doing.<br><br>Is there a way to access the fields of the solution for the previous timestep during the evaluation of the current residual?<br></blockquote><div><br></div><div>First, I can show you how to do what you are asking for. I think you can simply</div><div><br></div><div>PetscObjectQuery((PetscObject) dm, "old_solution", (PetscObject *) &old_solution);</div><div>if (!old_solution) {</div><div> <span class="gmail-m_2793265001548261999Apple-converted-space"> </span>DMCreateGlobalVector(dm, &old_solution);</div><div> <span class="gmail-m_2793265001548261999Apple-converted-space"> </span>PetscObjectCompose((PetscObj<wbr>ect) dm, "old_solution", old_solution);</div><div>}</div><div>VecCopy(u, oldsolution);</div></div></div></div></div></blockquote><br><div>Unfortunately, this produces an error and tells me “An object cannot be composed with an object that was composed with it."</div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Second, I think a better way to do this than composition is to use</div><div><br></div><div> <span class="gmail-m_2793265001548261999Apple-converted-space"> </span>DMGetNamedGlobalVector(dm, "old_solution", &old_solution);</div></div></div></div></div></blockquote><div><br></div><div>Yes, this seems to work and I do not get an error while running the monitor. Also the discretisation seems to be fine. But the old solution now is not available as an auxiliary field.</div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Third, I can say that I am profoundly troubled by this. This interferes with the operation of</div><div>the time integrator, and I cannot see a reason for this. If you are keeping track of the integral</div><div>of some quantity, I would update that in TSPostStep() and request that integral instead of the</div><div>previous solution. We do this for some non-Newtonian rheologies.</div></div></div></div></div></blockquote><div><br></div><div>I have an “if” condition in my residual which I need to evaluate to determine the correct formulation for my residuals. I use actual fields to keep track of the integrals. But when I use the actual field to evaluate the “if” condition, due to the implicit nature of the solver I jump “back and forth” over that condition. I need the “if” condition to be independent from the field for which it determines the residual.</div><div>The actual application is as follows:</div><div> I have, amongst others, a displacement and a stress field.</div><div>I evaluate for my stress given a displacement increment delta u.</div><div>If the resulting stress is > yield stress, I need a plasticity formulation, if it is smaller, I can use elasticity.</div></div></div></blockquote><div><br></div><div>Hmm, I think this is a formulation problem. You should be using the "correct" formulation at the implicit step, since otherwise</div><div>the residual will be inconsistent with what you tested when evaluated at the new step. I have the same kind of elasto-plastic</div><div>system in PyLith (<a href="http://www.geodynamics.org/cig/software/pylith/" target="_blank">http://www.geodynamics.org/<wbr>cig/software/pylith/</a>) which we solve implicitly without much problem.</div></div></div></div></div></blockquote><div><br></div>Possible, but I rechecked the formulation and it looks fine to me. In literature, this kind of algorithm uses an elastic predictor step to determine whether to use the elastic or the plastic formulation. The elastic “trial” stress is compared with the yield stress from the past timestep. In my current setup, I do not compare the elastic “trial” stress with the past yield stress but the current stress (including plastic correction) with the current yield stress. I think this is what leads to my problem. When I cheat and just tell petsc to use the plastic formulation from the time on where I expect plastic behaviour, I get convergence and the results look reasonable.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">So I tried to implement a flow condition which would not change during the nonlinear solver iteration steps. If the first, elastic predictor step results in yielding then, in my understanding, from there on we should expect plastic behaviour and not jump “back and forth” between plastic and elastic behaviour.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">I have taken a look at pylith and it seems to use an explicit formulation for dynamic plasticity. I try to use an implicit formulation solving for displacement, stress, plastic strain and the plastic consistency operator at once. I am not aware of a possibility within the petsc framework to have an internal solver to compute stress state and internal variables depending on the displacement rate and then return to the outer iteration to solve for the correct displacements. This is how I found it done in literature. Is there a possibility to have such an “internal” snes?</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Thanks,</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Max<br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> <span class="gmail-m_2793265001548261999Apple-converted-space"> </span>Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>Thanks,</div><div>Max</div><div><br></div><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> <span class="gmail-m_2793265001548261999gmail-m_-3501194453730676254Apple-converted-space"> </span>Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks,<br>Max</blockquote></div><br><br clear="all"><span class="gmail-m_2793265001548261999gmail-HOEnZb"><font color="#888888"><div><br></div>--<span class="gmail-m_2793265001548261999gmail-m_-3501194453730676254Apple-converted-space"> </span><br><div class="gmail-m_2793265001548261999gmail-m_-3501194453730676254gmail_signature"><div dir="ltr"><div>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</div><div><br></div><div><a href="http://www.caam.rice.edu/~mk51/" target="_blank">http://www.caam.rice.edu/~mk51<wbr>/</a></div></div></div></font></span></div></div></div></blockquote></div><br></div></blockquote></div><br><br clear="all"><div><br></div>--<span class="gmail-m_2793265001548261999Apple-converted-space"> </span><br><div class="gmail-m_2793265001548261999gmail_signature"><div dir="ltr"><div>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</div><div><br></div><div><a href="http://www.caam.rice.edu/~mk51/" target="_blank">http://www.caam.rice.edu/~<wbr>mk51/</a></div></div></div></div></div></div></blockquote></div></div></blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>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</div><div><br></div><div><a href="http://www.caam.rice.edu/~mk51/" target="_blank">http://www.caam.rice.edu/~mk51/</a><br></div></div></div>
</div></div>