Improvements to SavePulses module

[benkrikler]

Currently it seems the SavePulses module has two issues:

1. Branch names aren't c++ valid so TTree::Draw is having issues. I thought I'd changed this but I must have been wrong. ModulesParser implements such a function so it's easy to correct this.
2. Specialised TAPs are being stored as normal TAPs so we don't see the extra fields they add. I think I know how to solve this though it going to be a messy it of code I think...

As well, it's important to point out the source ID for a given TAP is stored via it's flyweight proxy. To dump the table of source proxies open the root file and do:

TAP_sources->DumpTable()

Since the branch name contains all the same information at this point this is mostly redundant, but it may change in the future....

[jrquirk]

Is there any chance we could also not have these fully-qualified leaf names on the branches? Right now the fully qualified name for timing is

Ge-S#FirstComplete#{constant_fraction=0.10}.Ge-S#FirstComplete#{constant_fraction=0.10}.fTime

So you can't just grab the branch and draw it's elements like fTime:fAmplitude. Does anyone know of a way to fix this?

[benkrikler]

TTree::SetAlias

[benkrikler]

And make source strings c++ valid tokens in rootana.

[benkrikler]

I've fixed the above two issues now:

• Branch names are formed by replacing all non-token characters with '_'
• The derived type of TAP is added to the tree.

In the process of fixing the last point I've done a bit of re-engineering of the module/ generator factory which gives it knowledge of the 'product' of the modules / generators. When you register a generator with the factory via the ALCAP_TAP_GENERATOR macro, the factory is informed of the type of TAPs the generator produces. The TAPGeneratorFactory can then be given an ID::source or ID::generator and it will give you back the class name for the type of TAP (which uses ROOT's TClass internally).

The only additional effort from someone writing a generator is to overload the static TapType() method to give the correct class type back. I've done this for IntegralRatioAPGenerator and GaussFitAPGenerator. If you don't do this, it defaults back to TVAnalysedPulseGenerator::TapType() which returns TAnalysedPulse.

I hope that's clear. I'll close this for now, but if SavePulses causes problems then let me know....

[litchfld]

Can we make it something less common than "_"? We discussed this a while back, but I can't remember the issue number. It's important to have a character or digraph (trigraph) to separate the source::speed::generator::config parts that is otherwise escaped or forbidden. Otherwise there's no way to guarantee that they can be parsed correctly if you are trying to reconstruct the source IDs from a branch name.

The approach you have does not guarantee it because we allow the possibility to process a generic TAnalysedPulse (for example) with code that does not have the original module registered, either to keep down the executable size or because we are processing files written with older versions of the code (which could be as little as fixing a typo in the module name, or if an extra option was added.)

The alternative is to pre-parse all the config strings (etc) to remove the separator "_"...