[aspect-devel] Internal heating in aspect

Sat Aug 25 18:46:12 PDT 2018

Rene, Scott, and Ian,
Thank you for your help with this problem. I will re-run the case at global
refinement level 3 with the DG elements for the energy equation. I will
also re-run with higher resolution in the boundary layers. Our cluster is
unfortunately having a scheduler problem at the moment, so this won't
happen until Monday in all likelihood.

Scott - when you write "We find generally better results with a nearly
uniform radial mesh than the aspect default mesh pretty much across the
board," do you mean that the results are better without AMR, or are you
doing some depth-dependent refinement to ensure nearly uniform element size?

Best
Max

On Sat, Aug 25, 2018 at 1:25 PM Ian Rose <ian.rose at berkeley.edu> wrote:

> It is also possible that the accuracy could be improved by using the
> consistent-boundary-flux method (CBF) for calculating the fluxes in
> postprocessing. The CBF can be seen as a form of projection for the
> solution into the flux space. It essentially constructs a new linear
> system, the solution to which is the fluxes at the boundaries. That system
> can be made to be diagonal, so it is cheap to solve.
>
> I found that using CBF in calculating the dynamic topography significantly
> improved the convergence of the solution (quadratic rather than linear, if
> memory serves). The mathematics for computing the heat flux is essentially
> identical, so a lot of the dynamic topography code could be copied
> whole-cloth into the heat flux postprocessor, in case anyone wants to give
> it a shot.
>
> Best,
> Ian
>
> On Sat, Aug 25, 2018 at 4:01 PM Scott King <sdk at vt.edu> wrote:
>
>> Hi Rene, Max, Wolfgang, and Diogo;
>>
>> Grant found when looking at the Zhong 2008 “Benchmark” calculations that
>> he gets better agreement with mean temperature and mean RMS velocity than
>> he does with surf/cmb Nusselt number.  We find generally better results
>> with a nearly uniform radial mesh than the aspect default mesh pretty much
>> across the board.  As we go to higher and higher resolution (5 or 6
>> refinements), we get convergence of the surf and cmb heatflow and good
>> agreement with other codes.  We are puzzling about it because the mean
>> temperature and mean velocity profiles (fn of r) are spot on with the ones
>> from CitcomS, so the fluxes should really be correct.  The numerical
>> diffusion still being included sounds like a possibility. On the other
>> hand, that explanation puzzles me because the 2D Cartesian cases are spot
>> on.  It made me wonder if there is a scaling issue that only shows up in
>> the spherical case?  On my list of things to do is to check into that but
>> life interrupted my to do list.
>>
>> Interestingly we get a significantly higher mean temperatures
>> (essentially the profile shifted by 10%) for the C cases (Ra=10^5) and
>> we’ve never quite figured out why.  That sort of concerns me because all
>> the recent spherical papers I’ve seen only address the Ra=7000 cases and
>> assume this tell us enough about how these codes behave at higher Ra, which
>> seems to me a bit optimistic.   We’ve also never seen any codes try to
>> reproduce the 10^5 results or to use more than a single grid either :)   Of
>> course that makes me wonder which code is correct. (LOL)  Convergence
>> studies seem to be out of favor.
>>
>> Scott
>>
>> On Aug 25, 2018, at 1:58 PM, Rene Gassmoeller <
>> rene.gassmoeller at mailbox.org> wrote:
>>
>> Hi Max,
>>
>> let me cc this to the mailing list, as it might be of interest to others.
>>
>> I found this old email thread on the mailing list that seems to discuss
>> the same issue:
>> http://lists.geodynamics.org/pipermail/aspect-devel/2012-November/000138.html
>> (there are some additional messages when you scroll through the thread). In
>> short: At the time Ian found that this is a problem when the boundary layer
>> is underresolved. Since the element at the surface are larger than the
>> elements at the CMB they do resolve a different temperature gradient for
>> the boundary layer if the boundary layer is not sufficiently resolved, and
>> we compute the heat flux based on the temperature gradient.
>>
>> However, thinking about it again, I do not think this can be the only
>> reason. If the difference were caused by numerical resolution alone, the
>> average temperature should change, until the two heat fluxes are in balance
>> as you mentioned. But another idea I had was that the computed heat flux is
>> a postprocessor that only considers physical diffusion (i.e. diffusion due
>> to thermal conductivity), while in the assembly we also include the
>> numerical diffusion to stabilize the equation. So maybe the difference
>> between the heat fluxes is caused by numerical diffusion (and it is so
>> large because the cells are relatively coarse)? If that were the case the
>> difference should increase/decrease with higher/lower resolution, as the
>> stabilization scales with the element size. Unfortunately that is not a
>> criterion to distinguish between the two possible causes (obviously
>> resolution of the temperature gradient across the boundary layer also
>> scales with element size). You could try to re-run the model with
>> discontinuous temperature elements, that should disable the numerical
>> diffusion. Let me know if that makes sense.
>>
>> Best,
>>
>> Rene
>>
>> On 08/24/2018 06:46 PM, Max Rudolph wrote:
>>
>> Rene and Wolfgang,
>> We're running some models in 3D spherical geometry in aspect with
>> internal heating and are unable to reproduce thermal histories consistent
>> with what we saw in identically configured calculations in CitcomS. It is
>> possible that there is some aspect of our model setup that is inconsistent,
>> but we are using the same depth profile of viscosity, same boundary
>> conditions, and same initial conditions. The ASPECT models cool much faster
>> (which also drives up viscosity). We are trying to get understand these
>> results, and I was looking at the heat transport in the 3D spherical model
>> discussed in section 5.3.2 of the aspect manual 'simple convection in the
>> 3D spherical shell'. In figure 40, it appears that this calculation has
>> been run to nearly statistically steady state. Is this correct? I am
>> wondering, basically, how to interpret the imbalance between reported
>> surface and CMB heat flow. To follow up on this, I ran the cookbook .prm
>> file from 5.3.2 (shell_simple_3d) for 5 Gyr, which appears to be very close
>> to or at statistically steady state at the end of the calculation. Due to
>> resource constraints, I only ran at global refinement level 3 (definitely
>> under-resolved, mea culpa). However, at the end of the calculation, there
>> is still a significant imbalance between the surface and core mantle
>> boundary heat flows. This is a model with no internal heating, so at
>> statistically steady state, the surface and cmb heat flows should balance
>> to conserve energy. Do you have any insight into why we might be seeing
>> this behavior? I've attached the input .prm file, the statistics file, and
>> a plot showing the average temperature and surface and cmb heat flows.
>> Thank you for thinking about this!
>>
>> Best
>> Max
>>
>> p.s. I sent this to both of you because it looked to me like Wolfgang
>> contributed the cookbook. Please let me know if there is someone else that
>> might be better positioned to help with this.
>>
>> <image.png>
>>
>>
>>
>>
>> --
>> Rene Gassmoellerhttps://gassmoeller.github.io/
>>
>> _______________________________________________
>> 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
>> 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/20180825/892e5e62/attachment.html>