Notes from mu2e framework tutorial

Met with BrianRebel, RobK, Walter, Jim and ChrisPolly to discuss the difference between "cmsLite" and the FMWK framework.

mu2e has not yet decided what to use as the "event".

Rob has a tutorial at

What was interesting or alarming to Chris and Brian?

  • The scons build system.
  • The concept of services.
  • How the user code doesn't change even when the geometry service switches from using text files to a database.
  • Rob raises the issue of not using Root for some steps, because of thread safety issues -- it would be necessary to turn data files into Root files at some later point.
  • The part of the configuration language that allows filtering

What to come back to

  • Use cases for EDLooper. If they don't see the value, we can remove it.
  • Maybe move Root include files so that #include "Root/TF1.h" finds it;
    move Geant4 include files so that #include "Geant4/G4Volume.h" finds it.
    • Added by Rob: this might not be smart. When I include TF1.h, it includes other files using the syntax #include "Txxx.h". Therefore I will need to have an include path that includes two -I entries for root: one for the way root wants its and one for the way we want it. There is a similar problem for G4. We will also need to make symlinks so that new syntax points to the native syntax. We also need to consider how much searching the root and g4 include directories twice slows down compilation. In my opinion, includes from external packages should use the syntax that is native for that external package.
  • Brian is very cautious about obfuscation resulting from excessive use of typedefs.

Things to ask about

  • Are untracked parameters useful?

I mentioned the idea of how we might separate buckets of untracked from buckets of tracked parameters.

  • Are default parameter values (in the code) useful?

Default values in the code are very useful for lots of things, particularly for debug stuff. Rob uses conditional debugging based on "levels" of debugging, as well as "other conditions". He doesn't want to expose all this cruft in the runtime configuration at all times.

What features do they not like?

  • The fact that the edm::Service<T> must be used through operator->(), but does
    not have pointer in its name. This did not bother Rob. Calling this a ServiceHandle might
    be a good thing, for consistency. Is there a reason that this handle should have a different
    name from the other Handle template?

Things to add

  • Root things made in beginRun should be in a distinct folder for that run, etc.
    • Added by Rob: I think this refers to histograms that are booked in beginRun etc, as opposed to histograms that are booked in beginJob.