From: Bill P. <pa...@ki...> - 2008-11-10 15:43:20
|
On Nov 10, 2008, at 5:09 AM, Roni Waldman wrote: > I am interested in trying out mesa, > Where is the actual evolution code, and how do I run it? Hi Roni, I'm happy that you're interested in trying out mesa. The top-level stellar evolution package is "mesa/star". Like the other packages, mesa/star is organized with sources in public and private directories. In mesa/star/public you'll find procedures (in star_lib.f), stellar data (in star_data.dek), and control parameters (in star_controls.dek). Code that actually runs the mesa/star evolution package can be found in mesa/star/test/src. However, you shouldn't have to edit those files (at least not for now). Instead, the parameters of a run are read from a text file called 'inlist' that lives in the star/test directory. You can edit that file to pick things such as initial_mass and initial_Z as well as more exotic things like which nuclear net to use. After you've set up inlist, you can launch the code by using one of several little script files that are found in star/test: ./rn -- run an evolution using the current contents of inlist. Information about the state of the star is periodically written to the terminal (at a frequency determined by the 'log_cnt' control). The code also periodically saves "snapshots" of the internal state for possible restarts (the 'photostep' control determines how often this happens). For model numbers that are a multiple of 1000, the name of the snapshot is simply the model number. Otherwise, the name is 'x' followed by the last 3 digits of the model number. For example, a snapshot of model 1325 will be saved as x325. The snapshot files are saved in the 'photos' directory. (This naming scheme was created after I filled up my disc with snapshots during an overnight run -- now with photostep set to 10 or 20, I can let it run overnight without worrying about creating too many snapshots.) If you want to change some controls and restart from the snapshot in x325, do ./re x325 -- restart using snapshot in file photos/x325 Logs and profiles are written to the 'LOGS' directory in test (profiles are saved at a frequency determined by the 'profile_interval' control; a star log entry is created for each model). The files 'log1.data', 'log2.data', etc. have information about a particular model. The file 'profiles.index' has information about what's in those log files. Finally, 'star.log' has the history for the entire run of a variety of values. The LOGS information is automatically reset when you start a new evolution using ./rn, but it is not reset when you do a restart using ./re -- however it is okay to delete the entire contents of LOGS at any time during a run; it will automatically remake the files and keep going from there. You'll find that the profiles and logs are organized as columns of data with enough text info included to make it reasonably clear what's what. I use Tioga for plotting (it was created for this sort of thing), and the plot routines that I use for mesa/star can be found in star_history and star_profile. At this time, the documentation for mesa/star is limited to emails from me! So don't hesitate to ask. Just understand that things are still in a very preliminary state; I'm sure there are lots of bugs out there waiting to be found. ; - ) Cheers, Bill |
From: Bill P. <pa...@ki...> - 2008-11-10 17:34:33
|
Hi, BTW: just a side-note: EZ was fast at what it could do, but it was pretty much impossible for me to make it do anything beyond what Eggleton's original code could do. With mesa I've tried to make the code much more flexible and robust, but you'll find places where this means much slower evolution as it cautiously tip-toes along. The climb up the rgb for low mass stars is a particularly striking case. You may want to let some of those run overnight! Cheers, Bill |
From: Bill P. <pa...@ki...> - 2008-11-11 14:20:14
|
On Nov 10, 2008, at 10:24 PM, Roni Waldman wrote: > What's wrong? Let's go back to check how mesa was installed. Did you do an svn checkout? That's currently the best way to go. The current release version is given in the "getting started" webpage as 743, so you'd do svn co -r 743 https://mesa.svn.sourceforge.net/svnroot/mesa/trunk mesa After the svn checkout finishes downloading lots of files, open mesa/utils/makefile_header and check that it's setup to use the fortran compiler you use. Once you've specified the compiler, the build is done by: cd mesa ./install This script goes through building and testing all of the required packages, finishing with mesa/star. You shouldn't have to do ./mk unless you've edited some source file. Let me know how it goes! Cheers, Bill |
From: Bill P. <pa...@ki...> - 2008-11-13 15:59:50
|
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 |
From: Bill P. <pa...@ki...> - 2008-11-16 16:10:28
|
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 |
From: Bill P. <pa...@ki...> - 2008-11-17 15:27:26
|
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 |
From: astrophysics <ast...@o2...> - 2008-11-28 18:47:20
|
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 |
From: Bill P. <pa...@ki...> - 2008-11-28 19:24:32
|
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 |
From: Bill P. <pa...@ki...> - 2008-12-03 16:42:00
|
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. |
From: Marcin @ a. <ast...@o2...> - 2008-12-03 19:43:54
|
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 |
From: Bill P. <pa...@ki...> - 2008-12-04 05:18:06
|
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 |