[Mesa-users] Finding the origin of an internal error

[Francis Timmes]

i suggest starting as simple as possible. gain confidence and understanding
in that part of the model, and only then adding complicating pieces one at a time.

if you've never run a non-rotating, zero mass loss, single star 3 msun model 
from zams to, say, core helium depletion, then do that first. then add 
standard mass loss prescriptions to gain an understanding of what happens 
when and and why. then add rotation to learn how the angular momentum and
other properties evolve in the model. only after this consider adding a 
x_ctrl variable to mimic binary mass transfer. then proceed to evolving 
the two stars, a non-rotating 5 msun and a rotating 3 msun, in a binary model.

fxt




> On Oct 26, 2018, at 9:42 AM, Gehrman, Thomas Charles <thomas.gehrman at mnsu.edu> wrote:
> 
> Thank you all for the input! I do have a questions about simplifying the 3M model. Do you think it will be best to create a x_ctrl variable to simulate mass transfer for the single star model since my equations strictly depend on binary mass transfer? I think what I would do, is start the star not at omega/omega_crit= 0.1 at  zams, but have it slowly achieve the omega/omega_crit = 0.1 over period of time without my equations. Then of course implement them later. Do you think this would be the best approach?
> 
> The paper's data I'm reproducing has the star spinning at omega/omega_crit = 0.1 at the start of mass transfer and this is why I started the spin at zams. 
> 
> Thank you again,
> 
> Thomas
> From: Francis Timmes <fxt44 at mac.com>
> Sent: Friday, October 26, 2018 2:00:50 AM
> To: Gehrman, Thomas Charles
> Cc: Frank Timmes; mesa-users at lists.mesastar.org
> Subject: Re: [Mesa-users] Finding the origin of an internal error
>  
> on the modeling side of the house, it appears, if i understand 
> correctly from just reading the inlists, the issue is getting the 
> 3.0 msun model in the binary to rotate with omega/omega_crit = 0.1 at zams.
> if so, my suggestiion to to reduce the complexity by running the 3.0 msun 
> as a single star until it is working, then return to binary.
> 
> fxt
> 
> 
> 
> 
> 
> > On Oct 25, 2018, at 11:49 PM, Warrick Ball via Mesa-users <mesa-users at lists.mesastar.org> wrote:
> > 
> > Hi Thomas,
> > 
> > If you're just making small changes in `star`, I think it should be fine to just run `./i1` after you've made your changes.  `star/i1` just points to `utils/i1` which contains
> > 
> >    #!/bin/bash
> > 
> >    function check_okay {
> >            if [ $? -ne 0 ]
> >            then
> >                    echo
> >                    pwd
> >                    echo "./build_and_test FAILED"
> >                    echo
> >                    exit 1
> >            fi
> >    }
> > 
> >    ./build_and_test
> >    check_okay
> >    echo "export"
> >    ./export
> >    echo "done"
> > 
> > If you do something that affects the test results, you can skip the test by touching the file `star/skip_test`.
> > 
> > Or, as Roque has already said, you can just run `./export` after rebuilding `star`.
> > 
> > Cheers,
> > Warrick
> > 
> > 
> > ------------
> > Warrick Ball
> > Postdoc, School of Physics and Astronomy
> > University of Birmingham, Edgbaston, Birmingham B15 2TT
> > W.H.Ball at bham.ac.uk
> > +44 (0)121 414 4552
> > 
> > 
> > On Thu, 25 Oct 2018, Gehrman, Thomas Charles wrote:
> > 
> >> Hello all,
> >> I have a question regarding determining the origin of an internal error.
> >> When I run my model the time steps become so short they're on the dynamical timescale. When I set report_why_dt_limits to true I find the that the set_omega_adjust_mass failed to adjust mass printed out in
> >> my terminal. I went to star/private directory to find the adjust_mass module and look for the set_omega_adjust_mass subroutine to figure out what part of the routine is failing. I was attempting to put print
> >> statements in the routine in specific spots to see if it would printout in the terminal to find the error. However, I noticed that even if I ./clean and ./mk all the private modules in mesa/star it doesn't
> >> carry through to my terminal output. Is there a way to have print statments in the terminal so I can solve exactly what is failing in the set_omega_adjust_mass subroutine? I've been stuck on this for awhile
> >> and have tried changing the mesh_delta_coeff varcontrol_target among other suggestions to solve my time step problem.
> >> I have attached my inlists and run_star_extras files. Sorry if the run_binary_extras is a bit messy. My formulas I'm using from my paper are a bit cumbersome.
> >> Thank you,
> >> Thomas
> >> Thomas C. Gehrman Jr.
> >> M.S. Physics & Graduate Teaching Assistant
> >> Department of Physics and Astronomy
> >> Minnesota State University, Mankato
> >> Office: N144
> >> 
> > _______________________________________________
> > mesa-users at lists.mesastar.org
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mesastar.org%2Fmailman%2Flistinfo%2Fmesa-users&data=02%7C01%7Cthomas.gehrman%40mnsu.edu%7Cbc227a3442bd43d0122c08d63b10c4ea%7C0c0d13782eaf49c7afa98b40189a1b5c%7C0%7C0%7C636761340561763183&sdata=Yo4kQqGeT3fzRj87sd8P5Q0YHMxVSlW%2FkCqik4zgKkI%3D&reserved=0
> >