Context for this PR: I don't remember what the argument was with @SylvainPlessis about this, but it is now time differentiate between NASA9 and CEA. The main reason is that when doing our ASCII parsing, we parse (practically) direct output from the CEA program which has 10 coefficients; the 7th is always 0. (I don't know why this is, but it is.) When parsing from XML files, the expected 9 coefficients are there, not 10. Furthermore, I've already found some XML files that have NASA9 values outside the traditional CEA intervals; looks like they just supplied coefficients for a sane extrapolation beyond the fit ranges (and that seems like a not unreasonable thing to do). So we need sane behavior for the different number of coefficients cases and have NASA9 be able to deal with non-traditional intervals.
So, the end game is:
Rework the internals of NASA9 to only store 9 coefficients (so we actually match the indexing in the math). Errors will happen if not consistent with this.
Rework CEACurveFit take 10 coefficients in the constructor, map it down to the true 9 coefficients and then then give that to NASA9.
That will preserve backward compatibility with CEACurveFit and will allow us to sanely parse XML (which still needs fixing). CEACurveFit is the only backward compatibility that needs to be supported.
This PR sets the stage for doing that refactoring. I've split NASA9 from CEA, created a base class to house common data structures and methods and added some runtime consistency checks. I've also allowed NASA9 to start taking temperature vectors in, but not using it anywhere yet.
So the follow-on to this PR will be just a reworking of the construction of NASA9 and CEA (plus moar unit testing).
Context for this PR: I don't remember what the argument was with @SylvainPlessis about this, but it is now time differentiate between NASA9 and CEA. The main reason is that when doing our ASCII parsing, we parse (practically) direct output from the CEA program which has 10 coefficients; the 7th is always 0. (I don't know why this is, but it is.) When parsing from XML files, the expected 9 coefficients are there, not 10. Furthermore, I've already found some XML files that have NASA9 values outside the traditional CEA intervals; looks like they just supplied coefficients for a sane extrapolation beyond the fit ranges (and that seems like a not unreasonable thing to do). So we need sane behavior for the different number of coefficients cases and have NASA9 be able to deal with non-traditional intervals.
So, the end game is:
CEACurveFittake 10 coefficients in the constructor, map it down to the true 9 coefficients and then then give that to NASA9.That will preserve backward compatibility with CEACurveFit and will allow us to sanely parse XML (which still needs fixing). CEACurveFit is the only backward compatibility that needs to be supported.
This PR sets the stage for doing that refactoring. I've split NASA9 from CEA, created a base class to house common data structures and methods and added some runtime consistency checks. I've also allowed NASA9 to start taking temperature vectors in, but not using it anywhere yet.
So the follow-on to this PR will be just a reworking of the construction of NASA9 and CEA (plus moar unit testing).