Tidy up rarely used fcl files

[AndrewEdmonds11]

We have a few fcl files that are not regularly used (e.g. TrkAnaReco_wTrkQualFilter.fcl). These either need deleting or tidying up.

Examples of the kind of tidying that might be needed:

• updating to TrkAna v5 configuration (e.g. no candidate parameter)
• have a trigger_paths and end_paths defined (see #169)

[sophiemiddleton]

I think deleting makes most sense, if these are rarely used. We could add something in our documentation about specific things we might want to do and how to do them from the nominal examples. I have done something similar in REve.

[AndrewEdmonds11]

Thanks, Sophie. Yeh, I think most can be deleted but there are some rarely-used ones (e.g. TrkAnaReco_ceSimReco.fcl) that we should keep around. Here's a list of what I think we want to do. I'm open to other points of view:

Keep

• TrkAnaDeMFromDigis.fcl
• TrkAnaExtracted.fcl
• TrkAnaLineFromDigis.fcl
• TrkAnaReco.fcl
• TrkAnaRecoEnsemble-Data.fcl
• TrkAnaRecoEnsemble-MC.fcl
• TrkAnaReco_ceSimReco.fcl
• TrkAnaReco_mergedKalSeeds.fcl
• TrkAnaTriggerMC.fcl

More discussion needed:

• TrkAnaReco_MultipleTrkQual.fcl
  • will this be how we add different ML algorithm outputs to EvtNtuple?
• TrkAnaReco_addMCUpstream.fcl
  • if we move to a single trk branch, then we won't need this
• TrkAnaReco_addStopTgtVDs.fcl
  • I think we will likely want to keep this and maybe add them to the general EvtNtuple
• TrkAnaReco_multipleBestCrv.fcl and TrkAnaReco_multipleBestCrv_differentThresholds.fcl
  • I think we have turned away from the idea that we determine the single best CRV before the ntuple is made, however we may want something for having different thresholds

Delete

• CrvExpert.fcl
• TrkAnaReco_wTrkQualFilter.fcl

[sophiemiddleton]

Yes, this list seems reasonable, if things are useful they should be kept and updated