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

Re: mesa-users] "bad composition in setup for kap builder"

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

Hi Petar,

That's a new one!  But hopefully we'll find a fix.

During the first install, or when the opacities data has been updated,
the install process builds new opacity tables.   When the top-level
mesa/install script finds that the mesa/data/kap_data directory is
missing or the data/kap_data/tag data/kap_data/tag_cpy file
isn't up to date, it runs the 'build_data_and_export' script in kap.

That script in turn cd's to kap/preprocessor where it does 'mk',
and then 'rn_all'.  The rn_all script builds the data files, and it
seems to be having trouble with co_z00_x00.data.  You can find
the line of code that's complaining in kap/preprocessor/src/ 
kap_support.f.

          if (Zbase+X+XC+XO > 1) then
             write(*,*) 'bad composition in setup for kap builder'
             stop 1
          end if

Let's add a few lines to print out the offending sum that's > 1.
Here's what I added at the start of the setup routine:

          include 'formats.dek'

          write(*,1) 'Zbase+X+XC+XO', Zbase+X+XC+XO
          write(*,1) 'Zbase', Zbase
          write(*,1) 'X', X
          write(*,1) 'XC', XC
          write(*,1) 'XO', XO

And when I ran it, I got this:

                            Zbase+X+XC+XO    1.0000000000000001E-01
                                    Zbase    1.0000000000000001E-01
                                        X    0.0000000000000000E+00
                                       XC    0.0000000000000000E+00
                                       XO    0.0000000000000000E+00

So it looks like the problem may be that trailing '1' in Zbase.
On my machine, it seems to be ignored (perhaps the compiler
is doing me a favor?).   It seems that the test comparing the sum to 1
is wrong.   Why don't you try changing it to the following:

          if (Zbase+X+XC+XO-1 > 1d-9) then
             write(*,*) 'bad composition in setup for kap builder'
             stop 1
          end if

Please let me know if that helps!

BTW: what system & compiler are you using?

Cheers,
Bill





On May 20, 2009, at 12:14 PM, Petar Todorov wrote:

> Dear MESA list,
>
> I'm a newbie with MESA, so my problem will probably be trivial for  
> most of
> you, but unfortunately I can't overcome it. So, my problem is that the
> compilation stops when it comes to build the opacities tables (just  
> after
> the EOS was built):
>
>> creating data/kap_data/co_z000_x00.data
>> bad composition in setup for kap builder
>> STOP 1
>
> What does it mean? I didn't find with grep which script shows this  
> error
> message (I also browsed several scripts in the mesa and mesa/kap
> directories) and google wasn't my friend either when tried to see if  
> this
> is a standard error message.
>
> Regards,
> Petar
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>

mesa-users] "bad composition in setup for kap builder"

[Petar T. <pet...@ob...>]

Dear MESA list,

I'm a newbie with MESA, so my problem will probably be trivial for most of
you, but unfortunately I can't overcome it. So, my problem is that the
compilation stops when it comes to build the opacities tables (just after
the EOS was built):

> creating data/kap_data/co_z000_x00.data
> bad composition in setup for kap builder
> STOP 1

What does it mean? I didn't find with grep which script shows this error
message (I also browsed several scripts in the mesa and mesa/kap
directories) and google wasn't my friend either when tried to see if this
is a standard error message.

Regards,
Petar

mesa-users] The latest build

[Marcin @ a. <ast...@o2...>]

Hi Bill,

With svn I've downloaded the latest 1214 mesa build.
To delete any recent I've used ./clean and then I've used ./install to 
build mesa.
Afters successful passing eos data compilation stopped at eos package 
with error:

*//home/lab/mesa/eos/test/make
FAILED/*
and
/*make: *** no rules to make `plot_eosDP.o', required by 'plotter'. Stop.*/
it's my translation from Polish ;)

How to clean this error and to go on with compilation?

I'd like to remind you my configuration:
OS: Fedora 10 (ran virtually on SUN VirtualBox)
compliter: Intel Fortran Compiler 11
Disabled OpenMP
Default build 1214 mesa settings.

Regards

Marcin

Re: mesa-users] Inquiry about the mesa code

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

Hi Takuma,

On Apr 15, 2009, at 10:46 AM, Takuma Suda wrote:

>> What did you type on the command line to restart?
>>
>
> I just typed
> [mesaroot/star/work/]% ./re

Ah -- the "re" script needs the name of a file from the
"photos" directory.  I need to fix it to give an error message
if it doesn't have any command line arg.

If you look in work/photos, you'll find files with names like 'x010'.
That particular file would be for model number 10 (or 1010 or
2010, etc.).  To restart from that model, do

./re x010

Hope that works!

Cheers,
Bill

Re: mesa-users] Inquiry about the mesa code

[Takuma S. <t....@ep...>]

Hi Bill,

Thank you very much for your quick reply.


>> So far, I was successful in computing the M=7 Msun and Z=0.02 model
>> in the first trial. But, it doesn't work if I tried to restart
>> the program today.
>
> What did you type on the command line to restart?
>

I just typed
[mesaroot/star/work/]% ./re

>> It stops with the following message.
>>
>> -------
>> loading eos data
>> loading kap data
>> finished loading
>>
>> read restart_photo
>> star_load_zams ierr        5009
>> -------
>>
>> I tried to start a new model, but it still fails.
>> Could you tell me how to cope with it?
>
> Let's check to see if it can still pass the installation test.
> cd to your mesa/star/test directory and enter the command line
> 	
> ./ck
>
> If it passes the test, there will be no output.
>

Certainly, there was no output.


> To see what the test is doing, try this command
>
> ./tester
>
> The terminal output should match the contents of the file called
> "test_output".
>
> Actually, the match won't be exact, digit for digit, but it should
> be numerically close.  That's why we use ndiff for checking
> instead of diff.
>
> If it fails the test, then it might be best to just reinstall and  
> start over.
>

The output is almost the same as in "test_output" (not exactly as you  
mentioned).


> If it passes the test, then there is perhaps a problem in the  
> 'inlist' file.
> Why don't you send me a copy of that and I'll see if it works for me.
>

I would attach the 'inlist' to this e-mail. Thank you for your help.

>> Could you also tell me
>> if you have a brief instruction of the structure
>> of the program? I would be very grateful if you help
>> me to understand the program.
>
> I've recently changed the default inlist so that it includes
> all of the options with brief comments along with default values.
> Do you have that version?  If not, you might want to update.
>

I think I have the updated version. The parameters in inlist are
easy to understand thanks to the comments.

> In terms of understanding the implementation, you might want
> to start with the files in mesa/star/public.  The 'star_def.f' file
> defines the basic data structure for a star.  The file 'star_data.dek'
> has the data about the model, while 'star_controls.dek' declares
> the control parameters.  The default values and comments about
> the controls are in 'star_defaults.dek'.  Finally, 'star_lib.f' has
> the procedures that users of the modules should call.  The actual
> code that does the work is called from here; sources are in
> mesa/star/private.
>
> The code in mesa/star/test/src/run_star.f is another place you
> might want to start looking.  It is the top-level routine that
> calls functions in star_lib to drive the evolution.
>
> Let me know how it goes.
>

This is what I'd like to know. Thank you. I will check all these files.

Cheers,
Takuma

--
---------------------------------------------------------
Dr. Takuma Suda <t....@ep...>
Marie Curie Fellow (FP7 - International Incoming Fellowship)
Astrophysics Group, Lennard-Jones Laboratories (LJ2.01), Keele  
University
Keele, Staffordshire ST5 5BG, UK
Phone: +44(0)1782-737-195

Re: mesa-users] Inquiry about the mesa code

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

Hi Takuma,

On Apr 15, 2009, at 8:47 AM, Takuma Suda wrote:

> Dear Prof. Paxton,

Actually, just plain "Bill" will be fine in the future.  ; - )

> My name is Takuma Suda at Keele University working on
> stellar evolution.
>
> I started using the mesa code recently. It is a great work
> and interesting to look into the details of the program!
> I am very interested in using and customizing the mesa code,
> but it is still hard to understand the structure of the program.

And the lack of documentation makes things difficult, I know.
Please don't hesitate to email questions, and I'll try to help.

> So far, I was successful in computing the M=7 Msun and Z=0.02 model
> in the first trial. But, it doesn't work if I tried to restart
> the program today.

What did you type on the command line to restart?

> It stops with the following message.
>
> -------
> loading eos data
> loading kap data
> finished loading
>
> read restart_photo
> star_load_zams ierr        5009
> -------
>
> I tried to start a new model, but it still fails.
> Could you tell me how to cope with it?

Let's check to see if it can still pass the installation test.
cd to your mesa/star/test directory and enter the command line
	
./ck

If it passes the test, there will be no output.

To see what the test is doing, try this command

./tester

The terminal output should match the contents of the file called
"test_output".

Actually, the match won't be exact, digit for digit, but it should
be numerically close.  That's why we use ndiff for checking
instead of diff.

If it fails the test, then it might be best to just reinstall and  
start over.

If it passes the test, then there is perhaps a problem in the 'inlist'  
file.
Why don't you send me a copy of that and I'll see if it works for me.


> I spent some
> time to find what's going on, but the program is
> hard for me to understand.

It's hard for me too sometimes.  ; - )


> Could you also tell me
> if you have a brief instruction of the structure
> of the program? I would be very grateful if you help
> me to understand the program.

I've recently changed the default inlist so that it includes
all of the options with brief comments along with default values.
Do you have that version?  If not, you might want to update.

In terms of understanding the implementation, you might want
to start with the files in mesa/star/public.  The 'star_def.f' file
defines the basic data structure for a star.  The file 'star_data.dek'
has the data about the model, while 'star_controls.dek' declares
the control parameters.  The default values and comments about
the controls are in 'star_defaults.dek'.  Finally, 'star_lib.f' has
the procedures that users of the modules should call.  The actual
code that does the work is called from here; sources are in
mesa/star/private.

The code in mesa/star/test/src/run_star.f is another place you
might want to start looking.  It is the top-level routine that
calls functions in star_lib to drive the evolution.

Let me know how it goes.

> Thank you very much in advance for your kind assistance.
>
> With best regards,
> Takuma Suda

You are very welcome!

Cheers,
Bill

Re: mesa-users] mesa on Mac OS X 10.5 -- what's the trick? stuck with segfaults. ; -(

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

Thanks for the help -- looks like upgrading ifort was the answer.

Cheers,
Bill

Re: mesa-users] mesa on Mac OS X 10.5 -- what's the trick? stuck with segfaults. ; -(

[Jonathan T. <jto...@gm...>]

Bill,

I've got OSX 10.5.6 on my MacBook and have mesa running just fine.
I'm guessing you probably use ifort which I can't comment on (can't
really justify spending the money), but with gfortran it seems to work
okay.  My copy of gfortran is installed through macports (I'm lazy
;-), the version info is:

zefiris:~ jshine$ gfortran -v
Using built-in specs.
Target: i386-apple-darwin9.6.0
Configured with: ../gcc-4.3.3/configure --prefix=/opt/local
--enable-languages=c,c++,objc,obj-c++,java,fortran
--libdir=/opt/local/lib/gcc43 --includedir=/opt/local/include/gcc43
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-4.3
--with-gxx-include-dir=/opt/local/include/gcc43/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local
Thread model: posix
gcc version 4.3.3 (GCC)
zefiris:~ jshine$

Other than using macports to install gfortran, I've done nothing
special with regards to getting mesa to compile & run, and have had no
particular problems with segfaults.

-Jon

Also, here's the version info on my machine from "System Profiler":
  Model Name:	MacBook Pro
  Model Identifier:	MacBookPro4,1
  Processor Name:	Intel Core 2 Duo
  Processor Speed:	2.5 GHz
  Number Of Processors:	1
  Total Number Of Cores:	2
  L2 Cache:	6 MB
  Memory:	4 GB
  Bus Speed:	800 MHz
  Boot ROM Version:	MBP41.00C1.B03
  SMC Version:	1.27f1





On Tue, Mar 31, 2009 at 1:10 PM, Bill Paxton <pa...@ki...> wrote:
> Hi,
>
> I just committed the sin of upgrading my mac from good old 10.4 to the
> nasty new 10.5.6, so now I get seg faults when I try to run mesa.  ; - (
>
> I know that someone out there has managed to make mesa work on 10.5 --
> could you give me some help here?
>
> Thanks,
> Bill
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>



-- 
Jonathan Tomshine
PhD Candidate
University of Minnesota
Dept. of Chemical Engineering and Materials Science
Box 78, Amundson Hall
421 Washington Ave SE
Minneapolis, MN  55455
jto...@gm...

mesa-users] mesa on Mac OS X 10.5 -- what's the trick? stuck with segfaults. ; -(

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

Hi,

I just committed the sin of upgrading my mac from good old 10.4 to the  
nasty new 10.5.6, so now I get seg faults when I try to run mesa.  ; - (

I know that someone out there has managed to make mesa work on 10.5 --  
could you give me some help here?

Thanks,
Bill

mesa-users] Matlab import & plotting

[Jonathan T. <jto...@gm...>]

Just a quick note: a few weeks ago I wrote some scripts to import data
from Mesa's text logs (star/test/logs) into Matlab, store the
resulting data as a matlab binary data (.mat) file, and generate
arbitrary 3d plots.  I put these online here:

http://www.jshine.net/astronomy/mesa/

These aren't particularly efficient -- some of the code could be sped
up considerably with a bit of effort -- but they should work.

I'm not sure I'll continue on this path though, since Matlab is not
free software & there are other interesting options with Python
(thanks for the heads-up Dr. Herwig!).  I've also been tinkering with
giving Mesa support for NetCDF binary output of stellar profile data
(from mesa rev. 1000 forward), which should make writing text-import
filters in various languages less necessary in the future.

-Jon


-- 
Jonathan Tomshine
PhD Candidate
University of Minnesota
Dept. of Chemical Engineering and Materials Science
Box 78, Amundson Hall
421 Washington Ave SE
Minneapolis, MN  55455
jto...@gm...

Re: mesa-users] MESA install is taking forever to complete

[Aaron D. <do...@uv...>]

Hi all,

Thanks for the feedback.  I am using an AMD phenom CPU under fedora core 10 with gcc
4.3.2.  As with Josiah, the install hangs while running tester on the mtx module. 
It is uses 100% of one processor and just goes forever.

>>gfortran -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile
--enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux
Thread model: posix
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC)

Anyway, I have access to machines with ifort now so I can carry on.

Thanks,
Aaron


Josiah Schwab wrote:
>> Here's my experience.
>>
>> For me, the ./tester in the mtx module hangs using the following
>> gfortran on an Intel P4 box,
>>
>> jschwab: mesa$ gfortran -v
>> Using built-in specs.
>> Target: i686-pc-linux-gnu
>> Configured with: ../gcc/configure --enable-languages=c,c++,fortran
>> Thread model: posix
>> gcc version 4.4.0 20080510 (experimental) (GCC)
>>
>> ifort works fine on that machine
>>
>> On my G4 PowerBook, gfortran 4.3 has built MESA successfully.
>>
>> Josiah

Re: mesa-users] MESA install is taking forever to complete

[Josiah S. <js...@gm...>]

Here's my experience.

For me, the ./tester in the mtx module hangs using the following
gfortran on an Intel P4 box,

jschwab: mesa$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.4.0 20080510 (experimental) (GCC)

ifort works fine on that machine

On my G4 PowerBook, gfortran 4.3 has built MESA successfully.

Josiah

On Wed, Jan 28, 2009 at 1:21 PM, Jonathan Tomshine <jrt...@ya...> wrote:
> I compile with a slightly older gfortran (4.3 rather than 4.4) and it works for me without locking-up or crashing (Intel MacBook, 4 gb ram):
>
> dhcp-12:~ jshine$ gfortran -v
> Using built-in specs.
> Target: i386-apple-darwin9.4.0
> Configured with: ../gcc-4.3.2/configure --prefix=/opt/local --enable-languages=c,c++,objc,obj-c++,java,fortran --libdir=/opt/local/lib/gcc43 --includedir=/opt/local/include/gcc43 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.3 --with-gxx-include-dir=/opt/local/include/gcc43/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local
> Thread model: posix
> gcc version 4.3.2 (GCC)
> dhcp-12:~ jshine$
>
>
> -Jon
>
>
>
>
> --- On Wed, 1/28/09, Bill Paxton <pa...@ki...> wrote:
>
>> From: Bill Paxton <pa...@ki...>
>> Subject: Re: mesa-users] MESA install is taking forever to complete
>> To: "Aaron Dotter" <do...@uv...>
>> Cc: mes...@li...
>> Date: Wednesday, January 28, 2009, 11:54 AM
>> Hi Aaron,
>>
>> On Jan 28, 2009, at 9:37 AM, Aaron Dotter wrote:
>>
>> > Just a quick question: I'm trying to install mesa
>> on my desktop machine, compiled
>> > with gfortran because I don't have ifort, and
>> 'tester' is taking a VERY long time to
>> > complete.  Do you have any sense of how long it should
>> take?
>>
>> Minutes on my Intel mac powerbook.
>>
>> > Right now it is over
>> > 24 hours on an AMD 2.4 GHz processor.  What is tester
>> doing?
>>
>> Each package in mesa has the same layout and the same
>> installation steps.
>> And part of the installation is running a test to see if
>> things look okay.
>> That test is done in the 'test' directory of the
>> package; you'll find a test/make/makefile too.
>> The makefile for test creates a little test program called
>> 'tester'.
>> So each each package, during installation a new
>> 'tester' is created and run.
>> The output from tester is compared (using ndiff) to the
>> expected output (in 'test_output').
>>
>> > Obviously for real use of the code I will run it on a
>> machine with ifort but for
>> > testing and exploring the code I want to be able to
>> run it on my machine.
>>
>> My guess is that you have an old gfortran.   There was a
>> bug that caused the thing to hang like that.
>>
>> You might want to update from
>> http://gcc.gnu.org/wiki/GFortran
>>
>> I'm currently using the following gfortran without
>> problems:
>>
>> /Users/billpaxton/mesa/star/test: gfortran -v
>> Using built-in specs.
>> Target: i386-apple-darwin8.10.1
>> Configured with:
>> /tmp/gfortran-20081006/ibin/../gcc/configure
>> --prefix=/usr/local/gfortran --enable-languages=c,fortran
>> --with-gmp=/tmp/gfortran-20081006/gfortran_libs
>> --enable-bootstrap
>> Thread model: posix
>> gcc version 4.4.0 20081006 (experimental) [trunk revision
>> 140904] (GCC)
>>
>>
>> Please let me know if updating fixed things. I'll add a
>> warning to the installation documentation about old
>> gfortrans.
>>
>> BTW: at one time I ran into trouble with the gfortran
>> implementation of OpenMP.
>> I haven't gone back to check for a long time to see if
>> things are ok now, but
>> in the meantime I'm suggesting that people using
>> gfortran disable multi-threading.
>>
>> setenv OMP_NUM_THREADS 1
>>
>> Hopefully that problem will go away since it's great
>> fun to use all the cores,
>> and mesa does a pretty good job of that when given a
>> chance.
>>
>> Thanks,
>> Bill------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
>> mesa-users mailing list
>> mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>

Re: mesa-users] MESA install is taking forever to complete

[Jonathan T. <jrt...@ya...>]

I compile with a slightly older gfortran (4.3 rather than 4.4) and it works for me without locking-up or crashing (Intel MacBook, 4 gb ram):

dhcp-12:~ jshine$ gfortran -v
Using built-in specs.
Target: i386-apple-darwin9.4.0
Configured with: ../gcc-4.3.2/configure --prefix=/opt/local --enable-languages=c,c++,objc,obj-c++,java,fortran --libdir=/opt/local/lib/gcc43 --includedir=/opt/local/include/gcc43 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.3 --with-gxx-include-dir=/opt/local/include/gcc43/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local
Thread model: posix
gcc version 4.3.2 (GCC) 
dhcp-12:~ jshine$ 


-Jon




--- On Wed, 1/28/09, Bill Paxton <pa...@ki...> wrote:

> From: Bill Paxton <pa...@ki...>
> Subject: Re: mesa-users] MESA install is taking forever to complete
> To: "Aaron Dotter" <do...@uv...>
> Cc: mes...@li...
> Date: Wednesday, January 28, 2009, 11:54 AM
> Hi Aaron,
> 
> On Jan 28, 2009, at 9:37 AM, Aaron Dotter wrote:
> 
> > Just a quick question: I'm trying to install mesa
> on my desktop machine, compiled
> > with gfortran because I don't have ifort, and
> 'tester' is taking a VERY long time to
> > complete.  Do you have any sense of how long it should
> take?
> 
> Minutes on my Intel mac powerbook.
> 
> > Right now it is over
> > 24 hours on an AMD 2.4 GHz processor.  What is tester
> doing?
> 
> Each package in mesa has the same layout and the same
> installation steps.
> And part of the installation is running a test to see if
> things look okay.
> That test is done in the 'test' directory of the
> package; you'll find a test/make/makefile too.
> The makefile for test creates a little test program called
> 'tester'.
> So each each package, during installation a new
> 'tester' is created and run.
> The output from tester is compared (using ndiff) to the
> expected output (in 'test_output').
> 
> > Obviously for real use of the code I will run it on a
> machine with ifort but for
> > testing and exploring the code I want to be able to
> run it on my machine.
> 
> My guess is that you have an old gfortran.   There was a
> bug that caused the thing to hang like that.
> 
> You might want to update from
> http://gcc.gnu.org/wiki/GFortran
> 
> I'm currently using the following gfortran without
> problems:
> 
> /Users/billpaxton/mesa/star/test: gfortran -v
> Using built-in specs.
> Target: i386-apple-darwin8.10.1
> Configured with:
> /tmp/gfortran-20081006/ibin/../gcc/configure
> --prefix=/usr/local/gfortran --enable-languages=c,fortran
> --with-gmp=/tmp/gfortran-20081006/gfortran_libs
> --enable-bootstrap
> Thread model: posix
> gcc version 4.4.0 20081006 (experimental) [trunk revision
> 140904] (GCC)
> 
> 
> Please let me know if updating fixed things. I'll add a
> warning to the installation documentation about old
> gfortrans.
> 
> BTW: at one time I ran into trouble with the gfortran
> implementation of OpenMP.
> I haven't gone back to check for a long time to see if
> things are ok now, but
> in the meantime I'm suggesting that people using
> gfortran disable multi-threading.
> 
> setenv OMP_NUM_THREADS 1
> 
> Hopefully that problem will go away since it's great
> fun to use all the cores,
> and mesa does a pretty good job of that when given a
> chance.
> 
> Thanks,
> Bill------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

Re: mesa-users] MESA install is taking forever to complete

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

Hi Aaron,

On Jan 28, 2009, at 9:37 AM, Aaron Dotter wrote:

> Just a quick question: I'm trying to install mesa on my desktop  
> machine, compiled
> with gfortran because I don't have ifort, and 'tester' is taking a  
> VERY long time to
> complete.  Do you have any sense of how long it should take?

Minutes on my Intel mac powerbook.

> Right now it is over
> 24 hours on an AMD 2.4 GHz processor.  What is tester doing?

Each package in mesa has the same layout and the same installation  
steps.
And part of the installation is running a test to see if things look  
okay.
That test is done in the 'test' directory of the package; you'll find  
a test/make/makefile too.
The makefile for test creates a little test program called 'tester'.
So each each package, during installation a new 'tester' is created  
and run.
The output from tester is compared (using ndiff) to the expected  
output (in 'test_output').

> Obviously for real use of the code I will run it on a machine with  
> ifort but for
> testing and exploring the code I want to be able to run it on my  
> machine.

My guess is that you have an old gfortran.   There was a bug that  
caused the thing to hang like that.

You might want to update from http://gcc.gnu.org/wiki/GFortran

I'm currently using the following gfortran without problems:

/Users/billpaxton/mesa/star/test: gfortran -v
Using built-in specs.
Target: i386-apple-darwin8.10.1
Configured with: /tmp/gfortran-20081006/ibin/../gcc/configure -- 
prefix=/usr/local/gfortran --enable-languages=c,fortran --with-gmp=/ 
tmp/gfortran-20081006/gfortran_libs --enable-bootstrap
Thread model: posix
gcc version 4.4.0 20081006 (experimental) [trunk revision 140904] (GCC)


Please let me know if updating fixed things. I'll add a warning to  
the installation documentation about old gfortrans.

BTW: at one time I ran into trouble with the gfortran implementation  
of OpenMP.
I haven't gone back to check for a long time to see if things are ok  
now, but
in the meantime I'm suggesting that people using gfortran disable  
multi-threading.

setenv OMP_NUM_THREADS 1

Hopefully that problem will go away since it's great fun to use all  
the cores,
and mesa does a pretty good job of that when given a chance.

Thanks,
Bill

Re: mesa-users] matlab script for 3D plots of mesa/star results

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

Hi Jon,

Very cool!  And there are enough matlab users, that it will be worth  
having even if it doesn't work with Octave.

Perhaps we need to pause and think about how to set up a general way  
for mesa users to contribute to a collection of such tools that could  
be made available for download through the mesa website.  Do you have  
any ideas about how that might be setup?

I've Cc'd this to mesa-users in case anyone else out there has ideas  
on this subject.

Cheers,
Bill




On Jan 25, 2009, at 7:14 PM, Jonathan Tomshine wrote:

> Bill,
>
> As I mentioned earlier, I've been tinkering with a Matlab .m script  
> to parse all the log files & combine all the structure vs. time  
> data into a single .mat data file which Matlab can handle  
> relatively quickly & easily.  A second script then uses the  
> resulting .mat file to draw arbitrary plots in 3-dimensions like  
> the two attached here (where one horizontal axis is a star  
> "summary" variable that describes the entire star, such as time,  
> while the other horizontal and the vertical axes describe internal  
> structure).
>
> I think that they're somewhat revealing, although, sadly, the code  
> probably does not work on Octave (I'll have to check).  After some  
> tweaking, and if you think it's useful, I could add them to the SVN  
> repository.

Re: mesa-users] Break-evens

[Marcin @ a. <ast...@o2...>]

Hi Bill,


Bill Paxton wrote:
> One of the wonderful aspects of EZ was how fast it could do evolution 
> up the RGB.  EZ was based on Eggleton's code, and that was designed 
> specifically for thin shell burning up the RGB.  But I found that I 
> couldn't generalize it to let me do other stuff reliably.  So I've 
> abandoned the EZ methods.
Yes, now I can see it much closer. Anyway I still use EZ as an another 
approach to understand the stellar evolution.

> So mesa/star is slow up the RGB as it follows the shell burning in 
> detail.  However, I have been able to reach the helium core flash and 
> even continue through it to reach steady helium burning.   But it 
> currently requires some changes in parameter settings.  Since its been 
> some time since I've tried this, let me run some tests before I 
> suggest what you should do.
Calculations are slower but its very good to know that mesa does those 
details. It's another field for explorations. Let's just wait for your 
suggestions to parameter settings changes.

> So, mesa/star is sometimes (much) slower than EZ, but there are many 
> interesting things that mesa/star can do that I couldn't get EZ to do 
> at all.
Exactly!

>> And if we're talking about break-evens. What are the capabilities of 
>> mesa in this area?  Maybe it is possible to reach the point near to 
>> supernova expolsion?
>>
> The eos at high T is based on Frank Timmes' code and should be fine 
> for advanced burning.
> The other parts of the mesa microphysics should also be capable of 
> supporting this.
>
> The problem at the moment is the breakdown of the convergence of the 
> structure equations.
> I'm currently working on a new approach to that problem, but it's too 
> early to tell if it will work.
I can't wait for it.

> (...) they should actually show helium shell flashes on the AGB.
I'll plot it out. I've already seen some mesa's loops on H-R diagram on 
Helium burning stage.


> The advanced burning stages after c12 are o16, ne20, mg24, si28, s32, 
> etc.  For carbon burning stars, I use
> new_net_num = 83 ! Basic + o18 + ne22 + alpha_mg24_to_s32
At this moment I use /new_net_num = 83 ! Basic + o18 + ne22 + 
alpha_mg24_to_s32/ for all runs

I'll just run a set of cases with different settings. I'm sure I'll find 
many interesting things.


Regards

Marcin

Re: mesa-users] Break-evens

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

Hi Marcin,

On Dec 4, 2008, at 11:57 AM, Marcin @ astrophysics wrote:

> I'm trying to reach Helium break-even point for stars with masses  
> around 1 Msun. None of my runs reached it. The lg_dt_yr value is  
> getting smaller and smaller and I wonder how much time would be  
> needed to reach Helium flash.

One of the wonderful aspects of EZ was how fast it could do evolution  
up the RGB.  EZ was based on Eggleton's code, and that was designed  
specifically for thin shell burning up the RGB.  But I found that I  
couldn't generalize it to let me do other stuff reliably.  So I've  
abandoned the EZ methods.

So mesa/star is slow up the RGB as it follows the shell burning in  
detail.  However, I have been able to reach the helium core flash and  
even continue through it to reach steady helium burning.   But it  
currently requires some changes in parameter settings.  Since its  
been some time since I've tried this, let me run some tests before I  
suggest what you should do.

So, mesa/star is sometimes (much) slower than EZ, but there are many  
interesting things that mesa/star can do that I couldn't get EZ to do  
at all.


> About 10 Msun stars cross Helium and Carbon break-evens.

Great.   I get that too.


> And if we're talking about break-evens. What are the capabilities  
> of mesa in this area?  Maybe it is possible to reach the point near  
> to supernova expolsion?

The eos at high T is based on Frank Timmes' code and should be fine  
for advanced burning.
The other parts of the mesa microphysics should also be capable of  
supporting this.

The problem at the moment is the breakdown of the convergence of the  
structure equations.
I'm currently working on a new approach to that problem, but it's too  
early to tell if it will work.

In the meantime, I think you should be able to get stars of up to  
about 15Msun to go through carbon burning.

And stars over about 2.5Msun should be fine to go through helium  
burning.  And they should actually show helium shell flashes on the AGB.


Here are some nets to try for helium and carbon burning:

During helium burning, the nitrogen (n14) gets converted to o18 and  
then to ne22.  That's worth following by itself for stars that will  
not reach carbon burning.  For those, I use
	new_net_num = 65 ! Basic + o18 + ne22

The advanced burning stages after c12 are o16, ne20, mg24, si28, s32,  
etc.  For carbon burning stars, I use
	new_net_num = 83 ! Basic + o18 + ne22 + alpha_mg24_to_s32


Cheers,
Bill

Re: mesa-users] Successful compilation

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

Hi Marcin,

On Dec 3, 2008, at 11:43 AM, Marcin @ astrophysics wrote:

> I read mesa description at sourceforge and tried to run a model  
> even of 0.05Msun. Mesa successfully produced outcomes. May I rely  
> on them?

I think the mesa microphysics should be okay down to about 0.01Msun  
since the eos includes the SCVH data for sub-stellar objects.  So the  
low mass results are probably as good as the rest, but I can't really  
say how good that is yet -- more testing is needed to verify/validate/ 
calibrate.

>  Is it possible to expand mass boundaries? Let's say lower than  
> 0.03Msun and higher than about 120Msun.

At the low mass end, I've run some simple roche lobe overflow  
experiments that are able to reduce masses down to below 0.02.

At the high mass end, there are convergence problems with the current  
code that seem to get worse the more radiation dominated the star  
is.  It may require some new ideas and hard work to fix that.

> Yes, I would appreciate for other Z models. How many of them there  
> are?

I've added the current set to the release, so you'll get them next  
time you update.   There are 8 Z values from 1e-6 to 4e-2.

> So, could I change to any initial_Z (making sense of course) value  
> I'd like?
> Could you explain to me what is the difference between mentioned  
> the only Z=0.02 models and different initial_Z values?

If you ask for a Z value for which the system has prebuilt models, it  
will of course use one of those.

If your requested Z is not one of the prebuilt ones, the system will  
load a prebuilt model with the closest available Z, and then modify  
it by adjusting mass fractions.  Hopefully the modified model will  
still be able to converge.  With a large set of pre-builts it seems  
to work.  I've even been able to change Z to 0 for at least some masses.

The main problem comes from models that are of a mass that puts them  
on the boundary between PP versus CNO burning as their main energy  
source.  For them, a change in Z can make a big difference in their  
internal structure.  You may still be able to make the change, but  
you may have to do it in a series of substeps and let things  
reconverge in small steps.

>> You can also make composition changes.  The simplest ways are to  
>> use the change_Y and change_Z controls.  Just set the flag to true  
>> and specify the desired value.
>>       !change_Y = .true.
>>       new_Y = 0.29
>>       !change_Z = .true.
>>       new_Z = 0.018
> It is really great. Are those values applicable to even main and  
> pre-main sequence models?

Yes.

>
>> There are also options for including more details for pre-main- 
>> sequence burning (h2, li7, be7, b8), and alpha chains, etc.  See  
>> mesa/net/public/net_def for more details.
> Is it possible to use that burning to not pre-main sequence starts  
> but to very low mass stars (Msun < 0.08)?

Yes.

> How could I quickly add colors to the output

I've added a routine to star/test/src/run_star.f that creates a log  
of colors info.
Find the following line and change .false. to .true.

          if (.false.) then ! save color magnitude info in log file

Look at the routine write_colors_info to see what's happening.

The latest stuff is revision number 838.  After doing the svn update,  
remove the directory star/zams_models before doing the install.  That  
will cause the install of the star package to create a new  
zams_models directory with all of the Z's.

Let me know how it goes.

Cheers,
Bill

Re: mesa-users] Successful compilation

[Marcin @ a. <ast...@o2...>]

Hi Bill,


Bill Paxton wrote:
> The ZAMS starting models are in the mesa/star/zams_models directory. 
>  The release only has the Z=0.02 models, but I have others I can 
> include if you'd like them.   The pre-built models go from 0.08Msun to 
> 80Msun.
I like crossing borders :-P so...
I read mesa description at sourceforge and tried to run a model even of 
0.05Msun. Mesa successfully produced outcomes. May I rely on them?
However masses over 80 are really not welcome;-) Is it possible to 
expand mass boundaries? Let's say lower than 0.03Msun and higher than 
about 120Msun.

Yes, I would appreciate for other Z models. How many of them there are?

> You're not limited to using the pre-built models.   The file 
> star/test/inlist has the control parameters, and in there you'll find 
>
>    ! starting specifications
>
>       initial_mass = 1
>       initial_Z = 2d-2
>
> Try changing those to what you want, and see if the system can create 
> something that matches.
So, could I change to any initial_Z (making sense of course) value I'd like?
Could you explain to me what is the difference between mentioned the 
only Z=0.02 models and different initial_Z values?

> Those same controls are used when you want to start from 
> pre-main-sequence rather than ZAMS.
>
> To switch to pre-main-sequence starting models, edit the inlist file
>
>    create_pre_main_sequence_model = .true.
>       pre_main_sequence_rho_bar = 1d-4
>    
> The "rho_bar" parameter is the average density of the proto-star.  The 
> system will create a polytrope (n=1.5) for a starting model.
You may be sure I'll try and test it. I'm very curious where would it go to.

> You can also make composition changes.  The simplest ways are to use 
> the change_Y and change_Z controls.  Just set the flag to true and 
> specify the desired value.
>    
>    !change_Y = .true.
>       new_Y = 0.29
>    
>    !change_Z = .true.
>       new_Z = 0.018
It is really great. Are those values applicable to even main and 
pre-main sequence models? And again how does it imply to "one Z" and 
initial_Zs?

> There are also options for including more details for 
> pre-main-sequence burning (h2, li7, be7, b8), and alpha chains, etc. 
>  See mesa/net/public/net_def for more details.
Is it possible to use that burning to not pre-main sequence starts but 
to very low mass stars (Msun < 0.08)? I ask about Deuterium burning for 
stars not allowed to start Hydrogen burning.

> p.s. you might have noticed that there's now a mesa/colors package 
> that has the code for calculating theoretical color magnitudes using 
> color magnitude data from Lejeune, Cuisinier, Buser (1998) A&AS 130, 
> 65-75.
Oh yes, I've noticed! Thank you for that. How could I quickly add colors 
to the output (let's say B-V and U-B only) without heavy code digging 
for me at this moment?

Waiting for your reply, regards.

Marcin

Re: mesa-users] Successful compilation

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

On Dec 3, 2008, at 7:19 AM, Marcin @ astrophysics wrote:

> I've updated mesa to 834 revision and recompiled the whole source.  
> There have been no warnings and errors.
> At this moment I am successfully running mesa with different inlist  
> parameters. It's great!


Wonderful!

> Could you tell me what are the ranges for initial mass and initial  
> Z in mesa?

The ZAMS starting models are in the mesa/star/zams_models directory.   
The release only has the Z=0.02 models, but I have others I can  
include if you'd like them.   The pre-built models go from 0.08Msun  
to 80Msun.

You're not limited to using the pre-built models.   The file star/ 
test/inlist has the control parameters, and in there you'll find

    ! starting specifications

       initial_mass = 1
       initial_Z = 2d-2


Try changing those to what you want, and see if the system can create  
something that matches.

Those same controls are used when you want to start from pre-main- 
sequence rather than ZAMS.

To switch to pre-main-sequence starting models, edit the inlist file

    create_pre_main_sequence_model = .true.
       pre_main_sequence_rho_bar = 1d-4

The "rho_bar" parameter is the average density of the proto-star.   
The system will create a polytrope (n=1.5) for a starting model.

You can also make composition changes.  The simplest ways are to use  
the change_Y and change_Z controls.  Just set the flag to true and  
specify the desired value.

    !change_Y = .true.
       new_Y = 0.29

    !change_Z = .true.
       new_Z = 0.018

In addition to changing Y and Z, you can change the set of isotopes  
by changing the net.   The "Basic" net has h1, he3, he4, c12, n14,  
o16, ne20, and mg24 (mg24 is a place holder for all things heavy!).    
If you'd like more details on what happens to the n14, you can add  
o18 and n22 by doing this

    change_net = .true.
       new_net_num = 65 ! Basic + o18 + ne22

There are also options for including more details for pre-main- 
sequence burning (h2, li7, be7, b8), and alpha chains, etc.  See mesa/ 
net/public/net_def for more details.

Finally, there's an option to include a velocity variable rather than  
making the hydro-static assumption that all velocities are  
negligible.  When velocities are included, there's an acceleration  
term included in the momentum equation.  To add velocities,

    set_v_flag = .true.
       new_v_flag = .true.


That's probably enough to get you started!

Let me know how it goes.

Cheers,
Bill

p.s. you might have noticed that there's now a mesa/colors package  
that has the code for calculating theoretical color magnitudes using  
color magnitude data from Lejeune, Cuisinier, Buser (1998) A&AS 130,  
65-75.

Re: mesa-users] Using Mesa

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

Hi Marcin,

Good to hear from you again.  I look forward to having you use mesa!


On Nov 28, 2008, at 10:47 AM, astrophysics wrote:

> Dear Bill,
>
> First of all I admire your huge effort creating MESA.
> I'm interested in stellar astrophysics especially a stellar  
> evolution. Prevoiusly I used your old good EZ. However I wanted to  
> see even more, of course ;)

; - )

> I use latest Debian distribution as an operating system and Intel  
> Fortran Compiler 11.0. I have difficulties with compiling MESA.

Unfortunately, we keep getting surprises like this.  It may take a  
few iterations to work out the problems.

> Prevoius packages were built just fine.

Do you mean packages other than mesa?   Or were you able to build  
mesa before with a different compiler?

> In num package I received the following error message:
> ../private/mod_rosenbrock.f(226): error #7068: The characteristics  
> of a dummy argument of the associated actual procedure differ from  
> the characteristics of the same  dummy argument of the dummy  
> procedure. (12.2)   [RODAS4_COEFFS]
>>      ns,contro4,rodas4_coeffs,n,fcn,ifcn,x,y,xend,
> -----------------------^
> ../private/mod_rosenbrock.f(258): error #7068: The characteristics  
> of a dummy argument of the associated actual procedure differ from  
> the characteristics of the same  dummy argument of the dummy  
> procedure. (12.2)   [RODASP_COEFFS]
>>      ns,contro4,rodasp_coeffs,n,fcn,ifcn,x,y,xend,
> -----------------------^
> compilation aborted for ../private/mod_rosenbrock.f (code 1)
>
> All I changed from default svn821 mesa package was disabling openmp.

That shouldn't be a problem.

> Have you seen something like this before?

No -- each one is different!

Since 11.0 is new, I don't have personal experience with it yet.   If  
you're willing, we'll have to try a few things until we find  
something that fixes the problem.   Looks like the new compiler is  
being more restrictive testing argument types.  That's a good thing  
in the long run, but it causes this sort of trouble during the  
conversion period.

The 2 errors may be the result of missing "intent(out)" info in the  
declarations.  I've fixed this and made a new release.

Please do

svn update -r 822

In general, after doing an update, you should recompile everything.   
So do a 'clean' before restarting the 'install':

./clean
./install

Let me know how it goes.

Cheers,
Bill

Re: mesa-users] Using Mesa

[astrophysics <ast...@o2...>]

Dear Bill,

First of all I admire your huge effort creating MESA.
I'm interested in stellar astrophysics especially a stellar evolution. Prevoiusly I used your old good EZ. However I wanted to see even more, of course ;)

I use latest Debian distribution as an operating system and Intel Fortran Compiler 11.0. I have difficulties with compiling MESA. Prevoius packages were built just fine.

In num package I received the following error message:
../private/mod_rosenbrock.f(226): error #7068: The characteristics of a dummy argument of the associated actual procedure differ from the characteristics of the same  dummy argument of the dummy procedure. (12.2)   [RODAS4_COEFFS]
     >      ns,contro4,rodas4_coeffs,n,fcn,ifcn,x,y,xend,
-----------------------^
../private/mod_rosenbrock.f(258): error #7068: The characteristics of a dummy argument of the associated actual procedure differ from the characteristics of the same  dummy argument of the dummy procedure. (12.2)   [RODASP_COEFFS]
     >      ns,contro4,rodasp_coeffs,n,fcn,ifcn,x,y,xend,
-----------------------^
compilation aborted for ../private/mod_rosenbrock.f (code 1)

All I changed from default svn821 mesa package was disabling openmp.
Have you seen something like this before? 

Kind regards

Marcin

Re: mesa-users] Using Mesa

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

Hi Roni,

On Nov 17, 2008, at 12:35 AM, Roni Waldman wrote:

> I tried to install Tioga, got error, see hist.txt. Help, please.

I'm glad you're installing Tioga -- your other email mentioned that  
you were going to try updating to a new pdflatex; let me know if that  
does the job.

> Meanwhile I am successfully running a 9 solar mass model.

For that massive a star, you might want to try a larger nuclear  
reaction net for the later burning stages.
If so, wait for the next time the job does "save photos", then

stop the run (ctrl-C works nicely!)

edit inlist as follows to change the net to one including an alpha  
chain to s32

    change_net = .true.
       new_net_num = 83 ! Basic + o18 + ne22 + alpha_mg24_to_s32

restart from the most recent photo.
For example, if it last said "save photos/x880", do

./re x880

When it restarts, it should output info indicating that it has a new  
net in place.

> Question: I am now running one job in the directory mesa/star/test.  
> What is the proper way to run several jobs at the same time,  
> regarding directory organization?

I haven't put in all the handles for a general solution yet -- but  
now that you've mentioned it, I'll put out a new release soon with  
the fixes for that.

--Bill

Re: mesa-users] Using Mesa

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

Hi,

On Nov 16, 2008, at 2:04 AM, Roni Waldman wrote:

> Do you have any tools ready for plotting the results?

I use Tioga for plotting (http://rubyforge.org/projects/tioga/).
My plotting programs for mesa/star are in test/star_profile
and test/star_history.

Here's a sample from profiles:


And another from histories (showing helium core flash and after):



Cheers,
Bill

Re: mesa-users] Using Mesa

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

On Nov 13, 2008, at 3:42 AM, Roni Waldman wrote:

> OK, compilation was successful.

Great!

> Now, when I try to run in mesa/star/test, the program tries to  
> restart from  rgb_mods/rgb_base_100.mod which does not exist.

Open mesa/star/test/inlist and comment out this line:

!   load_saved_model = .true.

You might also want to comment out these for now (you can try them  
later):

!   set_v_flag = .true.

!   change_net = .true.

Then edit the initial_mass (3 might be a good thing to try for a start).

And you'll also need to change initial_Z to 2d-2 (other Z's are  
available but they are not currently being included in the release --  
let me know when you'd like to have some other options beyond solar).

> Also, is there a straightforward way to change the compilation to  
> not have all the debugging and checking flags? Setting COMPILE_STD  
> = $(COMPILE_TO_DEPLOY) in makefile_header did not work for all the  
> directories.

Each package makefile defines COMPILE; most use COMPILE_STD, but when  
I'm debugging (or just feeling paranoid) I set it to COMPILE_TO_TEST.

If you want to turn off testing in a package, edit pkg/make/makefile  
to change the definition of COMPILE, then cd pkg/test and do ./ 
cleanup and ./mk.  (NOTE: ./clean only does the test directory; ./ 
cleanup does the entire package)   When that finishes, do ./ck to  
check it, and assuming that is okay, do ./export to export it for use  
by other packages.

Cheers,
Bill