<div dir="ltr">Hello again,<br><br><div>to simplify the process I created a pull request on bitbucket, only for the domain error function (e.g. there is no change to the TSSetCheckStage function.</div><div><br></div><div>Here is the link to the pull request:</div><div><br></div><div><a href="https://bitbucket.org/petsc/petsc/pull-request/263">https://bitbucket.org/petsc/petsc/pull-request/263</a></div><div><br></div><div>Cheers,</div><div><br></div><div>Pierre</div></div><br><div class="gmail_quote">On Fri Feb 13 2015 at 14:59:31 Pierre Barbier de Reuille <<a href="mailto:pierre.barbierdereuille@gmail.com">pierre.barbierdereuille@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<br><br><div>sorry to bombard you with emails. But here is another patch, still on the master branch, which adds TSSetFunctionDomainError and TSFunctionDomainError functions. I tried them with Runge-Kutta and they work. I think I added the correct calls to all the methods, or at least all the ones calling TSPostStage.</div><div><br></div><div>Note that I needed to modify the Runge-Kutta call to remove the goto. For some reason, on my system (Ubuntu 14.04, gcc 4.8.2), the time step would not get updated if compiled with optimisations. Removing the goto and replacing it with break/continue prevented that issue.</div><div><br></div><div>Please tell me what you think of the modification.</div><div><br></div><div>Cheers,</div><div><br></div><div>Pierre</div></div><div dir="ltr"><div><br></div><br><div class="gmail_quote">On Thu Feb 12 2015 at 15:37:48 Pierre Barbier de Reuille <<a href="mailto:pierre.barbierdereuille@gmail.com" target="_blank">pierre.barbierdereuille@<u></u>gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<br><br>so here is a patch against the MASTER branch to add time and current solution vector to the TSAdaptCheckStage. What I did is add the same arguments as for the TSPostStage call.<div>I hope I haven't made any mistake.<br><div><br></div><div>In addition, if the stage is rejected, PETSc only tried again, changing nothing, and therefore failing in the exact same way. So I also added a reduction of the time step if the stage is rejected by the user.</div><div><br></div><div>Note: I tested the code with the RungeKutta solver only for now.</div><div><div><br></div><div>Cheers,</div><div><br></div><div>Pierre<br><div><br></div></div></div></div></div><div dir="ltr"><br><div class="gmail_quote">On Thu Feb 12 2015 at 03:45:13 Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Pierre Barbier de Reuille <<a href="mailto:pierre.barbierdereuille@gmail.com" target="_blank">pierre.barbierdereuille@<u></u>gmail<u></u><u></u><u></u>.com</a>> writes:<br>
<br>
> Ok, I made progress. But:<br>
><br>
>  1 - whatever I do, I have very slightly negative values, and therefore all<br>
> my steps get rejected (values like 1e-16)<br>
>  2 - As I expected, SNES is only used with implicit methods. So if I use<br>
> explicit Runge-Kutta, then there is no solution vector stored by the SNES<br>
> object.<br>
><br>
> Reading the code for the Runge-Kutta solver, it seems that TSPostStage is<br>
> where I can retrieve the current state, and TSAdaptCheckStage where I can<br>
> reject it. But is this something I can rely on?<br>
<br>
TSPostStage is only called *after* the stage has been accepted (the step<br>
might be rejected later, e.g., based on a local error controller).<br>
<br>
We should pass the stage solution to TSAdaptCheckStage so you can check<br>
it there.  I can add this, but I'm at a conference in Singapore this<br>
week and have a couple more pressing things, so you'd have to wait until<br>
next week unless someone else can do it (or you'd like to submit a<br>
patch).<br>
<br>
We should also add TSSetSetFunctionDomainError() so you can check it<br>
there (my preference, actually).<br>
</blockquote></div></div></blockquote></div></div></blockquote></div>