[mesa-users] critical problem with history interval

Fri Jan 11 16:08:50 EST 2013

Hi!

I performed more tests and it looks even worse than before.

I change value of OMP_NUM_THREADS to 1 in order to achieve single threaded calculations, as I was suggested by few persons. And it is really bad, not even mentioning that it was terribly slow. I made two runs on my Mac (for history_interval = 1 and 5). This time the two results was the same. In the attached figure they are depicted by red and green lines.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 15m-hr-single.pdf
Type: application/pdf
Size: 43377 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20130111/1010d009/attachment.pdf>
-------------- next part --------------

I also checked the same inlists on supercomputer which runs Scientific Linux. I used there the newest SDK and MESA 4740 and I set OMP_NUM_THREADS = 1 in order to have perfect agreement between the cluster and my Mac. As you can see in the figure (blue and orange lines) two runs produced the same results but they are different than any other result obtained on Mac.

Right now I have no clue what to do about it. I'm about to start a project that heavily rely on MESA and I can't do it because I have no trust in its results. It really looks like a fundamental problem.

Bill help, please :) I really need to use MESA, but I can't fix it on my own.

Cheers,
Jakub

On 11 sty 2013, at 17:17, Evan O'Connor <evanoc at cita.utoronto.ca> wrote:

> Hi Jakub,
> 
> Are you using threading? If so try the evolution again with just one thread, perhaps there is an openmp bug that the history_interval makes apparent.  If you are just using 1 thread that ignore this (that is why I'm not replying to the list)
> 
> Evan
> 
> On 2013-01-11, at 10:50 AM, Jakub Ostrowski <ostrowski at astro.uni.wroc.pl> wrote:
> 
>> Hi Lars,
>> 
>> My biggest issue is now the problem with MESA which I described and it basicaly doesn't have anything in common with WNJ.
>> 
>> The comparison is secondary thing. I pointed it out because I wanted to give you a reason why I've found this bug and I also think that this stage of evolution is a shortcoming of MESA. This is weird because it perfectly handles much more sophisticated stages.
>> 
>> Of course I can happily provide my settings of WNJ to anyone who is interested. Just tell me what you need and you'll have it. I'm definitely going to compare more tracks myself when the problem with MESA is gone.
>> 
>> And yes, you are right: WNJ doesn't have helium burning implemented so that the tracks I've shown you are everything you can get for massive stars. I cut calculations when central temperature rises to 10^8 K because higher values would be unrealistic due to the lack of support for next stages of nuclear burning.
>> 
>> Cheers,
>> Jakub
>> 
>> 
>> On 11 sty 2013, at 16:09, Lars Bildsten <bildsten at kitp.ucsb.edu> wrote:
>> 
>>> Jakub, 
>>> 
>>> It seems you are raising two distinct issues: 
>>> 
>>>   1. MS and just after MS, How does MESA compare to WNJ? For that exercise, it would seem to me that many on this mailing list 
>>>        can now make comparisons assuming you can let them know exactly all the settings in teh WNJ code. Such comparisons are 
>>>       extremely valuable and revealing, so I am eager to see how that works. 
>>> 
>>>   2. post MS and into the red. ..  It seems that WNJ does not proceed into that regime? If not, then look at the recent MESA Paper II where 
>>>         comparisons were made to STERN. If WNJ proceeds into that regime, let's make some comparisons with similar settings. 
>>> 
>>> Thanks for your continued interest in using MESA! 
>>> 
>>>  Cheers
>>> 
>>> Lars
>>> 
>>> 
>>> On Jan 11, 2013, at 6:06 AM, Jakub Ostrowski wrote:
>>> 
>>>> Hi!
>>>> 
>>>> I'm reporting a critical problem that renders MESA pretty useless for me until I understand what's going on.
>>>> 
>>>> I observed that changing value of history_interval from 5 to 1 in 15 M_S model made enormous difference in evolution track which is rather ridiculous behavior. I can obtain one of two very different solutions just changing this one seemingly irrelevant parameter. 
>>>> <15m-hr.pdf>
>>>> Take a look at this HR diagram. Red line depicts the track I obtained with history_interval = 1 and green line is for history_interval = 5. I'll talk about blue line later on. Tracks are very different and the parameters of models are very different too. For example, model with logTeff ~ 4.20 that undergoes helium burning in the core and moves towards hotter temperature has for history_interval = 1 central abundance of he4 ~ 0.35 while model on similar place in HR but with history_interval = 5 has central abundance of he4 ~ 0.70. 
>>>> 
>>>> Which track is real? I have no idea. And take a look for similar figure calculated for 16 M_S models. The difference is even more obvious.
>>>> 
>>>> <16m-hr.pdf>
>>>> 
>>>> In order to solve a problem I have calculated 15 M_S model at least ten times, just changing history_interval. Generally speaking I always obtained one of these two solutions, but I ended with conclusion that it is even possible to obtain two solutions with history_interval = 1, but most likely there will look like in the first figure. This is even more problematic.
>>>> 
>>>> So my questions are: what's the reason for this behavior and how to fix it? And which (if any) solution is real?
>>>> 
>>>> There is also another problem that I would lie to point out. On both figures I plotted tracks from Warsaw - New Jersey code (blue lines). The main reason why I wanted history_interval = 1 was because of very poor reproduction of contraction after main sequence in MESA. Unfortunately even with every model in history file it looks like MESA loses some information - time step seems to be too long for this stage of evolution. There are only few points at this stage of evolution while Warsaw code beautifully renders this moment of star's life. I attached the files I used to plot these tracks.
>>>> 
>>>> Do you have any comments about that? Is it possible to get closer to solution of Warsaw - New Jersey code here?
>>>> 
>>>> All calculations have been carried out using MESA 4740 on OS X 10.8.2 with the latest SDK. I attached all inlists and obtained history files for every case shown on these plots.
>>>> 
>>>> I hope this is my simple failure and not a serious bug :)
>>>> Cheers,
>>>> Jakub
>>>> 
>>>> <report.zip>------------------------------------------------------------------------------
>>>> Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
>>>> much more. Get web development skills now with LearnDevNow -
>>>> 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
>>>> SALE $99.99 this month only -- learn more at:
>>>> http://p.sf.net/sfu/learnmore_122812_______________________________________________
>>>> mesa-users mailing list
>>>> mesa-users at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
>> much more. Get web development skills now with LearnDevNow -
>> 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
>> SALE $99.99 this month only -- learn more at:
>> http://p.sf.net/sfu/learnmore_122812
>> _______________________________________________
>> mesa-users mailing list
>> mesa-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
> 