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>
macros provides a unified place to define macros which can be accessed at other points in the code. I defined a DEPRICATION_WARNING_OFF macro so we can disable those warnings for times when we cannot control them
previously I had a lagrangian multipliers at every element; however, we are enforcing a global constraint so there need only be one lagrangian multiplier
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
