mesa-users — open list for mesa comments, questions, & answers

[mesa-users] extrem horizontal branch star

[AbdelBassit A. S. <se...@ho...>]

Hi all :

I am trying to repduce the ‘’extrem horizontal branch star’’ on MESA, but i had problems on that i get an evolution after the red geant step.

Do you have any hint or advice to do the code correctly !


Cheers

Abdel

Provenance : Courrier<https://go.microsoft.com/fwlink/?LinkId=550986> pour Windows 10

Re: [mesa-users] What are included in the 'other' burning?

[Byeong-Chan P. <pb...@gm...>]

Oops, I missed Rob's answer.

I get a set of information for the class of nuclear burning in accordance
with current network by the show_net_reactions_info = .true. command.
Terminal displays this after mesa creates main sequence model.

Thank you for your help.

Park

2017-05-09 7:48 GMT+09:00 Josiah Schwab <jws...@uc...>:

>
> > what is rigorous definition of the 'other' burning in mesa?
>
> The rigorous definition is given by Rob's answer earlier in the thread.
> Use the control
>
>   show_net_reactions_info = .true.
>
> to print out information about each reaction in your network.  That
> should tell you exactly what MESA is classifying as "other".
>
> Hope that helps,
> Josiah
>

Re: [mesa-users] negative delta nu!?!

[Jean M. <je...@nm...>]

Here are the inlists I used.

2017-05-08 17:22 GMT-06:00 Jean McKeever <je...@nm...>:

> Hello,
>
> I am running some models using astero and have ran into an interesting
> conundrum. As soon as astero starts computing individual frequencies, the
> delta_nu value, both printed on the graph display and written to the
> history file, becomes negative.  I am using gyre to compute only radial
> modes. Has anyone else encountered this or something similar?
>
> On another note I am constantly getting  a "failed to find required l=0
> modes" message, however modes appear on the echelle diagram. I have double
> checked my gyre input files are in the right units and cover the range of
> observed modes. Is this something to worry about?
>
>
> Jean McKeever
>

Re: [mesa-users] negative delta nu!?!

[Aaron D. <aar...@gm...>]

Hi Jean,

It will help to diagnose your problem if you send your inlists to
Mesa-users. And maybe tell us more about what you're doing.

Thanks,
Aaron

On Mon, May 8, 2017 at 7:22 PM Jean McKeever <je...@nm...> wrote:

> Hello,
>
> I am running some models using astero and have ran into an interesting
> conundrum. As soon as astero starts computing individual frequencies, the
> delta_nu value, both printed on the graph display and written to the
> history file, becomes negative.  I am using gyre to compute only radial
> modes. Has anyone else encountered this or something similar?
>
> On another note I am constantly getting  a "failed to find required l=0
> modes" message, however modes appear on the echelle diagram. I have double
> checked my gyre input files are in the right units and cover the range of
> observed modes. Is this something to worry about?
>
>
> Jean McKeever
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>

Re: [mesa-users] negative delta nu!?!

[Earl B. <bel...@mp...>]

Hi Jean,

Can you post your inlists?

Best regards,
Earl Bellinger

On Mon, May 8, 2017 at 7:22 PM, Jean McKeever <je...@nm...> wrote:

> Hello,
>
> I am running some models using astero and have ran into an interesting
> conundrum. As soon as astero starts computing individual frequencies, the
> delta_nu value, both printed on the graph display and written to the
> history file, becomes negative.  I am using gyre to compute only radial
> modes. Has anyone else encountered this or something similar?
>
> On another note I am constantly getting  a "failed to find required l=0
> modes" message, however modes appear on the echelle diagram. I have double
> checked my gyre input files are in the right units and cover the range of
> observed modes. Is this something to worry about?
>
>
> Jean McKeever
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

[mesa-users] negative delta nu!?!

[Jean M. <je...@nm...>]

Hello,

I am running some models using astero and have ran into an interesting
conundrum. As soon as astero starts computing individual frequencies, the
delta_nu value, both printed on the graph display and written to the
history file, becomes negative.  I am using gyre to compute only radial
modes. Has anyone else encountered this or something similar?

On another note I am constantly getting  a "failed to find required l=0
modes" message, however modes appear on the echelle diagram. I have double
checked my gyre input files are in the right units and cover the range of
observed modes. Is this something to worry about?


Jean McKeever

Re: [mesa-users] What are included in the 'other' burning?

[Josiah S. <jws...@uc...>]

> what is rigorous definition of the 'other' burning in mesa?

The rigorous definition is given by Rob's answer earlier in the thread.
Use the control

  show_net_reactions_info = .true.

to print out information about each reaction in your network.  That
should tell you exactly what MESA is classifying as "other".

Hope that helps,
Josiah

Re: [mesa-users] What are included in the 'other' burning?

[Byeong-Chan P. <pb...@gm...>]

Thank you for your help. However, unfortunately, I encounter new problem. I
think some reaction categories show some mismatch between reaclib_input.f90
and the reactions.list.

I understand 'other' burning means nuclear reactions for z (z: atomic
number) > 28 isotopes based on the reaclib_unput.f90. However, the
reaction.list file shows some reactions with light elements are categorized
as 'other' burning. For example, f19(p,a)o16 reaction is categorized as
'other' in the reaction.list file. As you know f19 and o16 are not
contained in z>28 isotopes......

what is rigorous definition of the 'other' burning in mesa?

2017-05-05 0:19 GMT+09:00 Josiah Schwab <jws...@uc...>:

> Hello,
>
> > As you know profile data shows energy genration by each reaction rates,
> for
> > example, 'pp, cno, trialpha, burn_c, burn_o.....'. There are 'other'
> > inlcuded in the burning list, but I can't find what is the definition of
> > the 'other' burning anywhere.
> >
> > what are included in the 'other' burning?
>
> The file
>
>   $MESA_DIR/data/rates_data/reactions.list
>
> has a list of some reactions and includes a column indicating the
> "category" of each reaction.
>
> You should also look at the subroutine extract_rates_from_reaclib in
>
>   $MESA_DIR/rates/private/reaclib_input.f90
>
> where this classification happens from reactions coming from reaclib (it
> is primarily based on Z).
>
> Josiah
>

Re: [mesa-users] What are included in the 'other' burning?

[Robert F. <rjf...@as...>]

Also if you add:

show_net_reactions_info = .true.

to your star_job inlist mesa will print out information about each reaction
in your network and which category it is in

Rob

On Thu, May 4, 2017 at 8:19 AM, Josiah Schwab <jws...@uc...> wrote:

> Hello,
>
> > As you know profile data shows energy genration by each reaction rates,
> for
> > example, 'pp, cno, trialpha, burn_c, burn_o.....'. There are 'other'
> > inlcuded in the burning list, but I can't find what is the definition of
> > the 'other' burning anywhere.
> >
> > what are included in the 'other' burning?
>
> The file
>
>   $MESA_DIR/data/rates_data/reactions.list
>
> has a list of some reactions and includes a column indicating the
> "category" of each reaction.
>
> You should also look at the subroutine extract_rates_from_reaclib in
>
>   $MESA_DIR/rates/private/reaclib_input.f90
>
> where this classification happens from reactions coming from reaclib (it
> is primarily based on Z).
>
> Josiah
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>

Re: [mesa-users] What are included in the 'other' burning?

[Josiah S. <jws...@uc...>]

Hello,

> As you know profile data shows energy genration by each reaction rates, for
> example, 'pp, cno, trialpha, burn_c, burn_o.....'. There are 'other'
> inlcuded in the burning list, but I can't find what is the definition of
> the 'other' burning anywhere.
>
> what are included in the 'other' burning?

The file

  $MESA_DIR/data/rates_data/reactions.list

has a list of some reactions and includes a column indicating the
"category" of each reaction.

You should also look at the subroutine extract_rates_from_reaclib in

  $MESA_DIR/rates/private/reaclib_input.f90

where this classification happens from reactions coming from reaclib (it
is primarily based on Z).

Josiah

[mesa-users] What are included in the 'other' burning?

[Byeong-Chan P. <pb...@gm...>]

Dears.

I simulate stellar evolution with mesa8118.

As you know profile data shows energy genration by each reaction rates, for
example, 'pp, cno, trialpha, burn_c, burn_o.....'. There are 'other'
inlcuded in the burning list, but I can't find what is the definition of
the 'other' burning anywhere.

what are included in the 'other' burning?

Thanks
Park

Re: [mesa-users] Extracting data from TRho_profile plot

[Robert F. <rjf...@as...>]

Hi

Also you'll want to look in $MESA_DIR/star/private/pgstar_trho_profile.f90
to see how the data is potted

If you a python person, then you could use my plotting package
https://github.com/rjfarmer/mesaplot which has all the lines for the trho
already hooked up.

After installing it:

import mesaPlot as mp
m=mp.MESA()
m.loadProfile(num=model_number)
p=mp.plot()
p.setMESAPath("MESA_DIR")
p.plotTRho(m,showAll=True)

Rob


On Tue, May 2, 2017 at 12:20 PM, Manos Chatzopoulos <
cha...@ph...> wrote:

> Hi Jieun,
>
> Found them - perfect thanks a lot!
>
> Manos
>
> On 5/2/17 2:14 PM, Choi, Jieun wrote:
>
> Hi Manos,
>
> They can be found in mesa/data/star_data/plot_info.
>
> Cheers,
> Jieun
>
> On Tue, May 2, 2017 at 2:58 PM, Manos Chatzopoulos <
> cha...@ph...> wrote:
>
>> Dear mesa-users,
>>
>> Anyone knows if some data that are plotted in the TRho_profile pgplot
>> png files like the degeneracy line, the Pgas ~ Prad line and the nuclear
>> burning lines can be easily extracted from somewhere within MESA (I
>> could calculate these lines on my own, but I am trying to save time from
>> that). For example, can one extract a file that contains the logT vs
>> logRho datapoints that correspond to the degeneracy line for plotting
>> with an external plotting tool?
>>
>> Thank you all,
>>
>> --
>> Dr. Manos Chatzopoulos
>> Assistant Professor
>> Department of Physics & Astronomy
>> Louisiana State University
>> Nicholson #275
>> Office # 225-578-2907 <(225)%20578-2907>
>> Baton Rouge, LA 70803
>> United States of America
>> http://www.lsu.edu/physics/people/faculty/chatzopoulos.php
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> mesa-users mailing list
>> mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>
>
> --
> Dr. Emmanouil Chatzopoulos
> Assistant Professor
> Department of Physics & Astronomy
> Nicholson 275
> Office # 225-578-7459 <(225)%20578-7459>
> Louisiana State University
> Baton Rouge, LA 70803
> United States of Americahttp://www.lsu.edu/physics/people/faculty/chatzopoulos.php
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

Re: [mesa-users] Extracting data from TRho_profile plot

[Choi, J. <jie...@cf...>]

Hi Manos,

They can be found in mesa/data/star_data/plot_info.

Cheers,
Jieun

On Tue, May 2, 2017 at 2:58 PM, Manos Chatzopoulos <
cha...@ph...> wrote:

> Dear mesa-users,
>
> Anyone knows if some data that are plotted in the TRho_profile pgplot
> png files like the degeneracy line, the Pgas ~ Prad line and the nuclear
> burning lines can be easily extracted from somewhere within MESA (I
> could calculate these lines on my own, but I am trying to save time from
> that). For example, can one extract a file that contains the logT vs
> logRho datapoints that correspond to the degeneracy line for plotting
> with an external plotting tool?
>
> Thank you all,
>
> --
> Dr. Manos Chatzopoulos
> Assistant Professor
> Department of Physics & Astronomy
> Louisiana State University
> Nicholson #275
> Office # 225-578-2907
> Baton Rouge, LA 70803
> United States of America
> http://www.lsu.edu/physics/people/faculty/chatzopoulos.php
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>

Re: [mesa-users] Extracting data from TRho_profile plot

[Kenny V. <kv...@ua...>]

Hi Manos,

The data that contains the information describing the properties you're
looking for are likely in profile.data files inside the LOG folder of your
run.
You can also adjust the outputs here by changing the profile_columns.list
file to fit your needs.

Best

On 2 May 2017 at 11:58, Manos Chatzopoulos <cha...@ph...>
wrote:

> Dear mesa-users,
>
> Anyone knows if some data that are plotted in the TRho_profile pgplot
> png files like the degeneracy line, the Pgas ~ Prad line and the nuclear
> burning lines can be easily extracted from somewhere within MESA (I
> could calculate these lines on my own, but I am trying to save time from
> that). For example, can one extract a file that contains the logT vs
> logRho datapoints that correspond to the degeneracy line for plotting
> with an external plotting tool?
>
> Thank you all,
>
> --
> Dr. Manos Chatzopoulos
> Assistant Professor
> Department of Physics & Astronomy
> Louisiana State University
> Nicholson #275
> Office # 225-578-2907
> Baton Rouge, LA 70803
> United States of America
> http://www.lsu.edu/physics/people/faculty/chatzopoulos.php
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>

Re: [mesa-users] Extracting data from TRho_profile plot

[Jakub O. <ost...@as...>]

Hi,

Take a look at data/star_data/plot_info.

Cheers,
Jakub

> On 2 May 2017, at 20:58, Manos Chatzopoulos <cha...@ph...> wrote:
> 
> Dear mesa-users,
> 
> Anyone knows if some data that are plotted in the TRho_profile pgplot 
> png files like the degeneracy line, the Pgas ~ Prad line and the nuclear 
> burning lines can be easily extracted from somewhere within MESA (I 
> could calculate these lines on my own, but I am trying to save time from 
> that). For example, can one extract a file that contains the logT vs 
> logRho datapoints that correspond to the degeneracy line for plotting 
> with an external plotting tool?
> 
> Thank you all,
> 
> -- 
> Dr. Manos Chatzopoulos
> Assistant Professor
> Department of Physics & Astronomy
> Louisiana State University
> Nicholson #275
> Office # 225-578-2907
> Baton Rouge, LA 70803
> United States of America
> http://www.lsu.edu/physics/people/faculty/chatzopoulos.php
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

Re: [mesa-users] Extracting data from TRho_profile plot

[Manos C. <cha...@ph...>]

Hi Jieun,

Found them - perfect thanks a lot!

Manos


On 5/2/17 2:14 PM, Choi, Jieun wrote:
> Hi Manos,
>
> They can be found in mesa/data/star_data/plot_info.
>
> Cheers,
> Jieun
>
> On Tue, May 2, 2017 at 2:58 PM, Manos Chatzopoulos 
> <cha...@ph... <mailto:cha...@ph...>> wrote:
>
>     Dear mesa-users,
>
>     Anyone knows if some data that are plotted in the TRho_profile pgplot
>     png files like the degeneracy line, the Pgas ~ Prad line and the
>     nuclear
>     burning lines can be easily extracted from somewhere within MESA (I
>     could calculate these lines on my own, but I am trying to save
>     time from
>     that). For example, can one extract a file that contains the logT vs
>     logRho datapoints that correspond to the degeneracy line for plotting
>     with an external plotting tool?
>
>     Thank you all,
>
>     --
>     Dr. Manos Chatzopoulos
>     Assistant Professor
>     Department of Physics & Astronomy
>     Louisiana State University
>     Nicholson #275
>     Office # 225-578-2907
>     Baton Rouge, LA 70803
>     United States of America
>     http://www.lsu.edu/physics/people/faculty/chatzopoulos.php
>     <http://www.lsu.edu/physics/people/faculty/chatzopoulos.php>
>
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     _______________________________________________
>     mesa-users mailing list
>     mes...@li...
>     <mailto:mes...@li...>
>     https://lists.sourceforge.net/lists/listinfo/mesa-users
>     <https://lists.sourceforge.net/lists/listinfo/mesa-users>
>
>

-- 
Dr. Emmanouil Chatzopoulos
Assistant Professor
Department of Physics & Astronomy
Nicholson 275
Office # 225-578-7459
Louisiana State University
Baton Rouge, LA 70803
United States of America
http://www.lsu.edu/physics/people/faculty/chatzopoulos.php

[mesa-users] Extracting data from TRho_profile plot

[Manos C. <cha...@ph...>]

Dear mesa-users,

Anyone knows if some data that are plotted in the TRho_profile pgplot 
png files like the degeneracy line, the Pgas ~ Prad line and the nuclear 
burning lines can be easily extracted from somewhere within MESA (I 
could calculate these lines on my own, but I am trying to save time from 
that). For example, can one extract a file that contains the logT vs 
logRho datapoints that correspond to the degeneracy line for plotting 
with an external plotting tool?

Thank you all,

-- 
Dr. Manos Chatzopoulos
Assistant Professor
Department of Physics & Astronomy
Louisiana State University
Nicholson #275
Office # 225-578-2907
Baton Rouge, LA 70803
United States of America
http://www.lsu.edu/physics/people/faculty/chatzopoulos.php

[mesa-users] More on the definition of Teff

[Warrick B. <wb...@bi...>]

Hi again all,

Continuing my tinkering with atmospheric structure, I've come across what 
looks like some coding of Teff as the temperature of a model's outermost 
meshpoint.  Since I'm working on incorporating the stellar atmosphere into 
the stellar model, the outermost meshpoint is *not* the photosphere, which 
causes issues.

As a simple example, I've attached an inlist for r9575 that extends the 
outermost meshpoint of the model to an optical depth of 0.001*(2/3).  It's 
possible to show that by solving the usual structure equations above the 
photosphere, you recover an Eddington grey atmosphere.

When run, you'll get a profile for the last model (final.profile).  In the 
header data, I find Teff = 5778.56 K, as is displayed to the terminal 
during the evolution.  But if I compute the effective temperature using 
the black body law with photosphere_L and photosphere_r from the same 
profile, I get Teff = 5780.28 K.  What's going on?

I did some digging into the code and found that Teff is set by the 
atmosphere module.  Following the function calls, I eventually got to line 
215 of atm/private/integrate_atm.f90:

     Teff4 = L/(4d0*pi*R*R*boltz_sigma)

which, on first sight, looks fine.  But what are R and L here?  Turns out 
that these come from line 1372+ in star/private/hydro_vars.f90:

     call atm_get_int_T_tau( &
        s% atm_int_errtol, s% cgrav(1), M, r_surf, L_surf, &
        ...

As the name suggests, r_surf and L_surf are defined on lines 809-810 as

     r_surf = s% r(1)
     L_surf = s% L(1)

So Teff is indeed being defined by the outermost meshpoints, rather than 
the actual photosphere.

Two notes here.  First, this doesn't matter if, like in most cases I 
expect, the outermost meshpoint *is* the photosphere. Second, I noticed 
that elsewhere (and for what purpose I'm not sure) the star_info structure 
has a variable called photosphere_black_body_T.  This is computed e.g. on 
lines 93-94 of star/private/report.f90:

     s% photosphere_black_body_T = &
        atm_black_body_T(s% photosphere_L, s% photosphere_r)

where atm_black_body_T is on lines 656-661 in atm/public/atm_lib.f90:

     real(dp) function atm_black_body_T(L, R)
        use crlibm_lib, only: pow_cr
        use const_def, only: pi, boltz_sigma
        real(dp), intent(in) :: L, R
        atm_black_body_T = pow_cr(L / (4d0*pi*R*R*boltz_sigma), 0.25d0)
     end function atm_black_body_T

and is therefore what I would expect Teff to be.

Anyway, I'm not sure what the "fix" is.  In my own work in progress, I use 
the star_info pointer to get the photospheric information inside the 
routine for the atmospheric BC, so that Teff is returned correctly.  It 
works for me but I have no idea if that a universal or optimal solution.

Cheers,
Warrick




------------
Warrick Ball
Postdoc, School of Physics and Astronomy
University of Birmingham, Edgbaston, Birmingham B15 2TT
wb...@bi...
+44 (0)121 414 4552

Re: [mesa-users] Running PGSTAR on VPN connection alongside with screen command

[Héctor MR <hec...@pi...>]

  Hi Josiah, Evan,

  Thank you so much for your advice!

A possible workaround is to turn off the plot windows (with the
> *_win_flag controls) before you detach and then turn them back on
> after you resume.  I'm not 100% sure this will work, but I seem to
> vaguely recall doing something similar.
> Let us know how that goes.
>


> The best workaround I’ve been able to find is to turn off all “_win_flag”
> controls and turn on the associated “_file_flag” controls. This at least
> avoids creating an X session during the run, so it won’t kill it when you
> disconnect and close the terminal. And it preserves the ability to have
> images you can look at to track things, just not quite in real time.
>

  You are right. The way my inlist_pgstar is structured, setting

  Grid1_win_flag = .false.

  has been enough.


> I would of course love to find a way to associate an X session with a tmux
> or screen session, but some googling a while ago suggested that it’s either
> impossible or very difficult for reasons I don’t remember. Hoping somebody
> will come along and prove me wrong!
>

  This is precisely what I was thinking about when I wrote my email. I hope
anyone can figure this out!

  Thanks!


  --
  H.

Re: [mesa-users] Running PGSTAR on VPN connection alongside with screen command

[Evan B. <eb...@ph...>]

Hi Hector,

The best workaround I’ve been able to find is to turn off all “_win_flag” controls and turn on the associated “_file_flag” controls. This at least avoids creating an X session during the run, so it won’t kill it when you disconnect and close the terminal. And it preserves the ability to have images you can look at to track things, just not quite in real time.

I would of course love to find a way to associate an X session with a tmux or screen session, but some googling a while ago suggested that it’s either impossible or very difficult for reasons I don’t remember. Hoping somebody will come along and prove me wrong!

Cheers,
Evan

> On Apr 19, 2017, at 9:26 AM, Josiah Schwab <jws...@uc...> wrote:
> 
> Hi Héctor,
> 
> A possible workaround is to turn off the plot windows (with the
> *_win_flag controls) before you detach and then turn them back on
> after you resume.  I'm not 100% sure this will work, but I seem to
> vaguely recall doing something similar.
> 
> Let us know how that goes.
> 
> Josiah
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

Re: [mesa-users] Running PGSTAR on VPN connection alongside with screen command

[Josiah S. <jws...@uc...>]

Hi Héctor,

A possible workaround is to turn off the plot windows (with the
*_win_flag controls) before you detach and then turn them back on
after you resume.  I'm not 100% sure this will work, but I seem to
vaguely recall doing something similar.

Let us know how that goes.

Josiah

[mesa-users] Running PGSTAR on VPN connection alongside with screen command

[Héctor MR <hec...@pi...>]

  Dear all,

  When I run MESA in a cluster through a VPN connection (ssh -XY
my...@se...), I usually employ the screen command so that my
calculations will keep running after I close the terminal. However, if I
try to do so when pgstar_flag = .true., the calculations will stop upon
closing the terminal with an error message

  XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server
"localhost:10.0"
      after 85 requests (81 known processed) with 0 events remaining.

  Does anybody know how to couple the PGSTAR interactive plot with screen
so that, after closing and then resuming the screen (screen -r), I can see
MESA happily running with PGPLOT?

  Thanks!


  --
  H.

Re: [mesa-users] secular modes with GYRE

[<al...@ga...>]

Rich,

thanks for the pointer to the hidden treasure in &osc! This is the  
basic trick I looked for. I will play around with it.

> There already is some support in GYRE for this kind of calulation.  
> In the &osc namelist group, there is an (undocumented) parameter  
> ‘time_factor’ which allows one to control the assumed time  
> dependence of modes. The two options are ‘OSC’, which has time  
> dependence proportional to exp(-i omega t), and ‘EXP’, which has  
> time dependence proportional to exp(-omega t). The ‘EXP’ option in  
> effect allows one to scan along the imaginary frequency axis, which  
> I use when searching for dynamically unstable modes.

The above is potentially helpful also to the broader stellar-evolution  
community.
The rest that follows is indeed more of shop-talk for your GYRE-Forum,  
so I keep my mouth shut on that here.

Alfred


> The more general case of scanning along an arbitrary line in the  
> complex plane isn’t supported by GYRE, but there are some  
> (experimental) executables that ship with GYRE, which provide this  
> sort of functionality. In particular, the file  
> gyre/src/frontend/gyre_map.fpp allows a 2-D sampling of the  
> discriminant D(omega) over the complex plane, which is a robust way  
> to find very non-adiabatic modes. Attached below for your amusement  
> is a map showing the real(D)=0 (blue) and imag(D)=0 (red) contours  
> for radial modes in a massive star, as calculated using gyre_map.  
> The crossings of these contours correspond to the star’s modes. Note  
> the almost-complex-conjugate pairs of modes — we’re in the NAR limit  
> here!
>
> To build gyre_map, all you need do is download the most recent  
> release candidate of GYRE (5.0rc3), edit gyre/src/build/Makefile to  
> add gyre_map to the definitions of the TARGETS variable, and then  
> build as usual; gyre_map will then be placed in gyre/bin. An example  
> of gyre_map in action is given in the gyre/test/map directory; just  
> do ‘./gyre_map gyre_map.in’ to run the example. The resulting map.h5  
> file can be plotted as a contour map using the plot_map.py python  
> script in the same directory.
>
> Since this is a very GYRE/pulsation specific topic, perhaps we  
> should take further discussion to the GYRE forums (unless people on  
> the MESA list want to hear about very non-adiabatic modes and the  
> numerical challenges they present?).
>
> cheers,
>
> Rich
>
>

Re: [mesa-users] Entropy Profiles

[Pablo M. <pa...@gm...>]

Then I would expect that your MESA model should be happy to sit forever with
>
>   dL/dM = eps_nuc
>
> and hence Tds/dt = 0.
>

I don't think this is right, this forces the star to be in thermal
equilibrium, and that's not equivalent to evolving at constant entropy. It
will actually force the star to an entropy profile such that T ds/dt=0.
This is quite obvious if you have mass loss on a ZAMS star while fixing its
composition profile and assuming hydrostatic equilibrium. In this case
setting eps_grav=0 will just give you the different entropy profiles for
ZAMS stars of different masses, which are completely different.

In particular, if one is looking for a hydrostatic solution to the
equations of stellar structure, given a fixed composition and entropy
profile, this is completely determined by the mass and pressure equations.
The temperature and luminosity equations will then give you the value of T
ds/dt, which will very likely be non-zero.


> Josiah
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>



-- 
Pablo Marchant Campos
M.Sc on Astrophysics, Universidad Católica de Chile
PhD student, Argelander-Institut für Astronomie

Re: [mesa-users] Entropy Profiles

[Josiah S. <jws...@uc...>]

Hi Kenny,

> Has anyone had any success with freezing the entropy profile of a star? I
> have tried applying an eps_grav_factor = 0 as I thought this would result
> in dS/dt = 0, but this doesn't appear to be the case. Speaking to Bill it
> sounds as though mixing is the culprit for the change in entropy, so I was
> wondering if anyone has had any success in forcing the entropy profile to
> remain the same.

If you take a star that's in thermal equilibrium and turn off composition
changes due to burning

    dxdt_nuc_factor = 0

composition changes due to mixing

    mix_factor = 0

and neutrino losses

    non_nuc_neu_factor = 0

Then I would expect that your MESA model should be happy to sit forever with

  dL/dM = eps_nuc

and hence Tds/dt = 0.

Josiah