[aspect-devel] Internal heating in aspect (Ludovic Jeanniot)
Scott King
sking07 at vt.edu
Thu Sep 6 19:18:46 PDT 2018
Great! Glad I could contribute instead of being my usual grumpy PITA.
We’re all set up to run Zhong cases as quickly as we can get them through the queues.
Best
Scott
Sent from my iPhone
> On Sep 6, 2018, at 10:08 PM, Rene Gassmoeller <rene.gassmoeller at mailbox.org> wrote:
>
> Hi Scott,
>
> very interesting, thanks for sharing that thought! That looks like a significant improvement for the heat flux postprocessors. You were right, the changes to the postprocessor were not very complicated, and I will open a pull request for them tomorrow, when I have cleaned up a few things. I just wanted to share some first results with you:
>
> These are the original convergence studies for the Blankenbach 1a case with ASPECT:
>
> # Nu Vrms name (refinement level):
> 4.78661864e+00 4.34590432e+01 case1a_ref4.stat
> 4.87927972e+00 4.29377468e+01 case1a_ref5.stat
> 4.88993106e+00 4.28733838e+01 case1a_ref6.stat
> 4.88680525e+00 4.28659548e+01 case1a_ref7.stat
> 4.88440900e+00 4.28649470e+01 case1a_reference.stat
>
> Both Nu and Vrms converge, but rather slowly for the very low Rayleigh number (10^4). Below are the values with Wolfgang's improvements in pull request 2650 (taking the max of artificial diffusion and physical diffusion instead of the sum):
>
> # Nu Vrms name (refinement level):
> 5.30885322e+00 4.28499932e+01 case1a_ref3.stat
> 5.06735289e+00 4.28656773e+01 case1a_ref4.stat
> 4.93712396e+00 4.28650353e+01 case1a_ref5.stat
> 4.88440900e+00 4.28649470e+01 case1a_reference.stat
>
> As you can see the Vrms is now much closer to the reference value already at low resolutions (even at refinement level 3, which is only 8x8 cells). But the Nusselt number is now worse, and converging from above the reference value instead of from below. With your suggested improvements to the postprocessors (taking the volume averaged total heat flux in the boundary cell, instead of the conductive heat flux at the surface):
>
> # Nu Vrms name (refinement level):
> 4.89728221e+00 4.28499932e+01 case1a_ref3.stat
> 4.88535143e+00 4.28656773e+01 case1a_ref4.stat
> 4.88443365e+00 4.28650353e+01 case1a_ref5.stat
> 4.88440900e+00 4.28649470e+01 case1a_reference.stat
> The Vrms is not affected, because it is only a change in the postprocessor, but now the Nu number is significantly closer to the reference value even at low resolutions. All in all, we now get a better accuracy with a 16x16 grid, than with a 128x128 grid before the changes. I would say that is progress :-).
> The other Blankenbach cases show similar improvements (still running though), and I have not yet tested the behavior for other geometries, but I do not think there is a conceptual problem. I will not have time to do much more benchmarking, because I am traveling from the end of next week on, but do you think you or Grant would have some time to give a few of the cases of the Zhong 2008 paper another try once the changes are in the main version?
>
> Thanks again for the reference!
>
> Best,
> Rene
>
>> On 09/05/2018 04:47 PM, Scott King wrote:
>>
>> As for calculating fluxes at the boundaries, I looked at the heat flux code a bit and I’m wondering... I will share this paper with you all.
>>
>> https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1365-246X.1987.tb01375.x
>>
>> It might be less relevant to second-order elements than linear elements but, a lot of the same arguments I’m seeing in the posts the last few days are bringing back memories. This is what is done by default in CitcomS (unless you explicitly call the CFB method). I suspect it should be fairly trivial for someone who is good with deal.ii to implement because it is pretty standard finite element stuff, i.e., calculate fluxes at the internal integration points and project the values to the nodes.
>>
>> Yes, the artificial diffusivity is an issue but I think this explains why even when we turn it off we get relatively poor Nusselt numbers while getting excellent agreement with depth-averaged properties and mean values.
>>
>> Scott
>>
>>> On Sep 5, 2018, at 2:56 PM, Max Rudolph <maxrudolph at ucdavis.edu> wrote:
>>>
>>> OK, you are right that there will always be some region with more artificial than physical heat transport.
>>> What about instead looking at the ratio of physical to artificial heat flux through each boundary?
>>> For Rene's anisotropic "SUEV" implementation, even in the presence of large entropy viscosity, the artificial heat transport can be very small as long as u.gradT is small. In particular, even though entropy viscosity is fairly large at the boundaries, the velocities are tangential to the boundary, so there is very little artificial diffusion.
>>>
>>> Max
>>>
>>>> On Wed, Sep 5, 2018 at 10:41 AM Wolfgang Bangerth <bangerth at colostate.edu> wrote:
>>>> On 09/05/2018 07:12 AM, Max Rudolph wrote:
>>>> >
>>>> > Rene and I discussed this idea on Monday and I don't think that this is
>>>> > the right thing to do. It would lead to an unexpected relationship
>>>> > between the temperature gradient (and hence temperature structure of the
>>>> > lithosphere) and the physical thermal conductivity. Maybe more helpful
>>>> > would be a separate output of the non-physical contribution to the heat
>>>> > flux through each boundary, or within the entire domain as the ratio of
>>>> > the norm of the artificial heat flux divided by the norm of the total
>>>> > heat flux. I still think that a warning message when this quantity
>>>> > exceeds, say, 1% would help users understand that they should expect
>>>> > unphysical results.
>>>>
>>>> But this warning message would be printed on pretty much every single
>>>> simulation in which the mesh does not completely resolve boundary and
>>>> internal layers -- which is essentially every simulation ever done in
>>>> the field of mantle convection.
>>>>
>>>> If it was a rare occasion where artificial viscosity is needed to make a
>>>> simulation stable, then we wouldn't use it. But the reality is that all
>>>> realistic global-scale simulations must necessarily have some kind of
>>>> artificial diffusion (SUPG, EV, dG schemes, ...) that is larger than the
>>>> physical diffusion at least in parts of the domain because resolving the
>>>> boundary layers is not possible on a global scale and will not be
>>>> possible for a long time to come. The idea of artificial diffusion
>>>> schemes is to make boundary layers as large as the cells of the mesh so
>>>> that they are resolved, rather than leading to over/undershoots. It is
>>>> *needed* to avoid Gibb's phenomenon if you can't make the mesh small enough.
>>>>
>>>> That does not mean that (i) the scheme we currently use is the best
>>>> idea, (ii) we can't improve the situation. But I do not think that
>>>> printing a warning for essentially every single simulation is useful.
>>>>
>>>> (I'll note that we also use artificial diffusion schemes for the
>>>> compositional fields for which the physical diffusion is zero -- so the
>>>> artificial diffusion is *always* larger than the physical one.)
>>>>
>>>> Best
>>>> W.
>>>>
>>>> --
>>>> ------------------------------------------------------------------------
>>>> Wolfgang Bangerth email: bangerth at colostate.edu
>>>> www: http://www.math.colostate.edu/~bangerth/
>>>> _______________________________________________
>>>> 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
>
> --
> Rene Gassmoeller
> https://gassmoeller.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geodynamics.org/pipermail/aspect-devel/attachments/20180906/7e0b8a24/attachment.html>
More information about the Aspect-devel
mailing list