[mesa-users] Convergence issues when simulating massive eruptions by modifying .mod file

Thu Apr 18 13:11:39 EDT 2013

Hi Kent,

I absolutely agree: we can't count on the convergence of the code even if
the starting model is physical. But intuitively it seems reasonable to
expect the solution to be found if the model is realistic and the time step
is arbitrarily low. Of course, that's not always the case.

Alexey

On Thu, Apr 18, 2013 at 11:49 AM, Kent G. Budge <kgbudge at lanl.gov> wrote:

>  A more general observation.
>
> MESA is solving a large set of highly nonlinear equations. This is a
> notoriously difficult numerical problem. You're searching for the
> intersection of the zero surfaces of a very large number of equations in a
> very large solution space. Formally, there's no guarantee there even *is*such an intersection (though, since we're modeling a physical system, we
> expect there to be one) and there's no guarantee any particular numerical
> method, with possibly the exception of symplectic methods, will actually
> take you to the solution, if it exists, except in the linear limit.
>
> Upshot: If your initial guess is not very close to the solution, almost
> any numerical method you pick to try to find that solution is liable to
> fail.
>
> The starting models calculated by MESA rely on very good guesses (or at
> least very well-behaved guesses) of the initial solution. Thereafter the
> assumption is that the previous solution will be close enough to the new
> solution for the current time step that the solver will succeed. If not --
> and this happens routinely -- the code backtracks and uses a smaller time
> step so that the new solution will be even closer to the previous solution.
> Repeat until a solution finally converges or the time step is below (by
> default) about 1e-12 years or so.
>
> If you toss out a big chunk of mass, you've got a starting solution that
> is nowhere near your final solution. It's a marvel if MESA is able to find
> a solution at all. Smoothing the outer zones sometimes works because it
> sometimes gives you a starting guess that is just close enough to the
> solution.
>
> Better to do what Bill advises, and take the mass off gradually. Your
> initial guess never gets too far from the solution that way. This applies
> to any other physical process that produces abrupt changes in the model:
> Better to turn it on slowly, somehow, so there is a gentle "path" from the
> previous solution to the next solution.
>
> Apologies if all of this is obvious and tiresome.
>
>
> On 04/18/13 10:32, Bill Paxton wrote:
>
> Hi,
>
>  1) instantaneous mass loss
>
>  you can use very high mass loss rates (e.g. 10 to 100 Msun/year) with
> small timesteps (e.g., 1d-2 years) to remove a large amount of mass in a
> short time.
> rather than playing with a wind recipe to remove the mass, you can
> directly set the "mass_change" parameter in the inlist.
>
>           mass_change = 0d0 ! rate of accretion (Msun/year).  negative
> for mass loss.
>             ! this only applies when the wind scheme = ''
>
>  you can set the max timestep too
>
>           max_years_for_timestep = 0  ! max_years_for_timestep <= 0 means
> no upper limit.
>
>  the code might not be happy making the jump to very high mdot in a
> single step,
> so you may need to use these to turn the mass_change on.
>
>       relax_mass_change = .false.
>       relax_mass_change_min_steps = 10
>       relax_mass_change_max_yrs_dt = 10 ! years
>       relax_mass_change_init_mdot = 0 ! Msun/year
>       relax_mass_change_final_mdot = 0 ! Msun/year
>
>  you may also need to use them again after mass removal to turn the
> mass_change off.
>
>
>  2) energy conservation with mass loss
>
>  interesting question!
> you can compute the energy loss rate for the mass_change rate yourself and
> remove that amount from
> the envelope using the "other_energy" hook.  once you have it working, let
> us know so we can add it as an option. ;-)
>
>  cheers,
> Bill
>
>
>
>
>
>
>
>  On Apr 18, 2013, at 8:43 AM, Alexey Zinger wrote:
>
>  Hi Josiah,
>
> Thanks for pointing me to the relaxation routines direction! I haven't yet
> looked into those. Hopefully, they might get me through some of the
> simulations.
>
> Before fiddling with the .mod files I've tried to simulate the eruptions
> using the built-in wind schemes with high wind coefficients. There are two
> issues with this: first, I'm trying to observe how the star adjusts to a
> (nearly) instantaneous mass removal, and all of the wind routines remove
> mass gradually. Second, as far as I know, the wind schemes in the code do
> not account for the conservation of energy, and this might be important
> when so much mass is removed so quickly.
>
> Alexey
>
>
> On Thu, Apr 18, 2013 at 9:56 AM, Josiah Schwab <jwschwab at berkeley.edu>wrote:
>
>> > I do this by artificially modifying the saved model file and restarting
>> the evolution with loading that file.
>>
>>  I tried manipulating model files once and in my experience (and as you
>> seem to be finding) that way lies madness :)
>>
>> Is there something about MESA's built-in routines for changing the mass
>> of model that are insufficient/inappropriate for what you want to explore?
>>  What other (if any) approaches have you tried?
>>
>> My personal recommendation is to use an existing relaxation routine or to
>> add something you write yourself to run_star_extras.f to do the relaxation.
>>  I think it will save you a lot of grief.
>>
>> Perhaps others will share their experiences.
>>
>> Josiah
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
>
> http://www2.precog.com/precogplatform/slashdotnewsletter_______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!http://www2.precog.com/precogplatform/slashdotnewsletter
>
>
>
> _______________________________________________
> mesa-users mailing listmesa-users at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/mesa-users
>
>
>
> --
> Kent G. Budge
> CCS-2, LANL
>
> *Veni, Vader, Vinci
> ("I came, I choked everyone I saw, I conquered")*
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> 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/20130418/df0cc5db/attachment.html>