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: Evan B. <eb...@ph...> - 2017-03-01 01:14:02
|
Hi Brian, Sorry I’m a little late jumping in on this one, but this issue is already partially fixed in the latest public MESA release (9575). It will now throw out a warning about mdot_edd at you and prevent the code from calculating NaN’s for mdot_edd_eta. Perhaps just a little motivation to upgrade to the latest and greatest version ;) Cheers, Evan > On Feb 28, 2017, at 4:52 PM, Brian Jackson <bja...@bo...> wrote: > > That got it. Thanks! > > Brian > > On Tue, Feb 28, 2017 at 5:38 PM, Pablo Marchant <pa...@gm...> wrote: >> Besides from the nuclear network discrepancy, here is an issue that Evan ran >> into and reported to me a couple of weeks ago. The default implementation >> for the Eddington mass accretion limit applies to BH accretors, and it >> breaks down and produces NaNs when evolving both stars simultaneously with >> limit_retention_by_mdot_edd = .true.. This translates into the obscure error >> messages you are getting Brian. >> >> Just commited a fix that will be up in the next MESA version. For the >> moment, just set limit_retention_by_mdot_edd = .false. in your inlist and >> things should work. >> >> Cheers! >> >> On Tue, Feb 28, 2017 at 5:47 PM, Robert Farmer <rjf...@as...> wrote: >>> >>> Hi >>> The nuclear networks (and hence the isotopes each model has defined) in >>> the two model files are different, can you try in the planet inlist >>> >>> new_net_name = 'o18_and_ne22.net' >>> change_initial_net = .true. >>> >>> so the planet model will have the same network as the star >>> >>> Rob >>> >>> >>> On Tue, Feb 28, 2017 at 4:30 PM, Brian Jackson <bja...@bo...> >>> wrote: >>>> >>>> Dear MESA Users, >>>> In my group, we're trying to continue our analysis of planetary >>>> Roche-lobe overflow (RLO). >>>> >>>> For that, we generate starting planetary and stellar models >>>> (attached). The star model is generated using the 1M_pre_ms_to_WD test >>>> suite with only "max_age = 20e6" added to inlist_1.0 file. The >>>> planetary model is generated using the make_planets test suite with >>>> only "max_age = 20d6" changed in inlist_evolve_1.0_MJ_10.0_ME_2.0_RJ >>>> file. >>>> >>>> We make some modifications to inlists for the binary_both_stars test >>>> suite to load in the saved model files but otherwise use the standard >>>> test suite. >>>> >>>> The following shows the last few lines from MESA before it stops >>>> running our calculation: >>>> >>>> get_xa_for_accretion: accretion species mass fractions do not add to 1.0 >>>> sum(xa(1:species)) >>>> 0.0000000000000000D+00 >>>> h1 1 >>>> 0.0000000000000000D+00 >>>> he3 2 >>>> 0.0000000000000000D+00 >>>> he4 3 >>>> 0.0000000000000000D+00 >>>> c12 4 >>>> 0.0000000000000000D+00 >>>> n14 5 >>>> 0.0000000000000000D+00 >>>> o16 6 >>>> 0.0000000000000000D+00 >>>> ne20 7 >>>> 0.0000000000000000D+00 >>>> mg24 8 >>>> 0.0000000000000000D+00 >>>> 1 1 2.000000000E+07 >>>> 9.244518984E-04 -9.900000000E+01 -3.245769587E-01 >>>> 2 1 2.000000000E+07 >>>> 9.999853565E-01 -9.900000000E+01 -6.799606683E-01 >>>> have reached retry limit so now backup >>>> have reached retry limit so now backup >>>> >>>> dt >>>> 6.3566365930376634D-07 >>>> min_timestep_limit >>>> 9.9999999999999995D-07 >>>> >>>> stopping because of convergence problems dt < min_timestep_limit >>>> >>>> terminated evolution: convergence problems >>>> >>>> termination code: min_timestep_limit >>>> >>>> --- >>>> >>>> The species mass fractions look like nonsense, even though they look >>>> fine in the initial model files. And strangely, they change depending >>>> on the initial orbital period we choose. >>>> >>>> I am running Mac OS X 10.9.5, MESA version 8845, and the MESA SDK >>>> version from April 4 2016. I have attached the binary inlists and >>>> initial models we use to run the calculation. >>>> >>>> Please let me know if you need additional information and if you have >>>> any advice. >>>> >>>> Many thanks, >>>> Brian Jackson >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> mesa-users mailing list >>>> mes...@li... >>>> https://lists.sourceforge.net/lists/listinfo/mesa-users >>>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> mesa-users mailing list >>> mes...@li... >>> https://lists.sourceforge.net/lists/listinfo/mesa-users >>> >> >> >> >> -- >> Pablo Marchant Campos >> M.Sc on Astrophysics, Universidad Católica de Chile >> PhD student, Argelander-Institut für Astronomie > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users |
|
From: Brian J. <bja...@bo...> - 2017-03-01 00:53:29
|
That got it. Thanks! Brian On Tue, Feb 28, 2017 at 5:38 PM, Pablo Marchant <pa...@gm...> wrote: > Besides from the nuclear network discrepancy, here is an issue that Evan ran > into and reported to me a couple of weeks ago. The default implementation > for the Eddington mass accretion limit applies to BH accretors, and it > breaks down and produces NaNs when evolving both stars simultaneously with > limit_retention_by_mdot_edd = .true.. This translates into the obscure error > messages you are getting Brian. > > Just commited a fix that will be up in the next MESA version. For the > moment, just set limit_retention_by_mdot_edd = .false. in your inlist and > things should work. > > Cheers! > > On Tue, Feb 28, 2017 at 5:47 PM, Robert Farmer <rjf...@as...> wrote: >> >> Hi >> The nuclear networks (and hence the isotopes each model has defined) in >> the two model files are different, can you try in the planet inlist >> >> new_net_name = 'o18_and_ne22.net' >> change_initial_net = .true. >> >> so the planet model will have the same network as the star >> >> Rob >> >> >> On Tue, Feb 28, 2017 at 4:30 PM, Brian Jackson <bja...@bo...> >> wrote: >>> >>> Dear MESA Users, >>> In my group, we're trying to continue our analysis of planetary >>> Roche-lobe overflow (RLO). >>> >>> For that, we generate starting planetary and stellar models >>> (attached). The star model is generated using the 1M_pre_ms_to_WD test >>> suite with only "max_age = 20e6" added to inlist_1.0 file. The >>> planetary model is generated using the make_planets test suite with >>> only "max_age = 20d6" changed in inlist_evolve_1.0_MJ_10.0_ME_2.0_RJ >>> file. >>> >>> We make some modifications to inlists for the binary_both_stars test >>> suite to load in the saved model files but otherwise use the standard >>> test suite. >>> >>> The following shows the last few lines from MESA before it stops >>> running our calculation: >>> >>> get_xa_for_accretion: accretion species mass fractions do not add to 1.0 >>> sum(xa(1:species)) >>> 0.0000000000000000D+00 >>> h1 1 >>> 0.0000000000000000D+00 >>> he3 2 >>> 0.0000000000000000D+00 >>> he4 3 >>> 0.0000000000000000D+00 >>> c12 4 >>> 0.0000000000000000D+00 >>> n14 5 >>> 0.0000000000000000D+00 >>> o16 6 >>> 0.0000000000000000D+00 >>> ne20 7 >>> 0.0000000000000000D+00 >>> mg24 8 >>> 0.0000000000000000D+00 >>> 1 1 2.000000000E+07 >>> 9.244518984E-04 -9.900000000E+01 -3.245769587E-01 >>> 2 1 2.000000000E+07 >>> 9.999853565E-01 -9.900000000E+01 -6.799606683E-01 >>> have reached retry limit so now backup >>> have reached retry limit so now backup >>> >>> dt >>> 6.3566365930376634D-07 >>> min_timestep_limit >>> 9.9999999999999995D-07 >>> >>> stopping because of convergence problems dt < min_timestep_limit >>> >>> terminated evolution: convergence problems >>> >>> termination code: min_timestep_limit >>> >>> --- >>> >>> The species mass fractions look like nonsense, even though they look >>> fine in the initial model files. And strangely, they change depending >>> on the initial orbital period we choose. >>> >>> I am running Mac OS X 10.9.5, MESA version 8845, and the MESA SDK >>> version from April 4 2016. I have attached the binary inlists and >>> initial models we use to run the calculation. >>> >>> Please let me know if you need additional information and if you have >>> any advice. >>> >>> Many thanks, >>> Brian Jackson >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> mesa-users mailing list >>> mes...@li... >>> https://lists.sourceforge.net/lists/listinfo/mesa-users >>> >> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> mesa-users mailing list >> mes...@li... >> https://lists.sourceforge.net/lists/listinfo/mesa-users >> > > > > -- > Pablo Marchant Campos > M.Sc on Astrophysics, Universidad Católica de Chile > PhD student, Argelander-Institut für Astronomie |
|
From: Pablo M. <pa...@gm...> - 2017-03-01 00:38:12
|
Besides from the nuclear network discrepancy, here is an issue that Evan ran into and reported to me a couple of weeks ago. The default implementation for the Eddington mass accretion limit applies to BH accretors, and it breaks down and produces NaNs when evolving both stars simultaneously with limit_retention_by_mdot_edd = .true.. This translates into the obscure error messages you are getting Brian. Just commited a fix that will be up in the next MESA version. For the moment, just set limit_retention_by_mdot_edd = .false. in your inlist and things should work. Cheers! On Tue, Feb 28, 2017 at 5:47 PM, Robert Farmer <rjf...@as...> wrote: > Hi > The nuclear networks (and hence the isotopes each model has defined) in > the two model files are different, can you try in the planet inlist > > new_net_name = 'o18_and_ne22.net' > change_initial_net = .true. > > so the planet model will have the same network as the star > > Rob > > > On Tue, Feb 28, 2017 at 4:30 PM, Brian Jackson <bja...@bo...> > wrote: > >> Dear MESA Users, >> In my group, we're trying to continue our analysis of planetary >> Roche-lobe overflow (RLO). >> >> For that, we generate starting planetary and stellar models >> (attached). The star model is generated using the 1M_pre_ms_to_WD test >> suite with only "max_age = 20e6" added to inlist_1.0 file. The >> planetary model is generated using the make_planets test suite with >> only "max_age = 20d6" changed in inlist_evolve_1.0_MJ_10.0_ME_2.0_RJ >> file. >> >> We make some modifications to inlists for the binary_both_stars test >> suite to load in the saved model files but otherwise use the standard >> test suite. >> >> The following shows the last few lines from MESA before it stops >> running our calculation: >> >> get_xa_for_accretion: accretion species mass fractions do not add to 1.0 >> sum(xa(1:species)) >> 0.0000000000000000D+00 >> h1 1 >> 0.0000000000000000D+00 >> he3 2 >> 0.0000000000000000D+00 >> he4 3 >> 0.0000000000000000D+00 >> c12 4 >> 0.0000000000000000D+00 >> n14 5 >> 0.0000000000000000D+00 >> o16 6 >> 0.0000000000000000D+00 >> ne20 7 >> 0.0000000000000000D+00 >> mg24 8 >> 0.0000000000000000D+00 >> 1 1 2.000000000E+07 >> 9.244518984E-04 -9.900000000E+01 -3.245769587E-01 >> 2 1 2.000000000E+07 >> 9.999853565E-01 -9.900000000E+01 -6.799606683E-01 >> have reached retry limit so now backup >> have reached retry limit so now backup >> >> dt >> 6.3566365930376634D-07 >> min_timestep_limit >> 9.9999999999999995D-07 >> >> stopping because of convergence problems dt < min_timestep_limit >> >> terminated evolution: convergence problems >> >> termination code: min_timestep_limit >> >> --- >> >> The species mass fractions look like nonsense, even though they look >> fine in the initial model files. And strangely, they change depending >> on the initial orbital period we choose. >> >> I am running Mac OS X 10.9.5, MESA version 8845, and the MESA SDK >> version from April 4 2016. I have attached the binary inlists and >> initial models we use to run the calculation. >> >> Please let me know if you need additional information and if you have >> any advice. >> >> Many thanks, >> Brian Jackson >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> mesa-users mailing list >> mes...@li... >> https://lists.sourceforge.net/lists/listinfo/mesa-users >> >> > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users > > -- Pablo Marchant Campos M.Sc on Astrophysics, Universidad Católica de Chile PhD student, Argelander-Institut für Astronomie |
|
From: Brian J. <bja...@bo...> - 2017-03-01 00:37:18
|
Rob, Thanks for catching that mistake. I've fixed the planetary model (attached). Unfortunately, that didn't seem to fix the problem I have, though. Same error. Brian On Tue, Feb 28, 2017 at 4:47 PM, Robert Farmer <rjf...@as...> wrote: > Hi > The nuclear networks (and hence the isotopes each model has defined) in the > two model files are different, can you try in the planet inlist > > new_net_name = 'o18_and_ne22.net' > change_initial_net = .true. > > so the planet model will have the same network as the star > > Rob > > > On Tue, Feb 28, 2017 at 4:30 PM, Brian Jackson <bja...@bo...> > wrote: >> >> Dear MESA Users, >> In my group, we're trying to continue our analysis of planetary >> Roche-lobe overflow (RLO). >> >> For that, we generate starting planetary and stellar models >> (attached). The star model is generated using the 1M_pre_ms_to_WD test >> suite with only "max_age = 20e6" added to inlist_1.0 file. The >> planetary model is generated using the make_planets test suite with >> only "max_age = 20d6" changed in inlist_evolve_1.0_MJ_10.0_ME_2.0_RJ >> file. >> >> We make some modifications to inlists for the binary_both_stars test >> suite to load in the saved model files but otherwise use the standard >> test suite. >> >> The following shows the last few lines from MESA before it stops >> running our calculation: >> >> get_xa_for_accretion: accretion species mass fractions do not add to 1.0 >> sum(xa(1:species)) >> 0.0000000000000000D+00 >> h1 1 >> 0.0000000000000000D+00 >> he3 2 >> 0.0000000000000000D+00 >> he4 3 >> 0.0000000000000000D+00 >> c12 4 >> 0.0000000000000000D+00 >> n14 5 >> 0.0000000000000000D+00 >> o16 6 >> 0.0000000000000000D+00 >> ne20 7 >> 0.0000000000000000D+00 >> mg24 8 >> 0.0000000000000000D+00 >> 1 1 2.000000000E+07 >> 9.244518984E-04 -9.900000000E+01 -3.245769587E-01 >> 2 1 2.000000000E+07 >> 9.999853565E-01 -9.900000000E+01 -6.799606683E-01 >> have reached retry limit so now backup >> have reached retry limit so now backup >> >> dt >> 6.3566365930376634D-07 >> min_timestep_limit >> 9.9999999999999995D-07 >> >> stopping because of convergence problems dt < min_timestep_limit >> >> terminated evolution: convergence problems >> >> termination code: min_timestep_limit >> >> --- >> >> The species mass fractions look like nonsense, even though they look >> fine in the initial model files. And strangely, they change depending >> on the initial orbital period we choose. >> >> I am running Mac OS X 10.9.5, MESA version 8845, and the MESA SDK >> version from April 4 2016. I have attached the binary inlists and >> initial models we use to run the calculation. >> >> Please let me know if you need additional information and if you have >> any advice. >> >> Many thanks, >> Brian Jackson >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> mesa-users mailing list >> mes...@li... >> https://lists.sourceforge.net/lists/listinfo/mesa-users >> > |
|
From: Robert F. <rjf...@as...> - 2017-02-28 23:47:27
|
Hi The nuclear networks (and hence the isotopes each model has defined) in the two model files are different, can you try in the planet inlist new_net_name = 'o18_and_ne22.net' change_initial_net = .true. so the planet model will have the same network as the star Rob On Tue, Feb 28, 2017 at 4:30 PM, Brian Jackson <bja...@bo...> wrote: > Dear MESA Users, > In my group, we're trying to continue our analysis of planetary > Roche-lobe overflow (RLO). > > For that, we generate starting planetary and stellar models > (attached). The star model is generated using the 1M_pre_ms_to_WD test > suite with only "max_age = 20e6" added to inlist_1.0 file. The > planetary model is generated using the make_planets test suite with > only "max_age = 20d6" changed in inlist_evolve_1.0_MJ_10.0_ME_2.0_RJ > file. > > We make some modifications to inlists for the binary_both_stars test > suite to load in the saved model files but otherwise use the standard > test suite. > > The following shows the last few lines from MESA before it stops > running our calculation: > > get_xa_for_accretion: accretion species mass fractions do not add to 1.0 > sum(xa(1:species)) > 0.0000000000000000D+00 > h1 1 > 0.0000000000000000D+00 > he3 2 > 0.0000000000000000D+00 > he4 3 > 0.0000000000000000D+00 > c12 4 > 0.0000000000000000D+00 > n14 5 > 0.0000000000000000D+00 > o16 6 > 0.0000000000000000D+00 > ne20 7 > 0.0000000000000000D+00 > mg24 8 > 0.0000000000000000D+00 > 1 1 2.000000000E+07 > 9.244518984E-04 -9.900000000E+01 -3.245769587E-01 > 2 1 2.000000000E+07 > 9.999853565E-01 -9.900000000E+01 -6.799606683E-01 > have reached retry limit so now backup > have reached retry limit so now backup > > dt > 6.3566365930376634D-07 > min_timestep_limit > 9.9999999999999995D-07 > > stopping because of convergence problems dt < min_timestep_limit > > terminated evolution: convergence problems > > termination code: min_timestep_limit > > --- > > The species mass fractions look like nonsense, even though they look > fine in the initial model files. And strangely, they change depending > on the initial orbital period we choose. > > I am running Mac OS X 10.9.5, MESA version 8845, and the MESA SDK > version from April 4 2016. I have attached the binary inlists and > initial models we use to run the calculation. > > Please let me know if you need additional information and if you have > any advice. > > Many thanks, > Brian Jackson > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users > > |
|
From: Brian J. <bja...@bo...> - 2017-02-28 23:31:24
|
Dear MESA Users,
In my group, we're trying to continue our analysis of planetary
Roche-lobe overflow (RLO).
For that, we generate starting planetary and stellar models
(attached). The star model is generated using the 1M_pre_ms_to_WD test
suite with only "max_age = 20e6" added to inlist_1.0 file. The
planetary model is generated using the make_planets test suite with
only "max_age = 20d6" changed in inlist_evolve_1.0_MJ_10.0_ME_2.0_RJ
file.
We make some modifications to inlists for the binary_both_stars test
suite to load in the saved model files but otherwise use the standard
test suite.
The following shows the last few lines from MESA before it stops
running our calculation:
get_xa_for_accretion: accretion species mass fractions do not add to 1.0
sum(xa(1:species))
0.0000000000000000D+00
h1 1
0.0000000000000000D+00
he3 2
0.0000000000000000D+00
he4 3
0.0000000000000000D+00
c12 4
0.0000000000000000D+00
n14 5
0.0000000000000000D+00
o16 6
0.0000000000000000D+00
ne20 7
0.0000000000000000D+00
mg24 8
0.0000000000000000D+00
1 1 2.000000000E+07
9.244518984E-04 -9.900000000E+01 -3.245769587E-01
2 1 2.000000000E+07
9.999853565E-01 -9.900000000E+01 -6.799606683E-01
have reached retry limit so now backup
have reached retry limit so now backup
dt
6.3566365930376634D-07
min_timestep_limit
9.9999999999999995D-07
stopping because of convergence problems dt < min_timestep_limit
terminated evolution: convergence problems
termination code: min_timestep_limit
---
The species mass fractions look like nonsense, even though they look
fine in the initial model files. And strangely, they change depending
on the initial orbital period we choose.
I am running Mac OS X 10.9.5, MESA version 8845, and the MESA SDK
version from April 4 2016. I have attached the binary inlists and
initial models we use to run the calculation.
Please let me know if you need additional information and if you have
any advice.
Many thanks,
Brian Jackson
|
|
From: <yan...@xa...> - 2017-02-28 05:15:30
|
Hi Rich, Thanks for your help. As your suggestions, I set the first_*, min_* and max_* parameters in the file gyre.in and the range of frequencies shown on screen is indeed in the search bounds. However, I also add the follow parameters: search_type = ‘simplex' vary_FeH = .true. vary_Y = .true. vary_mass = .true. in the file inlist_astero_search_controls, It seems remain unchanged as before, it still just match the finnal model's frequency, I really don't konw how to do with it. Can you give me any help? Cheers, Taozhi From: RICHARD H D TOWNSEND Date: 2017-02-24 23:25 To: yan...@xa... CC: mesa-users Subject: Re: [mesa-users] A question about the pulsation package Hi Taozhi — The way the pulsation_gyre is currently set up, it doesn’t perform any optimization on the mass, metallicity etc — it just assumes that these parameters are sufficient to get a good match (at some point during the star’s evolution) to the frequencies specified in the inlist_astero_search_controls file. If you alter these frequencies (but don’t otherwise modify the inlist), then it’s unsurprising that you’re not able to get a good match. To fix this, you need to set some parameters in inlist_astero_search_controls. To allow mass and abundances to vary: search_type = ‘simplex' vary_FeH = .true. vary_Y = .true. vary_mass = .true. Also, look at the first_*, min_* and max_* parameters to set the search bounds. cheers, Rich > On Feb 23, 2017, at 4:04 AM, yan...@xa... wrote: > > Hi everyone, > > I want to use the package 'pulsation_gyre' to calculate the frequency of every model, and match a certain frequency, but when I have a try, I find that it always match the final model's frequency when it terminate, for example, in the package /star/test_suit/pulse_gyre, firstly, I have a try to the initial test, it is OK and it can match the frequency (n=0, l=4, frequency=378d0) which is set in the file /src/run_star_extras.f, and it terminate. when I change the frequency to another value (it maybe the previous model's frequency), it will show the bad match for the expected frequency. > > I don't know why is it? Can anyone give me some help, How can I set the parameter? > > Thanks in advance. > Taozhi > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users |
|
From: Mathieu R. <m....@uv...> - 2017-02-28 02:01:46
|
Dear all,
I would like to share the outcome of one of the many resolution tests I
have been performing lately, to show what can go wrong and encourage
everybody to spend some time doing these (often painful) exercises.
The attached plot shows the post-oxygen depletion time evolution of the
compactness parameter,
$$ \xi_{M=2.5} \propto \frac{M}{R(M)}$$ ,
for an initially 25$M_\odot$ model, at solar metallicity, with mass loss
but no rotation. All the curves start from the same exact model and
differ only in the adopted mesh_delta_coeff and
mesh_delta_coeff_for_highT ($\Delta$ and $\Delta_\mathrm{high \ T}$ in
the legend). The end point is either the onset of core collapse, or in
some cases (e.g. thick gray curve), failure to find an acceptable
solution for the stellar structure equations.
I ran these models as a self-consistency test on the spatial meshing,
using an approx21 nuclear reaction network. This network pre-determines
the value of $Y_e$, therefore the effective Chandrasekhar mass of the
stellar core and ultimately the core structure and compactness, so do
not take the values on the y axis as realistic.
*The key point is that there is a bifurcation point in the evolution,
and two different classes of solutions appear. Which class of solutions
MESA finds depends on the spatial resolution, and increasing it, MESA
can jump back and forth between the 2 classes.* I did not investigate
further what physically causes this bifurcation, as it was not relevant
for my scientific question.
This kind of behavior might be an issue also in your research, so beware
of it!
Best regards,
Mathieu
--
Mathieu Renzo <https://staff.fnwi.uva.nl/m.renzo/>
PhD student/KITP grad fellow
Anton Pannekoek Institute,
University of Amsterdam
Contacts:
Address: PO Box 94249, 1090 GE Amsterdam
Office: C4.128a
Telephone: (+31) 020-5258352
Skype name: m4thr3n
Mail: m....@uv... <mailto:m....@uv...>
|
|
From: Aaron D. <aar...@gm...> - 2017-02-27 16:49:47
|
Hi Warrick, The error message is caused by leftover code in MESA from an experiment (the _2_ is experimental). I ran into the same problem when trying to use a different set of tables. In the next development cycle, I'll be removing the _2_ file requirements and then you'll be able to try the MacDonald tables again. I can let you know when a new version is ready to try. Jim MacDonald's EOS tables were brought in, as far as I recall, to completement the current OPAL/SCVH EOS tables at higher Z (=0.2 and 1.0). The OPAL EOS is only provided at Z=0, 0.02, and 0.04. The full set of MacDonald tables were provided for completeness. Aaron On Mon, Feb 27, 2017 at 8:39 AM, Warrick Ball <wb...@bi...> wrote: > Hi everyone, > > I've been calibrated some solar models and was interested to try a > different equation of state option in r9575. I had a look on the forums > and saw [1] that suitable prefixes can be found by listing > > ls $MESA_DIR/data/eos* > > I tried the 'macdonald' option but immediately ran into issues, after > which I found that there's a separate export script for the Macdonald data > at > > $MESA_DIR/eos/build_macdonald_DTdata_and_export > > and > > $MESA_DIR/eos/build_macdonald_PTdata_and_export > > I ran both of those and then tried a simple test run (just add > eos_file_prefix = 'macdonald' to a new $MESA_DIR/star/work/ directory). > It starts by caching some EoS data. e.g. > > write /home/wball/mesa/9575/data/eosDT_data/cache/macdonald- > eosDT_00z60x.bin > write /home/wball/mesa/9575/data/eosDT_data/cache/macdonald- > eosDT_00z80x.bin > write /home/wball/mesa/9575/data/eosDT_data/cache/macdonald- > eosDT_02z60x.bin > write /home/wball/mesa/9575/data/eosDT_data/cache/macdonald- > eosDT_02z80x.bin > write /home/wball/mesa/9575/data/eosDT_data/cache/macdonald- > eosDT_04z60x.bin > write /home/wball/mesa/9575/data/eosDT_data/cache/macdonald- > eosDT_04z80x.bin > > but then halts with > > load eos tables /home/wball/mesa/9575/data/eosDT_2_data/macdonald-eosDT_ > 2_00z60x.data > > FATAL ERROR: missing or bad eos data. > Please update by removing the directories mesa/data/eos*_data and > rerunning the mesa ./install script. > > I duly followed those instructions, which roughly took me back to the > beginning. i.e. had to manually build_and_export the Macdonald data and > got the same output. > > Is the Macdonald EoS no longer supported in MESA? In fact, are any other > EoS's supported? I'll have another go at using HELM throughout the star > now. > > Cheers, > Warrick > > [1] https://sourceforge.net/p/mesa/mailman/message/35327771/ > > ------------ > Warrick Ball > Postdoc, School of Physics and Astronomy > University of Birmingham, Edgbaston, Birmingham B15 2TT > wb...@bi... > +44 (0)121 414 4552 > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users > |
|
From: Warrick B. <wb...@bi...> - 2017-02-27 16:39:59
|
Hi everyone, I've been calibrated some solar models and was interested to try a different equation of state option in r9575. I had a look on the forums and saw [1] that suitable prefixes can be found by listing ls $MESA_DIR/data/eos* I tried the 'macdonald' option but immediately ran into issues, after which I found that there's a separate export script for the Macdonald data at $MESA_DIR/eos/build_macdonald_DTdata_and_export and $MESA_DIR/eos/build_macdonald_PTdata_and_export I ran both of those and then tried a simple test run (just add eos_file_prefix = 'macdonald' to a new $MESA_DIR/star/work/ directory). It starts by caching some EoS data. e.g. write /home/wball/mesa/9575/data/eosDT_data/cache/macdonald-eosDT_00z60x.bin write /home/wball/mesa/9575/data/eosDT_data/cache/macdonald-eosDT_00z80x.bin write /home/wball/mesa/9575/data/eosDT_data/cache/macdonald-eosDT_02z60x.bin write /home/wball/mesa/9575/data/eosDT_data/cache/macdonald-eosDT_02z80x.bin write /home/wball/mesa/9575/data/eosDT_data/cache/macdonald-eosDT_04z60x.bin write /home/wball/mesa/9575/data/eosDT_data/cache/macdonald-eosDT_04z80x.bin but then halts with load eos tables /home/wball/mesa/9575/data/eosDT_2_data/macdonald-eosDT_2_00z60x.data FATAL ERROR: missing or bad eos data. Please update by removing the directories mesa/data/eos*_data and rerunning the mesa ./install script. I duly followed those instructions, which roughly took me back to the beginning. i.e. had to manually build_and_export the Macdonald data and got the same output. Is the Macdonald EoS no longer supported in MESA? In fact, are any other EoS's supported? I'll have another go at using HELM throughout the star now. Cheers, Warrick [1] https://sourceforge.net/p/mesa/mailman/message/35327771/ ------------ Warrick Ball Postdoc, School of Physics and Astronomy University of Birmingham, Edgbaston, Birmingham B15 2TT wb...@bi... +44 (0)121 414 4552 |
|
From: Martin C. <mar...@gm...> - 2017-02-26 00:49:39
|
I notice you have
overshoot_f_above_burn_h_core = 0.01
overshoot_f0_above_burn_h_core = 0.21
Shouldn't f> f0?
Martin
On Thu, Feb 16, 2017 at 11:46 AM, Juan Carlos Suárez <jcs...@ia...>
wrote:
> Hi!
> Well, at some point, some years ago, it seemed that glob(14) was the Teff
> but maybe it changed since.
> But I am really not sure about the source of this…
>
> OK so MESA in principle does not provide this information, so that we have
> to infer it from the
> photometric radius. If I understood correctly glob(2) is the photometric
> radius, right?
>
> JC
>
>
> On 16 Feb 2017, at 16:57, RICHARD H D TOWNSEND <tow...@as...>
> wrote:
>
> Hi Juan Carlos —
>
> The OSC output routines are based on the description of the OSC file
> format given in the ESTA project:
>
> https://www.astro.up.pt/corot/ntools/docs/CoRoT_ESTA_Files.pdf
>
> According to this document, fields 14 and onwards of glob are not used. Do
> you have an updated description of the OSC file format which indicates
> glob(14) should contain Teff?
>
> cheers,
>
> Rich
>
> On Feb 16, 2017, at 9:54 AM, Juan Carlos Suárez <jcs...@ia...> wrote:
>
> Dear Richard and all,
>
> Thank you very much for your valuable help.
> Now we are able to construct a complete evolutionary track from PMS to
> TAMS (we are indeed interested in
> keeping the PMS models), with around 4K for the number of shells, and
> using the Eddington atmosphere.
> Taking a look to the OSC files, it seems that now everything is OK except
> for the effective temperature (corresponding
> to glob(14) which is now 0.00000 for all the models in the track).
>
> We have used the inlist attached to this email.
>
> JC
>
> On 11 Feb 2017, at 23:17, RICHARD H D TOWNSEND <tow...@as...>
> wrote:
>
> Hi Juan Carlos —
>
> In your email below, I can spot quite a few different problems you’re
> running into. In each case I’ll try to explain what’s going on
>
> On Feb 10, 2017, at 12:26 PM, Juan Carlos Suárez <jcs...@ia...> wrote:
>
> Dear Richard,
>
> We have modified a little bit the previous “inlist” in order to include
> some atmosphere (the default simple atmosphere)
> since we are interested in working with the photosphere radius. So we
> decided to include the following options in the
> inlist (attached)
> ! if true, write atmosphere to pulse files
>
> add_atmosphere_to_pulse_info = .TRUE.
>
>
> Although it’s not the main cause of your problems below, I should mention
> that In MESA 8845 (and previous releases) there is a bug in the atmosphere
> writing routine. The code should output the same atmosphere as selected by
> the ‘which_atm_option’ parameter; however, in many cases (including the
> default ‘simple_photosphere’ atmosphere), the atmosphere written out is
> actually the ‘Paczynski_grey’ atmosphere. This bug is fixed in the
> development version of MESA, but only for a restricted set of atmosphere
> choices:
>
> Eddington_grey
> Paczynski_grey
> solar_Hopf_grey
> Krishna_Swamy
> grey_and_kap
>
> For other atmosphere options the code now halts — because there is
> insufficient information to construct the atmosphere structure.
>
> ! if true, add point for r=0 to pulse files
>
> add_center_point_to_pulse_info = .FALSE.
>
>
> In fact, it’s setting this flag to .FALSE. that ‘fixed’ the problem with
> age and rotation rate being overwritten (as discussed in the previous
> email) — the central second derivative data only gets calculated when
> add_center_point_to_pulse_info = .TRUE. (which itself is a bug — again,
> fixed in the development version)
>
> ! if true, add k=1 cell to pulse files
>
> keep_surface_point_for_pulse_info = .false.
> ! add double points at discontinuities
>
> add_double_points_to_pulse_info = .TRUE.
>
>
> This is what’s causing the (approximate) doubling of the number of points
> in the OSC files. This flag causes MESA to write out a double points when
> it detects a density discontinuity. The threshold for recognizing density
> discontinuities is set by the threshold_dlnrho_for_double_point flag.
> Since this flag defaults to zero, *every* pair of adjacent cells in the
> model is producing a double point!
>
> The fix is to set add_double_points_to_pulse_info = .FALSE., or to
> specify a non-zero value for threshold_dlnrho_for_double_point — e.g., 10.
>
>
> Curiously, it seems that now the problem of the negative ages and rotation
> values is solved, but we
> do not know why.
>
>
> See above!
>
> On the other hand unfortunately the computation halted with an error
>
> failed to open LOGS/profile686.data
> star_finish_step ierr 28
> after_step_loop ierr 28
>
> That is, it halted at model 686, while without the above options MESA
> reached the 905 models with no errors.
>
>
> I imagine the program halted because it ran out of disk space. You are
> writing out a profile *and* an OSC file after each timestep. Each profile
> file is ~15MB, and each OSC file is ~5MB. After 686 models, you have used
> up well over 10 GB of disk space.
>
> To get around this issue, you should consider the following approaches:
>
> *) Don’t set mesh_delta_coeff so small — you use 0.15, which results in
> very high resolution models (some might say over-resolved). 0.5 might be a
> better choice for this parameter.
>
> *) Only write out every N’th profile/OSC file, rather than all of them. To
> do this, set profile_interval = N
>
> *) Don’t bother writing out the pre-MS models, if you don’t need them.
> This can be achieved by doing two separate runs — an initial run with no
> profile/OSC file output, which terminates at the ZAMS. Then, do a restart
> and write out profiles/OSC files as necessary.
>
> In addition to this, with the above options it seems that MESA has doubled
> the number
> of mesh points (from 4K to 8K). Is that what we should expect? The 4K
> additional
> points are located at the atmosphere?
>
>
> No, as I mentioned above, every single model point is being written as a
> double point — not what you want!
>
> So, to sum up:
>
> *) Upgrade to the development version of MESA.
>
> *) Set add_atmosphere_to_pulse_data = .FALSE., or set which_atm_option to
> one of the atmosphere choices listed above.
>
> *) Set add_double_points_to_pulse_data = .FALSE., or specify a non-zero
> value for threshold_dlnrho_for_double_point.
>
> *) Adjust mesh_delta_coeff, set_profile_interval to reduce size of files,
> or run the pre-MS and MS parts separately.
>
> (Note also that some of the parameter names have changed, with the phrase
> ‘pulse_info’ changed to ‘pulse_data’)
>
> Hope that helps!
>
> cheers,
>
> Rich
>
>
> Thanks!
> JC
>
>
> On 9 Feb 2017, at 20:38, Juan Carlos Suárez <jcs...@ia...> wrote:
>
> Yes here it is!
> JC
>
> On 9 Feb 2017, at 20:05, RICHARD H D TOWNSEND <tow...@as...>
> wrote:
>
> Hi Juan —
>
> Can you post the inlist file(s) that you’re using?
>
> Many thanks,
>
> Rich
>
> On Feb 9, 2017, at 12:43 PM, Juan Carlos Suárez <jcs...@ia...> wrote:
>
> Dear colleagues
>
> I am trying to compute a 1.5 Msun evolutionary model (with solar
> metallicity) from PMS to TAMS approx.
> We have set the options to obtain the .OSC files to be read by our
> oscillation codes.
>
> We found that for all the models the age provided has negative values.
>
> Moreover, although no option for rotation was included in the inlist (i.e.
> rotation should be zero)
> we obtain some models with rotation 0 but others with negative non-zero
> values
>
> Any idea?
>
> Thanks in advance!
>
>
> ------------------------------------------------------------
> --------------------------------------------------------
> Dr. Juan Carlos Suárez
> Ramon y Cajal fellow at Física Teórica y del Cosmos Dept. University of
> Granada
> Facultad de Ciencias. 18071. Granada. Spain
> jcs...@ug... | +34 958249056 <+34%20958%2024%2090%2056> |
> www.ugr.es/~fqm292/
> Associate researcher at Stellar Physics Dept. IAA-CSIC
> Glorieta de la Astronomia s/n. 18008. Granada. Spain
> jcs...@ia... | +34 958230619 <+34%20958%2023%2006%2019> | www.iaa.es
> ------------------------------------------------------------
> --------------------------------------------------------
>
>
>
> <inlist_project>
>
>
>
> ------------------------------------------------------------
> --------------------------------------------------------
> Dr. Juan Carlos Suárez
> Ramon y Cajal fellow at Física Teórica y del Cosmos Dept. University of
> Granada
> Facultad de Ciencias. 18071. Granada. Spain
> jcs...@ug... | +34 958249056 <+34%20958%2024%2090%2056> |
> www.ugr.es/~fqm292/
> Associate researcher at Stellar Physics Dept. IAA-CSIC
> Glorieta de la Astronomia s/n. 18008. Granada. Spain
> jcs...@ia... | +34 958230619 <+34%20958%2023%2006%2019> | www.iaa.es
> ------------------------------------------------------------
> --------------------------------------------------------
> <inlist_project>
>
>
>
> ------------------------------------------------------------
> --------------------------------------------------------
> Dr. Juan Carlos Suárez
> Ramon y Cajal fellow at Física Teórica y del Cosmos Dept. University
> of Granada
> Facultad de Ciencias. 18071. Granada. Spain
> jcs...@ug... | +34 958249056 <+34%20958%2024%2090%2056> |
> www.ugr.es/~fqm292/
> Associate researcher at Stellar Physics Dept. IAA-CSIC
> Glorieta de la Astronomia s/n. 18008. Granada. Spain
> jcs...@ia... | +34 958230619 <+34%20958%2023%2006%2019> | www.iaa.es
> ------------------------------------------------------------
> --------------------------------------------------------
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>
--
Martin C.
|
|
From: RICHARD H D T. <tow...@as...> - 2017-02-24 15:26:08
|
Hi Taozhi — The way the pulsation_gyre is currently set up, it doesn’t perform any optimization on the mass, metallicity etc — it just assumes that these parameters are sufficient to get a good match (at some point during the star’s evolution) to the frequencies specified in the inlist_astero_search_controls file. If you alter these frequencies (but don’t otherwise modify the inlist), then it’s unsurprising that you’re not able to get a good match. To fix this, you need to set some parameters in inlist_astero_search_controls. To allow mass and abundances to vary: search_type = ‘simplex' vary_FeH = .true. vary_Y = .true. vary_mass = .true. Also, look at the first_*, min_* and max_* parameters to set the search bounds. cheers, Rich > On Feb 23, 2017, at 4:04 AM, yan...@xa... wrote: > > Hi everyone, > > I want to use the package 'pulsation_gyre' to calculate the frequency of every model, and match a certain frequency, but when I have a try, I find that it always match the final model's frequency when it terminate, for example, in the package /star/test_suit/pulse_gyre, firstly, I have a try to the initial test, it is OK and it can match the frequency (n=0, l=4, frequency=378d0) which is set in the file /src/run_star_extras.f, and it terminate. when I change the frequency to another value (it maybe the previous model's frequency), it will show the bad match for the expected frequency. > > I don't know why is it? Can anyone give me some help, How can I set the parameter? > > Thanks in advance. > Taozhi > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users |
|
From: Manos C. <cha...@ph...> - 2017-02-23 19:32:54
|
Bill, Sure thing! I am excited for the new version. Thanks for all the good work, hope all is well! Manos On 2/23/17 12:03 PM, Bill Paxton wrote: > Hi Manos, > > The release message that went out failed to mention that the ccsn_IIp test case is not yet ready for general use. I'm working on it! And hopefully by the next public release I'll have something for you to try. Until then, hold off please. Good things (sometimes) come to those who wait patiently. ;) > > Thanks, > Bill > > > On Feb 23, 2017, at 9:51 AM, Manos Chatzopoulos wrote: > >> Dear all, >> >> I am having a lot of fun with the new version of MESA! For starters, I >> was trying to run the test_suite problem ccsn_IIp without any changes, >> and I got it to get through shock_part5 and start making a nice shock >> break-out lightcurve, but then before getting into the shock_part6 I got >> the following error: >> >> NOTICE: missing kap data ../../../data/kap_data/IIp_d001_z0.002_x0.74.data >> >> Please check the validity of the kap_prefix string for this file. >> >> If it is okay, you may need to install new kap data. >> To do that, remove the directory mesa/data/kap_data, >> and rerun the mesa ./install script. >> >> File: ../private/load_kap.f90, Line: 304 >> ERROR STOP 1 >> DATE: 2017-02-23 >> TIME: 11:21:59 >> >> ****************************************************************** >> failed to create shock_part6.mod when running inlist_shock_part6_header >> >> Are opacity data files (I assume taken from SEDONA by reading >> run_star_extras.f) like 'IIp_d001_z0.002_x0.74.data' missing from the >> distribution or am I missing something? >> >> Thank you all, >> >> -- >> Dr. Manos Chatzopoulos >> Assistant Professor >> Department of Physics & Astronomy >> Louisiana State University >> Nicholson #275 >> Office # 225-578-2907 >> Baton Rouge, LA 70803 >> United States of America >> http://www.lsu.edu/physics/people/faculty/chatzopoulos.php >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> mesa-users mailing list >> mes...@li... >> https://lists.sourceforge.net/lists/listinfo/mesa-users > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users -- Dr. Manos Chatzopoulos Assistant Professor Department of Physics & Astronomy Louisiana State University Nicholson #275 Office # 225-578-2907 Baton Rouge, LA 70803 United States of America http://www.lsu.edu/physics/people/faculty/chatzopoulos.php |
|
From: Robert F. <rjf...@as...> - 2017-02-23 18:04:30
|
Hi So currently that test case isn't being tested by the test suite (look in do1_test_source in $MESA_DIR/star/test_suite for ones that are tested) so it may or may not work. To get the needed opacities cd $MESA_DIR/kap tar xvf ccsn_opacities.tar.bz2 ./export_ccsn_opacities Rob On Thu, Feb 23, 2017 at 10:51 AM, Manos Chatzopoulos < cha...@ph...> wrote: > Dear all, > > I am having a lot of fun with the new version of MESA! For starters, I > was trying to run the test_suite problem ccsn_IIp without any changes, > and I got it to get through shock_part5 and start making a nice shock > break-out lightcurve, but then before getting into the shock_part6 I got > the following error: > > NOTICE: missing kap data ../../../data/kap_data/IIp_ > d001_z0.002_x0.74.data > > Please check the validity of the kap_prefix string for this file. > > If it is okay, you may need to install new kap data. > To do that, remove the directory mesa/data/kap_data, > and rerun the mesa ./install script. > > File: ../private/load_kap.f90, Line: 304 > ERROR STOP 1 > DATE: 2017-02-23 > TIME: 11:21:59 > > ****************************************************************** > failed to create shock_part6.mod when running inlist_shock_part6_header > > Are opacity data files (I assume taken from SEDONA by reading > run_star_extras.f) like 'IIp_d001_z0.002_x0.74.data' missing from the > distribution or am I missing something? > > Thank you all, > > -- > Dr. Manos Chatzopoulos > Assistant Professor > Department of Physics & Astronomy > Louisiana State University > Nicholson #275 > Office # 225-578-2907 > Baton Rouge, LA 70803 > United States of America > http://www.lsu.edu/physics/people/faculty/chatzopoulos.php > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users > |
|
From: Bill P. <pa...@ki...> - 2017-02-23 18:03:56
|
Hi Manos, The release message that went out failed to mention that the ccsn_IIp test case is not yet ready for general use. I'm working on it! And hopefully by the next public release I'll have something for you to try. Until then, hold off please. Good things (sometimes) come to those who wait patiently. ;) Thanks, Bill On Feb 23, 2017, at 9:51 AM, Manos Chatzopoulos wrote: > Dear all, > > I am having a lot of fun with the new version of MESA! For starters, I > was trying to run the test_suite problem ccsn_IIp without any changes, > and I got it to get through shock_part5 and start making a nice shock > break-out lightcurve, but then before getting into the shock_part6 I got > the following error: > > NOTICE: missing kap data ../../../data/kap_data/IIp_d001_z0.002_x0.74.data > > Please check the validity of the kap_prefix string for this file. > > If it is okay, you may need to install new kap data. > To do that, remove the directory mesa/data/kap_data, > and rerun the mesa ./install script. > > File: ../private/load_kap.f90, Line: 304 > ERROR STOP 1 > DATE: 2017-02-23 > TIME: 11:21:59 > > ****************************************************************** > failed to create shock_part6.mod when running inlist_shock_part6_header > > Are opacity data files (I assume taken from SEDONA by reading > run_star_extras.f) like 'IIp_d001_z0.002_x0.74.data' missing from the > distribution or am I missing something? > > Thank you all, > > -- > Dr. Manos Chatzopoulos > Assistant Professor > Department of Physics & Astronomy > Louisiana State University > Nicholson #275 > Office # 225-578-2907 > Baton Rouge, LA 70803 > United States of America > http://www.lsu.edu/physics/people/faculty/chatzopoulos.php > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users |
|
From: Manos C. <cha...@ph...> - 2017-02-23 17:49:54
|
Dear all, I am having a lot of fun with the new version of MESA! For starters, I was trying to run the test_suite problem ccsn_IIp without any changes, and I got it to get through shock_part5 and start making a nice shock break-out lightcurve, but then before getting into the shock_part6 I got the following error: NOTICE: missing kap data ../../../data/kap_data/IIp_d001_z0.002_x0.74.data Please check the validity of the kap_prefix string for this file. If it is okay, you may need to install new kap data. To do that, remove the directory mesa/data/kap_data, and rerun the mesa ./install script. File: ../private/load_kap.f90, Line: 304 ERROR STOP 1 DATE: 2017-02-23 TIME: 11:21:59 ****************************************************************** failed to create shock_part6.mod when running inlist_shock_part6_header Are opacity data files (I assume taken from SEDONA by reading run_star_extras.f) like 'IIp_d001_z0.002_x0.74.data' missing from the distribution or am I missing something? Thank you all, -- Dr. Manos Chatzopoulos Assistant Professor Department of Physics & Astronomy Louisiana State University Nicholson #275 Office # 225-578-2907 Baton Rouge, LA 70803 United States of America http://www.lsu.edu/physics/people/faculty/chatzopoulos.php |
|
From: <yan...@xa...> - 2017-02-23 10:23:09
|
Hi everyone, I want to use the package 'pulsation_gyre' to calculate the frequency of every model, and match a certain frequency, but when I have a try, I find that it always match the final model's frequency when it terminate, for example, in the package /star/test_suit/pulse_gyre, firstly, I have a try to the initial test, it is OK and it can match the frequency (n=0, l=4, frequency=378d0) which is set in the file /src/run_star_extras.f, and it terminate. when I change the frequency to another value (it maybe the previous model's frequency), it will show the bad match for the expected frequency. I don't know why is it? Can anyone give me some help, How can I set the parameter? Thanks in advance. Taozhi |
|
From: Evan B. <eb...@ph...> - 2017-02-22 23:33:16
|
Hi Everyone, I noticed one minor change that didn’t quite make its way into the release notes, but is probably worth warning everyone about. The default profile_columns.list has been modified to save only a bare minimum of essential information. All the same information is still available if you want to access it, but almost none of the columns are turned on by default anymore. If you take a look in star/defaults/profile_columns.list, you’ll see ! minimal set of enabled columns: zone ! numbers start with 1 at the surface mass ! m/Msun. mass coordinate of outer boundary of cell. logR ! log10(radius/Rsun) at outer boundary of zone logT ! log10(temperature) at center of zone logRho ! log10(density) at center of zone logP ! log10(pressure) at center of zone x_mass_fraction_H y_mass_fraction_He z_mass_fraction_metals This has the advantage of greatly reducing disk space taken up by profile.data files, but it means that you’ll have to be more careful to consciously add quantities you want to track to your profile_columns.list. It may be a good idea to keep a copy of your own custom profile_columns.list that tracks columns you care about in your typical usage. For example, I care a lot about abundances for my work with diffusion, so I keep a copy of profile_columns.list that (among other things) uncomments add_abundances ! this adds all of the isos that are in the current net As long as I remember to include this custom profile_columns.list file in my working directories, I get abundance info for every isotope in my network in every profile.data file. But unlike previous MESA release versions, I won’t get this info by default. Cheers, Evan > On Feb 17, 2017, at 10:38 AM, RICHARD H D TOWNSEND <tow...@as...> wrote: > > Dear MESA Community, > > It is our great pleasure to announce MESA public release version 9575. > There are a number of changes we'd like to bring to your attention; > please see the release notes below. > > Best wishes, > > Rich (on behalf of Rob, Josiah, Evan, Aaron, Frank and Bill) > > MESA 9575 - Release Notes > ========================= > > Opacities > --------- > > The kap module has been modified to make it easier to incorporate > alternative opacity tables, while preserving the normal behavior of > the default tables. The modifications come in 2 basic forms: > > 1) the naming convention for opacity table files has been streamlined > so that all X and Z values are now consistently written across all > different types of tables. > > 2) the input X and Z values required by the kap module are no longer > hard-coded in kap_def; they are now read from a configuration file > that is (optionally) read at run time. The number of X and Z values > are set in the file, along with the numbers Xs for each Z, and the > actual X and Z values. This is accomplished through the star_job > inlist through 'kappa_config_file'. > > These changes should be completely transparent to users of the > standard kap tables. No changes have been made to the OP monochromatic > opacities either. > > For users who update their mesa install through svn, kap_data will > need to be reinstalled after the update. > > Pulsation > --------- > > *) Fixed code that adds atmosphere data to pulsation output files (as > enabled by add_atmosphere_to_pulse_data). Previously, this code only > worked correctly for the four atmosphere choices that perform a T-Tau > integration: ‘Eddington_grey’, ‘Krishna_Swamy’, ‘solar_Hopf_grey’ and > ‘Pacznski_grey’. In other cases, the code silently added on a > ‘Paczynski_grey’ atmosphere instead of what was requested; typically, > this led to density/temperature discontinuities at the transition > between atmosphere and interior. In the fixed code, along with the > four T-tau cases, the ‘simple_photosphere’ and ‘grey_and_kap’ options > now function as they should; while the remaining options (e.g., > ‘photosphere_tables’) cause MESA to terminate with a message > indicating that an atmosphere cannot be added. > > *) Fixed the headers written to FGONG- and OSC-format pulsation output > files; previously, some of the fields (e.g., stellar age) were being > incorrectly set up. > > *) MESA can now write pulsation output files that include > composition/density discontinuities (in fact, this capability was > present in release 8845, but undocumented). When a density > discontinuity is detected in a model (see below for more details on > how this is done), and the control flag > ‘add_double_point_to_pulse_data’ is .TRUE. MESA writes a double point > to the output file, containing the model values on either side of the > discontinuity. Double points can easily be recognized in the file > because they share the same radial (r) and mass (M_r) coordinate > values. Recent releases of the GYRE pulsation code (5.0 onward) > correctly treat double points by applying appropriate jump conditions > in the pulsation equations. > > To control what MESA considers to be a density discontinuity, use the > ‘threshold_grad_mu_for_double_point’ control. Cell faces where > |grad_mu| = |d(ln mu)/d(ln P)| rises above this threshold are treated > as density discontinuities. A typical threshold value might be > somewhere in the range 1-10. To avoid having *too* many double points > created, you can set an upper limit on the number using the > ‘max_number_of_double_points’ control. > > *) MESA by default now uses the ‘wide’ (version >= 1000) format when > writing FGONG pulsation output files. This format was formalized > during the 2015 Aarhus RGB Workshop in Birmingham, England. > > *) Some of the pulsation output parameters have been renamed, as > follows: > > save_pulsation_info_for_model_number -> save_pulse_data_for_model_number > save_pulsation_info_when_terminate -> save_pulse_data_when_terminate > save_pulsation_info_filename -> save_pulse_data_filename > write_pulse_info_with_profile -> write_pulse_data_with_profile > pulse_info_format -> pulse_data_format > add_atmosphere_to_pulse_info -> add_atmosphere_to_pulse_data > add_center_point_to_pulse_info -> add_center_point_to_pulse_data > keep_surface_point_for_pulse_info -> keep_surface_point_for_pulse_data > add_double_points_to_pulse_info -> add_double_points_to_pulse_data > > *) Fixed incorrect filename when using write_gyre_for_best_model > > Accretion > --------- > > Accretion with small timesteps has been improved, using a patch and > test case provided by Dean Townsley. Here is his commentary: > > "The attached adjust_mass.f90 has some fixes for accretion with small > timesteps when the mass added in the step is similar to the mass of > the outer zone. In the current code (I tested 8845), if the material > being added is not the same abundance as the surface already there, > the individual species accretion rates are wrong and the profiles get > messed up as well. See the attached plots of h1 mass and the h1 > profile after about 50 steps into adding mass. The test here is just > taking the current "wd" accretion test, setting the initial timestep > so that the initial added mass in a timestep is about half that in the > outer zone, and changing to helium-rich accreted material, though any > abundance different from what is already there will do. Updates to > adjust_mass.f90 seem to fix things. > > The main issues were: > > - dm(k) was being used after revise_q_and_dq() was called but was not > actually updated. it is now updated with the dq's. > > - the renorming of the dq's after the constant dm / constant dq > boundary determination was done in a way that suffered from > truncation problems when the the constant dq region is small. This > caused the mass added in various species to be off (too small). As > you can see in the plots, the H mass could actually decrease even > when accreting material with H in it! > > - there was some code in there that seemed to be trying to fix this by > rescaling abundances to match expectations in layers near the > surface, but due to the need to keep abundances to sum to 1 and the > fact that all the accreted masses were off in the same direction, > this distorted the abundance profile instead of fixing the > problem. (see the second set of plots) I have disabled this code now > that the underlying problem appears to be fixed. > > - there was a minor error in the way the abundance was computed for > partially accreted cells. This doesn't seem to have been having a > major impact. > > In fixing the second of these issues related to truncation, I > refactored the revise_q_and_dq() to work in 1-q instead of q > coordinates to reduce truncation issues. The logic is otherwise the > same, just with 1-q as the coordinate. > > I have also included a new test suite test to check for these issues. > This test reports failure for the current release (8845) but success > with the adjust_mass.f90 changes attached here. While this test could > be done at the start of the "wd" test, starting from small timesteps > takes around 1200 steps which is a fair bit more than the current "wd" > test, which takes around 400. Also it's a bit more clear to just test > it separately." > > Miscellaneous > ------------- > > *) Added new pgstar plot production_plots which show the relative > change in the abundances against the initial composition. > > *) pgstar plots can now be used while mesa is using one of the relax > routines to "relax" the model to a new state. > > *) makefiles will now warn the user if $MESA_DIR variable is not set, > or if using the SDK makefile (the default) if the SDK has not been > initialized. > > *) Cache files will now be written to the current working directory > before being moved to the $MESA_DIR/data folder. This will stop > multiple mesa runs, running simultaneously, from over writing the > cache files leaving them in a inconsistent state. This should help > those running MESA on clusters or otherwise running more than 1 mesa > job at a time. > > *) A new file $MESA_DIR/star/defaults/env_vars.list has been added > which describes the environment variables MESA uses as well as few > miscellaneous options. > > *) fixed a bug in the color code that prevents the use of more than > one bolometric correction file. In previous versions of MESA, when > using bc’s from a second or subsequent file, the wrong column is > returned. > > *) Add test_suite case (custom_rate_c14ago18) exercising custom > rate. This test case provides an example of how to set up and use one > of your own reaction rates in MESA. Physically, it is a WD slowly > accreting He (with some N14, which has electron-captured to C14 at > the base of the He layer). It illustrates the effect of the > c14(a,g)o18 rate on the ignition of the He. The custom rate is that > from Hashimoto et al. (1986) and is compared to the default "reaclib" > rate that ships with MESA. > > *) MESA now strictly respects max_timestep control. Previously, if you > loaded a model that has a stored timestep greater than the requested > max_timestep, the timestep would remain above the limit for several > steps (since it could only shrink so much per step). > > *) Fixed check_for_redo_MLT by using mlt_mixing_type, so that it now > functions as documented. > > *) Tweak convective zone boundary mesh controls, changing the effect > of the convective zone boundary mesh controls xtra_coef_*_*_*_czb > (hereafter "coef") and xtra_dist_*_*_*_czb (hereafter, > "dist"). Previously, the meshing was adjusted by setting the value of > delta_gval_max to be a linear blend between coef at the boundary and > 1.0 over a length dist * Hp (measured from the boundary). > > If you try to increase the resolution near the convective boundary by > a significant factor, the linear blend means that delta_gval_max is > only near the specified value of coef for a distance away from the > boundary of order coef * dist. So in practice, MESA increases the > resolution over a significantly smaller region than you might expect. > > To fix this, the form of the blend is now a piecewise linear form > that guarantees that delta_gval_max is near coef for at least half of > dist. > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users |
|
From: Frank T. <fx...@ma...> - 2017-02-21 20:56:30
|
if you have developed a run_star_extras.f file for your models, please reply to aaron dotter and/or frank timmes. we’re developing a new vehicle for aggregating the mesa community’s software development efforts. we want to include your contributions and give you credit for your work! aaron and frank |
|
From: chenhl <chl...@gm...> - 2017-02-21 12:58:11
|
oh, yes, it works. Thanks. Best wishes, Hailiang On Tue, Feb 21, 2017 at 11:24 AM, Frank Timmes <fx...@ma...> wrote: > have you tried using a negative value? > it appears star/private/evolve.f90 does not care > about the sign of a non-zero inject_uniform_extra_heat. > > fxt > > > > > On Feb 20, 2017, at 9:52 PM, chenhl <chl...@gm...> wrote: > > > > Dear all, > > > > How can I artificially remove some energy from the envelope of a star? > > > > In the control list, 'inject_uniform_extra_heat' can be used to > > add extra heat to cells in range min_q_for_uniform_extra_heat to max. > > What I want to do is to remove extra heat from cells in range > > min_q_for_uniform_extra_heat to max. > > > > Is there anyone have experience on this? Thanks for help. > > > > > > > > Best wishes, > > Hailiang > > > > > > > > ------------------------------------------------------------ > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, SlashDot.org! http://sdm.link/slashdot______ > _________________________________________ > > mesa-users mailing list > > mes...@li... > > https://lists.sourceforge.net/lists/listinfo/mesa-users > > |
|
From: Frank T. <fx...@ma...> - 2017-02-21 03:24:32
|
have you tried using a negative value? it appears star/private/evolve.f90 does not care about the sign of a non-zero inject_uniform_extra_heat. fxt > On Feb 20, 2017, at 9:52 PM, chenhl <chl...@gm...> wrote: > > Dear all, > > How can I artificially remove some energy from the envelope of a star? > > In the control list, 'inject_uniform_extra_heat' can be used to > add extra heat to cells in range min_q_for_uniform_extra_heat to max. > What I want to do is to remove extra heat from cells in range > min_q_for_uniform_extra_heat to max. > > Is there anyone have experience on this? Thanks for help. > > > > Best wishes, > Hailiang > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users |
|
From: chenhl <chl...@gm...> - 2017-02-21 02:52:26
|
Dear all, How can I artificially remove some energy from the envelope of a star? In the control list, 'inject_uniform_extra_heat' can be used to add extra heat to cells in range min_q_for_uniform_extra_heat to max. What I want to do is to remove extra heat from cells in range min_q_for_uniform_extra_heat to max. Is there anyone have experience on this? Thanks for help. Best wishes, Hailiang |
|
From: Dennis S. <den...@sy...> - 2017-02-20 23:49:09
|
worked for me just now as well. Dennis/ On 21/02/17 7:19 AM, Frank Timmes wrote: > might also be location dependent. > i just downloaded v6950 via the phoenix airport wifi. > > fxt > > > >> On Feb 20, 2017, at 1:05 PM, RICHARD H D TOWNSEND<tow...@as...> wrote: >> >> >>> On Feb 20, 2017, at 2:59 AM, Dennis Stello<den...@sy...> wrote: >>> >>> Hi, >>> >>> I have tried repeatedly today to get v6950 with svn, and get a very similar looking error message. >>> >>> For how long can it be down? >>> >>> Dennis/ >>> >> As long as it wants — we have no control over Sourceforge. >> >>> On 20/02/17 12:23 PM, Robert Farmer wrote: >>>> Hi >>>> >>>> Sourecforge has hosting issues every so often, normally all you need to do is wait an hour or so and try again >>>> >>>> Rob >>>> >>>> On Sun, Feb 19, 2017 at 6:17 PM, Willie Strickland<cw...@gm...> wrote: >>>> I am getting the following error when trying to svn. Anyone else seeing this? >>>> >>>> svn: E170013: Unable to connect to a repository at URL 'svn://svn.code.sf.net/p/mesa/code/trunk' >>>> svn: E000061: Can't connect to host 'svn.code.sf.net': Connection refused >>>> >>>> The download worked fine. >>>> >>>> Willie >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, SlashDot.org!http://sdm.link/slashdot >>>> _______________________________________________ >>>> mesa-users mailing list >>>> mes...@li... >>>> https://lists.sourceforge.net/lists/listinfo/mesa-users >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, SlashDot.org! >>>> http://sdm.link/slashdot >>>> >>>> >>>> _______________________________________________ >>>> mesa-users mailing list >>>> >>>> mes...@li... >>>> https://lists.sourceforge.net/lists/listinfo/mesa-users >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org!http://sdm.link/slashdot_______________________________________________ >>> mesa-users mailing list >>> mes...@li... >>> https://lists.sourceforge.net/lists/listinfo/mesa-users >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org!http://sdm.link/slashdot >> _______________________________________________ >> mesa-users mailing list >> mes...@li... >> https://lists.sourceforge.net/lists/listinfo/mesa-users > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org!http://sdm.link/slashdot > _______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users |
|
From: Frank T. <fx...@ma...> - 2017-02-20 20:19:24
|
might also be location dependent. i just downloaded v6950 via the phoenix airport wifi. fxt > On Feb 20, 2017, at 1:05 PM, RICHARD H D TOWNSEND <tow...@as...> wrote: > > >> On Feb 20, 2017, at 2:59 AM, Dennis Stello <den...@sy...> wrote: >> >> Hi, >> >> I have tried repeatedly today to get v6950 with svn, and get a very similar looking error message. >> >> For how long can it be down? >> >> Dennis/ >> > > As long as it wants — we have no control over Sourceforge. > >> On 20/02/17 12:23 PM, Robert Farmer wrote: >>> Hi >>> >>> Sourecforge has hosting issues every so often, normally all you need to do is wait an hour or so and try again >>> >>> Rob >>> >>> On Sun, Feb 19, 2017 at 6:17 PM, Willie Strickland <cw...@gm...> wrote: >>> I am getting the following error when trying to svn. Anyone else seeing this? >>> >>> svn: E170013: Unable to connect to a repository at URL 'svn://svn.code.sf.net/p/mesa/code/trunk' >>> svn: E000061: Can't connect to host 'svn.code.sf.net': Connection refused >>> >>> The download worked fine. >>> >>> Willie >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> mesa-users mailing list >>> mes...@li... >>> https://lists.sourceforge.net/lists/listinfo/mesa-users >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! >>> http://sdm.link/slashdot >>> >>> >>> _______________________________________________ >>> mesa-users mailing list >>> >>> mes...@li... >>> https://lists.sourceforge.net/lists/listinfo/mesa-users >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________ >> mesa-users mailing list >> mes...@li... >> https://lists.sourceforge.net/lists/listinfo/mesa-users > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > mesa-users mailing list > mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa-users |
|
From: RICHARD H D T. <tow...@as...> - 2017-02-20 20:05:13
|
> On Feb 20, 2017, at 2:59 AM, Dennis Stello <den...@sy...> wrote: > > Hi, > > I have tried repeatedly today to get v6950 with svn, and get a very similar looking error message. > > For how long can it be down? > > Dennis/ > As long as it wants — we have no control over Sourceforge. > On 20/02/17 12:23 PM, Robert Farmer wrote: >> Hi >> >> Sourecforge has hosting issues every so often, normally all you need to do is wait an hour or so and try again >> >> Rob >> >> On Sun, Feb 19, 2017 at 6:17 PM, Willie Strickland <cw...@gm...> wrote: >> I am getting the following error when trying to svn. Anyone else seeing this? >> >> svn: E170013: Unable to connect to a repository at URL 'svn://svn.code.sf.net/p/mesa/code/trunk' >> svn: E000061: Can't connect to host 'svn.code.sf.net': Connection refused >> >> The download worked fine. >> >> Willie >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> mesa-users mailing list >> mes...@li... >> https://lists.sourceforge.net/lists/listinfo/mesa-users >> >> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! >> http://sdm.link/slashdot >> >> >> _______________________________________________ >> mesa-users mailing list >> >> mes...@li... >> https://lists.sourceforge.net/lists/listinfo/mesa-users > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________ > 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.
