[mesa-users] Results changing while rerunning the same problem

Bill Paxton paxton at kitp.ucsb.edu
Fri Jan 18 13:14:00 EST 2013 

Hi Roberto,

I believe I've fixed the problem.  ;-)   Get version 4767.

It was a tough one -- caused by uninitialized values,
but the values were more often than not the same.
So on a given rerun, we had a pretty good chance
of getting the same value just by chance.  I often had to
run it 4 or 5 times to get the bug to show up.
It took lots of confusion before I realized that was happening.

Your hunch that it was related to turning on rotation near zams
was right.  In all other cases we turn on rotation immediately
after a ./rn or a ./re, but in this case we can turn it on later
during a run.  In addition, we use time smoothing for the
rotational diffusion coefficients which is implemented by
using a linear combination of the current with the past step.
Obviously when you are doing the 1st step after ./rn or ./re
there is no past step and the code correctly skips the
time smoothing for that special case.   That was all
working fine when we later came up with the idea of
doing the "near zams" automatic start of rotation.
You can see the problem, right?   When we start
rotation in the middle of a run, there is a previous step
to use for time smoothing, but we weren't doing
rotation during the previous step so we don't have
valid data -- we need to check for this case, but we
weren't.  So on the 1st step after turning on rotation
in the middle of a run, we'd do time smoothing using
uninitialized data that we though held the results from
rotation on the previous step.    Now we don't do that. ;-)

Thank you for noticing this and reporting it.
As I've said in previous emails, mesa/star is designed
to give identical results when you rerun with identical
data (on the same computer with the same compiler...)
This is true both for ./rn and ./re from the same photo.

So, dear mesa user, if you get different results it is important 
to report it.  But before firing off an annoying false alarm, 
carefully repeat the runs to confirm that you get different
results with the same inputs.  As we found in this case,
you might get the same results several times before getting
something different.  That still counts as a bug of course.

On the topic of false alarms:  I understand that they will happen.
I just ask you to keep in mind that when you report a problem
you have encountered using mesa, the problem might be you
rather than mesa.   Keep that in mind when you are writing
your email to mesa-users.  You might want to avoid phrases
such as "horrible mesa bug" or "critical failure in mesa".
They might turn out to be true, but they might not.  And
in either case they guaranteed to piss me off.

Cheers,
Bill



 




On Jan 17, 2013, at 9:17 PM, trobolo dinni wrote:

> 
> Hi Bill,
> 
> I did a set of three simulations in my machine, with only 1 processor, the three history files are attached in the first archive.
> As you can see the second and third simulations yield the same result, while the first 1core simulation results in a completely different model. The procedure through which I did the three simulations is the following:
> 
> 1.launched the first one (./rn)
> 2.saved the LOGS dir in a separate dir and cleaned the original LOGS dir
> 3. ./clean ./mk ./rn
> 4.saved the LOGS dir in a separate dir and cleaned the original LOGS dir
> 5. ./clean ./mk ./rn
> 
> So my doubt is the following: since the first simulation yields different results of the following two, and in that case I didn't  ./clean ./mk ./rn after the previous simulation, can this alter in some way the results?
> Anyway I am doing 1 more test with one core.
> 
> 
> I also did a pair of of 1 core simulations in another computer, the two history files are attached in the second archive.
> The two simulations yield the same result, that is different to everyone of those obtained in the other machine. The difference between the results in one machine and the other starts as in the previous case after model number number 806, when rotation comes in.  In the second machine I followed the steps:
> 
> 1. ./clean ./mk ./rn
> 2.saved the LOGS dir in a separate dir and cleaned the original LOGS dir
> 3. ./clean ./mk ./rn
> 4.saved the LOGS dir in a separate dir and cleaned the original LOGS dir
> 
> Here I made two clean runs, so part of the problem could be really the fact that I have to ./clean ./mk ./rn  after every run, or do the runs in different directories; but still, the results in one machine are different from those in the other!
> I am also doing another pair of simulations in the second machine.
> 
> Cheers,
>             Roberto
> 
> 
> 
> 
> ---------- Forwarded message ----------
> From: trobolo dinni <trobolo.trobolo.dinni5 at gmail.com>
> Date: 2013/1/17
> Subject: Re: [mesa-users] Results changing while rerunning the same problem
> To: Bill Paxton <paxton at kitp.ucsb.edu>
> 
> 
> Hi Bill, 
> 
> I attached the inlist I am using.
> I finished the first simulation with a single processor, Iam now running the second one.
> 
> Thanks,
>                Roberto
> 
> 
> 2013/1/17 Bill Paxton <paxton at kitp.ucsb.edu>
> Hi,
> 
> Please resend the inlist (even if it is the same as you sent before!).   I want to be sure I'm using the same as you are.
> 
> -B
> 
> 
> 
> On Jan 15, 2013, at 10:25 PM, trobolo dinni wrote:
> 
>> 
>> Hi Bill,
>> 
>> just did two additional runs to test (now the 1 core simulations are running...but they are very slow), the two corresponding hystory.data files are attached and renamed with the number of models of the run and the number of cores used.
>> As you can see from them, the last model which is the same in both the simulations is number 806, with priority 2, which should correspond to the beginning of the main sequence (am I right?).
>> Now, as you can also see from the inlist I attached previously, I turn on rotation at the ZAMS, so could it be a problem related to the rotation routines?
>> 
>> Thanks,
>>                   Roberto
>> 
>> 
>> 2013/1/16 trobolo dinni <trobolo.trobolo.dinni5 at gmail.com>
>> Hi Bill, 
>> 
>> yes, I saved the logs for the last one and I will compare them with those of the simulation that is running now!
>> After this I will try the 1 processor runs, btw the cpu is an i7 (4real+4virtual cores) and I am running on all of them atm.
>> 
>> Thanks,
>>                  Roberto
>> 
>> 
>> 2013/1/16 Bill Paxton <paxton at kitp.ucsb.edu>
>> Hi,
>> 
>> Please DO NOT run another 12000 step run before checking to see if the results are changing.
>> Start over with 2 runs in separate directories and run each for minimal number of steps to show a difference.
>> 
>> -B
>> 
>> 
>> 
>> 
>> On Jan 15, 2013, at 4:36 PM, trobolo dinni wrote:
>> 
>>> Hi Bill,
>>> 
>>> Exactly, I did two runs with exactly the same inlist: after I finished the first simulation I checked the results, then I ./rn in the same directory without touching anything.
>>> 
>>> I didn't check at what model number the simulations begin to differ, but for sure in the first one the "power_he_burn_upper_limit" reaches 1d4 at model number 15295, while in the second at model number 12835, and at that time all the physical variables of the two stars are different.
>>> Unfortunately since I did the simulation in the same directory of the previous I have lost the logfiles of the first one and I can't go back to check. Anyway I am now running a third one.
>>> 
>>> After this third try I am going to change to OMP_NUM_THREADS 1.
>>> 
>>> I hope I have been clearer, sorry and thanks, 
>>>                                                                    Roberto
>>> 
>>> 
>>> 
>>> 2013/1/16 Bill Paxton <paxton at kitp.ucsb.edu>
>>> Hi,
>>> 
>>> I still don't understand.   You do two runs with the same inlist.  At what model number do the results first differ?  model 1?  model 10000?
>>> 
>>> Can you repeat this?  Or does it happen randomly?
>>> 
>>> Does it still happen when you set OMP_NUM_THREADS 1
>>> 
>>> -B
>>> 
>>> 
>>> 
>>> On Jan 15, 2013, at 4:03 PM, trobolo dinni wrote:
>>> 
>>>> Hi Bill,
>>>> 
>>>> I attached the namelist I am using, I have not starting models since I rerun the same simulation from the beginning.
>>>> 
>>>> Starting from the model number reached at the end of the simulation (15295 the first time and 12835 the second), every physical variable of the star I was simulating was different.
>>>> I am stopping the simulations at the He flash, using the criterion suggested me by Aaron Dotter in a previous discussion, which consists in setting up the "power_he_burn_upper_limit" control to 1d4 or so. Hence is like the star reaches the He flash at different moments in different simulations.
>>>> 
>>>> I am using mesasdk to compile mesa, it uses gfortran 4.7.2; I am running the code in 64 bit linux (Ubuntu 12.04.1 LTS) box; the mesa version is the 4740.
>>>> 
>>>> Sorry for the lack of information in my first email!
>>>> Thanks for the help,
>>>>                                 Roberto
>>>> 
>>>> 
>>>> 2013/1/16 Bill Paxton <paxton at kitp.ucsb.edu>
>>>> Hi,
>>>> 
>>>> Please provide the necessary info for us to try to reproduce the problem.
>>>> That means inlists and starting model if any.
>>>> And exact details about what you notice as different.
>>>> Also, what compiler and what system and what version of mesa.
>>>> 
>>>> -B
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Jan 15, 2013, at 3:36 PM, trobolo dinni wrote:
>>>> 
>>>> > Dear MESA users,
>>>> >
>>>> > I have got a simple weird problem: I run the same simulation twice, and I am getting two different results.
>>>> >
>>>> > I know it does not depends on the code, but I would like to ask if anyone noticed the same behavior and if it can depend on my computer or if I have to do something particular before running again the same simulation in the same directory.
>>>> >
>>>> >
>>>> > Thanks,
>>>> >                 Roberto
>>>> > ------------------------------------------------------------------------------
>>>> > Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
>>>> > and more. Get SQL Server skills now (including 2012) with LearnDevNow -
>>>> > 200+ 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_122512_______________________________________________
>>>> > mesa-users mailing list
>>>> > mesa-users at lists.sourceforge.net
>>>> > https://lists.sourceforge.net/lists/listinfo/mesa-users
>>>> 
>>>> 
>>>> <inlist.1M-preMS_RGBtip-sb_rot_0.3_from_ZAMS>
>>> 
>>> 
>> 
>> 
>> 
>> <history_15437_8core.data.tar.gz><history_15575_8core.data.tar.gz>
> 
> 
> 
> <Histories1.tar.gz><Histories2.tar.gz>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20130118/780cbff4/attachment.html>

More information about the Mesa-users mailing list