[mesa-users] New Energy Routine Problem

Tue Oct 1 16:02:10 EDT 2013

Hi Dean,

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.

perhaps "VARIABLE" since the timestep is varying according to a variety of controls and properties of the models.
as opposed to "FIXED" where you've set a max timestep that is smaller than what would be selected by the variable scheme.

and of course it isn't really the label in the plot I'm concerned about.   I was taking advantage of an opportunity to preach once again about the importance of user's doing the work of selecting controls to match the problem.   I know that you and Broxton appreciate this --- but it seems to be important to restate it.

> 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.

Exactly the right approach!!! Bravo!!!

> 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.

Were you limiting the timesteps in the previous version using this?

            ! limit on added mass to keep L > Cp T Mdot in new material
            L_div_CpTMdot_limit = 2 ! reduce next timestep if L/(Cp T Mdot) < this in new material
            L_div_CpTMdot_hard_limit = -1 ! retry with smaller timestep if ratio < this

> 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.

Please keep sending updates to the users list as you explore this.
It is turning into a valuable case study in how to decide how to do a problem with mesa,
or even whether or not the problem is actually suitable for doing with mesa!

> Later,
> Dean

Thanks again.  It is great to have you working on this!

Cheers,
Bill

> 
> 
> 
> 
> 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/20131001/dda351ae/attachment.html>