[aspect-devel] strain rate corner values and velocity boundary conditions

[Glerum, A.C. (Anne)]

Hello all,

Thank you for all the recent mails on the development of Aspect, it's really nice to be kept in the loop so.

Recently I reencountered a problem with the strain rate values in the top corners of our viscoplastic models as was earlier stated by one of our students (see messages below). It greatly complicates some of our models, but we hope we've found the cause.

The model is after Kaus 2010: it is a plastic medium with an inclusion at the bottom in extension (or compression). We enforce extension by using "Prescribed velocity boundary indicators: 0:function, 1:function" and then prescribing a certain horizontal velocity and zero vertical velocity. The bottom boundary is free slip, the top boundary not specified.

What this should produce are two conjugate shears as in the first figure. What it actually produces is shown in the second figure; a broad shear zone reaching into the top corners plus the desired shears. When we prescribe extension velocities on the bottom boundary as well, we get something close to what we want, but still with some strain rate anomaly in the upper corners (figure 3, different scaling).

Now, the first 2 figures are produced with another code, one that can prescribe boundary conditions per component of velocity: in figure 1 the vertical velocity component is free slip and only the horizontal component is prescribed. In figure 2 both are prescribed (zero vertical velocity), as is the case with the Aspect model. We believe that because some material enters through the top near the corners with a vertical velocity component, but no vertical component is allowed along the vertical boundary, strain rate is increased locally, triggering an additional shear band.

So, my question is, am I correct that right now you have to specify all velocity components when prescribing velocity and if so, would you be willing to change this?

Thank you for your help and hope to see you at AGU,

Anne

Anne Glerum, MSc | PhD candidate | Department of Earth Sciences | Utrecht University|  Budapestlaan 4, 3584 CD Utrecht | Room Z.204 | A.C.Glerum at uu.nl |

[cid:7B26DFB5-1AE7-4471-82C3-83E51BD04467 at geo.uu.nl]


[cid:5531CE59-9443-4D3C-8B2B-9380BA1B6623 at geo.uu.nl]
[cid:54A2DE02-B0EE-448E-8AEA-AE1C079E0688 at geo.uu.nl]

On Jul 1, 2013, at 1:36 AM, A.B.M. Graas wrote:

Hi there,

No worries. Actually, I found out later that the problem is not caused by the material model but rather by strain rate values in the corners. This is more or less the same problem and should be easy to reproduce. An demonstration input file is here: http://pastebin.com/5LCvM9fT. Just tested it with the latest version. It might be necessary to alter the visual range of your viewer to find the strain rate values, since they are extremely small. However, in other experiments they can become significantly large and even invalidate the set-up.

Thanks for looking at this and let me know when you need any additional information,

Adriaan





2013/6/30 Timo Heister <heister at math.tamu.edu<mailto:heister at math.tamu.edu>>
Dear Adriaan,

sorry for net getting back to your email earlier.

>>> - 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)

Can you explain what the material model is and what you expect to see
here? This image highlights some bug for sure (be it in your material
model, the solver, or in the output).

> 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.

"Nonlinear iteration" was a left over parameter that did not have any
effect. Therefore, I removed this parameter. You should use "Nonlinear
solver scheme".

Best,
Timo

--
Timo Heister
http://www.math.tamu.edu/~heister/
_______________________________________________
Aspect-devel mailing list
Aspect-devel at geodynamics.org<mailto:Aspect-devel at geodynamics.org>
http://geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel

_______________________________________________
Aspect-devel mailing list
Aspect-devel at geodynamics.org<mailto:Aspect-devel at geodynamics.org>
http://geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://geodynamics.org/pipermail/aspect-devel/attachments/20131031/b357622e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen shot 2013-10-30 at 2.56.12 PM.png
Type: image/png
Size: 15417 bytes
Desc: Screen shot 2013-10-30 at 2.56.12 PM.png
URL: <http://geodynamics.org/pipermail/aspect-devel/attachments/20131031/b357622e/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen shot 2013-10-30 at 3.03.03 PM.png
Type: image/png
Size: 30219 bytes
Desc: Screen shot 2013-10-30 at 3.03.03 PM.png
URL: <http://geodynamics.org/pipermail/aspect-devel/attachments/20131031/b357622e/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2013-10-31 at 10.35.05 AM.png
Type: image/png
Size: 45024 bytes
Desc: Screen Shot 2013-10-31 at 10.35.05 AM.png
URL: <http://geodynamics.org/pipermail/aspect-devel/attachments/20131031/b357622e/attachment-0005.png>