Add alternative stellar yield tables

[abensonca]

Given that there are no strong constraints on the best yield tables to use it would make sense to have a few different options for these so that we can explore the variations resulting from modeling uncertainties.

This is relatively simple to do as we would just need to create different files containing the yields etc. for different models.

[abensonca]

From James Johnson:

For massive stars, Limongi & Chieffi (2018) looked at yields at log10(Z / Zsun) = -3, -2, -1, and 0 at initial rotational velocities of v_rot = 0, 150, and 300 km/s. If you're looking for yields from the literature that go down to [Fe/H] ~ -3, I'd start there. The one caution with Limongi & Chieffi (2018) is that they have a simplified prescription for which massive stars explode (everything above 25 Msun collapses to a black hole). They've also got a relatively sparse mass grid. For those reasons I'd also look into Sukhbold et al.'s (2016) yields, which have a much more realistic prescription for stellar explodability and a much denser grid of ZAMS masses, but there you're limited to solar metallicity and non-rotating progenitors.

For SN Ia yields, the papers I'm most familiar with are Iwamoto et al. (1999), Seitenzahl et al. (2013), and the 2021/2022 series from Sabrina Gronow. Classically, people assume that SN Ia yields don't depend on the metallicity of the progenitor population. The Gronow et al. series would argue the contrary -- that the changes in WD composition with metallicity affect the structure enough to impact yields, though as far as I can tell, they had to fix the Fe yields in their models to do the calculations, so it's hard to do much quantitatively with their results. Last fall, I wrote a paper with Chris Kochanek and Kris Stanek at OSU arguing that the metallicity dependence of the close binary fraction should produce more Ia's at low Z (with a ~Z^(-1/2) dependence), and that the implied rates as a function of mass line up with what's seen in, e.g., ASAS-SN and DES.

[abensonca]

Also, for the stellarAstrophysicsFile class we should process XInclude elements in the XML file so that it would be simple to combine different tables of yields etc. as needed. It then might make sense to take the different datasets currently compiled into the static/stellarAstrophysics/Stellar_Properties_Compilation.xml file and separate them so that they can be combined as needed.

[abensonca]

Also from James Johnson:

I'd also advocate for implementing a separate mode of chemical enrichment in which the user specifies (for each enrichment channel, e.g., CCSNe, SNe Ia) a yield for each element, which may vary with metallicity Z of the stellar pops, and a delay-time distribution. A lot of abundance modelers, myself included, are starting to move beyond tables from stellar models as the only option for parameterizing yields. That's primarily driven by the low number of stellar nucleosynthesis models available in the literature, and the models that do exist are quite rife with uncertainties to boot.

[abensonca]

Also, for the stellarAstrophysicsFile class we should process XInclude elements in the XML file so that it would be simple to combine different tables of yields etc. as needed. It then might make sense to take the different datasets currently compiled into the static/stellarAstrophysics/Stellar_Properties_Compilation.xml file and separate them so that they can be combined as needed.

This is actually already implemented - the XML_Parse() function handles this for us. So, we'd just need to split this file into components and replace is with one that XIncludes all of those components.

[abensonca]

From James Johnson on Ia delay times:

Our most direct measurements come from comparisons of the cosmic star formation history with volumetric event rates as a function of redshift - Maoz & Mannucci (2012) is a highly cited article doing that. Even then, they get measurements in only three bins of delay-time with sizable errors. My understanding is that the cosmic SFH is the more poorly constrained of the two, but both carry substantial uncertainties.

[abensonca]

The stellar properties file is now split into individual files, seperated by source (i.e. Heger & Woosley 2002 in one file, Marigo et al. 2001 in another, etc.). The standard compilation of stellar properties is now simply a file that uses XInclude to combine these separate files. This allows for more flexibility in combining different sets of stellar property models as needed.