[aspect-devel] Internal heating in aspect

Sat Aug 25 13:17:13 PDT 2018

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geodynamics.org/pipermail/aspect-devel/attachments/20180825/41f8abc5/attachment-0001.html>