[mesa-users] Reconstructing tracks for asterg-module fits

Richard Townsend townsend at astro.wisc.edu
Mon Jan 26 10:21:31 EST 2015


Hi Wiebke —

Thanks for your email. Fortunately, after throwing a lot of computing time at the problem over the weekend, I tracked down the issue: MESA-astero and MESA-star were using different abundances. In MESA-star, the abundances are set through initial_Y and initial_Z; whereas  in MESA-astero (assuming one is only optimizing the mass) the abundances come from first_Y, first_FeH and Z_div_X_solar.

When the abundances are brought into harmony, the differences between star and astero become small — certainly good enough to plot tracks which pass through the target point.

Best wishes,

Rich

> On Jan 26, 2015, at 9:15 AM, Wiebke Herzberg <wiebke at kis.uni-freiburg.de> wrote:
> 
> Hi Rich,
> 
> I had the exact same problem. I could not reproduce the best fitting model from the astero module with a normal MESA evolution run. After some testing I actually think it is not possible (I suspected the different time steps, but did not dig any deeper). If you find out otherwise please let me know!
> 
> As a workaround you can use your optimized starting parameters (from the best fitting model) and do another astero run with search_type = 'use_first_values'. If I remember correctly, that way you will have access to the evolution information of your model, which is otherwise lost/overwritten when using one of the other search_types.
> 
> Cheers,
> Wiebke
> 
> 
> 
> 
> Am 25.01.2015 um 16:14 schrieb Richard Townsend:
>> Dear MESAnauts —
>> 
>> I’m currently using the astero module to calculate stellar models with a certain Teff and luminosity. Although these quantities aren’t the usual free parameters we get to choose when calculating a stellar evolution track, the astero module (with the seismic frequency matching turned off) allows one to find the initial mass, age, etc which will produce an evolutionary track shooting right through the desired (Teff,L). It’s a really useful piece of functionality.
>> 
>> However, I’ve run into an issue: if I take the initial mass found by the astero module, and then do an ordinary run (i.e., non-astero) using this value, then the resulting evolutionary track does *not* go through the desired point.
>> 
>> My suspicion is that the calculations inside/outside astero are being run with different parameters; but I’m not able to track down what the issue is. I attach the relevant inlists — can anyone see what might be going wrong?
>> 
>> One possibility: although step-based overshooting is turned on in the main inlist (inlist_project_…), it is turned off in inlist_astero_search_controls. However, from my reading of the source code, the astero module only changes the overshoot length for standard (rather than step) overshooting — so this should matter, right?
>> 
>> Many thanks for any assistance,
>> 
>> cheers,
>> 
>> Rich
>> 





More information about the Mesa-users mailing list