You can subscribe to this list here.
2004 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(5) 
_{Oct}
(3) 
_{Nov}

_{Dec}
(1) 

2005 
_{Jan}

_{Feb}
(3) 
_{Mar}

_{Apr}
(1) 
_{May}

_{Jun}

_{Jul}

_{Aug}
(4) 
_{Sep}
(1) 
_{Oct}

_{Nov}
(1) 
_{Dec}
(3) 
2006 
_{Jan}
(3) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(2) 
2007 
_{Jan}
(3) 
_{Feb}

_{Mar}

_{Apr}
(1) 
_{May}

_{Jun}
(2) 
_{Jul}
(2) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2008 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(4) 
_{Jul}
(4) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}
(4) 
_{Dec}
(2) 
2009 
_{Jan}
(2) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2010 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(1) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2011 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(1) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2012 
_{Jan}

_{Feb}

_{Mar}
(4) 
_{Apr}
(12) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1

2
(1) 
3

4

5

6

7

8

9

10

11

12

13

14
(2) 
15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

From: Alan W. Irwin <irwin@be...>  20051214 21:14:28

On 20051214 17:48+0100 Ana Palacios wrote: > > Hello, > > I intend to use the free_eos in a stellar evolution code, and I have some > concerns about the chemicals. > In my code, I only treat species up to Cl, and then, I use a fake "heavy" > element to account for the rest of the nuclides. In free_eos you include > A, Ca, Ti, Cr, Mn, Fe, Ni, all nuclides that I don't follow in details. > How should I account for them ? > Shall I decompose my "heavy" fake element into the sum of each of these > elements, and if then, what proportions should I use (solar scaling?) ? Ana, that is a good question that is not asked enough. I believe the best course here is to assume an initial set of the 20 elemental abundances treated by FreeEOS. For example, you could start with solar abundances for all elements. Then, you could keep direct track of the effects of your reaction network on those abundances. I am completely inexperienced at nucleosynthesis calculations, but I assume for a given time step you would get a change in number for certain isotopes and other isotopes outside your network would have unchanged numbers for the particular reaction network you have chosen to follow.. FreeEOS does not treat isotopes and instead depends only on the epsilon form (see below for a definition) for the total abundance by element. However, it turns out that the sum of the epsilon values for each isotope of each element is an excellent approximation for the epsilon value to adopt for the total abundance of each element. Also, note that even the total epsilon values of elements unaffected by nuclear burning will be changed by this "best" procedure since the normalization conditions are affected by mass and mass is being converted to energy by the nucleosynthesis. My impression is this "best" approach is rarely followed. The assumption seems to be the details of the Z mix and indeed the effect on abundance of the conversion of matter to energy don't matter much for EOS calculations. However, my view is that assumption needs to be tested for whatever your particular needs are. (Obviously, calculations predicting solar acoustical frequencies would have much higher precision standards than calculations predicting say just radius and luminosity.) Thus, I feel the "best" approach for the calculation of abundances should always be programmed as an option (FreeEOS allows you to do this) with which to test the more traditional abundance transformation treatments (FreeEOS allows you to do those as well since individual epsilon values can be approximated as constant or even artifically be forced to zero throughout an evolutionary track). I would now like to turn to a related topic, the transformation of abundances. The fewer elements that are treated in any EOS calculations (including FreeEOS calculations where you reduce the number of abundances be setting a subset of the epsilon values to 0.) the less computer time is required for that calculation but also the less realistic the results will be. So over the years a number of approximation schemes have been used to simplify the abundance mix used for EOS calculations while reducing the damaging effects of the abundance transformation approximation as much as possible. Here is one such possible scheme based on my memory an idea from Fritz Swenson. (I have just developed this now for this email and never tried it so you should check my results.) It is straightforward to show that for the fully ionized case, the EOS results depend on various weighted sums over the epsilon form of the abundance vector (see equation 5 in Paper II linked from http://freeeos.sourceforge.net/documentation.html for a definition of the epsilon form of abundance. Note it is not identical to either the traditional abundance by weight or abundance by number although it is a renormalization of the latter.) For completely ionized conditions it follows from the equations in my Papers I through IV (see above URL for links to those) that P_gas = R rho T sum_0 + P_e(eta, T) + P_C(sum_0, sum_2, eta, rho, T) + P_x(eta, rho, T) where R is the gas constant, rho and T are the density and temperature, P_C and P_x are corrections for the nonideal Coulomb and exchange effects, P_e is the electron pressure, eta is the degeneracy parameter determined by n_e(eta,T) = N_A rho sum_1 N_a is Avogadro's number, and sum_0 = sum_i eps_i, sum_1 = sum_i eps_i Z_i, and sum_2 = sum_i eps_i (Z_i)^2. Thus, if you transform abundances in a way that preserves sum_0, sum_1, and sum_2, then I believe errors from this transformation should be zero for the fully ionized case and (hopefully) small for the partially ionized case. If memory serves, Fritz used three "artificial" elements to achieve this preservation. For your own case where you have only one "artificial" element, then you are only allowed to preserve one of these sums and your abundance transformation errors should be higher then in the above transformation scheme. However, I have never tried such abundance transformations myself so this is something you should experiment with using FreeEOS (which is a nice tool for such test comparisons). Of course, such experiements should also include a comparison with the "best" approach I outlined above. By the way, I (in colloboration with Santi Cassisi and possibly others) also intend to explore these abundance transformation issues when dealing with the problem of interpolating tabulated FreeEOS results by abundance. (See Dorman, Irwin, and Pedersen, 1991 Ap.J 381,228 for an initial look at this problem.) Obviously, if you interpolate in all 20 abundances, the tables become massive and the intepolation becomes quite slow, so the course we employed in the 1991 work was to assume no change in Z mix for EOS tables. But that abundance simplification introduces an additional error. I don't claim (yet) that that error is important, but it does need to be investigated. Ana, I hope this discussion of abundance issues for EOS calculations has been of some help to you. Alan __________________________ Alan W. Irwin email: irwin@... phone: 2507272902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equationofstate implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick frontend to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linuxpowered Science __________________________ 
From: Ana Palacios <apalacio@ce...>  20051214 16:48:54

Hello, I intend to use the free_eos in a stellar evolution code, and I have some concerns about the chemicals. In my code, I only treat species up to Cl, and then, I use a fake "heavy" element to account for the rest of the nuclides. In free_eos you include A, Ca, Ti, Cr, Mn, Fe, Ni, all nuclides that I don't follow in details. How should I account for them ? Shall I decompose my "heavy" fake element into the sum of each of these elements, and if then, what proportions should I use (solar scaling?) ? Do you have any suggestion ? Thanks for your help, Ana ================================================================================ Dr Ana Palacios CEA/DSM/DAPNIA/Service d'Astrophysique Phone: + 33 (0)1 69 08 92 64 Centre de Saclay  l'Orme des Merisiers bat709 Fax : + 33 (0)1 69 08 65 77 F91191 GifsurYvette Cedex Email: ana.palacios@... ================================================================================ 
From: Alan W. Irwin <irwin@be...>  20051202 07:42:16

On 20051115 14:430800 Alan W. Irwin wrote: > [...] So with that background, the first two parts of the plan are to reorganize > the FreeEOS iterations to combine the inner and outer iterations and provide > an alternative BFGS convergence technique when the combined NewtonRaphson > technique fails to converge. The first change should give a factor of ~ 3 > improvement in speed for kif = 1 and 2 (but not kif = 0). > [...] The current status is I almost have the first part of the plan completed for > the kif = 2 case. The previous free_eos_detailed code has large sections of > code moved to additional subroutines that it now calls. Furthermore, the > free_eos_detailed code has been completely reorganized. However, when I > tried the revised kif = 2 code this morning for the first time, there were > obviously some introduced bugs that will need to be sorted out. Here is an update on the status of the recent FreeEOS development effort. That debugging effort for the kif=2 case was long and difficult. First, I discovered and fixed some longstanding bugs which gave poor starting values for the FreeEOS iteration procedure and which were obfuscating some of my test results. Those bugs also affected the reliability of convergence of the previously released versions of FreeEOS, but not the results when convergence was obtained. Second, the code reorganization also created some bugs of its own. However, I think I have those fixed now, and, for example, my comprehensive numerical tests of the new combined NewtonRaphson technique gave excellent results for the first time today for the kif=2 case. I am pleased at this large step forward, but substantially more work is needed to consolidate the gain by implementing the kif=1 combined NewtonRaphson case, implementing the BFGS technique for use when the combined NewtonRaphson technique (either kif=0, 1, or 2) fails to converge, and comprehensively testing the new convergence code (once completed) by doing FreeEOS calculations for a wide variety of option suites and physical conditions. Once all that is done, I plan to release the revised code as FreeEOS1.7.0. With luck, my next post to the freeeosgeneral list will be the FreeEOS1.7.0 release announcement rather than another status report. Alan __________________________ Alan W. Irwin email: irwin@... phone: 2507272902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equationofstate implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick frontend to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linuxpowered Science __________________________ 