[Mesa-users] Using make_o_ne_wd to prepare some white dwarf models

[LAM Yi Hua]

Dear Richard,

Thanks for your info.
I am sorry, I am not aware that this is the exact version of SDK.

This shell script shows:
****************************
#!/bin/sh
#
# Return the SDK version

echo "x86_64-linux-20150908"
****************************






best regards,

Yi Hua
​, LAM

-- CaTCh EVEry SiNGle OppORtuNItY WhEN U r StILl alIVe --
---- Success Belonged To Those Who's Willing To Strive For It ----


On Wed, Jul 25, 2018 at 11:21 AM RICHARD H D TOWNSEND <
townsend at astro.wisc.edu> wrote:

>
>
> > On Jul 24, 2018, at 10:19 PM, LAM Yi Hua via Mesa-users <
> mesa-users at lists.mesastar.org> wrote:
> >
> > Dear Josiah,
> >
> >
> > >> Recently, I'd like to test some reactions associated with nova
> outbursts
> > >> using MESA-r10398 and MESA-sdk (revision 245). [Hopefully, older
> MESA-sdk
> > >> version won't affect the simulation.]
> >
> > >I don't understand how to interpret MESA SDK "revision 245".  But so
> > >long as MESA compiles, using an older MESA SDK should not be a problem.
> > >Results shouldn't vary between different SDKs.
> >
> > I meant MESA Software Development Kit (SDK) $Revision: 245 $
> > The revision number is written in /../../mesasdk/README
> >
>
> That's not the version. To print the version, run the command
> 'mesasdk_version.sh'
>
> cheers,
>
> Rich
>
> >
> >
> > >Most of the test suite cases have checks like
> >
> >  >    ! check for retries and backups as part of test_suite
> >  >        max_number_backups = 8
> >  >        max_number_retries = 30
> >  >        max_model_number = 700
> >
> > >which helps the developers notice if MESA suddenly starts struggling
> > >with a model that it use to evolve easily.
> >
> > Thanks for your reply!
> > I found that defining max_model_number can also help me to stop the
> simulation at a specified model (cycle) number.
> >
> >
> >
> > >Those temperatures sound like they're around the opacity blends between
> > >low and high T opacities.  Several opacity defaults changed between
> > >r8118 and r10398, so I don't think those differences are to worrying.
> >
> > >If that part of the evolution is of interest to you, you may be able to
> > >tune some opacity settings to eliminate it.
> >
> > Thanks for your suggestion.
> > If it is a kind of norm and not-worrying factor due to the change of
> MESA revision and blending of opacity, I will leave the fine-tune of
> opacity for future investigation.
> >
> >
> >
> > p/s: Thanks for writing my first name correctly... :)
> >
> >
> >
> > best regards,
> >
> > Yi Hua​, LAM​
> > -- CaTCh EVEry SiNGle OppORtuNItY WhEN U r StILl alIVe --
> > ---- Success Belonged To Those Who's Willing To Strive For It ----
> >
> >
> > On Wed, Jul 25, 2018 at 2:58 AM Josiah Schwab <jwschwab at ucsc.edu> wrote:
> > Hi Yi Hua,
> >
> > Let me add a few quick things for some of your questions.
> >
> > > Recently, I'd like to test some reactions associated with nova
> outbursts
> > > using MESA-r10398 and MESA-sdk (revision 245). [Hopefully, older
> MESA-sdk
> > > version won't affect the simulation.]
> >
> > I don't understand how to interpret MESA SDK "revision 245".  But so
> > long as MESA compiles, using an older MESA SDK should not be a problem.
> > Results shouldn't vary between different SDKs.
> >
> >
> > > I ran the simulation again, but it stopped at
> > >
> > > model 840
> > > stopping because of problems -- too many retries
> > > terminated evolution: nonzero_ierr
> > > termination code: max_number_retries
> > >
> > > Perhaps, someone can identify the problem.
> >
> > Most of the test suite cases have checks like
> >
> >      ! check for retries and backups as part of test_suite
> >          max_number_backups = 8
> >          max_number_retries = 30
> >          max_model_number = 700
> >
> > which helps the developers notice if MESA suddenly starts struggling
> > with a model that it use to evolve easily.
> >
> > Once you start adapting the inlists to your own problem, you can
> > probably delete these lines.
> >
> > > Although the HR diagram shown in Figure 1 of
> > > make_o_ne_wd/docs/make_o_ne_wd.pdf could not be reproduced, at least I
> can
> > > confirm that my installation is successful, and a partial HR diagram
> was
> > > produced from log Teff=3.9 up to 5.5 and log L/Ldot = 3.7 up to 4.5.
> >
> > The PDF documentation of MESA is quite old at this point, so I would not
> > worry about exactly reproducing it.  (We still include it since it
> > describes why many of the tests exist.)  For tests like this one which
> > are demonstration of a MESA capability, some difference are not worrying.
> >
> >
> > > I do not think the problem is due to older MESA-SDK version. After
> that, I
> > > tested the make_o_ne_wd test_suite of MESA-r8118 with MESA-sdk
> (revision
> > > 245). This simulation ran successfully until it terminated with
> > > log_L_lower_limit. The produced HR diagram make_o_ne_wd (MESA-r8118)
> is not
> > > exactly the same as the partial HR diagram of MESA-r10398, in
> particular
> > > there is a kink from Teff=3.9 to 4.2 in the HR diagram of make_o_ne_wd
> of
> > > MESA-r8118 during the post-AGB stage. In fact, the HR diagram shown in
> > > Figure 1 of make_o_ne_wd.pdf also has that kink.
> > >
> > > As long as we can still produce a WD model eventually, shall we change
> some
> > > settings to eliminate/reduce such kink? [Question 1]
> >
> > Those temperatures sound like they're around the opacity blends between
> > low and high T opacities.  Several opacity defaults changed between
> > r8118 and r10398, so I don't think those differences are to worrying.
> >
> > If that part of the evolution is of interest to you, you may be able to
> > tune some opacity settings to eliminate it.
> >
> >
> > Hope that helps a bit,
> > Josiah
> > _______________________________________________
> > mesa-users at lists.mesastar.org
> > https://lists.mesastar.org/mailman/listinfo/mesa-users
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20180725/1e49f49a/attachment.html>