<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">Hi,</span><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Thanks for your reply. To demonstrate the problems below I have set-up a parameter file, and a patch for the simple material model. I reduced all the code to get a clean set-up and also used a fresh checkout from the ASPECT repository.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div class="gmail_extra" style="font-family:arial,sans-serif;font-size:13px"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">- Running particle tracers crash with the message "Particle count unexpectedly<br>
changed". This happens mostly when timesteps are large (CFL number is large).<br>I suspect that the tracers postprocessor might not be ready for particles<br>leaving through velocity boundaries?<br></blockquote><br></div>
Is a "velocity boundary" one where the normal velocity is (or may be) nonzero? Eric has already suggested one solution. We may want to make this more robust but I'd like to know a bit more about the case you are considerig.</blockquote>
<div><br></div></div><div>The solution of Eric was exactly what I needed. I used "Prescribed velocity boundary indicators" with functions that define velocities normal to the boundaries on the sides and tangential on the bottom.<br>
</div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- In many of my models I model plasticity by using a Material Model<br>implementing the new Interface. Often, though not always, there are unexpected<br>irregularities (viscosity jumps) in the corners. I found that the evaluate()<br>
method of the Material Model is never called with a position Point in the<br>corners before the Stokes equation is solved. However, afterwards the<br>evaluate() method is called by the Viscosity postprocessor.<br></blockquote>
<br></div>You mean the point is never in a corner when assembling the linear systems, but it may be in a corner when using a postprocessor? That is correct -- we assemble linear systems using Gauss quadrature formulas where all quadrature points are in the interior of a cell. But we do output data using evaluation points that are the vertices of cells.<br>
<br>Can you explain how this leads to problems in your models?</blockquote><div><br></div></div><div>If I understand this correctly the problem is limited to the visualization? (here is an example VTU screenshot: <a href="http://img196.imageshack.us/img196/5954/corners.png" target="_blank">http://img196.imageshack.us/img196/5954/corners.png</a>)</div>
<div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- If "Max nonlinear iterations" and/or "Nonlinear solver scheme" is set in the<br>input file, one is not able to turn off the nonlinear iterative solver by<br>setting "Nonlinear iteration" to false.<br>
</blockquote><br></div>I think here it would be useful to have an input file (maybe based on a simple one from the tests/ directory, or based on box.prm) along with an explanation of what you expect to happen.</blockquote>
<div><br></div></div><div>What I intend to do is flipping on and off the "Nonlinear iteration" parameter in the input file. However, even when "Nonlinear iteration" is false, and "Nonlinear solver scheme" is set (f.e. to "iterated IMPES") nonlinear iterations are executed. This is the case for box.prm and the parameter file I send you.</div>
<div><br></div><div>Thanks in advance! Adriaan</div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/6/10 Wolfgang Bangerth <span dir="ltr"><<a href="mailto:bangerth@math.tamu.edu" target="_blank">bangerth@math.tamu.edu</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Adriaan,<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Running particle tracers crash with the message "Particle count unexpectedly<br>
changed". This happens mostly when timesteps are large (CFL number is large).<br>
I suspect that the tracers postprocessor might not be ready for particles<br>
leaving through velocity boundaries?<br>
</blockquote>
<br></div>
Is a "velocity boundary" one where the normal velocity is (or may be) nonzero? Eric has already suggested one solution. We may want to make this more robust but I'd like to know a bit more about the case you are considerig.<div class="im">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- In many of my models I model plasticity by using a Material Model<br>
implementing the new Interface. Often, though not always, there are unexpected<br>
irregularities (viscosity jumps) in the corners. I found that the evaluate()<br>
method of the Material Model is never called with a position Point in the<br>
corners before the Stokes equation is solved. However, afterwards the<br>
evaluate() method is called by the Viscosity postprocessor.<br>
</blockquote>
<br></div>
You mean the point is never in a corner when assembling the linear systems, but it may be in a corner when using a postprocessor? That is correct -- we assemble linear systems using Gauss quadrature formulas where all quadrature points are in the interior of a cell. But we do output data using evaluation points that are the vertices of cells.<br>
<br>
Can you explain how this leads to problems in your models?<div class="im"><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- If "Max nonlinear iterations" and/or "Nonlinear solver scheme" is set in the<br>
input file, one is not able to turn off the nonlinear iterative solver by<br>
setting "Nonlinear iteration" to false.<br>
</blockquote>
<br></div>
I think here it would be useful to have an input file (maybe based on a simple one from the tests/ directory, or based on box.prm) along with an explanation of what you expect to happen.<br>
<br>
In any case, thanks for the feedback!<br>
Cheers<span class="HOEnZb"><font color="#888888"><br>
W.<br>
<br>
-- <br>
------------------------------<u></u>------------------------------<u></u>------------<br>
Wolfgang Bangerth email: <a href="mailto:bangerth@math.tamu.edu" target="_blank">bangerth@math.tamu.edu</a><br>
www: <a href="http://www.math.tamu.edu/~bangerth/" target="_blank">http://www.math.tamu.edu/~<u></u>bangerth/</a><br>
<br>
</font></span></blockquote></div><br></div>