[mesa-users] Comparing OP_a09 vs. OP monochromatic track

[Aaron Dotter]

Hi Ehsan,

No, my suggestion was that you replace the abundances of the metals with
Z*AGSS09_element_zfracs each time you call the opacity routines during the
evolution.  This will mimic the opacity tables in terms of the composition
of the gas.

Aaron



On Saturday, August 1, 2015, Ehsan Moravveji <e.moravveji at gmail.com> wrote:

> Thanks Aaron for your hint.
> I put the following block, in the extras_startup and in extras_controls,
> and the result did not change.
> I thought in this way, the Z scaling precedes specifying the individual
> mass fractions in the net.
> In the following, I pass Z_ini = 0.014
>
>       subroutine extras_controls(id, ierr)
>
>          call crlibm_init
>          call chem_init(isotopes_filename, ierr)
>          if (ierr /= 0) return
>
>       end subroutine extras_controls
>
>
>       integer function extras_startup(id, restart, ierr)
>
>          initial_zfracs = s% job% initial_zfracs
>          select case(initial_zfracs)
>             case(AGSS09_zfracs)
>                   AGSS09_element_zfrac(:) = AGSS09_element_zfrac(:) * Z_ini
>             case (A09_Prz_zfracs)
>                   A09_Prz_zfrac(:) = A09_Prz_zfrac(:) * Z_ini
>             case default
>                 ierr = -1
>                 write(*,*) 'Error: run_star_extras: extras_controls:
> requested initial_zfracs not needed now'
>                 return
>          end select
>
>       end function extras_startup
>
> I guess this Z-scaling is internally done during the setting up of the
> run, before model_number 0.
> Am I correctly following your hint?
>
> Thanks for your help.
> Ehsan.
>
>
>
> On 31 Jul 2015, at 23:19, Aaron Dotter <aaron.dotter at gmail.com
> <javascript:_e(%7B%7D,'cvml','aaron.dotter at gmail.com');>> wrote:
>
> Hi Esan,
>
> I have one suggestion: Run the mono version again but this time force Z to
> be as defined in A09, instead of whatever it is exactly in your model.  By
> "force Z" I mean rescale the abundance array input to the mono routines
> such that H and He are unchanged but the other elements are rescaled by
> (1-X_H-X_He)*AGSS09_element_zfracs.  I hope that makes sense.
>
> This is essentially what the tabulated opacities do.
>
> I have done this before but only with low-T opacities calculated on the
> fly.  I can confirm that it resulted in a small shift in Teff similar to
> what you've shown.
>
> Aaron
>
>
> On Saturday, August 1, 2015, Ehsan Moravveji <e.moravveji at gmail.com
> <javascript:_e(%7B%7D,'cvml','e.moravveji at gmail.com');>> wrote:
>
>> Dear MESA users,
>> I have computed two prototypical evolutionary tracks for a 7.5Msun star
>> and Z=0.014 with Asplund et al. (2009) mixture, once setting
>>
>>     initial_zfracs = 6
>>     kappa_file_prefix = ‘OP_a09'
>>
>> and another time turning on the monochromatic opacity (Mono) computations
>> instead of using tables. Nothing else is changed.
>> Mass loss and overshoot are also turned off, to make sure they do not
>> intervene.
>> I have attached my inlist and my modified net (that includes all 17 OP
>> elements). I use version 7678 and MESASDK.
>>
>> I notice that there is a significant shift of the evolutionary track
>> towards higher log_Teff when using the Mono opacities. The reason is that
>> the OP Mono opacity profile in this model is systematically below what is
>> retrieved from tables.
>> This surprises me, because the default OP_A09 table should (almost) mimic
>> OP_a09 (with a difference that we need an interpolation in the latter case).
>>
>> Has anyone seen this before?
>> Is there a way to fix this difference? Am I making any mistake here in my
>> inlists?
>>
>> Best regards
>> Ehsan.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150802/1e5fa9aa/attachment.html>