Re: [mesa-users] controlling timestep using diffusion timescale

[Bill P. <pa...@ki...>]

On Mar 5, 2015, at 11:43 AM, Alina Istrate wrote:

> 
> Dear all,
> 
> I've been studying convergence for 1.2 solar mass models including the
> effect of gravitational settling (as you might recall from a previous
> email). In order to limit timesteps, I ended up using
> max_years_for_timestep low enough such that the main sequence evolution
> does not display large jumps in Teff, caused by the coupling of Ledoux
> criterion and settling. However, I would like to control the timestep
> directly using a timescale for diffusion, so the code adjusts properly
> at different masses, instead of needing to tune max_years_for_timestep
> each time.
> 

a reasonable idea.  let's see how to make it work.


> I saw that there is an option to reduce the timestep size for the
> diffusion substeps (diffusion_dt_div_timescale). This parameter is not
> used when calculating diffusion with isolve, is there a reason for this?

really??  can you provide me with inlist etc so I can see this in action.
when I look at the code, I find subroutine do_solve_diffusion in star/private/diffusion.f90 doing this to save the number of steps taken with isolve:
            steps_used = iwork(17) ! number of accepted steps
and the caller of do_solve_diffusion (in star/private/element_diffusion) does this
         s% num_diffusion_solver_steps = steps_used
in star/private/timestep, the routine check_diffusion_steps_limit then uses s% num_diffusion_solver_steps to enforce the limits set by the controls diffusion_steps_limit and diffusion_steps_hard_limit.

so if this isn't working, please give me details so we can fix it.



> Also, would it be possible to have the value computed by
> get_timescale(...) in star/private/mod_diffusion.f90 accesible through a
> public interface, and provide a timestep limit associated to diffusion
> using this timescale (something like dt_div_diffusion_timescale_limit)?


sure.  but keep in mind that when you use isolve for this, it can take multiple substeps, each of which can be much smaller than the timescale calculated by this routine.   this routine is for use in case you are not using isolve.  and it is called at each substep taken by the diffusion solver, and the value changes a lot as the initial transients are smoothed out allowing larger substeps to be taken.  so it isn't at all clear what you can usefully do with a particular value of this.    we can of course save the final value of get_timescale in a star_data variable so you can inspect it from your run_star_extras.

You can give that a try for yourself by making a patch.  Just after the call on get_timescale, add this line

	s% xtra1 = timescale

Then you can access s% xtra1 in your run_star_extras.

If this turns out to be a useful way to set timesteps, let me know and we'll add something so you won't have to do a patch for future releases.

Cheers,
Bill




> 
> Cheers!
> 
> Alina
> 
> 
> -- 
> Alina Istrate 
> PhD student
> 
> 
> Argelander Institute fur Astronomie
> Auf dem Hugel 71
> D-53121 Bonn
> Germany
> Room 2.024
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users