[mesa-users] Changing Timestep Dynamically

[Spencer C Wallace]

Neat, so global variables in run_star_extras are preserved across timesteps
and retries. That was exactly what I needed. Thank your for the advice,
Ehsan.

Francis, I'm working with H core burning models with little to no mixing at
the convective core boundary. It turns out that you get flat spots in the
composition profiles if the core recedes by multiple zones per timestep
(since the composition in the core is homogeneous) and there isn't enough
boundary mixing to smooth it out. These flat spots alter the location of
the Ledoux boundary, since Ledoux depends on the composition gradient. So
there is an additional constraint for getting convergence, which is that
the core recession must be sufficiently temporally resolved so that it
doesn't jump back over a multiple zones and make the composition gradient
noisy.

On Fri, Dec 12, 2014 at 12:52 AM, Ehsan Moravveji <e.moravveji at gmail.com>
wrote:
>
> Hi Spencer,
> In such cases, you can declare a variable on top of your run_star_extras,
> which will be within the scope of the whole module. With that, you can
> perfectly “remember” the last position/index of the core before a forced
> retry, and “refresh” it once a small enough timestep is taken.
>
> I hope this helps.
>
> Cheers
> Ehsan.
>
>
>
>
>
> On Dec 12, 2014, at 4:12 AM, Spencer C Wallace <spencerw at email.arizona.edu>
> wrote:
>
> Hi everyone,
>
> I am working with models of massive main sequence stars which all have
> receding convective cores. For the work I am doing, I want to make sure
> that the core only recedes by one zone per timestep. In order to enforce
> this requirement, I sometimes need to reduce the time step size while the
> model is running.
>
> I added some code to the function extras_check_model in run_star_extras.f.
> It basically works like this:
>
> if the core receded by > 1 zone
>   extras_check_model = retry
>
> Forcing a retry changes the timestep size by timestep_factor_for_retries,
> which reduces the amount by which the core recedes. However, it might take
> a few retries to get the right step size. In order to figure out how much
> the core receded, I look at
>
> s% cz_top_mass(1)
> s% cz_top_mass_older(1)
>
> However, after the first retry, it looks like cz_top_mass =
> cz_top_mass_older, so I no longer have the information I need to determine
> by which how many zones the core receded.
>
> Is there a way to remember the change in the core size over multiple
> retries? Or am I going about this the totally wrong way?
>
> Spencer Wallace
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&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/20141212/abf8b5ff/attachment.html>