[mesa-users] Changing Timestep Dynamically

[Ehsan Moravveji]

On Dec 12, 2014, at 10:51 PM, Spencer C Wallace <spencerw at email.arizona.edu> wrote:

> 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.
Glad that I could help :-)

> 
> 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.
Well, not so sure if I understand what you mean by “flat spots”, but be careful that generically, the number of mesh increases as the core shrinks on the MS. This means that with the drop of center_h1, you monotonically need to reduce your timesteps smaller and smaller. I think you are now fighting agains the way MESA decides to split cells close to the convective boundary.
Since v.7184, Bill has introduced a new feature called “smoothing” for a better drop of the convective mixing at the boundary from say 10^18, to zero within one or two cell points. I suggest you turn smoothing on, and see if that helps you with your “spots” (that I still do not digest), and multiple iterations to reduce timestep.
Are you also inhibiting overshooting? Even a tiny little bit?

Happy weekend.
Ehsan.

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