# [mesa-users] Depth-dependent alpha

Chris Mankovich cmankovich at ucsc.edu
Fri Apr 29 14:47:29 EDT 2016

```Ah, that should be doable. You're right, it would mean a second MLT call
for every zone.

cheers,
Chris

On Fri, Apr 29, 2016 at 11:44 AM, Ireland, Lewis <lgi201 at exeter.ac.uk>
wrote:

> Thank you both for your replies!
>
> Apologies, I missed out a fundamental part of my explanation about the
> gradT, which is why it seemed unclear.
>
> I want alpha(r) ~ alpha_0 * gradT_0(r) * other_stuff(r), where gradT_0(r)
> is the corresponds to the fixed alpha_0.
>
> So in a way, I wish to run one iteration with a fixed alpha_0, determine
> gradT_0, then on to the next iteration at the same radial point, using my
> newly calculated alpha(r) to work out a new gradT.
>
> Does this make sense? I guess it would mean running each step twice: one
> with alpha_0 and one with alpha(r)?
>
> Cheers,
>
> Lewis
>
> On 29 Apr 2016, at 19:10, Adam Jermyn <adamjermyn at gmail.com> wrote:
>
> relationship (so that gradT and alpha satisfy both the usual mixing length
> theory result and the additional relation you're imposing). If neither
> quantity is changing too quickly or if the correction is small you can get
> around this by using the value from the previous step as Chris suggests,
> but otherwise a consistent solve is probably warranted.
>
> On Apr 29, 2016, at 6:31 PM, Chris Mankovich <cmankovich at ucsc.edu> wrote:
>
> An alpha that depends on stuff(r) would be pretty simple; the
> whatever_other_mlt subroutine in your run_star_extras.f just calls the
> public mlt subroutine mlt_eval, and you can call this with different alphas
> for different zones.  For instance you could have a line in
> whatever_other_mlt that calculates alpha as a function of logP, or omega,
> or any variable which is independent for the purposes of MLT.
>
> Calculating an alpha that depends on gradT on the other hand sounds weird
> because gradT is a function of alpha, and you haven't solved for it
> yet---this is reflected in the fact that gradT is to be stored in
> mlt_basics, which has intent(out) in your whatever_other_mlt.  You could in
> principle make reference to gradT from the last time step, which has been
> interpolated onto the new mesh and stored in the star_info pointer, but
> first, why do you want to do this?
>
> Chris
>
> On Fri, Apr 29, 2016 at 5:58 AM, Ireland, Lewis <lgi201 at exeter.ac.uk>
> wrote:
>
>> Hi,
>>
>> I am currently using an other_mlt routine to modify the standard
>> convection prescription.
>>
>> I wish to set a value for alpha, i.e. mixing_length_alpha, which I will
>> call alpha_0. Then I wish to run a model using a depth-dependent alpha in
>> such a way that -> alpha(r) = alpha_0 * other stuff(r).
>>
>> How can I take the mixing_length_alpha (alpha_0) parameter set in the
>> inlist, and create a depth-dependent array of alpha values? My
>> depth-dependent alpha will depend on gradT at each point, but I can see
>> that in the Get_results subroutine, mixing_length_alpha is used multiple
>> times before gradT is even calculated!
>>
>> Cheers,
>>
>> Lewis
>>
>> ------------------------------------------------------------------------------
>> Find and fix application performance issues faster with Applications
>> Manager
>> Applications Manager provides deep performance insights into multiple
>> tiers of
>> _______________________________________________
>> mesa-users mailing list
>> mesa-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
>
> _______________________________________________
> 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/20160429/a2d93f2e/attachment.html>
```