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

[Alexey Zinger]

Hi Matteo,

Right, I probably shouldn't call it modifying the code. I've meant 'going
beyond inlist stuff'.

Alexey


On Thu, Apr 18, 2013 at 12:07 PM, Matteo Cantiello <cantiel at kitp.ucsb.edu>wrote:

> Hi Alexey,
> what Bill means is that you do NOT need to modify the code.
> You just can use the run_star_extras.f in your local src folder
> and the hook other_energy to be sure that your total energy is conserved.
> You have an option for doing this using both an implicit or explicit
> scheme.
>
> To start have a look at
>
> star/other/other_energy.f
>
> and
>
> star/other/other_energy_implicit.f
>
> -m
>
> On Apr 18, 2013, at 6:57 PM, Alexey Zinger wrote:
>
> Thanks, Bill!
>
> I've used the mass_change parameter too, and it worked (sorry, forgot to
> mention it - this was the first thing I've tried). But I guess there still
> might be a difference between an instantaneous, 'geyser-like' eruption, and
> a very rapid but gradual eruption at a pre-defined rate.
>
> Anyway, the main reason I ventured into modifying the saved files was for
> the sake of the energy conservation. I've expected it to be easier to
> implement than to modify the code. Guess I was wrong :). I'll try to see
> what I can do about adding this to the code.
>
> Alexey
>
>
> On Thu, Apr 18, 2013 at 11:32 AM, Bill Paxton <paxton at kitp.ucsb.edu>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 list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>
> Dr. Matteo Cantiello ------------------------
> Kavli Institute for Theoretical Physics
> Room 1226 Kohn Hall CA 93106-4030
> University of California, Santa Barbara
> ---------------- http://matteocantiello.com/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20130418/c35186cc/attachment.html>