[mesa-users] inconsistency

[Bill Paxton]

Just to finish this off.  Your inlist uses a starting model that doesn't initially have rotation, and then it turns rotation on in &star_job controls.  That's AOK.

Your other_D_mix routine is being called during the initialization of the starting model without rotation, so omega has not been set.

So on the 1st call, your other_D_mix was accessing an uninitialized array, omega, because there wasn't yet any rotation for the model.

The later calls are fine since they are happening after rotation has been added.

b





On Nov 5, 2016, at 9:43 AM, Martin C. wrote:

> 
> 
> 
> For example, try this and see what happens.   
> 
>     subroutine my_other_D_mix(id, ierr) 
> 	...
>         if (s% model_number < 1) return						! skip before starting
>         do k = 1, s% nz
>             if (mod(k,100) ==0) print*, s% omega(k)
>         end do
>         stop
>     end subroutine my_other_D_mix
> 
> aha.  yes this produces the same output for OMP_NUM_THREADS = 2,3 and also on the mac pro. 
> What I had in my previous email was evidently for model_number = 0...
> 
> thank you very much.
> 
>  
> 
> 
> The next question is why is your other_D_mix routine being called before omega has been set.
> 
> Probable answer: no one noticed and it hasn't caused any problems since things are okay after initialization ??
> 
> I don't know. 
> things seem to be ok for model_number >=1
> 
> 
> thanks. 
> 
> Martin 
> 
> 
> 
> 
> 
> 
> On Nov 5, 2016, at 9:07 AM, Martin C. wrote:
> 
>> Hi all
>> 
>> I think I've come across something in MESA that may contradict this from MESA paper 3:
>> 
>> From MESA paper 3
>> 
>> <image.png>
>> <image.png>
>> 
>> MESA is supposed to provide bit for bit consistency across all platforms, independent of threads. (for those not able to see the inline screenshots).
>> 
>> I'm using other_D_mix in run_star_extras to calculate a diffusion coefficient. For that I need to access values from s% omega. 
>> It seems that when I change OMP_NUM_THREADS from 3 to 2 the values in s% omega are different. I test this with this routine (also in attached run_star_extras)
>> 
>> <image.png>
>> 
>> I tested the above on ubuntu14, mesa 8118, latest sdk. 
>> example: OMP_NUM_THREADS =2 
>> <image.png>
>> 
>> OMP_NUM_THREADS = 3 produces:
>> 
>> <image.png>
>> 
>> 
>> I also installed mesa 8118 on a mac pro with latest sdk (default of 16 threads). Here no matter what I change OMP_NUM_THREADS to I don't get the results that I get on ubuntu. Worse: running the exact same code multiple times yields different results for the printed s% omega values! (Often zeros, sometimes NaN, sometimes "random" values). 
>> 
>> 
>> So am I misunderstanding something? What's causing this. How can I work around this problem (if it is one).
>> 
>> thanks!
>> 
>> Martin
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Martin C.
>> <inlist_project><inlist><run_star_extras.f>------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi_______________________________________________
>> mesa-users mailing list
>> mesa-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
> 
> 
> 
> 
> -- 
> Martin C.

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