[aspect-devel] Far different velocity magnitudes & timestep sizes of the same Ra

Mon Apr 24 11:10:21 PDT 2017

As far as I know we always use the full pressure (unless one chooses the 
density in the material model to only be the density deviations from the 
reference profile, in which case the computed pressure would be the 
dynamic pressure), and looking at the manual, I agree that we could 
document this better.
Rene, Timo, please correct me if I am wrong.

@Max: sorry, didn't see your email, we basically had the same idea you 
posted.

On 04/24/2017 11:32 AM, Scott King wrote:
>
> Julia;
>
> I had thought that the new business formulation was only using only 
> the dynamic pressure.  Is that not the case?  I had a hard time 
> figuring that out from the manual.
>
> Best,
>
> Scott
>
>> On Apr 24, 2017, at 12:39 PM, Juliane Dannberg 
>> <dannberg at gfz-potsdam.de <mailto:dannberg at gfz-potsdam.de>> wrote:
>>
>> Timo, Shangxin,
>>
>> if you have the model running already, another thing to check might 
>> be the ratio between the dynamic and static pressure (it is something 
>> that came up in a discussion between Rene, Wolfgang and me, and Rene 
>> mentioned that the problem we are talking about has quite a small 
>> Rayleigh number, so small dynamic pressures). This ratio is changed 
>> when scaling alpha vs. gravity, and if it is too small, it might not 
>> even be the solver tolerance that is the problem.
>>
>> Juliane
>>
>>
>> On 04/24/2017 09:09 AM, Timo Heister wrote:
>>> Shangxin,
>>>
>>> I looked a little bit more into your example. Some observations:
>>> 1. You are using the "simple" model for a nondimensional computation.
>>> It is probably a better idea to use "nondimensional" instead. I will
>>> try to see if that makes a difference.
>>> 2. I haven't quite figured out how to quantify "don't make gravity too
>>> large", but as I expected, the difference increases the larger the
>>> gravity is. I think our pressure scaling or linear solver tolerance
>>> needs to take the size of the gravity into account but it currently
>>> doesn't.
>>> 3. A finer solver tolerance is likely important (see 2).
>>> 4. It looks like the buoyancy term can not be resolved adequately on
>>> the current mesh (if you plot T or rho, you can see that it jumps from
>>> 0 to 0.5 within a single cell. See attached.
>>> 5. If you plot RMS over time, you can see that the timesteps are quite
>>> large (especially for alpha>0.1). I am not sure if this is connected
>>> to 4) or not.
>>>
>>> Anyways, I will get back to you when I figure out more.
>>>
>>> On Fri, Apr 21, 2017 at 6:00 PM, Shangxin Liu<sxliu at vt.edu>  wrote:
>>>> Hi Timo, John, and others,
>>>>
>>>> I quickly made several new tests using the new Boussinesq approximation
>>>> formulation of the higher 1e-7 Stokes linear tolerance and 0.1 CFL number.
>>>> The results are compiled in the attachment. 1e-7 higher tolerance and 0.1
>>>> CFL number don't help a lot. There is still order-of-magnitude difference of
>>>> the velocity statistics and time step size between g 7000&alpha 1, g
>>>> 70000&alpha 0.1, and g 700000&alpha 0.01. I can further try global
>>>> refinement 4 to see but global refinement 3 with quadratic element may be
>>>> already enough resolution. Something weird is still happening.
>>>>
>>>> Best,
>>>> Shangxin
>>>>
>>>>
>>>> On Fri, Apr 21, 2017 at 1:44 PM, John Naliboff<jbnaliboff at ucdavis.edu>
>>>> wrote:
>>>>> Hi Scott, Hi Shangxin,
>>>>>
>>>>> Shangxin - Thank you for the clarification regarding the models. CFL=0.5
>>>>> is certainly more reasonable, but it still might be worth it to try a value
>>>>> like 0.1 just to make sure nothing odd is going on there.
>>>>>
>>>>> Scott - Thanks for the explanation and definitely interested to see what
>>>>> solution(s) arise.
>>>>>
>>>>> Cheers,
>>>>> John
>>>>>
>>>>> *************************************************
>>>>> John Naliboff
>>>>> Assistant Project Scientist, CIG
>>>>> Earth & Planetary Sciences Dept., UC Davis
>>>>>
>>>>> On 04/21/2017 04:23 AM, Scott King wrote:
>>>>>
>>>>>
>>>>> John;
>>>>>
>>>>> See the section of the Aspect manual for the 2D incompressible Cartesian
>>>>> benchmarks.   This is a trick used to try to circumvent the density term in
>>>>> the time derivative of the temperature equation, which is not constant (as
>>>>> it would be for Bousinessq).   The small alpha makes that term nearly
>>>>> constant while keeping the buoyancy term as Ra.  In 2D the manual shows this
>>>>> works up to Ra=7000*1e10, alpha-1e-10.   Trying to use this for 3D spherical
>>>>> it breaks around 10^3/1e-3.   It suggests either the 3D spherical matrix is
>>>>> more illconditioned to begin with or something about the iterations and
>>>>> tolerance levels for the solver is different between 2D and 3D.   Or it
>>>>> needs to be different between the two and isn’t.
>>>>>
>>>>> Scott
>>>>>
>>>>>
>>>>>
>>>>> On Apr 20, 2017, at 12:16 PM, John Naliboff<jbnaliboff at ucdavis.edu>
>>>>> wrote:
>>>>>
>>>>> On a side note, I personally have trouble interpreting results that vary
>>>>> the Ra number by orders of magnitude through terms other than the viscosity.
>>>>> While this is certainly an interesting numerical case study, is there a
>>>>> different motivation for varying the Ra number through terms other than the
>>>>> viscosity?
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> _______________________________________________
>>> Aspect-devel mailing list
>>> Aspect-devel at geodynamics.org
>>> 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
>
>
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel

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