[aspect-devel] Internal heating in aspect

[Scott King]

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 <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 Gassmoeller
> https://gassmoeller.github.io/ <https://gassmoeller.github.io/>_______________________________________________
> 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/b72f5484/attachment.html>