[mesa-users] Fwd: Controls for Solver Tolerance

[Spencer C Wallace]

The vertical lines indicate the location of the convective boundary at each
snapshot. What confused me was that the composition is changing outside of
the convective region. Because this is outside the convective region, there
is little to no nuclear burning happening and no mixing, so I was rather
puzzled as to what would cause mu to increase. I was thinking maybe this
was due to the solver not finding an accurate enough solution.

Anyway, I realize that studying the MS evolution with no boundary mixing is
by no means physically realistic. As soon as I turn on overshoot, this
strange behavior goes away. However, since I am trying to write something
to replace the convective overshoot, I want to make sure that turbulent
entrainment is actually fixing the problem, rather than just covering it up.

On Mon, Nov 24, 2014 at 1:17 PM, Spencer C Wallace <
spencerw at email.arizona.edu> wrote:

> Thank you for the clarifications, Bill. I'll provide a little more
> background:
>
> I'm trying to simulate turbulent entrainment at the convective core
> boundary in massive stars during the main sequence. The code I have written
> is meant to be a more dynamic replacement for convective overshoot. Because
> I am trying to replace the standard boundary mixing algorithm, I am trying
> to understand what the code is doing both with and without overshoot
> enabled.
>
> I am using the Ledoux boundary condition for all of the models I run. If
> you recall, using Ledoux means that the criteria for convection is harder
> to satisfy near the boundary in the presence of a composition gradient.
> When I turn off overshoot, the composition gradient acts like a 'ratchet'
> that allows the core to recede, but makes it very difficult to grow at all,
> since there is no mixing across the boundary to punch through the mu
> gradient.
>
> Anyways, I found that I have to turn up the temporal and spatial
> resolution in order to get models that converge when the boundary mixing is
> disabled. This would be the end of the story, but I notice something very
> odd happening when I look at the evolution of the mu profiles in this case.
> The attached plot shows the mu profile at 3 different moments in time
> during the main sequence (blue = early, green = mid, red = late).
>
> On Sun, Nov 23, 2014 at 10:45 PM, Bill Paxton <paxton at kitp.ucsb.edu>
> wrote:
>
>> Hi,
>>
>> The "residual" is the left over difference between the left and right
>> hand sides of the equation we are trying to solve.  We do iterations to
>> reduce that, but we are limited by the non-linearity of the problem and the
>> quality of the estimates for the derivatives.
>>
>> The "correction" is the change in the primary variable that is calculated
>> using good-old Newton's rule in multiple dimensions --- so Jacobian and
>> residuals give a correction that would make the next residual vanish if the
>> problem were linear and the Jacobian was exact, neither of which are true.
>> So the best we can hope for is that the corrections will get smaller next
>> time.
>>
>> The "norm" is the average; the "max" is the max.  Sometimes you mainly
>> care about the norm and will accept a few outliers.  But sometimes you
>> don't want any really bad outliers, so you want to set a low limit for the
>> max residual or correction as well as the norm.
>>
>> You might want to try for several iterations with strict tolerances, and
>> then relax them if things are still not converged.  For example, you might
>> be willing to live with the larger tolerances, but you'd like to give it a
>> good try at the smaller ones before switching.  Also, you might be willing
>> to settle for any-old residual if the corrections have become small
>> enough.  You can do that too by relaxing the residual tolerances after a
>> few iterations.
>>
>> Hope that at least helps with the nomenclature.
>>
>> I agree with Frank that you should consider the effects of smaller
>> timesteps and more grid points as your main technique --- tightening up the
>> tolerances for the solver won't help if you are taking timesteps that are
>> too large or if you have inadequate grid resolution.
>>
>> -Bill
>>
>>
>>
>>
>> On Nov 23, 2014, at 7:51 PM, Spencer C Wallace wrote:
>>
>> > Hello,
>> >
>> > I am working with some models and I have a hunch that the solutions to
>> the structure and composition equations might not be precise enough for my
>> purposes. I would like to run a series of models with increasingly strict
>> tolerances for what the solver would consider a 'converged' solution.
>> >
>> > I found some inlist controls which looked useful:
>> >
>> > tol_correction_norm = 3d-5
>> > tol_max_correction = 3d-3
>> >
>> > max_iter_for_resid_tol1 = 4
>> > tol_residual_norm1 = 1d-4
>> > tol_max_residual1 = 1d-2
>> >
>> > I tried lowering the value of 'tol_max_residual1' and turning up
>> 'max_iter_for_resid_tol1'. Is this a good approach? I'm a little unclear
>> what the difference between 'tol_residual_norm1' and 'tol_max_residual1'
>> is. I'm not sure I understand what 'tol_correction_norm' and
>> 'tol_max_correction' do either. Would anyone care to enlighten me?
>> >
>> > Spencer Wallace
>> >
>> ------------------------------------------------------------------------------
>> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> > with Interactivity, Sharing, Native Excel Exports, App Integration &
>> more
>> > Get technology previously reserved for billion-dollar corporations, FREE
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&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/20141124/7b51241c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: muTimeNormTol5.png
Type: image/png
Size: 41061 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20141124/7b51241c/attachment.png>