Value to supply TAP generator for "constant_fraction"?

[AndrewEdmonds11]

I'm trying to run the production.cfg file on one file on the master branch and get the following error:

TAPGeneratorFactory::createModule: Error: Missing option for 'default generator options': 'constant_fraction'

Error while preprocessing first entry (0) for module MakeAnalysedPulses

which is because I haven't supplied a value for constant_fraction.

This is the config file:

[ analyse_pulses ]
analyse_channels=all
default_fast_generator=FirstComplete
default_slow_generator=FirstComplete

Because, we have different constant fraction values for different detectors do we now need to do something like this:

[ analyse_pulses ]
analyse_channels=all
default_fast_generator=FirstComplete
default_slow_generator=FirstComplete
muSc=FirstComplete(constant_fraction_value, time_shift)
Ge-F=FirstComplete(constant_fraction_value, time_shift)
etc.

Or would it be better to have a default value supplied in FirstCompleteAPGenerator's constructor. i.e.

fConstantFractionTime(SetupNavigator::Instance()->GetPedestal(GetChannel()),
                        TSetupData::Instance()->GetTriggerPolarity(TSetupData::Instance()->GetBankName(GetChannel().str())),
                        TSetupData::Instance()->GetClockTick(TSetupData::Instance()->GetBankName(GetChannel().str())),
                        opts->GetBool("no_time_shift", false) ? 0. : SetupNavigator::Instance()->GetCoarseTimeOffset(GetSource()),
                        ***opts->GetDouble("constant_fraction", SetupNavigator::Instance()->GetConstantFraction(GetChannel())***)),

Or some other way so that we only get the value that is in the calibration database?

[benkrikler]

I think the best way is for the modules file to contain the values for each channel (your first option). The actual values are on slide 3 from John's presentation on elog:163.

[AndrewEdmonds11]

Just been reading through the wiki here. It seems the values are in the timeoffset_calib.cfg.

I'll just copy them into the production.cfg file

[AndrewEdmonds11]

Although, there are several options for the muSc. I'll go with 0.60 for the time being. John, do you know which we should use?

[jrquirk]

All of them if you use the PlotTAP_TDiff module. Otherwise for scintillators it doesn't matter too much. But I haven't studied the muSc so I couldn't say.

[AndrewEdmonds11]

Why all of them? Do we not just decide on one for the muSc and then have the time offsets for all other channels? Or do we be compare timing with the same constant fraction value (which seems weird to me but I could be wrong)?

[jrquirk]

Why all of them?

That's a reasonable thing to ask. Right now the TAP TDiff plotter takes as an configuration the two channels to plot vs each other, the lower and upper bounds of the time axis in the tdiff histograms, and a bool specifying whether to output that CSV file for the database (example). The module then books for plotting all combinations of those two channels that have the same generator (source).

Or do we be compare timing with the same constant fraction value (which seems weird to me but I could be wrong)?

Right now, that's exactly what we do, and it is weird to some extent. It makes sense if we have lots of generators but don't want beastly combinatorics problems. But otherwise, yeah, there's no reason to assume we'd be using the same gens between channels.

Anyway, we can remove the if-statement in the source above and that should solve this issue. But then if we have multiple generators for a channel it'll start blowing up the processing time. There are other solutions, but this is the easiest.

Does that make sense?

[AndrewEdmonds11]

I still have a couple of questions.

It makes sense if we have lots of generators but don't want beastly combinatorics problems

I don't understand what you mean here. Are you saying that the way things are done right now makes sense with these points?

But then if we have multiple generators for a channel it'll start blowing up the processing time.

I think I understand this. So should we just check the "type" of generator (i.e. FirstComplete/CFTimeMBAmp etc)? This will mean the constant fraction values don't need to be exact

[jrquirk]

If we have tow channels to plot vs each other, each with two different generators, then we'd get 4 combinations for the TDiff plots instead of 2 is what I mean. For 3 each it's 9 instead of 3. This was a problem when looking at the best fraction, because each channel would have 9 generators (0.10->0.90), so there would've been 81 plots for each of the many channels.

I never ran into space problems, but a single run was not quick, and the majority of time in the program was in the deepest part of the event loop filling the histograms, so any more plots increases the run time a lot.

We can check the type or not even bother checking any part of the generators match. Either should work at this point.

[AndrewEdmonds11]

Thanks, John, that makes sense to me now. If that's the case then checking the type would not have helped. For production runs, I think we can assume we'll use one generator per channel most of the time and so I'll just remove that check. People can add it back in if they need it while developing code.

[litchfld]

Arguably generating constants for the database is a different job from making a few plots. It makes sense - I think - to let the constant generation code have freedom to compare any two methods for generating timestamps (modulo previous comments that generators should be designed so this doesn't really matter).

Not sure, but i'm wondering if it might be better if these two functions (filling histograms, outputting constants) lived in separate locations, with access to the same time finding code.) They could have separate behaviour then...

[jrquirk]

The idea to separate the two functions makes sense, but the pedestals and times are got from the histograms so in this situation it would duplicate code and work. Separate exportsql modules could be written with an end-of-job function to grab the histograms and do the calculations, but this seems to work for now.