[mesa-users] trace the computational cell that is limiting the timestep

[Mathieu]

Hi again,

sorry about the multiple mail. I've noticed that the computational cell 
that causes the timestep reduction is already in the standard terminal 
output, but I couldn't find it presumably because of a typo. For 
example, when starting from the photo of my previous email I get:

reduce dt because of excessive dHe_div_He  2008284006     0.653552773   
-15.579696979

while it should look like:

reduce dt because of excessive dHe_div_He  2008 284006     0.653552773 
-15.579696979

with a space between the two first number, which are the cell causing 
the timestep reduction and the model number. Am I right?

Mathieu

On 04/14/2014 05:23 PM, Mathieu wrote:
> Hi Bill,
>
> Many thanks for this! I'll remember to send a model next time.
>
> Mathieu
>
> On 04/13/2014 10:20 PM, Bill Paxton wrote:
>> Hi Mathieu,
>>
>> 1st, thanks for sending the inlist and a photo.  Usually it is better 
>> to send a saved model rather than a photo, but in this case it worked 
>> fine.
>>
>> I made the following 3 changes in your inlist:
>>
>> 1)
>> use approx21.net <http://approx21.net> instead of approx26.net 
>> <http://approx26.net>
>>
>> 2)
>>       mesh_delta_coeff = 3
>> instead of
>>       mesh_delta_coeff = 1
>>
>> for the late burning stages I've found that I can increase 
>> mesh_delta_coeff and still have enough cells.
>> in your case I'm still getting 1500+ cells even with mesh_delta_coeff 
>> = 3.
>> Try the larger value while you are trying to get things to work;
>> then come back and check for convergence by decreasing mesa_delta_coeff.
>>
>> 3)
>>          varcontrol_target = 1d-2
>> instead of
>>          varcontrol_target = 1d-4
>>
>> again, like for mesh_delta_coeff, try a larger value while trying to 
>> get things to work.
>> then reduce it to check convergence later.
>>
>> with these 3 changes, I was able to restart your photo and get it to 
>> go to core collapse in 247 steps in about 1.4 minutes of runtime.
>>
>>  runtime, prev time, retries, backups, steps 1.4         2.0     
>>  9739       299    284247
>>  284247  10.126392   1848.395  23.430390  24.849838  12.308650   
>> 8.132779   0.000000   0.000000   0.327378   0.424153  10.954351   
>> 1538   9739
>>  -10.393057  10.622930   3.111692  21.739086  17.688434 -99.000000   
>> 4.175871   0.000010   0.000000   0.019025   0.350215   3.580514     
>>  3    299
>>  1.3391E+07  28.782825   4.244046  24.832632   1.198830  -9.604670   
>> 2.495086   0.000000   0.000000   0.000000  2.256E-01  0.000E+00 
>>  highT del Ye
>>
>> Good luck!
>>
>> -B
>>
>>
>>
>>
>>
>>
>>
>>
>> On Apr 13, 2014, at 7:46 AM, Mathieu wrote:
>>
>>> Hi everyone,
>>>
>>> I am wondering if there is a way to trace which computational cell 
>>> is limiting the timestep in MESA 6208.
>>>
>>> I am trying to simulate a 15 solar mass star with MESA 6208 and I 
>>> find extremely small timesteps during Si shell burning.
>>> I know I could lower the min_timestep_limit (setting it to 10^-10 
>>> sec the run goes on), but I'd like to find why and where such small 
>>> timesteps are needed.
>>> I attach the inlist I am using and a photo (284000), if someone 
>>> wants to reproduce the problem.
>>>
>>> Thanks for any suggestion,
>>>
>>> Mathieu
>>>
>>>
>>> <284000><inlist_project.txt>------------------------------------------------------------------------------
>>> Put Bad Developers to Shame
>>> Dominate Development with Jenkins Continuous Integration
>>> Continuously Automate Build, Test & Deployment
>>> Start a new project now. Try Jenkins in the cloud.
>>> http://p.sf.net/sfu/13600_Cloudbees_______________________________________________
>>> 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/20140414/a2c953a1/attachment.html>