[mesa-users] New Energy Routine Problem

Wed Oct 2 14:29:49 EDT 2013

Hi Dean,

One quick comment -- keep in mind that you are not restricted to using the built-in calculation of eps_grav in mesa/star.  It may be that for your application, the build-in one with its 1st order time differences would require too-small timesteps to give the accuracy you need.  But perhaps you can work around that limitation.  You might be able to turn off the system eps_grav in the surface layers where they aren't doing what you need, and replace it by using the "other_energy" hook to inject a "compressional heating" that would be more accurate than the system eps_grav.  You might be able to invent a recipe for extra heat, as a function of column depth perhaps, by doing simulations with small timesteps in mesa or even better using explicit timesteps with equations such as yours in Townsley & Bildsten 2004.  If you could get such a recipe then you might be able to use it with larger timesteps in mesa/star.  Even if there isn't a simple recipe, you could do a side computation at each mesa/star step to decide on the extra heating for the current step -- the cost of that computation might be more than offset by enabling larger timesteps for the stellar evolution while still keeping the accuracy you need.

If the current hooks in mesa aren't adequate to do what you want, I'll be happy to add new ones for you.  And of course if you come up with a great solution, it should migrate into the mesa standard code so everyone can use it!  

Cheers,
Bill

On Sep 30, 2013, at 8:44 PM, Dean Townsley wrote:

> Hi Bill, and everyone,
> 
> Just to try to help clarify:  we are using the phrase "mesa chosen" in this context to denote timesteps determined based on various variation constraints (so that the timestep is therefore chosen in an automated way) as compared to those capped with a hard limit.  Maybe that wasn't the best choice of wording for that, but the hope     was that the included inlists would help clarify.  Perhaps "variation-determined" is a better term.  But I'm unsure, since "variation" has a special meaning in MESA timesteps and that's not exactly what we mean here since we also have, for example, a Teff change constraint in addition to the general variation constraint.
> 
> 
> Also, for the benefit of others on the list, Broxton is not just using the defaults for everything. (I think Bill knows this and is just referring to the defaults for the "new" timestep parameters.)  He is using timestep constraint parameters similar to those used in the "wd2" test suite problem.  That problem is an accreting WD at "high" accretion rate (2x10^-7 Msun/yr) that has one or two novae and then transitions to steady burning.  That is very similar to the problem we are doing.  So what we are using are not the global defaults, and they at least seem to be appropriate parameter choices for the older code version.  We are not starting from nothing here, we had timsteps that had passed various checks using the older version of the code.  We don't know yet what the appropriate values are for the parameters related to the new mass gain treatment.  That's what we are trying to figure out.  In my mind the first step is to figure out what timestep works, even if we have to impose it directly.
> 
> 
> But I am a little concerned that the comparison we are trying to make in Broxton's plot might be misunderstood.  The constraint-determined timstep cases are just there for reference, the point of the plot is the comparison between the cases with the capped timesteps.  With the old code the Teff is the same whether the timestep is capped at 100 years or 1000 years (or uncapped).  But in the new code the Teff is quite different depending on whether the timestep is capped at 100 or 1000 years.  Also note that the Teff from the old code is consistent with a simple comparison to Townsley & Bildsten 2004 for this M, Mdot, and Tc.
> 
> 
> We'll see where things lead from here.  But if we have to use, say, 10 year timesteps to get the right answer, then I'm concerned about our ability to do gigayears of accretion.
> 
> On a more general note, hopefully we are providing a reasonable demonstration that choosing timestep constraint parameters can take some effort.  Even if you had something that worked fine in an older version of MESA.
> 
> 
> Later,
> Dean
> 
> 
> 
> 
> On 09/30/2013 03:01 PM, Bill Paxton wrote:
>> Hi Broxton,
>> 
>> Thanks for sending the plots.  Keep us informed as you learn more about this.
>> 
>> My only request is to change the legend "MESA CHOSEN" to "DEFAULTS" or
>> perhaps even better, to "INAPPROPRIATE USE OF DEFAULT SETTINGS".  ;p
>> 
>> There is no reason to expect defaults (for timestep selection or mesh resolution)
>> to give you anything that is converged for your particular problem. It isn't mesa's fault 
>> that the defaults aren't converged. Mesa didn't choose to use the defaults; you did! 
>> 
>> I know you aren't really blaming mesa here for having chosen bad timesteps ---
>> I'm just super-sensitive about these things.  And more importantly, I want to stress 
>> once more that it is the user's responsibility to setup controls that make sense ---- 
>> don't just use the defaults!   Someday I'm just going to do in and set all the defaults 
>> to completely bogus values so that it will crash if you don't go through setting each 
>> one to a value of your choice!!!!  (not really; even I'm not that cruel.)
>> 
>> Cheers,
>> Bill
>> 
>> 
>> 
>> 
>> 
>> On Sep 30, 2013, at 12:12 PM, Broxton Miles wrote:
>> 
>>> Update everyone,
>>> 
>>> Attached are the results of a slightly different scenario than I showed everyone before. In this case, I took a .6 solar mass white dwarf and allowed to accrete 10^-10 solar masses per year up until the beginning of the first outburst, about 2.4e6 years. This was done with clean checkouts of versions 5329 and 5456 and the starting model was cooling.mod found in the wd_cool_0.6M test case in the test suite. I ran this scenario allowing MESA to choose its own time step as well as two other cases where the max timestep was 1000 and 100 years, and I think the results are rather interesting. In version 5329, all three cases result in fairly similar values despite the large difference in timestep size. In contrast, version 5456's results are differ greatly with the size of the timesteps, but do seem to become more consistent with smaller timestep size. If anyone would like to reproduce these results or try more cases, I'm attaching the inlists as well, and the as I stated before the starting model can be found in the test suite. Also, I'm still working with getting to know the new controls, but I wanted to give everyone some more information.
>>> 
>>> Thanks again for your time,
>>> Broxton
>>> 
>>> 
>>> 
>>> On Thu, Sep 26, 2013 at 7:48 PM, Broxton Miles <bjmiles at crimson.ua.edu> wrote:
>>> Hi everyone,
>>> 
>>> Thanks for the replies; it's all been very informative. I'll definitely try out these other controls over the next day or so, and let you all know how that goes.
>>> 
>>> Broxton
>>> 
>>> 
>>> On Thu, Sep 26, 2013 at 5:41 PM, Dean Townsley <Dean.M.Townsley at ua.edu> wrote:
>>> 
>>> I haven't worked this out in detail, so don't kill me if this ends up
>>> being on the wrong track...
>>> 
>>> On 09/26/2013 05:16 PM, Bill Paxton wrote:
>>> > So the model accepted by the newton iterations is self-consistent with respect to
>>> > changes in entropy and the corresponding T*Ds/Dt terms in the energy equation that determines dL/dm.
>>> > The energy from the lost entropy is captured in eps_grav, and that eps_grav is
>>> > reflected in the dL/dm equation so that energy is balanced in the final model
>>> > to reflect the change in entropy of the material added during the step.
>>> > All very circular in the fashion of implicit equations.
>>> 
>>> I should look at the code, but from your description, it sounds like
>>> that cell only knows about the local dL/dm, not the dL/dm further out,
>>> that the fluid element would have passed through.  If the integral is
>>> not done, I'm unsure if the magic of the implicit solution will have a
>>> chance to work.
>>> 
>>> I should make up a test that compares appropriately to the Townsley &
>>> Bildsten 04 semi-analytic work.  I haven't gotten that far yet :)
>>> 
>>> > Of course as usual it is the case that the timesteps need to be small enough to give a converged result.
>>> > Our 1st order differencing for time derivatives may force small timesteps to give adequate accuracy.
>>> > No magic to avoid that.
>>> I agree that there is a timestep for which the approach is valid, but I
>>> am concerned that the proper constraint will make this timestep always
>>> small, even when it doesn't need to be.  But I need to understand the
>>> timestep controls better before I could even say I think this might be a
>>> problem.
>>> 
>>> Sorry if me whingeing about my vague worries is too much babble. But
>>> thanks for listening :)
>>> 
>>> Dean
>>> 
>>> ------------------------------------------------------------------------------
>>> October Webinars: Code for Performance
>>> Free Intel webinars can help you accelerate application performance.
>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>>> the latest Intel processors and coprocessors. See abstracts and register >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> mesa-users mailing list
>>> mesa-users at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>> 
>>> 
>>> <version_compare_2.png><inlist_v5329><inlist_v5456>------------------------------------------------------------------------------
>>> October Webinars: Code for Performance
>>> Free Intel webinars can help you accelerate application performance.
>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
>>> the latest Intel processors and coprocessors. See abstracts and register >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk_______________________________________________
>>> mesa-users mailing list
>>> mesa-users at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131002/ab766b86/attachment.html>