`GetCoarseTimeOffset` needs correct algorithm parameters

[benkrikler]

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:

1. If the fraction is written differently ( 0.5 as opposed to 0.50 ) then the column in the DB table won't be found.
2. We assume currently that the fraction is contained in the first option of the config string and then strip away all other options so we can match the config to the column heading.

Two possible solutions are:

• Assume the fraction won't change and so allow for just a single column per channel
• Improve the generator IDs so they have fields to define the algorithms they use and the parameters they're run with (maybe do something with the algorithms themselves).

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.

[jrquirk]

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.

[benkrikler]

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?

[jrquirk]

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.