Open benkrikler opened 9 years ago
To add to the first list, whitespace is not stripped from config strings. So calling a module in the config file like MODULE(par1, par2)
or
[MODULE]
P1=par1
P2= par2
Leads to config strings with spaces like {P2= par2}
. This has given me problems vis-a-vis {cftime= 0.50}
not being equal to {cftime=0.50}
and throwing the "no calibration" exceptions.
With regards to the solutions, Phil suggested the first awhile back ('canonical' calibrations) which has becoming appealing to me because of consistency. And maybe versioning the calibrations and having checks and warnings could be worked in.
If there are no complaints, I'll assign this issue to myself.
I would go almost with the first option then, in that we only keep constants for one fraction. Can I ask that we still keep constants which depend on the generator though? I'm hoping to be more rigorous in testing the performance of the various template methods and being able to flick between different generators would be very helpful. Since the trouble is coming from the config strings, I think just using the generator's 'type' string without the config should be safe. What do you think, John?
That's fine. In the end if we want to copy a column because it uses the same algorithm but a different gen, that's quick and easy.
When we ask the calib DB for the timing parameters, we specify both the channel and the fraction used for CFT. The fraction is contained within the generator's config string and used to look up the column name we want to have.
There are two problems with this:
Two possible solutions are:
Clearly the first option is simpler; the second is more work, probably the 'correct' approach. I'm personally indifferent as to what we do and open to other suggestions.
This is also true for all the other calibration constants we pull out of the DB but the timing is currently more affected.