[aspect-devel] Difficulties with tracers and material model

[A.B.M. Graas]

Hi,

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.


> - Running particle tracers crash with the message "Particle count
>> unexpectedly
>> changed". This happens mostly when timesteps are large (CFL number is
>> large).
>> I suspect that the tracers postprocessor might not be ready for particles
>> leaving through velocity boundaries?
>>
>
> 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.


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.


> - In many of my models I model plasticity by using a Material Model
>> implementing the new Interface. Often, though not always, there are
>> unexpected
>> irregularities (viscosity jumps) in the corners. I found  that the
>> evaluate()
>> method of the Material Model is never called with a position Point in the
>> corners before the Stokes equation is solved. However, afterwards the
>> evaluate() method is called by the Viscosity postprocessor.
>>
>
> 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.
>
> Can you explain how this leads to problems in your models?


If I understand this correctly the problem is limited to the visualization?
(here is an example VTU screenshot:
http://img196.imageshack.us/img196/5954/corners.png)


> - If "Max nonlinear iterations" and/or "Nonlinear solver scheme" is set in
>> the
>> input file, one is not able to turn off the nonlinear iterative solver by
>> setting "Nonlinear iteration" to false.
>>
>
> 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.


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.

Thanks in advance! Adriaan


2013/6/10 Wolfgang Bangerth <bangerth at math.tamu.edu>

>
> Hi Adriaan,
>
>
>  - Running particle tracers crash with the message "Particle count
>> unexpectedly
>> changed". This happens mostly when timesteps are large (CFL number is
>> large).
>> I suspect that the tracers postprocessor might not be ready for particles
>> leaving through velocity boundaries?
>>
>
> 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.
>
>
>
>  - In many of my models I model plasticity by using a Material Model
>> implementing the new Interface. Often, though not always, there are
>> unexpected
>> irregularities (viscosity jumps) in the corners. I found  that the
>> evaluate()
>> method of the Material Model is never called with a position Point in the
>> corners before the Stokes equation is solved. However, afterwards the
>> evaluate() method is called by the Viscosity postprocessor.
>>
>
> 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.
>
> Can you explain how this leads to problems in your models?
>
>
>
>
>  - If "Max nonlinear iterations" and/or "Nonlinear solver scheme" is set
>> in the
>> input file, one is not able to turn off the nonlinear iterative solver by
>> setting "Nonlinear iteration" to false.
>>
>
> 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.
>
> In any case, thanks for the feedback!
> Cheers
>  W.
>
> --
> ------------------------------**------------------------------**
> ------------
> Wolfgang Bangerth               email:            bangerth at math.tamu.edu
>                                 www: http://www.math.tamu.edu/~**bangerth/<http://www.math.tamu.edu/~bangerth/>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://geodynamics.org/pipermail/aspect-devel/attachments/20130613/69c3948f/attachment.html>