[aspect-devel] Internal heating in aspect (Ludovic Jeanniot)
Rene Gassmoeller
rene.gassmoeller at mailbox.org
Wed Sep 12 15:13:34 PDT 2018
Hi Scott,
thanks, I think that might be something. The density we use in the
equation and postprocessing is correct, we use a reference profile for
all equations but the buoyancy term just like the ALA assumes. But I had
not tried only including the shear heating term when computing the heat
flux. It makes sense of course, in theory all heating terms contribute
(I had tried that), except for the adiabatic term, which only converts
heat into work. You mentioned it is nasty to write out, would you mind
pointing me to some place to look it up anyway? Because the conventional
heating term would have units W/m^3, while the term in the heat flux
would need to be W/m^2.
Thanks!
Rene
On 09/12/2018 11:55 AM, Scott King wrote:
> Hi Rene;
>
> I checked the flux calculation code itself. For the flux calculations
> we use the thermal diffusion term (-N,z * T), the advective term
> (rho_ref * N *T * N*V_z) and the viscous dissipation term which is
> really nasty to write out, so I will assume it’s o.k. (It is
> included in the tables in the paper, I think…) The dissipation terms
> drops out in the business cases, of course. So it seems like if BA is
> good there are two things to check. The dissipation term and whether
> you use rho_ref in the advection term.
>
> Scott
>
>> On Sep 11, 2018, at 2:44 PM, Rene Gassmoeller
>> <rene.gassmoeller at mailbox.org <mailto:rene.gassmoeller at mailbox.org>>
>> wrote:
>>
>> Scott,
>>
>> I have opened the pull request with the improved heat flux
>> computation, and it is available here:
>> https://github.com/geodynamics/aspect/pull/2660 . It already includes
>> the improvements Wolfgang made to the advection stabilization term,
>> so this should be a good version to start the testing.
>>
>> I have run into some issues trying to reproduce compressible
>> benchmark results with the new method though (I explain them in the
>> pull request), I do not suppose you have another magic fix for them
>> at hand? That would be much appreciated :-).
>>
>> Best,
>>
>> Rene
>>
>>
>> On 09/06/2018 07:18 PM, Scott King wrote:
>>> 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 <mailto: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
>>>>>> <mailto: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 <mailto: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
>>>>>> <mailto:bangerth at colostate.edu>
>>>>>> www:
>>>>>> http://www.math.colostate.edu/~bangerth/
>>>>>> <http://www.math.colostate.edu/%7Ebangerth/>
>>>>>> _______________________________________________
>>>>>> 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 <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
>>>>
>>>> --
>>>> Rene Gassmoeller
>>>> https://gassmoeller.github.io/
>>
>> --
>> Rene Gassmoeller
>> https://gassmoeller.github.io/
>> _______________________________________________
>> 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
--
Rene Gassmoeller
https://gassmoeller.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geodynamics.org/pipermail/aspect-devel/attachments/20180912/ccc85559/attachment-0001.html>
More information about the Aspect-devel
mailing list