Menu
▾
▴
mesa-users — open list for mesa comments, questions, & answers
This list is closed, nobody may subscribe to it.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(5) |
| 2009 |
Jan
(5) |
Feb
(1) |
Mar
(3) |
Apr
(4) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
|
Nov
(1) |
Dec
(13) |
| 2010 |
Jan
|
Feb
(6) |
Mar
(4) |
Apr
(1) |
May
(10) |
Jun
(43) |
Jul
(37) |
Aug
(3) |
Sep
(6) |
Oct
(26) |
Nov
(17) |
Dec
(29) |
| 2011 |
Jan
(28) |
Feb
(18) |
Mar
(42) |
Apr
(18) |
May
(13) |
Jun
(32) |
Jul
(32) |
Aug
(25) |
Sep
(46) |
Oct
(41) |
Nov
(36) |
Dec
(43) |
| 2012 |
Jan
(92) |
Feb
(120) |
Mar
(40) |
Apr
(75) |
May
(40) |
Jun
(93) |
Jul
(115) |
Aug
(67) |
Sep
(38) |
Oct
(92) |
Nov
(95) |
Dec
(47) |
| 2013 |
Jan
(171) |
Feb
(200) |
Mar
(100) |
Apr
(134) |
May
(112) |
Jun
(142) |
Jul
(123) |
Aug
(66) |
Sep
(175) |
Oct
(236) |
Nov
(141) |
Dec
(98) |
| 2014 |
Jan
(91) |
Feb
(88) |
Mar
(126) |
Apr
(63) |
May
(123) |
Jun
(122) |
Jul
(105) |
Aug
(83) |
Sep
(114) |
Oct
(90) |
Nov
(181) |
Dec
(85) |
| 2015 |
Jan
(111) |
Feb
(120) |
Mar
(161) |
Apr
(95) |
May
(93) |
Jun
(185) |
Jul
(170) |
Aug
(119) |
Sep
(128) |
Oct
(110) |
Nov
(145) |
Dec
(92) |
| 2016 |
Jan
(105) |
Feb
(106) |
Mar
(101) |
Apr
(59) |
May
(96) |
Jun
(168) |
Jul
(110) |
Aug
(183) |
Sep
(85) |
Oct
(79) |
Nov
(87) |
Dec
(86) |
| 2017 |
Jan
(100) |
Feb
(77) |
Mar
(85) |
Apr
(52) |
May
(60) |
Jun
(63) |
Jul
(67) |
Aug
(24) |
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
|
From: Ehsan M. <mor...@ia...> - 2011-01-03 08:22:40
|
<html><div> Hi Zahra, in /star/public/star_defaults.dek, there are several switches under " when to stop" part, to stop the evolution based on logTeff, logg, and logL, for ex (~line 256): log_Teff_upper_limit = 1d99 ! stop when log of T effective is greater than this limit. Copy this line to your working inlist first. Then look at your HR diagram, and carefully find the logTeff for which the evolutionary tracks loop. Once you had a good estimate of this logTeff, call it the upper Log Teff possible for the evolution of a pre-ms star, and edit your inlist for log_Teff_upper_limit set to this value. Next, restart ./rn, and MESA/star automatically stops at this point, and saves the last model profile into some *.data file. Bill and Aaron might have other suggestions. Best wishes with 2011. On Mon, January 3, 2011 11:28 am, zahra altaha motahar wrote: > Hi, > I want to find the ZAMS starting point in my results. How can I stop > running when pre-main sequence star has reached ZAMS? > > Regards, > Zahra > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, > and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl_______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users > -- Moravveji, Ehsan. Ph.D student of Astrophysics. Department of Physics, Institute for Advanced Studies in Basic Sciences (IASBS), GavaZang Road, Zanjan 45137-66731, Iran. Office: (+98)241-415 2212 Fax: (+98)241-415 2104 http://iasbs.ac.ir/students/moravveji -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: zahra a. m. <zam...@ya...> - 2011-01-03 07:58:15
|
Hi, I want to find the ZAMS starting point in my results. How can I stop running when pre-main sequence star has reached ZAMS? Regards, Zahra |
|
From: David K. <ka...@gr...> - 2010-12-17 20:40:44
|
Hi. I had actually written some similar code, although it's a bit simpler. If you look at: http://www.gravity.phys.uwm.edu/~kaplan/MESA/ there are two scripts. The first, parse_log.py converts MESA star.log and lognnn.data files to FITS binary tables. It's pretty simple, and I haven't verified all behavior, but I find it handy. Usage would be: plock[dk_wd]% parse_log.py LOGS/log1.data Converted LOGS/log1.data to LOGS/log1.fits You can then open these in python, matlab, IDL, etc and have the column definitions follow. The second: update_inlist.py allows for command-line modification of inlist files. I find this handy for keeping track of exactly how the files change, and to allow changing things from a script. For example: update_inlist.py -u h1_boundary_mass_limit -m h1_boundary_mass_limit 0.140 inlist_newwd uncomments the parameter "h1_boundary_mass_limit", and then sets its value to 0.140. update_inlist.py -u save_model_number -m save_model_number 225 -m save_model_filename \'he_0.15_stripped.mod\' inlist_newwd makes mesa/star first save a model and then: update_inlist.py -c save_model_number -u load_saved_model -m saved_model_name \'he_0.15_stripped.mod\' inlist_newwd makes it load in that model. This is a bit more complicated, and I'm sure some failures can be found, but let me know what you find. It might be worth having a SVN area for user-contributed software. David Kaplan ------------------------------------------------------- David Kaplan ka...@gr... Asst. Professor Dept. of Physics, UW-Milwaukee Room 480 o: +1-414-229-4971 f: +1-414-229-5589 http://www.lsc-group.phys.uwm.edu/~dkaplan/ On Dec 17, 2010, at 1:50 PM, Falk Herwig wrote: > We are making available a python tool to access the mesa star.log and > lognnn.data output files in the LOGS directory at > > http://forum.astro.keele.ac.uk:8080/nugrid/releases-and-software-downloads/python-tools/nugrid_pylib.tar/view > > This modules are in beta stage at present but they are useful to us > and so maybe useful to you. These modules are not presently part of > the official mesa release and therefore do not satisfy the rigourous > code standards that you are used to from the official mesa codes. If > you are able to make improvements, or add new plot type methods that > could be useful to others please send them (but please send only well > tested and debugged code!), and we may add these improvements or fixes > to our svn version of these modules and make them available to > everybody on this web page. > > Have fun ... > > -- > Falk Herwig > Dept of Physics & Astronomy, U of Victoria > fh...@uv..., tel: +1 (250) 721-7743 > > -------------------------------------------------- > I support http://www.rainforestsos.org > > > ------------------------------------------------------------------------------ > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users |
|
From: Falk H. <fh...@uv...> - 2010-12-17 19:50:25
|
We are making available a python tool to access the mesa star.log and lognnn.data output files in the LOGS directory at http://forum.astro.keele.ac.uk:8080/nugrid/releases-and-software-downloads/python-tools/nugrid_pylib.tar/view This modules are in beta stage at present but they are useful to us and so maybe useful to you. These modules are not presently part of the official mesa release and therefore do not satisfy the rigourous code standards that you are used to from the official mesa codes. If you are able to make improvements, or add new plot type methods that could be useful to others please send them (but please send only well tested and debugged code!), and we may add these improvements or fixes to our svn version of these modules and make them available to everybody on this web page. Have fun ... -- Falk Herwig Dept of Physics & Astronomy, U of Victoria fh...@uv..., tel: +1 (250) 721-7743 -------------------------------------------------- I support http://www.rainforestsos.org |
|
From: Bill P. <pa...@ki...> - 2010-12-17 19:21:52
|
Hi Shi-Shin, Try this. Here is the 'inlist' which just tells mesa to use 'inlist_very_low_mass_tst' |
|
From: Bill P. <pa...@ki...> - 2010-12-16 17:42:18
|
Hi Everett, Here are some files that might help you. They are from the directory that I use for very low mass cases and have some "how to" notes. I haven't made them public before -- you are the first to ask!!! Try the steps in the README -- edit the inlist inlist1_name's to inlist_vlm1, .... Let me know how it goes and we'll iterate until you have something! |
|
From: Bill P. <pa...@ki...> - 2010-12-16 17:30:55
|
Hi 張世昕,
BTW: Forgive my ignorance, but could you provide me with a westernized name I can use when I send you mail?
I'm completely stumped by 張世昕 ;- )
On Dec 16, 2010, at 7:29 AM, 張世昕 wrote:
> 1. Because we are interested in the planet with a core, then need to modify the inner boundary condition.
That's a very interesting idea! Up to now, I've only used non-standard inner boundary conditions
when I've been modeling the envelope of a neutron star, but the same scheme should work for
the rocky core of a giant planet.
You are the first person to ask about setting the inner BCs -- up to now, I'm the only one to have
used that feature! So it may take us a few tries before I manage to explain it well enough for you.
I changed the inner BCs in 3 stages. The numeric values in the following are for a neutron star,
so you'll of course need to change them for your case.
First, relax M_center to desired mass:
relax_M_center = .true.
new_mass = 1.4
dlgm_per_step = 1d-3
relax_M_center_dt = 3.1558149984d-1 ! secyer*1d-8
Second, R_center to desired radius
relax_R_center = .true.
new_R_center = 1d6 ! in cm
dlgR_per_step = 1d-2
relax_R_center_dt = 3.1558149984d-1 ! secyer*1d-8
Third, L_center to desired core luminosity -- depends on mdot.
relax_L_center = .true.
new_L_center = 1e33 ! in ergs/second
dlgL_per_step = 1d-2
relax_L_center_dt = 3.1558149984d-1 ! secyer*1d-8
The 'new_mass' is in Msun units.
dlgm_per_step and relax_M_center_dt determine how fast the value of M_center is changed
during the relaxation to the desired value. If you try to change too fast, it will fail. In that case,
you need to reduce dlgm_per_step and/or relax_M_center_dt. This part is trial-and-error.
Once you've gotten it too successfully change M_center, then you can go on to doing R_center.
Again, it is a trial-and-error process to find values for dlgR_per_step and relax_R_center_dt
that will let the relaxation go to completion.
Finally, if you want heat flow out from the core, you can set L_center. Otherwise,
you can just let L_center = 0 to thermally disconnect the core from the rest.
> 2. I wonder where to find the source code relates to the "mass_change" in the &controls namelist.
You are welcome to look at the private source code, but think twice before making changes!
Once you modify that code, you are on your own in that the mesa developers won't be able (or willing)
to help you with code that you have changed in the private files.
That said, the mass change code is in star/private/adjust_mass.f
> 3. When I use "simple_photosphere" instead of "tau_100_table" in the "very_low_mass" module,
> something wrong with the timestep.
That's an excellent one! The "very_low_mass" test case assumes use of the non-grey atmosphere tables.
It uses starting models from mesa/data/star_data/very_low_mass_models which are all created
using the "tau_100_table" option. That option puts the outer edge of the model at an optical depth of 100.
When you switch to "simple_photosphere", the outer edge of the model jumps abruptly to an
optical depth of 2/3. And it turns out that the change from 100 to 2/3 is too big for the code to deal
with in a single step. That is leading to convergence failures, which in turn cause the code to try
using a smaller timestep. But even reducing the timestep isn't enough, so the code eventually such a
small timestep that it gives up.
I think this is another case where we need to let the model "relax" to what we want. So at the same time
that you switch from tau_100_table to simple_photosphere, let's tell the system to use tau=100 for
the outer surface. We do that by the following controls in the &star_job part of the inlist:
new_tau_factor = 150
set_tau_factor = .true. ! change tau_factor without reconverging.
The surface optical depth will now be = (2/3)*150 = 100.
If that works, then relax the tau_factor down from 150 to 1 by the following:
relax_tau_factor = .true. ! gradually change tau_factor, reconverging at each step.
new_tau_factor = 1
dlogtau_factor = 0.1 ! change log10(tau_factor) by at most this amount per step
The 'dlogtau_factor' determines how fast the relaxation process changes the tau_factor;
you may have to reduce it if the code has trouble converging.
Please let me know how it goes. Using mesa to do what you propose is very exciting, but it won't be easy to get going!
However, I think if you stick with it, you'll be able to get some nice results.
Best wishes,
Bill Paxton
|
|
From: 張世昕 <ss...@as...> - 2010-12-16 02:40:57
|
Hi, I'm playing around the very_low_mass case, and wondering where to modify the outer (surface) boundary condition. Is it in the hydro_eqns.f ? Btw, how's about modifying the inner boundary condition? Thanks a lot. |
|
From: Everett S. <ea...@co...> - 2010-12-15 18:38:34
|
---------- Forwarded message ---------- From: Everett Schlawin <ea...@co...> Date: Wed, Dec 15, 2010 at 12:25 PM Subject: Fwd: Giant Planets To: mes...@li... Hi Everett, Glad you were able to fix your first problem. In order for your messages to get through to the mesa-users list, please sign up for the list. Otherwise they get sent to purgatory. You can do that here: https://lists.sourceforge.net/lists/listinfo/MESA-users On the subject of initial models for very low masses, you can find a set of pre-made models here: mesa/data/star_data/very_low_mass_models/ You can find some cases dealing with very low mass evolution in star/test_suite, see the README there for details. Using create_pre_main_sequence_model won't work for arbitrarily low masses, but you can push the minimum mass lower by setting pre_ms_T_c to lower values than the default. See star/public/run_star_defaults.dek for info on controls for creating pre-main sequence models. Aaron On Mon, Dec 6, 2010 at 12:43 AM, <mes...@li...> wrote: > As list administrator, your authorization is requested for the > following mailing list posting: > > List: mes...@li... > From: eve...@gm... > Subject: Re: Gas Giant Planets > Reason: Post by non-member to a members-only list > > At your convenience, visit: > > https://lists.sourceforge.net/lists/admindb/mesa-users > > to approve or deny the request. > > > ---------- Forwarded message ---------- > From: Everett Schlawin <eve...@gm...> > To: mes...@li... > Date: Mon, 6 Dec 2010 00:43:49 -0500 > Subject: Re: Gas Giant Planets > I eventually found in the instructions that I needed to turn > create_pre_main_sequence_model to .true for low mass objects. I now > successfully have profiles for M=0.01 M_solar objects. If you have any > suggestions on planet models or for getting masses below 0.01 M_solar, > please let me know but my original problem is solved. > > > On Dec 3, 2010, at 11:45 PM, Everett Schlawin wrote: > > > Hello, > > > > I am trying to create a model of a gas giant planet. For some reason, > MESA stops printing profiles for stars that have less than 0.01 solar > masses. Do I need another control in the inlist? I have MESA Revision 2734. > Here's my very simple input file: > > > > > > > > &star_job > > > > !read_extra_star_job_inlist1 = .true. > > !extra_star_job_inlist1_name = 'inlist_first_thing_to_try' > > pre_ms_T_c = 3d3 > > / ! end of star_job namelist > > > > &controls > > profile_model = 11 > > profile_interval = 10 > > photostep = 10 > > initial_mass = 0.001 > > > > !read_extra_controls_inlist1 = .true. > > !extra_controls_inlist1_name = 'inlist_first_thing_to_try' > > > > / ! end of controls namelist > > > > > > &pgstar > > > > !read_extra_pgstar_inlist1 = .true. > > !extra_pgstar_inlist1_name = 'inlist_first_thing_to_try' > > > > / ! end of pgstar namelist > > > > > > ----------------------------- > > Everett Schlawin > > sch...@as... > > Graduate Student > > Astronomy and Space Sciences > > Cornell University > > > > > > > > > > ----------------------------- > Everett Schlawin > sch...@as... > Graduate Student > Astronomy and Space Sciences > Cornell University > > > > > > > > ---------- Forwarded message ---------- > From: mes...@li... > To: > Date: > Subject: confirm ea67e2da23b41fa5c26a6448c868fc68c6af4bb0 > If you reply to this message, keeping the Subject: header intact, > Mailman will discard the held message. Do this if the message is > spam. If you reply to this message and include an Approved: header > with the list password in it, the message will be approved for posting > to the list. The Approved: header can also appear in the first line > of the body of the reply. > |
|
From: Bill P. <pa...@ki...> - 2010-12-15 17:41:39
|
Hi, The PGPLOT extension for MESA is a big hit -- thanks again to Philip Pinto for getting it started. I'm sending email this in case anyone in mesa-users can help me with a configuration issue. Upgrading to the new ifort (12.0) has forced me to rebuild pgplot, and somehow things have gotten confused so that configure is using one source for the png headers and a different source for the libpng.dylib library. The result is of course failure when I try to do png output. When I try to produce png output with pgplot, it reports as follows: libpng warning: Application was compiled with png.h from libpng-1.4.1 libpng warning: Application is running with png.c from libpng-1.2.44 libpng error: Incompatible libpng version in application and library PGPLOT /png: error in libpng while writing file tst.png, plotting disabled forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PC Routine Line Source libpng12.0.dylib 000000010037022C Unknown Unknown Unknown libpgplot.0.dylib 000000010005E9AC Unknown Unknown Unknown libpgplot.0.dylib 000000010005DBC6 Unknown Unknown Unknown There are libpng12's and libpng14's on my disk, so configure must be getting png.h from a place with libpng12 and then using the libpng from a place with libpng14. Do you happen to know a way to get configure to do the right thing here? Thanks, Bill |
|
From: Aaron D. <aar...@gm...> - 2010-12-14 14:49:02
|
Hi, For information about Tioga, please see the webpage: http://www.itp.ucsb.edu/~paxton/tioga.html Aaron On Tue, Dec 14, 2010 at 9:09 AM, 張世昕 <ss...@as...> wrote: > Hi, > > sorry for the basic question! > i run the star/test_suite/very_low_mass case, > and i want to use tioga to make some plots. > can you give me instructions or show some examples? > thank you very much! > > > > ------------------------------------------------------------------------------ > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users > > |
|
From: Aaron D. <aar...@gm...> - 2010-12-14 14:44:02
|
Sorry, also http://tioga.rubyforge.org/ Aaron On Tue, Dec 14, 2010 at 9:42 AM, Aaron Dotter <aar...@gm...>wrote: > Hi, > > For information about Tioga, please see the webpage: > > http://www.itp.ucsb.edu/~paxton/tioga.html > > > Aaron > > > > > > On Tue, Dec 14, 2010 at 9:09 AM, 張世昕 <ss...@as...> wrote: > >> Hi, >> >> sorry for the basic question! >> i run the star/test_suite/very_low_mass case, >> and i want to use tioga to make some plots. >> can you give me instructions or show some examples? >> thank you very much! >> >> >> >> ------------------------------------------------------------------------------ >> Lotusphere 2011 >> Register now for Lotusphere 2011 and learn how >> to connect the dots, take your collaborative environment >> to the next level, and enter the era of Social Business. >> http://p.sf.net/sfu/lotusphere-d2d >> _______________________________________________ >> mesa-users mailing list >> mes...@li... >> https://lists.sourceforge.net/lists/listinfo/mesa-users >> >> > |
|
From: 張世昕 <ss...@as...> - 2010-12-14 14:09:47
|
Hi, sorry for the basic question! i run the star/test_suite/very_low_mass case, and i want to use tioga to make some plots. can you give me instructions or show some examples? thank you very much! |
|
From: Ehsan M. <mor...@ia...> - 2010-12-12 06:53:15
|
<html><head></head><body style="visibility: visible;"><p><br />Hello Bill and Aaron, I hope you're doing fine. </p><p>These days, I wish to use the MESA output as an input to a pulsation code (GraCo). To this end, I need some more output columns as the profile. I like to ask for some help in writing a suitable run_star_extras.f.<br />The extra columns I need are: dln(eps)/dln(T),</p><p>dln(eps)/dln(rho), dln(opac)/dln(T), dln(opac)/dln(rho). I will also need to convert some outputs like q and radius into cgs units. Furthermore, I want all quantities to be calculated at the edge OR center of each zone not mixed.<br />My first question is:<br />Are those quantities that can be directed to file or to the terminal available as common blocks? If so, where is this common block defined?<br />Also, I checked star/test/src/run_star_extras and found no example of adding an extra column.<br />Thanks in advance.<br /><br />-- <br />Moravveji, Ehsan.<br />Ph.D student of Astrophysics.<br />Department of Physics, Institute for Advanced Studies in Basic Sciences (IASBS), GavaZang Road, <br />Zanjan 45137-66731, Iran.<br /><br />Office: (+98)241-415 2212<br />Fax: (+98)241-415 2104<br />http://iasbs.ac.ir/students/moravveji</p></body></html> |
|
From: Bill P. <pa...@ki...> - 2010-12-09 18:32:32
|
damn -- there's bug in that little code fragment I just sent. You'll need to set extra_heat(k) to 0 as in the fix below. Just proving once again that nothing is too simple to have a bug! Maybe there are still more in there. Let me know. -B On Dec 9, 2010, at 10:26 AM, Bill Paxton wrote: > Hi Yevgeni, > > As you know, there are a couple of simple schemes for adding energy, either uniformly by setting the 'extra_power_source' control or near surface to model irradiation by setting 'flux_for_hemisphere_irradiation'. But your case goes beyond those. > > The general scheme for adding extra heat involves writing a few lines of code. Look at star/public/other_energy.f. The routine 'do_other_energy' is called from inside star to set the vector 's% extra_heat'. The value of s% extra_heat(k) is in ergs/g/sec; it will be added to the energy generation term for cell k along with nuclear reactions. You'll want to change that to set extra_heat(k) according the your rule. You can access information such as the radius for the outer edge of cell k as s% r(k). Here is a little example that turns on extra heat depending on radius. > > subroutine do_other_energy(s, ierr) > ! set s% extra_heat(k) to ergs/g/sec average for cell k > use const_def, only: Rsun > type (star_info), pointer :: s > integer, intent(out) :: ierr > integer :: k > ierr = 0 > ! here is an example of calculating extra_heat for each cell. > do k = 1, s% nz > if (s% r(k) > 0.7*Rsun .and. s% r(k) < 0.9*Rsun) then > s% extra_heat(k) = 1d3*exp(-10*(s% r(k) - 0.8*Rsun)**2) ! 10^3 erg/g/s at peak else s% extra_heat(k) = 0 > end if > end do > s% d_extra_heat_dlnd(:) = 0 ! obsolete and will go away in future release > s% d_extra_heat_dlnT(:) = 0 ! obsolete and will go away in future release > end subroutine do_other_energy > > > After you edit other_energy.f, change to the mesa/star/test directory and do > ./mk > ./ck > ./export > > The ./ck should not produce any output (that means it is okay). > The ./export makes your changes available to your work directories. > > In the not-too-distant future I'll be changing the way this works to make it a bit easier (by using the Fortran2003 feature of having pointers to procedures as elements of derived types). But until then, you'll need to go through the sequence of edit, make & export from star/test, and then remake and run in your work directory. > > Let me know how it goes! > > Cheers, > Bill > > > > ------------------------------------------------------------------------------ > _______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users |
|
From: Bill P. <pa...@ki...> - 2010-12-09 18:27:06
|
Hi Yevgeni,
As you know, there are a couple of simple schemes for adding energy, either uniformly by setting the 'extra_power_source' control or near surface to model irradiation by setting 'flux_for_hemisphere_irradiation'. But your case goes beyond those.
The general scheme for adding extra heat involves writing a few lines of code. Look at star/public/other_energy.f. The routine 'do_other_energy' is called from inside star to set the vector 's% extra_heat'. The value of s% extra_heat(k) is in ergs/g/sec; it will be added to the energy generation term for cell k along with nuclear reactions. You'll want to change that to set extra_heat(k) according the your rule. You can access information such as the radius for the outer edge of cell k as s% r(k). Here is a little example that turns on extra heat depending on radius.
subroutine do_other_energy(s, ierr)
! set s% extra_heat(k) to ergs/g/sec average for cell k
use const_def, only: Rsun
type (star_info), pointer :: s
integer, intent(out) :: ierr
integer :: k
ierr = 0
! here is an example of calculating extra_heat for each cell.
do k = 1, s% nz
if (s% r(k) > 0.7*Rsun .and. s% r(k) < 0.9*Rsun) then
s% extra_heat(k) = 1d3*exp(-10*(s% r(k) - 0.8*Rsun)**2) ! 10^3 erg/g/s at peak
end if
end do
s% d_extra_heat_dlnd(:) = 0 ! obsolete and will go away in future release
s% d_extra_heat_dlnT(:) = 0 ! obsolete and will go away in future release
end subroutine do_other_energy
After you edit other_energy.f, change to the mesa/star/test directory and do
./mk
./ck
./export
The ./ck should not produce any output (that means it is okay).
The ./export makes your changes available to your work directories.
In the not-too-distant future I'll be changing the way this works to make it a bit easier (by using the Fortran2003 feature of having pointers to procedures as elements of derived types). But until then, you'll need to go through the sequence of edit, make & export from star/test, and then remake and run in your work directory.
Let me know how it goes!
Cheers,
Bill
|
|
From: Yevgeni K. <ki...@as...> - 2010-12-08 01:08:50
|
Hi All, I am interested in studying what happens when energy is added to a planet (mass = 0.001Msun). Specifically I am interested in flash heating, concentrated in a given range of mass shells. The closest parameter I found that would control this is 'extra_power_source'. However, it is defined as adding energy to the whole object. Does anybody know how I might be able to set this parameter (or a different one) to achieve this form of heating? Many thanks, Yevgeni. |
|
From: Bill P. <pa...@ki...> - 2010-12-06 16:31:11
|
Hi Nick, Let's first of all check to see if star was made and installed. Go to the mesa/star/test directory and do ./ck If it returns without producing any output, then star is installed and working okay. If ./ck complains, then I'd suggest going back to the top. Go to the top level mesa directory and do svn -r xxx update with xxx replaced by the currently released version of mesa (2841 at the moment). Double check to be sure the update completes successfully -- I've had problems from time to time with sourceforge dropping the transfer part way. Then do ./clean and ./install and try it again. If ./ck in star/test runs okay, then give us precise details of what you are trying next so we can try to reproduce the problem. Good luck, Bill On Dec 5, 2010, at 9:36 PM, Nicholas Stone wrote: > Hello, > I'm new to MESA, so apologies in advance if this is a silly question, > but I've run the install file (I think successfully) and am now trying > to work through the test examples in the /star directory, but there isn't > a star executable to run. The README in the work directory indicated > that I need to run the mk executable, but running the mk file in > /star/work gives the following errors: > > [nstone@iliadaccess01 work]$ ./mk > ifort -vec-report0 -traceback -error-limit 6 -openmp -threads -check > uninit -check pointers -check bounds -check all -g -I../../../include -c > -free ../src/run_star_extras.f > ../src/run_star_extras.f(34): error #5102: Cannot open include file > 'standard_run_star_extras.dek' > include 'standard_run_star_extras.dek' > --------------^ > ../src/run_star_extras.f(36): error #6818: The statement following a > CONTAINS is not a function-stmt or a subroutine-stmt. > end module run_star_extras > ------^ > ../src/run_star_extras.f(25): error #7002: Error in opening the compiled > module file. Check INCLUDE paths. [STAR_LIB] > use star_lib > ----------^ > ../src/run_star_extras.f(26): error #7002: Error in opening the compiled > module file. Check INCLUDE paths. [STAR_DEF] > use star_def > ----------^ > compilation aborted for ../src/run_star_extras.f (code 1) > make: *** [run_star_extras.o] Error 1 > > FAILED > > > > Any advice would be very appreciated! I'm running with ifort 11.1, and > did not edit any details of the makefile_header in the /utils directory > before installing other than setting the isnan flag to isnan_nope. > Thanks in advance, > Nick > > ------------------------------------------------------------------------------ > What happens now with your Lotus Notes apps - do you make another costly > upgrade, or settle for being marooned without product support? Time to move > off Lotus Notes and onto the cloud with Force.com, apps are easier to build, > use, and manage than apps on traditional platforms. Sign up for the Lotus > Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d > _______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users |
|
From: Nicholas S. <ns...@cf...> - 2010-12-06 06:01:56
|
Hello,
I'm new to MESA, so apologies in advance if this is a silly question,
but I've run the install file (I think successfully) and am now trying
to work through the test examples in the /star directory, but there isn't
a star executable to run. The README in the work directory indicated
that I need to run the mk executable, but running the mk file in
/star/work gives the following errors:
[nstone@iliadaccess01 work]$ ./mk
ifort -vec-report0 -traceback -error-limit 6 -openmp -threads -check
uninit -check pointers -check bounds -check all -g -I../../../include -c
-free ../src/run_star_extras.f
../src/run_star_extras.f(34): error #5102: Cannot open include file
'standard_run_star_extras.dek'
include 'standard_run_star_extras.dek'
--------------^
../src/run_star_extras.f(36): error #6818: The statement following a
CONTAINS is not a function-stmt or a subroutine-stmt.
end module run_star_extras
------^
../src/run_star_extras.f(25): error #7002: Error in opening the compiled
module file. Check INCLUDE paths. [STAR_LIB]
use star_lib
----------^
../src/run_star_extras.f(26): error #7002: Error in opening the compiled
module file. Check INCLUDE paths. [STAR_DEF]
use star_def
----------^
compilation aborted for ../src/run_star_extras.f (code 1)
make: *** [run_star_extras.o] Error 1
FAILED
Any advice would be very appreciated! I'm running with ifort 11.1, and
did not edit any details of the makefile_header in the /utils directory
before installing other than setting the isnan flag to isnan_nope.
Thanks in advance,
Nick
|
|
From: Aaron D. <aar...@gm...> - 2010-12-03 21:29:19
|
Hi, It has been brought to my attention that the uname command on a Mac will report the Darwin version, not the Mac OS version. If you're on a Mac, the sw_vers command will give the Mac OS version, which is the more relevant number to send. If you've already sent your info, no need to send it again. Thanks! Aaron |
|
From: Bill P. <pa...@ki...> - 2010-12-03 19:45:39
|
Hi Ale, First, thank you for your replies to mesa-users -- it is a big help to have involvement from people other than the developers! Concerning you questions, are you using the test_suite/rlo code as a start? If not, you should! It includes magnetic braking using the formula from Rappaport, Verbunt, and Joss. apj, 275, 713-731. 1983 It doesn't include enhanced winds caused by tidal synchronization, but the hooks are there to do it if you have a way to compute the enhancement (is it really that significant? are you getting close to rotational breakup?) I can confirm that rotation is not in the currently released mesa. But I'm working on it!!!! Hopefully we'll have an "alpha" release soon, and then we'll need help with testing. Perhaps as a potential user, you'd be willing to help with the testing? That would be great. For you last question about doing a grid of binaries, you'll need to do a driver that selects the initial orbital period, donor and accretor mass, but the actual evolution of the case can be done using something closely based on the test_suite/rlo code. Cheers, Bill On Dec 3, 2010, at 11:30 AM, Alessandro Patruno wrote: > Dear MESA developers, > > I am trying to simulate a set of binaries with a low mass donor star (typically below 1 Msun) > with short orbital period (typically below ~1 day). > > In my simulations I need to include a wind mass loss recipe, and I'm using the de Jager ones. > >From a theoretical point of view, if I use a star of, say, 1 Msun, then this will have a rotational > period of about 1 month, like our Sun. Tidal synchronization however will shortly bring the stellar > rotation to be the same as the orbital period, and therefore much faster than our Sun. > In this case I would expect a very large increase in the wind mass loss rate. > I am not sure whether these aspects are included in the code, from a quick inspection I couldn't find > anything like this, but only the possibility of setting the "eta" value for the wind of non-rotating and rotating models. > Can you please confirm that the rotation and its evolution (and the subsequent effect on the wind loss) > is not included as a feature of MESA ? > > Also, in the binary evolution I can't find magnetic braking, but only the GW angular momentum loss. > Is this also not yet included in the code ? > > On a separate note, I am planning to write a quick update for the MESA code to include the possibility of > evolving a grid of binaries with variable initial orbital period, donor and accretor mass. > Since I'm not a Fortran programmer as good as you are, is some of you available to give me some help in the next > days ? Who should I contact ? > > Many thanks ! > > Ale > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev_______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users |
|
From: Aaron D. <aar...@gm...> - 2010-12-03 19:40:20
|
Hi Ale, Thanks for your questions. You can send your new code to the MESA Council members as identified on the website. Please try to create for us a "test_suite" case, which includes not only your code but also inlist(s), makefile, and anything else you think we might need. There are lots of good examples already provided there to get you started. Rotation is a work in progress. At the moment, there is no option to do rotating models with MESA but I expect it will be possible certainly within a year from now. No promises, though! Magnetic fields of any sort are not supported. Once basic rotation is implemented, one of the next steps would be magnetic braking of some sort. Aaron |
|
From: Alessandro P. <ale...@gm...> - 2010-12-03 19:30:19
|
Dear MESA developers, I am trying to simulate a set of binaries with a low mass donor star (typically below 1 Msun) with short orbital period (typically below ~1 day). In my simulations I need to include a wind mass loss recipe, and I'm using the de Jager ones. >From a theoretical point of view, if I use a star of, say, 1 Msun, then this will have a rotational period of about 1 month, like our Sun. Tidal synchronization however will shortly bring the stellar rotation to be the same as the orbital period, and therefore much faster than our Sun. In this case I would expect a very large increase in the wind mass loss rate. I am not sure whether these aspects are included in the code, from a quick inspection I couldn't find anything like this, but only the possibility of setting the "eta" value for the wind of non-rotating and rotating models. Can you please confirm that the rotation and its evolution (and the subsequent effect on the wind loss) is not included as a feature of MESA ? Also, in the binary evolution I can't find magnetic braking, but only the GW angular momentum loss. Is this also not yet included in the code ? On a separate note, I am planning to write a quick update for the MESA code to include the possibility of evolving a grid of binaries with variable initial orbital period, donor and accretor mass. Since I'm not a Fortran programmer as good as you are, is some of you available to give me some help in the next days ? Who should I contact ? Many thanks ! Ale |
|
From: Aaron D. <aar...@gm...> - 2010-12-03 19:20:45
|
Dear MESA users, We are often faced with the issue of what compiler version MESA works with. We would like to provide information on (at least) the minimum version numbers for ifort and gfortran for a given OS. If you are able to successfully compile and run a fairly recent version of MESA (version > 2700), please do us the courtesy of sending information about your compiler and OS. On Mac and Linux systems, the following commands will tell us what we want to know. For example, > ifort -V #note uppercase V Intel(R) Fortran Compiler Professional for applications running on IA-32, Version 11.1 Build 20100414 Package ID: l_cprof_p_11.1.072 or > gfortran --version GNU Fortran (GCC) 4.4.5 20101112 (Red Hat 4.4.5-2) and > uname -a Linux 2.6.33.6-147.fc13.i686 #1 SMP Tue Jul 6 22:30:55 UTC 2010 i686 i686 i386 GNU/Linux To spare the rest of the community, you can just reply to me. We will compile the results and post them on the web page. Thanks for your help! Aaron |
|
From: Alessandro P. <ale...@gm...> - 2010-12-03 18:34:33
|
Hi Georgios, premise: I'm not a MESA developer, I'm just a user. I've managed to install MESA with gfortran 4.4.1 on my laptop with Ubuntu 9.10 (64 bit). The only problem I got during installation was with pgstar. Bill Paxton solved this problem (see thread "*Problem when installing MESA with pgstar<https://sourceforge.net/mailarchive/message.php?msg_name=AANLkTimD5Ps8MBwgDgeDk7LV6yQf2d9vwdb1HWZ%3DBGMD%40mail.gmail.com> "*). Can you please send the exact output you get when using gfortran ? I'm happy to help if I can help. Also, I need to know your OS and which machines are you using. Cheers, Ale Patruno On Fri, Dec 3, 2010 at 7:14 PM, Georgios Magkotsios <gma...@nd...> wrote: > Dear MESA developers, > > I am aware that MESA requires the latest compiler versions to compile > successfully. Unfortunately, our machines have ifort 11.1/046 and gcc > version 4.4.4. Both fail some tests during installation (ifort in eos > and gfortran in diffusion modules). > > I requested from our support team if they could update the compilers, > but they would like to confirm first that compilation cannot work under > any circumstances. With ifort they used some debugging options and see > the error message below. Could you please explain what this error means, > and whether you think it is really a compiler problem? Thank you. > > Georgios > > <snip> > tolerance 1.0000000000000000E-04 > > do_eos_look_for_brackets returned ierr -1 > x -7.3010299956639813E+00 > dx 1.0000000000000001E-01 > xb1 -7.5010299956639814E+00 > xb3 -7.1010299956639811E+00 > ntry 100 > lrpar 472 > lipar 5487 > ierr in test_get_Rho_T -1 > alert_message > </snip> > > > > > > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users > |
138 messages has been excluded from this view by a project administrator.
