[newchem-cpp] introduce GrainMetalInjectPathways type

[mabruzzo]

To be reviewed after PRs #461 and #462 are reviewed

---

Overview

The central premise of this PR is to adjust the way that we organize and load the data for the injection pathways.

Important

This PR is a LOT smaller than it looks:

• first, it builds on a bunch of other PRs
• second, 3800 lines holds tables of data (more on that below). I was EXTREMELY careful about reorganizing this data; I scripted the process and performed lots of manual checks.

In any case, this PR suffered significant scope creep. My apologies if that makes the PR difficult to remove

Summary of Changes

The main focus was introducing the GrainMetalInjectPathways type. It's used to hold the tables of data for each injection pathway. A few items worth mentioning:

• I use the term "injection pathway" rather than something like "Supernova model" because our model includes Local ISM properties.
• From a code organization perspective, I would ideally like to treat the injection pathway machinery as part of the multi-grain dust modelling machinery. But, until we address Issue [newchem-cpp] Metal Chemistry Shouldn't Require SNe Yields #446, the Injection pathway data always needs to be loaded to use metal chemistry (even if dust chemistry is disabled). In the short-term, I have partitioned the code into a distinct subdirectory.

I had to do a LOT of digging through the multi-grain species dust code so that I could appropriately document things. When I did this, I made a point of leaving a LOT of clarifying comments.

HDF5 Reading: Can't be implemented yet.

This PR doesn't include the machinery for loading the injection data from an external hdf5 file, yet. I REALLY think this is the direction we need to go in, but I wanted to cut my losses for the moment.

Essentially, we need to do two things before we do this (so that we can minimize the number of times we regenerate the HDF5 files).

1. We need to finalize the names of the dust species. I'll open a separate issue to discuss this more.

2. Currently we explicitly track 3 kinds of yields for a given injection pathway:

   1. total amounts of a metal nuclide (e.g. C, O, ...) injected
   2. the amount of a metal nuclide injected in the gas phase, alone
   3. Separately, we also track the yields of individual grain species.

   Under Grackle's current implementation,¹ the second kind of yield is subtracted from the first to determine the total amount of a given metal nuclide that is injected in dust grains. But, we should be able to compute quantity using the third kinds of yields. Basically I want to avoid tracking the first kind of data in the HDF5 files (to simplify some parsing and the structure of the files).

For now, I altered the formatting of the hardcoded data to make the code that loads the information more legible and so we could structure that code in a manner consistent with how it will look when we start reading HDF5 files. I need to make a point of posting my python scripts for generating the HDF5 files.

Other Thoughts

There's still stuff to follow up on here. I have a lot of thoughts. One thing we need to do is make it possible to query the relevant rate information through the dynamic rate-access API. I'll edit this section if I have time.

Footnotes

1. Issues [newchem-cpp] Metal Chemistry Shouldn't Require SNe Yields #446 and [newchem-cpp] make_consistent seems totally wrong for grain growth or destruction #460 highlight that the consistency enforcement should change, but that doesn't really change my point. ↩