[mesa-users] Having some fun with mu

[Ehsan Moravveji]

Hello Frank, and thanks for your suggestion.
Actually, using the A number (as I should have) instead of atomic weights, slightly improved the issue in the core, but increased the difference in the envelope.
So, my new block is 

   do i = 1, nz
      mu_inv = 0d0
      do j = 1, species
         id = s% chem_id(j)
         weight  = chem_isos% W(id)
         charge  = chem_isos% Z(id)
         A       = chem_isos% Z_plus_N(id)
         m_frac  = s% xa(j, i)
         mu_inv = mu_inv + m_frac * (1d0 + charge) / A
      enddo
      mu(i) = 1d0 / mu_inv
   enddo

And I use it in data_for_extra_profile_columns. I think this is a place were all massages to the model been already taken place, and the details and/or order of mixings would not intervene here.
Please take a look at the attached plot.



Cheers
Ehsan.



On Sep 13, 2014, at 5:36 AM, Francis Timmes wrote:

> might the small difference be due to using the 
> atomic weight W instead of the atomic number A?
> 
> W(hydrogen) = 1.00794 amu
> A(h1) = 1
> 
> W(helium) = 4.002602 amu
> A(he4) = 4
> 
> and so on ...
> 
> fxt
> 
> 
> 
> On Sep 12, 2014, at 2:40 AM, Ehsan Moravveji <e.moravveji at gmail.com> wrote:
> 
>> Hello all,
>> I've been experimenting here and there, and like to check recovering the profile of the mean molecular weight (mu), as it is written out in profiles. 
>> For that purpose, I use the following simple block (see Eq. (7.34) in Maeder (2009)) to calculate my mu, and later compare it with MESA's:
>> 
>>  do i = 1, nz
>>     mu_inv = 0d0
>>     do j = 1, species
>>        id = s% chem_id(j)
>>        weight  = chem_isos% W(id)
>>        charge  = chem_isos% Z(id)
>>        m_frac  = s% xa(j, i)
>>        mu_inv = mu_inv + m_frac * (1d0 + charge) / weight
>>     enddo
>>     mu(i) = 1d0 / mu_inv
>>  enddo
>> 
>> The resulting comparison plot is attached. There you easily notice that I fail to reproduce mu as done internally in MESA. This is for a 5 Msun model stopping at center_h1=0.4. I use v.6871, and the very basic inlist that I use is also attached.<inlist_mu>
>> <Comp-mu.png>
>> I have to confess that I did not dive deeper into this. But, I only "guess" that either my formula is not well implemented, or the order between burning and mixing in which mu is calculated "might" matter.
>> Please enlighten me with your comments.
>> 
>> Cheers
>> Ehsan
>> 
>> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk_______________________________________________
>> mesa-users mailing list
>> mesa-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20140914/acf8c933/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Comp-mu.png
Type: image/png
Size: 44672 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20140914/acf8c933/attachment.png>