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

Re: [mesa-users] diffusion test failed during compilation

[ztt <ztt...@12...>]

Hi,

When I try to see the test suite in star, I encounter this error:
ztt@ztt-laptop:~/mesa/star/test_suite/very_low_mass$ ./mk
gfortran -fno-range-check  -fopenmp -fbounds-check -g -I../../../../include  -c -ffree-form ../src/run_star_extras.f
../src/run_star_extras.f:25.18:

      use star_lib
                  1
Fatal Error: Can't open module file 'star_lib.mod' for reading at (1): No such file or directory
make: *** [run_star_extras.o] Error 1

FAILED
I don't know if this has something to do with the error in compilation before. There is indeed no 'star_lib.mod' file in mesa/star/public. Maybe it's because compilation failed so some related part not initiated ??

Many thanks,

Tingtao

[mesa-users] diffusion test failed during compilation

[ztt <ztt...@12...>]

Dear Mesa users,

I was doing '.\mk' in the mesa directory and below is the information from compilation:


mesa/ionization has been made, tested, and exported.

************************************************

/home/ztt/mesa/diffusion
building diffusion package.

make: `libdiffusion.a' is up to date.
make: `libdiffusion.a' is up to date.
gfortran -fopenmp -o ../tester test_diff_vels.o test_diff_eos.o test_diffusion.o -L../../make -ldiffusion -L../../../lib -lionization -leos -lkap -lweak -lnet -lscreen -lrates -lreaclib -lneu -lchem -linterp_2d -linterp_1d -lnum -lutils -lalert -lconst -lmtx    -lmesalapack -lmesablas

34c34
<                c_h      dX X_final v vgt         597    0.0000000000000000E+00    4.0717484546752951E-34    0.0000000000000000E+00    0.0000000000000000E+0
0
--- field 7	relative error 1.00e+00
>                c_h      dX X_final v vgt         597    8.5528470722950261E-50    4.0717484546752959E-34    0.0000000000000000E+00    0.0000000000000000E+0
0
35c35
<                c_he     dX X_final v vgt         597    0.0000000000000000E+00    9.8013262241242971E-01    0.0000000000000000E+00    0.0000000000000000E+0
0
--- field 7	relative error 1.00e+00
>                c_he     dX X_final v vgt         597    1.1102230246251565E-16    9.8013262241242971E-01    0.0000000000000000E+00    0.0000000000000000E+0
0
36c36
<                c_o      dX X_final v vgt         597    0.0000000000000000E+00    1.4494112994371195E-02    0.0000000000000000E+00    0.0000000000000000E+0
0
--- field 7	relative error 1.00e+00
>                c_o      dX X_final v vgt         597    1.7347234759768071E-18    1.4494112994371195E-02    0.0000000000000000E+00    0.0000000000000000E+0
0
37c37
<                c_fe     dX X_final v vgt         597    0.0000000000000000E+00    5.3732645931991114E-03    0.0000000000000000E+00    0.0000000000000000E+0
0
--- field 7	relative error 1.00e+00
>                c_fe     dX X_final v vgt         597    8.6736173798840355E-19    5.3732645931991122E-03    0.0000000000000000E+00    0.0000000000000000E+0
0

/home/ztt/mesa/diffusion/test
TEST FAILED -- compare test_output to tmp.txt

Is it a bug of the code or something I missed?? Thank you very much.

Zhou Tingtao

Re: [mesa-users] retry

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

Hi Jing,

The problem with your implementation is that the routine run1_star, which
run_star.f calls, only checks to see if return = keep_going after
extras_finish_step.  If not, it exits the evolve loop and the run ends.

If you want to force a retry, you ought to use extras_check_model instead of
extras_finish_step.  The former is able to force a retry.  You can see how
all of this is implemented if you read the source code in
mesa/star/public/run_star_support.f, look for evolve_loop in run1_star.

Aaron



On Fri, Jul 1, 2011 at 8:13 PM, Jing Luan <jin...@ca...> wrote:

> Hello :-)
>
> I force mesa to do a retry at some model but after retrying that model
> mesa stops without any report;
>
> Here is the content added to my extras_finish_step in run_star_extras.f, I
> just set extras_finish_step to be retry when kn is even, and set
> extras_finish_step to be keep_going when kn is odd, where kn is a save
> integer and increases by 1 every time extras_finish_step is called:
>
> integer, save :: kn
>
>         write (*,*) 'call extras_finish_step'
>         if (s% model_number == 3582) kn=0 ! model 3582 is the first model
> because I start the run with model 3581
>
>         if (mod(kn,2)==0) then
>           write (*,*) 'retry,kn',kn
>           kn=kn+1
>           extras_finish_step = retry
>         else
>           write (*,*) 'keep_going,kn',kn
>           kn=kn+1
>           extras_finish_step = keep_going
>         end if
>
>
> I tell mesa to print out 'call extras_finish_step' if extras_finish_step
> is executed. I find that extras_finish_step is executed after the first
> model with model number=3582, but NOT executed after the second model with
> model number=3582; That is to say mesa terminates after the retried model
> 3582 is calculated and before extras_finish_step is called.
>
> Because mesa does not report any information when it terminates, I really
> have no idea where to trace the problem. Any help or suggestion is
> appreciated!
>
> Thank you very much :-)
>
> Sincerely,
> Jing
>
>
>
>   Hi,
>>
>>  Mesa/star doesn't retrain complete information about previous states,
>>  so you should save what you need yourself in your run_star_extras.
>>
>>  Good luck,
>>  Bill
>>
>>
>>
>>
>>  On Jun 30, 2011, at 9:17 PM, jin...@ca... wrote:
>>
>>   Dear Bill,
>>>
>>>  May I ask a question about the pointer s in mesa? Because I am not
>>>  familiar with pointer in fortran and failed to find direct-relevant
>>>  example by google. Thank you very much :-)
>>>
>>>  For example, the current model is model2, the information contained in
>>>  its
>>>  s is different with the previous s in model1. After model2 is
>>>  calculated,
>>>  mesa goes on to extras_finish_step. In this extras_finish_step, is there
>>>  some way to use the information in the previous s in model1?
>>>
>>>  I define s_old like this : type(star_info), pointer, save :: s_old
>>>  and then set: s_old=s in model1's extras_finish_step.But mesa reports
>>>  segmentation err. I think it should be because s and s_old are both
>>>  pointers, but did not yet find the right way to refer the previous s.
>>>
>>>  I need to do it because I need some kind of mid-point integration, where
>>>  the mid-point is some linear combination of s and s_old.
>>>
>>>  Thank you very much :-)
>>>
>>>  Sincerely,
>>>  Jing
>>>
>>>
>>
>>
>
>

[mesa-users] Fwd: retry

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

Hello :-)

I force mesa to do a retry at some model but after retrying that model
mesa stops without any report;

Here is the content added to my extras_finish_step in run_star_extras.f, I
just set extras_finish_step to be retry when kn is even, and set
extras_finish_step to be keep_going when kn is odd, where kn is a save
integer and increases by 1 every time extras_finish_step is called:

integer, save :: kn

          write (*,*) 'call extras_finish_step'
          if (s% model_number == 3582) kn=0 ! model 3582 is the first model
because I start the run with model 3581

          if (mod(kn,2)==0) then
            write (*,*) 'retry,kn',kn
            kn=kn+1
            extras_finish_step = retry
          else
            write (*,*) 'keep_going,kn',kn
            kn=kn+1
	   extras_finish_step = keep_going
          end if


I tell mesa to print out 'call extras_finish_step' if extras_finish_step
is executed. I find that extras_finish_step is executed after the first
model with model number=3582, but NOT executed after the second model with
model number=3582; That is to say mesa terminates after the retried model
3582 is calculated and before extras_finish_step is called.

Because mesa does not report any information when it terminates, I really
have no idea where to trace the problem. Any help or suggestion is
appreciated!

Thank you very much :-)

Sincerely,
Jing



>  Hi,
>
>  Mesa/star doesn't retrain complete information about previous states,
>  so you should save what you need yourself in your run_star_extras.
>
>  Good luck,
>  Bill
>
>
>
>
>  On Jun 30, 2011, at 9:17 PM, jin...@ca... wrote:
>
>>  Dear Bill,
>>
>>  May I ask a question about the pointer s in mesa? Because I am not
>>  familiar with pointer in fortran and failed to find direct-relevant
>>  example by google. Thank you very much :-)
>>
>>  For example, the current model is model2, the information contained in
>>  its
>>  s is different with the previous s in model1. After model2 is
>>  calculated,
>>  mesa goes on to extras_finish_step. In this extras_finish_step, is there
>>  some way to use the information in the previous s in model1?
>>
>>  I define s_old like this : type(star_info), pointer, save :: s_old
>>  and then set: s_old=s in model1's extras_finish_step.But mesa reports
>>  segmentation err. I think it should be because s and s_old are both
>>  pointers, but did not yet find the right way to refer the previous s.
>>
>>  I need to do it because I need some kind of mid-point integration, where
>>  the mid-point is some linear combination of s and s_old.
>>
>>  Thank you very much :-)
>>
>>  Sincerely,
>>  Jing
>>
>
>

[mesa-users] test for diffusion module failed

[ztt <ztt...@12...>]

Dear Mesa users,
 
I'm a new comer to mesa. When I tried to compile mesa(I did 'make' in mesa directory), other part went well, but it terminated after a line complaining the diffusion test failed. Would this affect the performance of other part of code? How to solve this problem?
Thank you very much!
 
 

Re: [mesa-users] White Dwarf Mass Gain

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

Hi Eric,

To get you started, try running star/test_suite/wd_ignite with this slightly edited inlist (it turns on PGstar so you can watch it).

Re: [mesa-users] White Dwarf Mass Gain

[Pierre L. <pie...@lr...>]

  Dear Eric,

  I would start by accreting C and O on a pure C/O white dwarf. This to 
avoid any complications at the surface. Even then you will probably get 
trouble evolving the growing convective core as the C burning luminosity 
increases. But I have not yet tried it myself with Mesa... so
  good luck !

Pierre.

On Wed, 29 Jun 
2011, Eric Blaney wrote:

> Dear Mesa-Users,
> 
> I have recently been attempting to use MESA to model accreted mass onto a White 
> Dwarf until it reaches it's chandresekar mass limit.  I'm simply wondering if it 
> is even possible, or if anyone has done this before using MESA and would share 
> any tips on how to successfully do so. 
> 
> 
> When I add mass onto White Dwarfs, it seems that that star becomes unstable once 
> hydrogen burning begins--reducing the timestep to mere minutes and the mass gain 
> rate jumps back and forth from, my normal input value, 10^-8 SolarMass/yr and 
> 10^-99.  If anyone has any idea how to fix these problems, if there even is a 
> solution, it would be greatly appreciated.
> 
> Much thanks,
> 
> Eric
> 

[mesa-users] White Dwarf Mass Gain

[Eric B. <eri...@ya...>]

Dear Mesa-Users,

I have recently been attempting to use MESA to model accreted mass onto a White 
Dwarf until it reaches it's chandresekar mass limit.  I'm simply wondering if it 
is even possible, or if anyone has done this before using MESA and would share 
any tips on how to successfully do so. 


When I add mass onto White Dwarfs, it seems that that star becomes unstable once 
hydrogen burning begins--reducing the timestep to mere minutes and the mass gain 
rate jumps back and forth from, my normal input value, 10^-8 SolarMass/yr and 
10^-99.  If anyone has any idea how to fix these problems, if there even is a 
solution, it would be greatly appreciated.

Much thanks,

Eric

[mesa-users] A compilation Error

[Ehsan M. <mor...@ia...>]

Dear Bill.<br />Hello.<br />I finally managed to install ifort 2011
edition on the old machine that have borrowed.<br /><br />MESA
installation proceeds until this point:<br />write
../../data/eosDT_data/cache/mesa-eosDT_02z80x.bin<br />&nbsp;write
../../data/eosDT_data/cache/mesa-eosDT_04z00x.bin<br />&nbsp;write
../../data/eosDT_data/cache/mesa-eosDT_04z20x.bin<br />&nbsp;write
../../data/eosDT_data/cache/mesa-eosDT_04z40x.bin<br />&nbsp;write
../../data/eosDT_data/cache/mesa-eosDT_04z60x.bin<br
/>../utils/build_and_test: line 33:&nbsp; 6947
Killed&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
./test_quietly<br /><br />/home/emoravveji/mesa/eos/test<br />FAILED<br
/><br />where is my problem?<br />With kind regards.<br />Ehsan.

[mesa-users] MESA Summer School 2012

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

Dear MESA community,

We are planning to have a MESA Summer School in Santa Barbara in Summer
2012 aimed at educating users at the level of graduate student and above.
 We are aiming to identify resources for the local housing of the
participants, but not travel or food.

We are working to set the preliminary scope and scale, so we want to gauge
the level of interest at this time.  Filling out the following survey would
be very useful to us; it has only three items and won't take long.

http://www.surveymonkey.com/s/6CWCM83

Please address any additional questions or comments to Frank Timmes.

Aaron

Re: [mesa-users] mac(+gfortran?) performance issues

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

hi aaron,

in general, for production work (mesa or otherwise) i use spotlight disabled disks
and i disable hyperthreading on those machines that allow it.

fxt



On Jun 26, 2011, at 8:44 AM, Aaron Dotter wrote:

> Hi,
> 
> I've recently gotten access to some Apple Xserves running OS X 10.6.5.  They have gfortran 4.5.2 but no ifort, and getting the latter is not an option.
> 
> When I run mesa star with OMP_NUM_THREADS=4, I get performance that varies between 100% and 150% of 1 CPU, whereas I would expect it to be above 300% most of the time (I/O is not the cause).  top tells me that Spotlight (mdworker and mds) are running pretty heavily in the background.
> 
> I'm wondering 
> (a) Have other Mac users run into performance issues with mesa star because of Spotlight and disabled it for that reason?
> (b) Any other performance issues that people might have encountered with this setup?
> 
> Thanks,
> Aaron
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2_______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

[mesa-users] mac(+gfortran?) performance issues

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

Hi,

I've recently gotten access to some Apple Xserves running OS X 10.6.5.  They
have gfortran 4.5.2 but no ifort, and getting the latter is not an option.

When I run mesa star with OMP_NUM_THREADS=4, I get performance that varies
between 100% and 150% of 1 CPU, whereas I would expect it to be above 300%
most of the time (I/O is not the cause).  top tells me that Spotlight
(mdworker and mds) are running pretty heavily in the background.

I'm wondering
(a) Have other Mac users run into performance issues with mesa star because
of Spotlight and disabled it for that reason?
(b) Any other performance issues that people might have encountered with
this setup?

Thanks,
Aaron

Re: [mesa-users] Iron

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

Hi Jeremy,

The way to track a given isotope is to add it to your nuclear reaction
network.  In data/net_data/nets/ there are quite a few pre-defined nets as
well as a README file with some information.  You can also create your own
by adding isotopes to an existing net.  See the current nets and read
data/net_data/NET_NOTES for how to add isotopes to a network.

Aaron


On Thu, Jun 23, 2011 at 9:22 AM, Jeremy Sakstein <
j.a...@da...> wrote:

> Hello Everyone,
>
> Does anyone know how I can get MESA to track Iron so that I can follow its
> evolution? That stuff in the manual about JINA doesn't seem to work?
>
> Cheers,
>
> Jeremy
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>

Re: [mesa-users] Failure in installation in rev.3372

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

Hi Naveen,

This is an issue that we sometimes encounter with gfortran.  The ndiff
utility is looking for numerical differences between the expected result in
test_output and the actual result you get in tmp.txt.  The issue is that
sometimes gfortran reports very small numbers (e.g., 1E-50) where ifort
produces zeros.

This is something we've known that we need to account for in the way we
check test results, but haven't yet done anything about it.  I would
consider that your install of mesa passed this test based on the output
you've provided.  If you're confident you've passed the test, you can
override the test result:

cd diffusion/test
./tester > test_output
cd ../..
./install

Let us know if you continue to have problems.

Aaron



On Thu, Jun 23, 2011 at 9:53 AM, naveen yadav <
nav...@ya...> wrote:

> Hi
> There is a failure in installing mesa rev. 3372. I had been using the older
> version in the same machine.
> The updated version is not working. Seems to me like an error in some
> internal data in mesa, as
> there is a considerable mismatch between the outputs.
>
> I am attaching an output file of installation process.
>
> Its an intel I3 with gfortran 4.6.0 and openMPI
>
> Regards
> naveen
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

[mesa-users] Iron

[Jeremy S. <j.a...@da...>]

Hello Everyone,

Does anyone know how I can get MESA to track Iron so that I can follow its 
evolution? That stuff in the manual about JINA doesn't seem to work?

Cheers,

Jeremy

Re: [mesa-users] about the tolerance of the code

[Jeremy S. <j.a...@da...>]

Hi Maurice,

I also use MESA for modified gravity and I also hit this problem a while 
back. Are you trying to interpolate from a ZAMS model? In this case the 
Newton iterator tries to find a new solution to the equations based on the 
old ones except that gravity has changed so much that it tries to use 
smaller and smaller time steps in order to converge, in this case it takes 
to long and gives up.

My solution to this problem is the following, take your parameter that you 
are changing (in my case it was something related to the gravity) and write 
it as G = G_0+delta_G where G_0 is its original value and delta_G is the 
change due to your new scenario. Now add some time dependence so that G = 
G_0 + delta_G*(1-Exp(-t/t0)) so that at early times the parameter is 
unchanged and at late times you get your complete modification. You now 
just need to play around with t_0 so that the code interpolates properly 
and you avoid the convergence issues but at the same time the true value of 
your parameter is reached fast enough that it doesn't effect the results.

Hope this helps,

Jeremy

On Jun 23 2011, Leung Shing Chi wrote:

>Dear all,
>
>I am trying to modify the code in order to couple the effect of external 
>gravity to the structure of the star. But the effect seems to be too large 
>that the code reports with:
>
><<
>...
>first model is slow to converge: num tries         270
>stopping because of convergence problems
>terminated evolution: convergence problems
>>>
>
> I have tried to relaxed the tolerance (as suggested by the webpage of 
> MESA) so as to make the calculation easier and to see some primitive 
> results.
>
><<
>tol_correction_norm = 1d-3     (default = 1d-5)
>tol_max_correction = 1d-1      (default = 1d-2)
>tol_correction_norm_alt = 1d-2 (default = 1d-3)
>tol_max_correction_alt = 1d0   (same as default)
>>>
>
>But the result is still the same. I am wondering whether I have corrected 
>the appropriate paramters. Or are there any other parameters that I should 
>change as well, besides the above parameters? 
>
>Best regards and with thanks,
>Maurice
>
>--
>Open WebMail Project (http://openwebmail.org)
>
>
>  
> ------------------------------------------------------------------------------ 
> Simplify data backup and recovery for your virtual environment with 
> vRanger. Installation's a snap, and flexible recovery options mean your 
> data is safe, secure and there when you need it. Data protection magic? 
> Nope - It's vRanger. Get your free trial download today. 
> http://p.sf.net/sfu/quest-sfdev2dev 
> _______________________________________________ mesa-users mailing list 
> mes...@li... 
> https://lists.sourceforge.net/lists/listinfo/mesa-users

[mesa-users] about the tolerance of the code

[Leung S. C. <sc...@ph...>]

Dear all,

I am trying to modify the code in order to couple the effect of external 
gravity to the structure of the star. But the effect seems to be too large 
that the code reports with:

<<
...
first model is slow to converge: num tries         270
stopping because of convergence problems
terminated evolution: convergence problems
>>

I have tried to relaxed the tolerance (as suggested by the webpage of MESA) 
so as to make the calculation easier and to see some primitive results.  

<<
tol_correction_norm = 1d-3     (default = 1d-5)
tol_max_correction = 1d-1      (default = 1d-2)
tol_correction_norm_alt = 1d-2 (default = 1d-3)
tol_max_correction_alt = 1d0   (same as default)
>>

But the result is still the same. I am wondering whether I have corrected 
the appropriate paramters. Or are there any other parameters that I should 
change as well, besides the above parameters? 

Best regards and with thanks,
Maurice

--
Open WebMail Project (http://openwebmail.org)

Re: [mesa-users] Turning the velocity ON

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

Hi,

Take a look at star/test_suite/15M_dynamo.
I suggest you run that test case and look the inlist_15M_dynamo.
Before you run it, edit the inlist to set pgstar_flag = .true.
That will give you some nice plots show rotation and dynamo information.

Good luck,
Bill



On Jun 21, 2011, at 12:31 AM, naveen yadav wrote:

> Hi
> 
> I want to use the velocity and rotation flags on. Where to change them.
> 
> regards
> naveen
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev_______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

Re: [mesa-users] Problem getting pgplot to install on iMac

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

hi doug,

off the top-of-my-head it looks like your gcc creates 32-bit binaries 
and gfortran creates 64-bit binaries, or vice-versa.

we'll take this discussion offline to solve it.

fxt


On Jun 20, 2011, at 10:52 PM, Doug Krajnovich wrote:

> Hi,
>  
> As longtime Windows user, I recently purchased an iMac for primary purpose of experimenting with MESA. I got gfortran 4.5 and MESA to install and run without pgplot, but now I am stuck on the pgplot installation.  My Mac/Terminal/Unix/Linux skills are extremely limited and I am trying to blindly follow directions without knowing exactly what all the commands mean.
>  
> I unpacked pgplot.tbz and  ./makemake . osx gfortran_gcc runs without error.
>  
> But when I type
>   make
> it goes for awhile and then spits out a string of error messages
>  “cputype does not match previous archive members” and then halts without finishing libpgplot.a archive and without creating pgdemo files.
>  
> Any suggestions?
>  
> -Doug Krajnovich   
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev_______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

[mesa-users] Turning the velocity ON

[naveen y. <nav...@ya...>]

Hi

I want to use the velocity and rotation flags on. Where to change them.

regards
naveen

[mesa-users] Problem getting pgplot to install on iMac

[Doug K. <dj...@co...>]

Hi,
 
As longtime Windows user, I recently purchased an iMac for primary purpose
of experimenting with MESA. I got gfortran 4.5 and MESA to install and run
without pgplot, but now I am stuck on the pgplot installation.  My
Mac/Terminal/Unix/Linux skills are extremely limited and I am trying to
blindly follow directions without knowing exactly what all the commands
mean.
 
I unpacked pgplot.tbz and  ./makemake . osx gfortran_gcc runs without error.
 
But when I type
  make
it goes for awhile and then spits out a string of error messages
 "cputype does not match previous archive members" and then halts without
finishing libpgplot.a archive and without creating pgdemo files.
 
Any suggestions?
 
-Doug Krajnovich   

Re: [mesa-users] download about Mesa-code on stellar evolution

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

Dear Lifang,
you would check out a copy as described on the mesa web page.
F.

On 06/19/2011 06:09 PM, llf wrote:
> Dear Sir
> I am working on the evolution of single stars or binaries.
> I want to use the Mesa-code to investigate some
> interesting problems about stellar evolution or binary
> evolution. Can you tell me how to download this
> code on stellar evolution.
> Thank you very much
> Best regards
> Lifang Li
> 2011-06-20
> ------------------------------------------------------------------------
> llf
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
>
>
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

[mesa-users] download about Mesa-code on stellar evolution

[llf <ll...@yn...>]

Dear Sir

I am working on the evolution of single stars or binaries.
I want to use the Mesa-code to investigate some
interesting problems about stellar evolution or binary
evolution. Can you tell me how to download this
code on stellar evolution.

Thank you very much

Best regards

Lifang Li

2011-06-20 



llf 

[mesa-users] mesa release 3372

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

Hi,

I've added a few things and (hopefully) fixed a few others.  Of course that means I've probably broken a few things too, but I count on you to let me know!


One small change that might have an impact on you is the new default to deal with bad mass fractions more severely.  Turns out that the newton solver in star doesn't explicitly constrain mass fractions to be in the range 0 to 1 and to add to 1.  We have to enforce that as a separate operation.  In the past, we just cleaned things up and continued (the cleanup is to truncate values to be in the range 0 to 1 and then renormalize so that they sum to 1).   Now we cleanup if things aren't too bad, but we reject the step and force a retry if they are.   The meaning of "too bad" is given by these new controls:
         
         min_xa_hard_limit = -1d-6 
            ! if solver produces mass fraction < this limit, then reject the trial solution
         sum_xa_tolerance = 1d-6
            ! if solver gives solution with abs(sum(X) - 1) > this, then reject and retry.

During evolution you might now see terminal messages saying "bad_X_sum" or "neg_mass_frac".
And you might even get more accurate results!



For those of you who use Python or just want to try a GUI for mesa/star, Kent Budge has provided a nifty one.  
Check out star/test/gui.py and guic.py.   Please give it a try and let Kent know what you think.     kg...@la...



There are cases where you might want to get extremely fine resolution near the surface.  To help you with this,
there is a new "relax" operation, relax_max_surf_dq.   I've been able to get surface dq's down to 10^-21 this way.
The remesh limit on size changes for adjacent cells ensures that there are a bunch of small dq's near the surface.
It is even okay to make the max_surf_dq << min_dq -- the remesh code will make small cells near the surface to satisfy the max_surf_dq even if that means making them smaller than the normal min_dq.



The application that motivated relax_max_surf_dq stuff is WD asterseimology.
That application has also led to the addition of the ability to add an atmosphere model for the FGONG or OSC output.
Here are the new comments from run_star_defaults:

      ! you can create an atmosphere for use with pulsation codes.
      ! inspired by B. Paczynski, 1969, Acta Astr., vol. 19, 1.
      ! takes into account dilution of luminosity when tau < 2/3,
      ! and calls mlt to get gradT allowing for convection.
      ! you should use the Henyey option for mlt when adding an atmosphere.
      add_atmosphere_for_fgong = .false.
      add_atmosphere_for_osc = .false.

The added atmosphere can include convective regions.  To make that work, mlt now is given optical depth as another argument.
When tau < 2/3, it will now modify grad_rad for dilution following Paczynski, 1969, Acta Astr., vol. 19, 1., eqn 14
BTW: a big thank you to Agnes Kim and Mike Montgomery for helping with the effort to get mesa able to make state-of-the-art models for doing white dwarf asteroseismology -- we're not quite there yet, but we are making progress.   I'm also working with Jim MacDonald on improvements to the mesa diffusion module, so stay tuned for that.  ;-)



Recall that the "surface" of a model is defined to be the outer boundary of the outermost cell.  This means that unless you happen to have a surface boundary condition that places that outer boundary at the photosphere, T_surface will not be the same as T_effective.   The controls for when to stop a run need to provide limits for both -- and now they do.  The old controls for logTeff limits have been changed to logTsurf limits, and new controls for Teff upper and lower limits have been added.



Alexander Heger suggested we add the ability to stop a run more gracefully than by doing a CTRL-c --- what a good idea!
Here's the new &star_job control:

         stop_if_this_file_exists = ''
            ! at each step, the code will try to open this file
            ! if the file exists, it will terminate the run
            ! if the file doesn't exist, it will keep going.



There have also been some changes to the physics input modules, but hopefully nothing that you'll notice unless you call them directly.
For example, we've cleaned up the interface for the screen module so that Falk can use it with NuGrid.



Finally, I found and fixed a bug that was preventing the equation evaluation task in star from taking advantage of multi-cores.  Not a big change, but every bit helps.


Speaking of performance issues, when using a net with more than 20 isotopes or so, the time spent doing matrix algebra starts to be significant.  We currently aren't getting any help for this from multi-cores.   In theory the ifort MKL package should support multithreading for matrix algebra, but I haven't been able to get it to provide any improvement.  Perhaps I'm just not setting things up properly.  Let me know if you can figure that one out.   I've also tried to install ATLAS on my mac, but it also failed to give any improvement.  


As usual, expect bugs and let me know as soon as you find them.


Cheers,
Bill

Re: [mesa-users] how to specify the contents of a log file for a run

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

On Jun 15, 2011, at 1:32 AM, Yasunori Hori wrote:

> I have one question about how to make a new data file.
> 
> When I calculate evolution of an irradiated planet,
> I would like to make a data file that includes
> age(time), Mass, Radius, T_surf, P_surf, RHO_surf, L_surf.
> Could you please tell me which file should be changed?



Hi Yasunori,

In the &star_job section of your inlist, add this line:
      log_columns_file = 'log_columns.list' 

Make a local copy of the file
	mesa/data/star_data/log_columns.list

Edit your new copy to select the items you want saved in the star.log file (it is in your LOGS folder).

Keep in mind that "surf" means the outer boundary of the model.  So if you use a boundary condition that places that outer boundary somewhere other than the photosphere, then T_surf /= T_effective.

In the &controls section of your inlist, set the log_cnt to determine how often the log is updated.  
To get every model recorded in the log, do this:
      log_cnt = 1
  
If you find that there is something that you want to put in the log that isn't included in the standard options in log_columns.list, there are ways for you to write a few lines of code to add whatever you want.

Good luck!

Bill