[aspect-devel] Checkerboard at large scale

Fri Apr 6 11:46:51 PDT 2018

Hi Lev,

Following Juliane’s point about variations in mass flux between the two side boundaries due to AMR, I think the safest thing to do is just use a free surface. 

I would still go through the process of using a simple model to get the mass fluxes as close as possible and then building up complexity. If the mass fluxes are way off, you will see this in the average free surface elevation as well as in the post-processors. 

One more quick note - In the past I’ve had solver convergence issues if the transition between outflow and inflow on the side is too sharp. In a model with a height of 600 km and a resolution of 1-2 km, I would probably use a 50-100 km transition ‘length” where the velocity varies linearly between outflow and inflow. Even if the non-linear solvers converge, I’ve seen this transition ‘distance’ affect the long-term model solution in some cases. Anyhow, something worth exploring a bit in 2D test cases.

Happy testing and glad you brought this issue back to our attention!

Cheers,
John 

> On Apr 6, 2018, at 11:25 AM, Juliane Dannberg <judannberg at gmail.com> wrote:
> 
> Hi Lev, 
> 
> to extend on what John said:
>> 
>> If it was me, I would also start by using a uniform mesh 
> Yes, I would try this!
> The reason is this: You prescribe a function for the velocity on both sides of the model, and it is interpolated using the finite element. So if your function can not be exactly reproduced by the finite element shape function, it will be approximated, and you might get different results for the left and right boundary. So if you have different element sizes at the different boundaries, you might get a different mass flux across the boundaries just based on that interpolation, even if the analytical function that you prescribe would lead to a nonzero in-/outflux. 
>> 
>> If you don’t want to alter the velocity boundary conditions on the side, you could simply add inflow or outflow along the model base to account for the mass flux difference.
> That would be one solution, the easiest way would probably be to use a prescribed traction at the bottom and just prescribe the initial lithostatic pressure. 
>> 
>> I hope this helps and let us know if you have any additional questions or other issues pop up along the way.
>> 
>> Juliane/Rene/Wolfgang/Timo/etc - I believe this points back to the issue discussed here: https://github.com/geodynamics/aspect/issues/1872 <https://github.com/geodynamics/aspect/issues/1872>
>> 
> Yes, at least this is what I suspect too (one way to test this would be to see if the integrated mass flux over all model boundaries is very small, but nonzero).
>> Perhaps this is something to revisit at the Hack or sooner? If the composition along the side boundaries varies with time, it may be difficult to enforce mass conversation with a free surface. The suggestion to modify the boundary conditions slightly to account for the mass flux imbalance seems like a the easiest solution. 
> Yes. Let's think about how to do this best. 
> 
> Cheers, 
> Juliane
> 
>> 
>>> On Apr 6, 2018, at 9:45 AM, Lev Karatun <lev.karatun at gmail.com <mailto:lev.karatun at gmail.com>> wrote:
>>> 
>>> Hi Juliane,
>>> 
>>> If density of the material entering the model is different from material leaving it, the b.c. can't be both volume and mass conserving. Am I understanding something wrong?
>>> 
>>> Best regards,
>>> Lev Karatun.
>>> 
>>> 2018-04-06 2:18 GMT-04:00 Juliane Dannberg <judannberg at gmail.com <mailto:judannberg at gmail.com>>:
>>> 
>>>> 
>>>> 1. Are the applied boundary conditions mass and/or volume conserving?
>>>> Volume conserving. To be honest, I never put too much thought into this -- how do I determine if I should conserve mass or volume? Is there some sort of rule of thumb?
>>> From what you're saying, my guess would be that the boundary conditions could be the problem (as I think John was implying). 
>>> You can check if if they conserve mass for example by using the mass flux postprocessor; it will give you the mass flux though each of the boundaries. Usually you should conserve mass (and if the model is incompressible, that would also mean conserving the volume). 
>>> 
>>> Alternatively, you can also try leaving the top or bottom boundary open and see if material flows in or out there, that will also give you a clue if the boundary conditions you're prescribing at the sides are reasonable. 
>>> 
>>> Best, 
>>> Juliane
>>> 
>>> 
>>>> 2018-04-02 12:43 GMT-04:00 John Naliboff <jbnaliboff at ucdavis.edu <mailto:jbnaliboff at ucdavis.edu>>:
>>>> Hi Lev,
>>>> 
>>>> Typically 'checker boarding' is seen in the pressure field and arises when using plasticity with low-order (Q1P0) elements. This looks a bit different and could be related to any number of issues. However, I have not seen anything like this specifically. From your description, it sounds like you would expect convergence in the upper region (lithosphere?) and a downwelling in the model center that transitions to outflow in the outflux regions?
>>>> 
>>>> So, a few follow-up questions:
>>>> 
>>>> 1. Are the applied boundary conditions mass and/or volume conserving?
>>>> 2. Are there similar (or other odd) patterns in the pressure, temperature, etc fields?
>>>> 3. What element type?
>>>> 4. Linear or non-linear rheology?
>>>> 5. If non-linear, did the non-linear solver converge to a reasonable value?
>>>> 
>>>> Depending on the exact setup, there are a number way to start going about diagnosing the issue. I would start with simplifying the material properties and boundary conditions to make sure you are getting the expected velocity field. For example, use an isothermal temperature profile and constant density/viscosity/etc. This could be done in combination with only applying the imposed inflow/outflow one one side.
>>>> 
>>>> Cheers,
>>>> John
>>>> 
>>>> On 03/29/2018 07:05 PM, Lev Karatun wrote:
>>>>> Hi everyone, 
>>>>> 
>>>>> I was trying to run some 3-D compression models, but all I'm getting is a checkerboard pattern (see screenshot attached). Boundary conditions are as follows: 
>>>>> left, right walls: influx through the top half, outflux through bottom.
>>>>> all other walls: free slip.
>>>>> I tried increasing the resolution but it didn't help. I also thought about decreasing the CFL number but the instability happens at the first timestep, so it doesn't seem relevant. I was wondering if someone faced a similar problem in their research? What did you do to overcome it?
>>>>> 
>>>>> Thanks in advance!
>>>>> 
>>>>> Best regards,
>>>>> Lev Karatun.
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Aspect-devel mailing list
>>>>> Aspect-devel at geodynamics.org <mailto:Aspect-devel at geodynamics.org>
>>>>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel>
>>>> 
>>>> _______________________________________________
>>>> Aspect-devel mailing list
>>>> Aspect-devel at geodynamics.org <mailto:Aspect-devel at geodynamics.org>
>>>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel>
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Aspect-devel mailing list
>>>> Aspect-devel at geodynamics.org <mailto:Aspect-devel at geodynamics.org>
>>>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel>
>>> 
>>> ----------------------------------------------------------------------
>>> Juliane Dannberg
>>> Project Scientist, UC Davis
>>> jdannberg.github.io <https://jdannberg.github.io/>
>>> 
>>> 
>>> _______________________________________________
>>> Aspect-devel mailing list
>>> Aspect-devel at geodynamics.org <mailto:Aspect-devel at geodynamics.org>
>>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel>
> 
> 
> ----------------------------------------------------------------------
> Juliane Dannberg
> Project Scientist, UC Davis
> jdannberg.github.io <https://jdannberg.github.io/>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geodynamics.org/pipermail/aspect-devel/attachments/20180406/bee755dc/attachment-0001.html>