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

trobolo dinni trobolo.trobolo.dinni5 at gmail.com
Wed Jan 16 01:25:14 EST 2013


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>
>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20130116/0a7f0241/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: history_15437_8core.data.tar.gz
Type: application/x-gzip
Size: 1908331 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20130116/0a7f0241/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: history_15575_8core.data.tar.gz
Type: application/x-gzip
Size: 1916075 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20130116/0a7f0241/attachment-0001.bin>


More information about the Mesa-users mailing list