[mesa-users] Results changing while rerunning the same problem
trobolo dinni
trobolo.trobolo.dinni5 at gmail.com
Sun Jan 20 19:11:31 EST 2013
Hi Bill,
sorry for the delay in replying.
Thank you very much for fixing the problem so fast! :) I updated to version
4767.
I got what was the problem, that makes perfectly sense considering the
variety of results for the same simulation.
I hope I din't use any phrase that "pissed you off" (I used the word
"weird" for the problem in my first post maybe...but I did the same
simulation a lot of times getting different results before reporting the
problem. And I thought it was pretty strange for a code!), in any case was
not my intention and I would like to apologize if this was one of the
phrases you mentioned.
Cheers,
Roberto
On 19 January 2013 05:14, Bill Paxton <paxton at kitp.ucsb.edu> wrote:
> 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/20130121/cab9b9f9/attachment.html>
More information about the Mesa-users
mailing list