[mesa-users] accretion

[Bill Wolf]

Hi all,

This is very interesting, and if there is some work to be done on the topic, I'm very eager to help out, as I plan to do more work with wd2-like events for extended periods of time. The attention to detail in the outer layers of the steady-state accretors makes sense given what the code is trying to do, but to follow the long-term evolution for high accretion rates, something has to give. Dean and Bill, if you're interested in trying to implement an alternate scheme for steady-state accretion, I would certainly help out since I will be a prime benefactor of such a prescription, though I wouldn't know where to start.

Regards,

Bill Wolf

On Oct 2, 2013, at 1:35 PM, Dean Townsley <Dean.M.Townsley at ua.edu> wrote:

> 
> Hi Dave,
> 
> This is a good question, and is good to think through, so I'll take a stab at my viewpoint.
> 
> 
> I think things are straightforward as long as the accretion is "slow" in the sense that
>   Mdot * dt < dm(1)
> where Mdot is the accretion rate, dt is the timestep, and dm(1) is the mass in the "outermost" zone.  In this case having the material arrive at the same entropy as the surface can happen in the obvious way, you just add mass to the outermost zone, and then sometime down the line rezone things in a sensible way.  So we get the simple timestep constraint dt < dm/Mdot, just for our first-order differences for the outermost zones to make sense.
> 
> (If you want to think of a pretend physical problem here, I think of it as a corona in reverse.  Where material is settling into the surface of the star through the photosphere, and outside this the material is free to lose energy via Xrays or something that doesn't "count" toward the stellar photospheric luminosity.  In practice we tend to use it for "bursty" accretion, in which the photosphere is allowed to cool between accretion events.  Or use this as a baseline and then add additional heating terms on top of it.  For things deep in the star, the surface state is not critical.)
> 
> The case I would like to do is one in which the accretion rate is "large" compared to the meshing of the outer part of the star for the timesteps I am taking.  i.e. Mdot*dt is larger than even the top few zones taken together.  This makes sense because Mdot is constant, so the thermal state of the outermost zones is fairly well-determined and varying slowly, although the identity of the material in the outermost zones is changing.
> 
> The way I understand this has been handled in other codes of the Sugimoto and Nomoto heritage is that the coordinate used for gridding the star is not a truly Lagrangian one.  (Forgive me if this is oversimplified, as I realize that I have not written a stellar evolution code myself as both you, Dave, and Bill have! (gulp))  They use q = 1-m(r)/M.  Then the rate of change in mass, Mdot, appears in various terms in the stellar structure equations, rather than as mass added to any particular zone, and material is naturally added at the same entropy as the photosphere without any particularly special treatment.
> 
> This is similar to the way we did things in Townsley & Bildsten '04.  By writing everything in pressure coordinates (which are not lagrangian), the relevant Mdot-dependent terms appear in the structure equations.  We then assume quasi-steady-state and can integrate the equations to get a solution by assuming some boundary conditions.
> 
> 
> So I think the essential hurdle is that I want to take timesteps that are much bigger than dm(1)/Mdot.  I think Bill's older implementation did that at the cost of making some not-so-general approximations.  Nominally the right thing will probably be, as Bill suggests, to implement some special mass addition method like the "old one" for the problem we are trying to do -- and, for example, the similar mesa test suite problem "wd" (basically a classical nova).  This may not be necessary for "wd2" (basically a supersoft source) since it goes into runaway in the first 100 years, so the timesteps are small for other reasons.  Though if one wants to run the SSS for a long time (with the test suite problem does not do) one might want to take bigger timesteps.
> 
> 
> Hopefully that helps with the general picture a little.  Bill can chime in and fix all the things that I have glossed over or misrepresented :)  (sorry!)
> 
> Dean
> 
> 
> 
> 
> On 10/02/2013 02:31 PM, David Arnett wrote:
>> Historically we have used accretion as a way to change mass slowly, often without worrying about the entropy of the accreted matter or more rapid time dependence. That is actually a complex multidimensional radiation-hydrodynamics problem itself, as Dean knows perhaps too well ;-)
>> 
>> I have a question: are the short time steps due to accuracy constraints or causality constraints? If the former, we have to integrate through them (or change the algorithm). Are they due to instability (physical or numerical)? If the latter, we also can change the algorithm. I am curious about what MESA is trying to do here. Is it clumping?  Is it numerical inconsistency? Something else?
>> 
>> -- 
>> David Arnett
>> Regents Professor
>> Steward Observatory
>> University of Arizona
>> 
>> Facts are stubborn, but statistics are more pliable.  Mark Twain
>> Facts do not cease to exist because they are ignored.  Aldous Huxley
>> 
>> 
>> ------------------------------------------------------------------------------
>> 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=60134791&iu=/4140/ostg.clktrk
>> 
>> 
>> _______________________________________________
>> mesa-users mailing list
>> mesa-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
> 
> ------------------------------------------------------------------------------
> 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=60134791&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/b0b0d5e7/attachment.html>