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

[mesa-users] mesa bug fix release 3245

[Bill P. <pa...@ki...>]

Hi,

Thanks to James LLoyd to finding this bug that was introduced during some of my recent "improvements" to the net package and reaclib.  As you may know the reaclib interpolation formulas are not valid below T of 10^7.   So the code carefully avoids calling them for such low T's and just returns 0 rates instead.  Unfortunately it was doing that for the beta decays as well!   Not good.   Now it is fixed.   Since we get most weak rates from weaklib rather than reaclib, only a few decays were not happening -- but they include the ones in hydrogen CNO burning so it matters when you are using the full "cno extras" net.  The "basic" net assumes that the decays are instantaneous, so it wasn't effected by this particular bug.

As I said to James, sorry for the bug, but I'm sure that it must have been the last one in mesa so we should be okay now.  ; )

Cheers,
Bill

Re: [mesa-users] ine20

[Bill P. <pa...@ki...>]

Hi,

This routine should provide a template for what you need:
      
      
      subroutine write_abundance(s, k, cid)
         use chem_def
         type (star_info), pointer :: s
         integer, intent(in) :: k, cid
         integer :: j
         double precision :: abundance
         j = s% net_iso(cid)
         if (j == 0) then
            abundance = 0
         else
            abundance = s% xa(j, k)
         end if
         write(*,*) 'abundance ' // trim(chem_isos% name(cid)), j, cid, abundance
      end subroutine write_abundance



here's how to call it


      integer function extras_finish_step(s, id, id_extra)
         use chem_def
         type (star_info), pointer :: s
         integer, intent(in) :: id, id_extra


         call write_abundance(s, s% nz, ih1)
         call write_abundance(s, s% nz, ihe4)
         call write_abundance(s, s% nz, ic12)
         call write_abundance(s, s% nz, ine20)
         call write_abundance(s, s% nz, img24)



-Bill

[mesa-users] ine20

[Jing L. <jin...@ca...>]

Hellow,

I type 'use chem_def' in run_star_extras.f. And the isotope number 
returned by chem_def for Ne20 is ine20=114; But the size of s% chem_id 
is only 9. so when I used s% chem_id(ine20), it reports error. I guess 
the 9 isotopes included in the current nuclear network are 
H1,He3,He4,C12,N14,O16,Ne20,Mg24 and Si28; So I guess I should use s% 
xa(7,k) to give the mass fraction of Ne20 at shell k?

Actually I should be able to use s% xa(s% chem_id(ine20),k) to do the 
same thing, but it does not work. What might be wrong here please?

Thank you very much :-)

-- 
Sincerely
Jing

Ph.D candidate at physics.caltech
email: jin...@ca...
address: MC350-17,Caltech,1200 E.California Blvd
          Pasadena, CA 91125

Re: [mesa-users] solar calibration

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

Hi Zahra,

Two questions:

1.  What type of starting model did you use when you ran the solar
calibration job?  If not, you will need to use the same starting model.

Did you use all other inlist parameters exactly the same as in the solar
calibration run?  If not, then you'll need to use all the same settings.

Even with everything set up as in the solar calibration job, you may still
find *slightly* different results if you are using OpenMP.  But that effect
is not big enough to explain the difference in the depth of the convective
envelope that you reported.

Aaron



On Sun, Apr 17, 2011 at 1:01 AM, zahra altaha motahar <zam...@ya...>wrote:

> Hi,
>
> I have used the calibration inlist for finding the best initial Z, initial
> Y, and mixing length parameter that reproduce the solar luminosity and
> radius at solar age. After fine tuning and running the code and calibration
> several times, I could find the results as bellow
>
>                        Final Results
>                     <=================>
>                     Log10(R/Rsun) = -3.97536E-06
>                     Log10(L/Lsun) = -2.83505E-07
>                     log center Rho=  2.18996E+00
>                     log center P  =  1.73713E+01
>                     log center T  =  7.19736E+00
>                     center H      =  3.27475E-01
>                     center He4    =  6.50021E-01
>                     center Z      =  2.25040E-02
>                     surface H     =  7.36643E-01
>                     surface He4   =  2.45284E-01
>                     surface Z     =  1.80726E-02
>                     Rcz / Rsun    =  7.15706E-01
>                     Rov / Rsun    =  0.00000E+00
>
>                     rms (m-s)/s   =  1.43664E-03
>
> Then, I used the final Z, Y and alpha in my solar inlist and run the code
> up to solar age without calibration. The results were different in accuracy
> and the base of convective zone: 0.71659. Why with the same initial
> parameter that I found with calibration, MESA produce different L, R and
> R_cz?
>
>
> Regards,
> Zahra A. Motahar
> Master Candidate in Astrophysics
> Physics Department
> Faculty of Science
> University of Malaya
> za_...@si...
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

[mesa-users] solar calibration

[zahra a. m. <zam...@ya...>]

Hi,

I have used the calibration inlist for finding the best initial Z, initial Y, and mixing length parameter that reproduce the solar luminosity and radius at solar age. After fine tuning and running the code and calibration several times, I could find the results as bellow    

                       Final Results   
                    <=================>
                    Log10(R/Rsun) = -3.97536E-06
                    Log10(L/Lsun) = -2.83505E-07
                    log center Rho=  2.18996E+00
                    log center P  =  1.73713E+01
                    log center T  =  7.19736E+00
                    center H      =  3.27475E-01
                    center He4    =  6.50021E-01
                    center Z      =  2.25040E-02
                    surface H     =  7.36643E-01
                    surface He4   =  2.45284E-01
                    surface Z     =  1.80726E-02
                    Rcz / Rsun    =  7.15706E-01
                    Rov / Rsun    =  0.00000E+00
 
                    rms (m-s)/s   =  1.43664E-03
  

Then, I used the final Z, Y and alpha in my solar inlist and run the code up to solar age without calibration. The results were different in accuracy and the base of convective zone: 0.71659. Why with the same initial parameter that I found with calibration, MESA produce different L, R and R_cz?


Regards,

Zahra A. Motahar
Master Candidate in Astrophysics
Physics Department
Faculty of Science
University of Malaya
za_...@si...

[mesa-users] bug fix re-release for mesa -- 3201

[Bill P. <pa...@ki...>]

3201 replaces 3190

-Bill

Re: [mesa-users] Segfaults when running from photo

[Bill P. <pa...@ki...>]

Hi Warrick,

Great!  I'll get a new release out soon. 

Cheers,
Bill

On Apr 15, 2011, at 12:58 AM, Warrick Ball wrote:

> Bill,
> 
> That seems to have fixed it. ./re x050 (as well as x020 and x090 and a few other variations) ran perfectly when I compiled with gfortran. I also tried ifort just to be sure, and that worked too.
> 
> Thanks for responding so quickly!
> 
> Cheers,
> Warrick
> 
> On Thu, 14 Apr 2011, Bill Paxton wrote:
> 
>> Hi,
>> 
>> Okay -- let's try 3195 and see how that works.
>> 
>> do
>> svn update -r 3195
>> 
>> then to be safe, reinstall mesa
>> ./clean
>> ./install
>> 
>> then try the ./rn + ./re x050 again and let me know!
>> 
>> Thanks,
>> Bill
>> 
> 
> -- 
> Warrick Ball, PhD student
> Institute of Astronomy, Cambridge UK
> +44(0)1223 766653
> 

Re: [mesa-users] Segfaults when running from photo

[Bill P. <pa...@ki...>]

On Apr 14, 2011, at 7:13 AM, Warrick Ball wrote:

> I ran from the start (./rn), which stops at step 61 due to the core hydrogen limit. I then try to run from x050 (./re x050) and get the segfault.

Good news!  I breaks here too!    But only with gfortran -- ifort is fine on both the linux and max machines I've tried.
but we get a segfault with gfortran on both max and linux.  

I'll let you know as soon as I find and fix the problem.   New release coming soon!

thanks,
Bill

Re: [mesa-users] Segfaults when running from photo

[Kent B. <kg...@la...>]

Ahh, that sounds like a real bug then.

On Thu, 2011-04-14 at 14:46 +0100, Warrick Ball wrote:
> Kent,
> 
> This is a fresh installation and I'm taking photos from the run I've done 
> only moments before (so the same version). Even if I clear the photos/
> directory to make sure a new photo is generated, I get the segfault.
> 
> W
> 
> On Thu, 14 Apr 2011, Kent Budge wrote:
> 
> > Warrick,
> >
> > The photo restarts aren't guaranteed to work across versions of MESA.
> >> From the "How to Use MESA" web page:
> >
> > "Also, it should be emphasized that the photos are not intended for
> > long-term storage of models—the ‘save_model_number’ scheme described
> > above is meant for that purpose. Instead the photos are intended for use
> > during one specific run. In particular, when you update to a new version
> > of MESA star, you should expect your existing photo files to become
> > obsolete. If you have a lengthy run in progress when you want to update
> > MESA, then you should do ‘save_model_number’ to save state before
> > starting the update, and then do ‘load_saved_model’ to resume the
> > evolution after you have done the update."
> >
> >
> > On Thu, 2011-04-14 at 14:11 +0100, Warrick Ball wrote:
> >> Hi,
> >>
> >> I've just successfully installed MESA revision 3190. When I compile with
> >> gfortran (GCC 4.5.2), it runs on all of the "first things to try", except
> >> for restarting from a previous photo. After the first suggested run, if I
> >> try
> >>
> >> ./re x050
> >>
> >> I get the output
> >>
> >> x050
> >> Revision: 3190
> >> Thu Apr 14 13:23:57 BST 2011
> >>   read extra star_job inlist1 from inlist_first_thing_to_try
> >>   read extra controls inlist1 from inlist_first_thing_to_try
> >>   read restart_photo
> >> ./re: line 28: 29003 Segmentation fault      ./star
> >> Thu Apr 14 13:24:00 BST 2011
> >>
> >> I've explored the operating scripts a bit but I really can't see what the
> >> problem is. I've recompiled from scratch and checked things like disk
> >> space too, just to be sure.
> >>
> >> When I compile using ifort (11.1), everything works as expected.
> >>
> >> Not sure what other information is useful. I'm on RHEL 5.6, x86-64 arch
> >> (Intel Core 2).
> >>
> >> Cheers,
> >> Warrick
> >>
> >
> 
-- 

Re: [mesa-users] Segfaults when running from photo

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

Kent,

This is a fresh installation and I'm taking photos from the run I've done 
only moments before (so the same version). Even if I clear the photos/
directory to make sure a new photo is generated, I get the segfault.

W

On Thu, 14 Apr 2011, Kent Budge wrote:

> Warrick,
>
> The photo restarts aren't guaranteed to work across versions of MESA.
>> From the "How to Use MESA" web page:
>
> "Also, it should be emphasized that the photos are not intended for
> long-term storage of models—the ‘save_model_number’ scheme described
> above is meant for that purpose. Instead the photos are intended for use
> during one specific run. In particular, when you update to a new version
> of MESA star, you should expect your existing photo files to become
> obsolete. If you have a lengthy run in progress when you want to update
> MESA, then you should do ‘save_model_number’ to save state before
> starting the update, and then do ‘load_saved_model’ to resume the
> evolution after you have done the update."
>
>
> On Thu, 2011-04-14 at 14:11 +0100, Warrick Ball wrote:
>> Hi,
>>
>> I've just successfully installed MESA revision 3190. When I compile with
>> gfortran (GCC 4.5.2), it runs on all of the "first things to try", except
>> for restarting from a previous photo. After the first suggested run, if I
>> try
>>
>> ./re x050
>>
>> I get the output
>>
>> x050
>> Revision: 3190
>> Thu Apr 14 13:23:57 BST 2011
>>   read extra star_job inlist1 from inlist_first_thing_to_try
>>   read extra controls inlist1 from inlist_first_thing_to_try
>>   read restart_photo
>> ./re: line 28: 29003 Segmentation fault      ./star
>> Thu Apr 14 13:24:00 BST 2011
>>
>> I've explored the operating scripts a bit but I really can't see what the
>> problem is. I've recompiled from scratch and checked things like disk
>> space too, just to be sure.
>>
>> When I compile using ifort (11.1), everything works as expected.
>>
>> Not sure what other information is useful. I'm on RHEL 5.6, x86-64 arch
>> (Intel Core 2).
>>
>> Cheers,
>> Warrick
>>
>

-- 
Warrick Ball, PhD student
Institute of Astronomy, Cambridge UK
+44(0)1223 766653

Re: [mesa-users] Segfaults when running from photo

[Kent B. <kg...@la...>]

Warrick,

The photo restarts aren't guaranteed to work across versions of MESA.
>From the "How to Use MESA" web page:

"Also, it should be emphasized that the photos are not intended for
long-term storage of models—the ‘save_model_number’ scheme described
above is meant for that purpose. Instead the photos are intended for use
during one specific run. In particular, when you update to a new version
of MESA star, you should expect your existing photo files to become
obsolete. If you have a lengthy run in progress when you want to update
MESA, then you should do ‘save_model_number’ to save state before
starting the update, and then do ‘load_saved_model’ to resume the
evolution after you have done the update."


On Thu, 2011-04-14 at 14:11 +0100, Warrick Ball wrote:
> Hi,
> 
> I've just successfully installed MESA revision 3190. When I compile with 
> gfortran (GCC 4.5.2), it runs on all of the "first things to try", except 
> for restarting from a previous photo. After the first suggested run, if I 
> try
> 
> ./re x050
> 
> I get the output
> 
> x050
> Revision: 3190
> Thu Apr 14 13:23:57 BST 2011
>   read extra star_job inlist1 from inlist_first_thing_to_try
>   read extra controls inlist1 from inlist_first_thing_to_try
>   read restart_photo
> ./re: line 28: 29003 Segmentation fault      ./star
> Thu Apr 14 13:24:00 BST 2011
> 
> I've explored the operating scripts a bit but I really can't see what the 
> problem is. I've recompiled from scratch and checked things like disk 
> space too, just to be sure.
> 
> When I compile using ifort (11.1), everything works as expected.
> 
> Not sure what other information is useful. I'm on RHEL 5.6, x86-64 arch 
> (Intel Core 2).
> 
> Cheers,
> Warrick
> 
-- 

[mesa-users] Segfaults when running from photo

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

Hi,

I've just successfully installed MESA revision 3190. When I compile with 
gfortran (GCC 4.5.2), it runs on all of the "first things to try", except 
for restarting from a previous photo. After the first suggested run, if I 
try

./re x050

I get the output

x050
Revision: 3190
Thu Apr 14 13:23:57 BST 2011
  read extra star_job inlist1 from inlist_first_thing_to_try
  read extra controls inlist1 from inlist_first_thing_to_try
  read restart_photo
./re: line 28: 29003 Segmentation fault      ./star
Thu Apr 14 13:24:00 BST 2011

I've explored the operating scripts a bit but I really can't see what the 
problem is. I've recompiled from scratch and checked things like disk 
space too, just to be sure.

When I compile using ifort (11.1), everything works as expected.

Not sure what other information is useful. I'm on RHEL 5.6, x86-64 arch 
(Intel Core 2).

Cheers,
Warrick

-- 
Warrick Ball, PhD student
Institute of Astronomy, Cambridge UK
+44(0)1223 766653

[mesa-users] mesa release 3190

[Bill P. <pa...@ki...>]

3190 is now available with lots of small changes as listed below.

to reduce confusion, rename set_v_flag to change_v_flag and rename set_rotation_flag to change_rotation_flag
fix bug in star for irradiation; change name of control from "flux_for_hemisphere_irradiation" to "irradiation_flux"
add kap tables for Asplund, Grevesse, Sauval, and Scott (2009) with prefix "a09"
change net so that caches separate rate tables for each reaction
add const P option to net one_zone_burn
add optional source term to 1 zone burn in net
add support for multi-threaded sparse matrix solver SuperLU_MT to mtx
add SuperLU_MT tar file and README to utils
net 1 zone burn working with lapack, SuperLU_MT, and mkl_pardiso
drop support for sparskit from mtx
net can now access reactions from weaklib and reaclib
net definitions can have reactions automatically added from weaklib and reaclib
move jina reaclib file to net_data and delete jina_data from mesa/data
now can define new reaction by adding to reactions.list and providing a rate table
add cgrav vector and other_cgrav routine to star; change name to standard_cgrav in const
add atm_grey_irradiated_get based on Guillot, T, and Havel, M., A&A 527, A20 (2011). T(tau) equation 6.
add atm_grey_irradiated to star
add very_low_mass_grey_models to star_data
add special_rate_factor controls
add other_energy_implicit
pgstar abundances specify which isos to show
lots of additions to test_suite

cheers,
Bill

Re: [mesa-users] Time dependent Mass gain

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

Hi Fernando,

One way to accomplish this is to edit run_star_extras.f to include whatever
function of time you like.  I have done this for a few different mass loss
cases but it should work equally well for mass gain.

If you look at run_star_extras.f (see star/test/src/), you'll see it
includes 'standard_run_star_extras.dek' which lives in star/public/. What I
did was comment out the include line and then copy the entire contents of
the included file directly into run_star_extras.f.  You can then modify the
appropriate subroutine or function in run_star_extras.f and recompile star.

Specifically, I made use of the "other_wind" procedure pointer.  I edited
subroutine extras_control:

     subroutine extras_controls(s, ierr)
         type (star_info), pointer :: s
         integer, intent(out) :: ierr
         ierr = 0

         ! this is the place to set any procedure pointers you want to
change
         ! e.g., other_wind, other_mixing, other_energy  (see star_data.dek)

          s% other_wind => Schroder_Cuntz_wind

      end subroutine extras_controls

And then defined a new subroutine (also in run_star_extras.f) with the name
given above.  Bill provides a template for what the new subroutines should
look like in star/public/other_wind.f.

Aaron


On Wed, Apr 6, 2011 at 3:38 PM, Fernando Rivas <riv...@gm...>wrote:

> Hello,
>
> according to "star_defaults" the only mass gain option is "mass_change"
> which increases mass constantly through time. I'm looking for a way to vary
> mass increase with time so my question is which is the best option to
> accomplish this?
>
> Regards
> Fernando Rivas
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

[mesa-users] Time dependent Mass gain

[Fernando R. <riv...@gm...>]

Hello,

according to "star_defaults" the only mass gain option is "mass_change"
which increases mass constantly through time. I'm looking for a way to vary
mass increase with time so my question is which is the best option to
accomplish this?

Regards
Fernando Rivas

Re: [mesa-users] compiling pgplot on Snow Leopard - strncpy argument problem in grfileio, grtermio

[Steve K. <sd...@ia...>]

Hi Frank, Bill-

Thanks for your responses - I was able to solve this problem.  

Indeed, the warnings about strncpy were not fatal.  What was killing things was the 'ar ru' part of the makefile where the library libpgplot.a was being archived/ranlib-ed
More specifically, after running 'makemake . osx gfortran-gcc' I replaced the line 687 of the resulting makefile with
          libtool -s -o libpgplot.a \
and then all went well.  This tip came from the following website:
  http://iparrizar.mnstate.edu/~juan/urania/2009/10/23/pgplot-on-snow-leopard/

By the way, I'm currently using gfortran 4.5.2 and gcc 4.5.2, latest Xcode from SL 10.6.7 / Software Update.

Cheers,
Steve

On Mar 31, 2011, at 7:06 PM, Frank Timmes wrote:

> hi steve,
> 
> these are just warnings. it should be fine. 
> or are you saying these warnings stop the compilation or link?
> 
> what version of gcc and xcode are you using?
> 
> fxt
> 
> 
> 
> On Mar 31, 2011, at 4:04 PM, Steve Kawaler wrote:
> 
>> Hi all-
>> 
>> I've tried to find an answer on my own but am officially stumped.  I'm running mesa-star just fine on my MacPro, compiled with gfortran (4.5.2), and would like to implement the pgplot window displays.  The problem is when trying to compile pgplot (with the supplied source in the utils directory) the fortran routines all compile, but the some .c routines throw the error (i've removed the directory paths from the log to keep it simple):
>> 
>> gcc -c -DPG_PPU -O2 -I. sys/grfileio.c
>>   sys/grfileio.c: In function ‘grofil_’:
>>   sys/grfileio.c:82:5: warning: incompatible implicit declaration of built-in function ‘strncpy’
>> gcc -c -DPG_PPU -O2 -I. sys/grtermio.c
>>   sys/grtermio.c: In function ‘groter_’:
>>   sys/grtermio.c:39:5: warning: incompatible implicit declaration of built-in function ‘strncpy’
>> 
>> What am I missing?
>> 
>> Thanks,
>> Steve
>> 
>> Steven Kawaler
>> Physics and Astronomy
>> Iowa State University
>> ------------------------------------------------------------------------------
>> Create and publish websites with WebMatrix
>> Use the most popular FREE web apps or write code yourself; 
>> WebMatrix provides all the features you need to develop and 
>> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
>> _______________________________________________
>> mesa-users mailing list
>> mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
> 

Re: [mesa-users] compiling pgplot on Snow Leopard - strncpy argument problem in grfileio, grtermio

[Frank T. <fx...@ma...>]

i'm taking this thread offline. 
will return when solved.

fxt



On Mar 31, 2011, at 4:21 PM, Bill Paxton wrote:

> Hi Steve,
> 
> On Mar 31, 2011, at 4:12 PM, Steve Kawaler wrote:
> 
>> I am at 3107...
> 
> darn -- I was hoping for a simple cure.
> 
> I just ran the make on my mac and I got the same messages that you reported.
> so perhaps they don't matter [I'm running pgplot with star just fine.]
> 
> Frank's README suggests that after doing the make you run some tests:
> 
> test the build:
> 
> % ./pgdemo1
>  enter the following device driver when asked: /XWIN
> 
> % ./pgdemo1
>  enter the following device driver when asked: /PNG
> 
> 
> do those work for you?
> 
> -B
> 
> 
> 
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself; 
> WebMatrix provides all the features you need to develop and 
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

Re: [mesa-users] compiling pgplot on Snow Leopard - strncpy argument problem in grfileio, grtermio

[Bill P. <pa...@KI...>]

Hi Steve,

On Mar 31, 2011, at 4:12 PM, Steve Kawaler wrote:

> I am at 3107...

darn -- I was hoping for a simple cure.

I just ran the make on my mac and I got the same messages that you reported.
so perhaps they don't matter [I'm running pgplot with star just fine.]

Frank's README suggests that after doing the make you run some tests:

test the build:

% ./pgdemo1
  enter the following device driver when asked: /XWIN

% ./pgdemo1
  enter the following device driver when asked: /PNG


do those work for you?

-B

Re: [mesa-users] compiling pgplot on Snow Leopard - strncpy argument problem in grfileio, grtermio

[Bill P. <pa...@ki...>]

Hi Steve,

Which version of mesa are you using?    Frank Timmes has recently greatly simplified the pgplot installation for mesa, so if you are on an older version, it would be a good idea to try the current one (which is 3107).

If that isn't a fix, we'll need to see what Frank has to say.

Cheers,
Bill



On Mar 31, 2011, at 4:04 PM, Steve Kawaler wrote:

> Hi all-
> 
> I've tried to find an answer on my own but am officially stumped.  I'm running mesa-star just fine on my MacPro, compiled with gfortran (4.5.2), and would like to implement the pgplot window displays.  The problem is when trying to compile pgplot (with the supplied source in the utils directory) the fortran routines all compile, but the some .c routines throw the error (i've removed the directory paths from the log to keep it simple):
> 
>  gcc -c -DPG_PPU -O2 -I. sys/grfileio.c
>    sys/grfileio.c: In function ‘grofil_’:
>    sys/grfileio.c:82:5: warning: incompatible implicit declaration of built-in function ‘strncpy’
>  gcc -c -DPG_PPU -O2 -I. sys/grtermio.c
>    sys/grtermio.c: In function ‘groter_’:
>    sys/grtermio.c:39:5: warning: incompatible implicit declaration of built-in function ‘strncpy’
> 
> What am I missing?
> 
> Thanks,
> Steve
> 
> Steven Kawaler
> Physics and Astronomy
> Iowa State University
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself; 
> WebMatrix provides all the features you need to develop and 
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

[mesa-users] compiling pgplot on Snow Leopard - strncpy argument problem in grfileio, grtermio

[Steve K. <sd...@ia...>]

Hi all-

I've tried to find an answer on my own but am officially stumped.  I'm running mesa-star just fine on my MacPro, compiled with gfortran (4.5.2), and would like to implement the pgplot window displays.  The problem is when trying to compile pgplot (with the supplied source in the utils directory) the fortran routines all compile, but the some .c routines throw the error (i've removed the directory paths from the log to keep it simple):

  gcc -c -DPG_PPU -O2 -I. sys/grfileio.c
    sys/grfileio.c: In function ‘grofil_’:
    sys/grfileio.c:82:5: warning: incompatible implicit declaration of built-in function ‘strncpy’
  gcc -c -DPG_PPU -O2 -I. sys/grtermio.c
    sys/grtermio.c: In function ‘groter_’:
    sys/grtermio.c:39:5: warning: incompatible implicit declaration of built-in function ‘strncpy’

What am I missing?

Thanks,
Steve

Steven Kawaler
Physics and Astronomy
Iowa State University

Re: [mesa-users] very thin shell burning

[Frank T. <fx...@ma...>]

hi stan,

nice to see mesa being used in your grad class.

fxt


On Mar 30, 2011, at 8:44 AM, Stan Woosley wrote:

> Kent, Falk, et al.,
> 
> I am on this list because I am attempting to use Mesa in my
> graduate class, but I have worried a lot about these same issues
> and am currently writing a paper on Pop III pulsational pair SN in the
> 80 - 150 Msun range. I use the Kepler code for this.
> 
> Falk is right about the dredge up of carbon in these massive low
> Z stars. It is almost explosive once the first contact is made and the
> radius of the star goes  above 2 x 10**14 cm. It hangs by a thread
> and my guess is the envelope gets lost - somehow.  BUT
> 
> The carbon is converted to nitrogen in the envelope and C << O
> so it is not clear that grains will form AND
> 
> If the He core is uncovered one switches to a different sort
> of mass loss, which Vink has said (for WR stars) depends on the Fe  
> abundance,
> not the CO abundance. So it could be small.
> 
> Also, in most cases this very violent mixing only occurs when
> rotational mixing is included and the extent is very sensitive to
> an unknown convective undershoot parameter.
> 
> Another issue here is that the usual opacity tables don't work
> when you have large CNO mass fractions and no Fe.
> 
> Another is that the mass loss propto sqrt(Z) is generally for stars that
> have Fe and again, these have none.
> 
> Best wishes,
> 
>    Stan Woosley
> 
> 
> 
> On Mar 30, 2011, at 6:56 AM, Kent Budge wrote:
> 
>> This is exactly the kind of thing that has piqued my interest. It  
>> looks
>> like it might be a fruitful topic for research for me.
>> 
>> On Tue, 2011-03-29 at 23:25 -0700, Falk Herwig wrote:
>>> On 8-Mar-11, at 9:55 AM, Kent Budge wrote:
>>> 
>>>> So I'm running some Population III calculations at the lower end of
>>>> the
>>>> mass range, and the very thin shell burning on the giant branch is
>>>> taking *forever*.
>>>> 
>>>> What's the latest thinking about mass loss in Population III? I know
>>>> it's thought to be rather low, but just how rather low?
>>> 
>>> I think that really depends on the type of stars. There is common
>>> scaling out there in which Mdot ~ sqrt(Z) but that applies only to
>>> mass loss processes that are driven by radiation pressure on lines,
>>> and if there is no self-enrichment of the surface. For AGB stars both
>>> assumptions are wrong, since AGB stars will bring lots of C, O and
>>> other metals to the surface. I am not an expert on dust formation,  
>>> but
>>> I think it is not clear that in particular in the C-rich phase for
>>> advance AGB stars, even at Pop III you could not have effective dust
>>> formation, which would activate the characteristic dust-driven wind
>>> mechanism of AGB stars. Observations seem to indicate at least that  
>>> in
>>> the MCs Mdot is not smaller than in the Galaxy.
>>> 
>>>> 
>>>> What is the state of the art in modeling very thin shell burning?
>>>> Brute
>>>> force seems, well, like brute force. Are there methods out there  
>>>> that
>>>> treat it as a front propagation problem?
>>>> 
>>> 
>>> In Pop III AGB stars or even very low metallicity AGb stars you will
>>> encounter convective-overshoot induced H-flame propagation into the
>>> core when the convective envelope gets in touch with the hot CO core.
>>> This is not the regular H-shell in AGB stars, but rather a hot  
>>> dregde-
>>> up after thermal pulses. That is a situation where a flame model  
>>> would
>>> be needed, but I believe we have not much right now to base this on.
>>> Note that this is a flame across a fuel-mix boundary.
>>> 
>>> BEst, Falk.
>>> 
>>>> Interested in any information anyone has.
>>>> 
>>>> -- Kent G. Budge
>>>> CCS-2, LANL
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> What You Don't Know About Data Connectivity CAN Hurt You
>>>> This paper provides an overview of data connectivity, details
>>>> its effect on application quality, and explores various alternative
>>>> solutions. http://p.sf.net/sfu/progress-d2d
>>>> _______________________________________________
>>>> mesa-users mailing list
>>>> mes...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>> 
>>> --
>>> Falk Herwig
>>> Dept of Physics & Astronomy, U of Victoria
>>> fh...@uv..., tel: +1 (250) 721-7743
>>> 
>>> 
>>> 
>> -- 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Enable your software for Intel(R) Active Management Technology to  
>> meet the
>> growing manageability and security demands of your customers.  
>> Businesses
>> are taking advantage of Intel(R) vPro (TM) technology - will your  
>> software
>> be a part of the solution? Download the Intel(R) Manageability Checker
>> today! http://p.sf.net/sfu/intel-dev2devmar
>> _______________________________________________
>> mesa-users mailing list
>> mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>> 
>> !DSPAM:212,4d93368d111132383122390!
>> 
> 
> 
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself; 
> WebMatrix provides all the features you need to develop and 
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

Re: [mesa-users] very thin shell burning

[Falk H. <fh...@uv...>]

Hi Stan, Kent:
>
> On Wed, 2011-03-30 at 08:44 -0700, Stan Woosley wrote:
>> Kent, Falk, et al.,
>>

>>
>> The carbon is converted to nitrogen in the envelope and C << O
>> so it is not clear that grains will form AND

I have no feeling for massive star models in this situation, but for  
the intermediate mass stars, e.g. M_ini=5Msun it is not clear that  
this hot dredge-up or corrosive convection induced H-flame burning  
automatically leads to C<<O. The plot below (Herwig,2004, ApJ 605,  
425) shows the surface abundance evolution of C, N and O during such a  
H-flame burn after a thermal pulse when the envelope convection is  
making contact with the CO-core:

Re: [mesa-users] very thin shell burning

[Kent B. <kg...@la...>]

Herwig, Stan,

Yes, I work with Chris Fryer from time to time. I haven't done serious
astronomy in a long time (I've focused my career on time-dependent
thermal radiation transport for about 20 years) but would really like to
get back in the game.

I rolled my own star code a year or two ago, rolled my own Pop3
opacities for it, and found that the convective helium-burning core
expanded into the hydrogen-burning shell with spectacular consequences.
Apparently it's not just my code. Chris pointed me at Mesa last fall and
I pretty much abandoned my own code. (Reinventing the wheel is a
worthwhile learning exercise only to a point, and I'd reached it.) I've
put together a C++ interface for Mesa since (mostly as a learning
exercise for me, partly as an exercise in breaking down programming
language barriers generally) and have been having great fun -- but am
still looking for a viable research angle.

FWIW.

--KGB

On Wed, 2011-03-30 at 08:44 -0700, Stan Woosley wrote:
> Kent, Falk, et al.,
> 
> I am on this list because I am attempting to use Mesa in my
> graduate class, but I have worried a lot about these same issues
> and am currently writing a paper on Pop III pulsational pair SN in the
> 80 - 150 Msun range. I use the Kepler code for this.
> 
> Falk is right about the dredge up of carbon in these massive low
> Z stars. It is almost explosive once the first contact is made and the
> radius of the star goes  above 2 x 10**14 cm. It hangs by a thread
> and my guess is the envelope gets lost - somehow.  BUT
> 
> The carbon is converted to nitrogen in the envelope and C << O
> so it is not clear that grains will form AND
> 
> If the He core is uncovered one switches to a different sort
> of mass loss, which Vink has said (for WR stars) depends on the Fe  
> abundance,
> not the CO abundance. So it could be small.
> 
> Also, in most cases this very violent mixing only occurs when
> rotational mixing is included and the extent is very sensitive to
> an unknown convective undershoot parameter.
> 
> Another issue here is that the usual opacity tables don't work
> when you have large CNO mass fractions and no Fe.
> 
> Another is that the mass loss propto sqrt(Z) is generally for stars that
> have Fe and again, these have none.
> 
> Best wishes,
> 
>     Stan Woosley
> 
> 
> 
> On Mar 30, 2011, at 6:56 AM, Kent Budge wrote:
> 
> > This is exactly the kind of thing that has piqued my interest. It  
> > looks
> > like it might be a fruitful topic for research for me.
> >
> > On Tue, 2011-03-29 at 23:25 -0700, Falk Herwig wrote:
> >> On 8-Mar-11, at 9:55 AM, Kent Budge wrote:
> >>
> >>> So I'm running some Population III calculations at the lower end of
> >>> the
> >>> mass range, and the very thin shell burning on the giant branch is
> >>> taking *forever*.
> >>>
> >>> What's the latest thinking about mass loss in Population III? I know
> >>> it's thought to be rather low, but just how rather low?
> >>
> >> I think that really depends on the type of stars. There is common
> >> scaling out there in which Mdot ~ sqrt(Z) but that applies only to
> >> mass loss processes that are driven by radiation pressure on lines,
> >> and if there is no self-enrichment of the surface. For AGB stars both
> >> assumptions are wrong, since AGB stars will bring lots of C, O and
> >> other metals to the surface. I am not an expert on dust formation,  
> >> but
> >> I think it is not clear that in particular in the C-rich phase for
> >> advance AGB stars, even at Pop III you could not have effective dust
> >> formation, which would activate the characteristic dust-driven wind
> >> mechanism of AGB stars. Observations seem to indicate at least that  
> >> in
> >> the MCs Mdot is not smaller than in the Galaxy.
> >>
> >>>
> >>> What is the state of the art in modeling very thin shell burning?
> >>> Brute
> >>> force seems, well, like brute force. Are there methods out there  
> >>> that
> >>> treat it as a front propagation problem?
> >>>
> >>
> >> In Pop III AGB stars or even very low metallicity AGb stars you will
> >> encounter convective-overshoot induced H-flame propagation into the
> >> core when the convective envelope gets in touch with the hot CO core.
> >> This is not the regular H-shell in AGB stars, but rather a hot  
> >> dregde-
> >> up after thermal pulses. That is a situation where a flame model  
> >> would
> >> be needed, but I believe we have not much right now to base this on.
> >> Note that this is a flame across a fuel-mix boundary.
> >>
> >> BEst, Falk.
> >>
> >>> Interested in any information anyone has.
> >>>
> >>> -- Kent G. Budge
> >>> CCS-2, LANL
> >>>
> >>>
> >>> ------------------------------------------------------------------------------
> >>> What You Don't Know About Data Connectivity CAN Hurt You
> >>> This paper provides an overview of data connectivity, details
> >>> its effect on application quality, and explores various alternative
> >>> solutions. http://p.sf.net/sfu/progress-d2d
> >>> _______________________________________________
> >>> mesa-users mailing list
> >>> mes...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/mesa-users
> >>
> >> --
> >> Falk Herwig
> >> Dept of Physics & Astronomy, U of Victoria
> >> fh...@uv..., tel: +1 (250) 721-7743
> >>
> >>
> >>
> > -- 
> >
> >
> > ------------------------------------------------------------------------------
> > Enable your software for Intel(R) Active Management Technology to  
> > meet the
> > growing manageability and security demands of your customers.  
> > Businesses
> > are taking advantage of Intel(R) vPro (TM) technology - will your  
> > software
> > be a part of the solution? Download the Intel(R) Manageability Checker
> > today! http://p.sf.net/sfu/intel-dev2devmar
> > _______________________________________________
> > mesa-users mailing list
> > mes...@li...
> > https://lists.sourceforge.net/lists/listinfo/mesa-users
> >
> > !DSPAM:212,4d93368d111132383122390!
> >
> 
-- 

Re: [mesa-users] very thin shell burning

[Stan W. <wo...@uc...>]

Kent, Falk, et al.,

I am on this list because I am attempting to use Mesa in my
graduate class, but I have worried a lot about these same issues
and am currently writing a paper on Pop III pulsational pair SN in the
80 - 150 Msun range. I use the Kepler code for this.

Falk is right about the dredge up of carbon in these massive low
Z stars. It is almost explosive once the first contact is made and the
radius of the star goes  above 2 x 10**14 cm. It hangs by a thread
and my guess is the envelope gets lost - somehow.  BUT

The carbon is converted to nitrogen in the envelope and C << O
so it is not clear that grains will form AND

If the He core is uncovered one switches to a different sort
of mass loss, which Vink has said (for WR stars) depends on the Fe  
abundance,
not the CO abundance. So it could be small.

Also, in most cases this very violent mixing only occurs when
rotational mixing is included and the extent is very sensitive to
an unknown convective undershoot parameter.

Another issue here is that the usual opacity tables don't work
when you have large CNO mass fractions and no Fe.

Another is that the mass loss propto sqrt(Z) is generally for stars that
have Fe and again, these have none.

Best wishes,

    Stan Woosley



On Mar 30, 2011, at 6:56 AM, Kent Budge wrote:

> This is exactly the kind of thing that has piqued my interest. It  
> looks
> like it might be a fruitful topic for research for me.
>
> On Tue, 2011-03-29 at 23:25 -0700, Falk Herwig wrote:
>> On 8-Mar-11, at 9:55 AM, Kent Budge wrote:
>>
>>> So I'm running some Population III calculations at the lower end of
>>> the
>>> mass range, and the very thin shell burning on the giant branch is
>>> taking *forever*.
>>>
>>> What's the latest thinking about mass loss in Population III? I know
>>> it's thought to be rather low, but just how rather low?
>>
>> I think that really depends on the type of stars. There is common
>> scaling out there in which Mdot ~ sqrt(Z) but that applies only to
>> mass loss processes that are driven by radiation pressure on lines,
>> and if there is no self-enrichment of the surface. For AGB stars both
>> assumptions are wrong, since AGB stars will bring lots of C, O and
>> other metals to the surface. I am not an expert on dust formation,  
>> but
>> I think it is not clear that in particular in the C-rich phase for
>> advance AGB stars, even at Pop III you could not have effective dust
>> formation, which would activate the characteristic dust-driven wind
>> mechanism of AGB stars. Observations seem to indicate at least that  
>> in
>> the MCs Mdot is not smaller than in the Galaxy.
>>
>>>
>>> What is the state of the art in modeling very thin shell burning?
>>> Brute
>>> force seems, well, like brute force. Are there methods out there  
>>> that
>>> treat it as a front propagation problem?
>>>
>>
>> In Pop III AGB stars or even very low metallicity AGb stars you will
>> encounter convective-overshoot induced H-flame propagation into the
>> core when the convective envelope gets in touch with the hot CO core.
>> This is not the regular H-shell in AGB stars, but rather a hot  
>> dregde-
>> up after thermal pulses. That is a situation where a flame model  
>> would
>> be needed, but I believe we have not much right now to base this on.
>> Note that this is a flame across a fuel-mix boundary.
>>
>> BEst, Falk.
>>
>>> Interested in any information anyone has.
>>>
>>> -- Kent G. Budge
>>> CCS-2, LANL
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> What You Don't Know About Data Connectivity CAN Hurt You
>>> This paper provides an overview of data connectivity, details
>>> its effect on application quality, and explores various alternative
>>> solutions. http://p.sf.net/sfu/progress-d2d
>>> _______________________________________________
>>> mesa-users mailing list
>>> mes...@li...
>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>> --
>> Falk Herwig
>> Dept of Physics & Astronomy, U of Victoria
>> fh...@uv..., tel: +1 (250) 721-7743
>>
>>
>>
> -- 
>
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to  
> meet the
> growing manageability and security demands of your customers.  
> Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your  
> software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
> !DSPAM:212,4d93368d111132383122390!
>

Re: [mesa-users] very thin shell burning

[Kent B. <kg...@la...>]

This is exactly the kind of thing that has piqued my interest. It looks
like it might be a fruitful topic for research for me.

On Tue, 2011-03-29 at 23:25 -0700, Falk Herwig wrote:
> On 8-Mar-11, at 9:55 AM, Kent Budge wrote:
> 
> > So I'm running some Population III calculations at the lower end of  
> > the
> > mass range, and the very thin shell burning on the giant branch is
> > taking *forever*.
> >
> > What's the latest thinking about mass loss in Population III? I know
> > it's thought to be rather low, but just how rather low?
> 
> I think that really depends on the type of stars. There is common  
> scaling out there in which Mdot ~ sqrt(Z) but that applies only to  
> mass loss processes that are driven by radiation pressure on lines,  
> and if there is no self-enrichment of the surface. For AGB stars both  
> assumptions are wrong, since AGB stars will bring lots of C, O and  
> other metals to the surface. I am not an expert on dust formation, but  
> I think it is not clear that in particular in the C-rich phase for  
> advance AGB stars, even at Pop III you could not have effective dust  
> formation, which would activate the characteristic dust-driven wind  
> mechanism of AGB stars. Observations seem to indicate at least that in  
> the MCs Mdot is not smaller than in the Galaxy.
> 
> >
> > What is the state of the art in modeling very thin shell burning?  
> > Brute
> > force seems, well, like brute force. Are there methods out there that
> > treat it as a front propagation problem?
> >
> 
> In Pop III AGB stars or even very low metallicity AGb stars you will  
> encounter convective-overshoot induced H-flame propagation into the  
> core when the convective envelope gets in touch with the hot CO core.  
> This is not the regular H-shell in AGB stars, but rather a hot dregde- 
> up after thermal pulses. That is a situation where a flame model would  
> be needed, but I believe we have not much right now to base this on.  
> Note that this is a flame across a fuel-mix boundary.
> 
> BEst, Falk.
> 
> > Interested in any information anyone has.
> >
> > -- Kent G. Budge
> > CCS-2, LANL
> >
> >
> > ------------------------------------------------------------------------------
> > What You Don't Know About Data Connectivity CAN Hurt You
> > This paper provides an overview of data connectivity, details
> > its effect on application quality, and explores various alternative
> > solutions. http://p.sf.net/sfu/progress-d2d
> > _______________________________________________
> > mesa-users mailing list
> > mes...@li...
> > https://lists.sourceforge.net/lists/listinfo/mesa-users
> 
> --
> Falk Herwig
> Dept of Physics & Astronomy, U of Victoria
> fh...@uv..., tel: +1 (250) 721-7743
> 
> 
> 
--