Aaron Dotter implimented a C++ version of Frank Timmes' fortran code helmholtz.f90. I have taken that and refactored it to work in the 4DSEE code style. This has mostly involved some light moving of stuff around. The biggest change is removing all globals, and reorienting memory to be heap allocated and contiguous. This is because there was too much memory being stack allocated.
While writing 4DSSE we want a way to keep track of what defaults have been set for config files, and validate that we are using the same config variables where we want to. This python script generates a "default" yaml file based on the default values given in .get<T>
In order to prevent traversing the YAML tree I have added a hash map (O(1) lookup) to cache already accessed config variables. I have also added a vector to store keys requested but not found so we do not need to check for those every time
At many points in the code we may want configurable options, the Config class usses a yaml file to make this easy. It also allows for namespace references "opac:lowtemp:file" etc...
PreviouslyOPAT files were indexed using X and Z now they are indexed with a general index vector.
BREAKING CHANGE: all methods wch used X and Z now use std::vector<double> index (size: header.numIndex) instead. Also added a method to validate tables using checksum
the new general purpose index design introduced a bug in the loader related to the byte position of the byteStart field. This has been resolved. Further, I have updated the save to ascii format to provide an explicit warning that the ascii version is only for debugging purposes and not meant to be used directly.
OPAL type II tables use a 4 vector for composition, while many other opacity tables use a 2 vector of composition to index tables. In an attempt to be as general as possible I have updated the OPAT specification to allow for tables indexed by a vector of any length [1, 255]. This should allow a single spec to be used when storeing and accessing type I or type II tables.
BREAKING CHANGE: Careful thought will have to be given to how the C++ module handles this. We want the same code to work for querying data from any kind of opaticy table
