Improvements

[dglazier]

Hi,
I would like to focus on chanser development for the next few week. Please help by identifying issues that need fixed or can be improved and adding features. Some topics

Kinematics - include extra kinematics calculations (use kine branch)

RGB - make sure RGB compatible, initial anadbs files where required including simulated run number

Change combitorial configuration to something more intuitive, check for use of specific particle types, Document clearly combitorial algorithm.

...

[dglazier]

... target z-offset, currently fixed to -3cm should come from rcdb where it is given for run periods rather than run numbers

[naidoo88]

Hey Derek,

I really like the "philosophy" behind chanser of shareable, modular code, and common use actions (etc.) becoming a part of the chanser package.

However I think that will only work insofar as there is some form of structured documentation, where it is clear exactly what is available, and exactly what what is available is doing.

The Wiki/FAQs sort of serve this purpose, but it's already crowded. There is a lot there, and when you're just getting started it feels like too many things, which are just sort of just listed, that you're not sure whether you should be using etc.

I think a lot of the work has already been done, but converting it into a single document (or a document that links into separate .md's) that was structured would be a massive help in understanding what is available in chanser, and perhaps generate more users as it would be really clear what it offers over simply using clas12root or similar. It would also serve to massively flatten the learning curve in getting going on a chanser analysis (and hopefully save your inbox a bit!).

I also think it would be fair enough that if something was to be merged into the code, that a prerequisite would be that the merge include the addition of the appropriate documentation.

Eg. ToC:

1. COMBINATORICS
   • Combinatorial options [ALL, specific particles etc]
   • Limiting the number of particles
   • Combinatorial algorithm
   • ...
2. ACTIONS
   • Masking Actions
     • Masking radiated photons
     • Masking clusters in the ECAL
     • ...
   • Particle classes
   • Start times
   • ...
3. SIMULATIONS
   • Truth Matching
   • HipoTruth vs HipoData
   • ...

[dglazier]

So I think these things are covered in the current HipoTruth branch. If someone could test their code runs OK with this branch that would be great.

HipoData now needs to be given a run period t find correct AnaDB parameters

  hdata.SetRunPeriod("fall_2018");  //in Run script
  processor.AddOption("HIPOPROCESSOR_RUNPERIOD","fall_2018"); //In Processor.C

Also HipoData (and HipoTruth) can now take multiple files

     hdata.AddFile("/hdd/dglazier/dump/data/worker_0.0filtered.hipo");
     hdata.AddFile("/hdd/jlab/clas12data/skim14_005038.hipo");

You can produce a filtered file (of events which pass at least one final state topology with no RejectEvent() called) by adding

  hdata.SetWriteToFile("filtered.hipo");

or on PROOF (where it will produce 1 file for each worker in the top level output directory)

  processor.AddOption("HIPOPROCESSOR_FILTERHIPO","filtered.hipo");

I haven't quite worked out how to improve the combitorial configuration. I think I will add these lines to the skeleton code as perhaps it makes it more obvious

    auto useEBPidFor = "ALL"; //or "NONE"
    auto useInclusiveFilterFor = "ALL"; //or "NONE" or "gamma:neutron" (i.e. as may gammas and neutrons but exact other particles)

    auto FS = dglazier::Pi2::Make(useEBPidFor,useInclusiveFilterFor);

Also new documentation as requested at readthedocs which I will continue to update. Please send comments on the combitorial stuff as I think that is still the most complicated concept. I will add some more to that anyway

[dglazier]

you may need to update to most recent clas12root on dglazier github
For example if you see compilation error

[ 9%] Building CXX object core/CMakeFiles/chanser.dir/HipoData.cpp.o
/home/robertw/chanser/core/HipoData.cpp: In member function ‘virtual Bool_t chanser::HipoData::Init()’:
/home/robertw/chanser/core/HipoData.cpp:37:20: error: no match for ‘operator==’ (operand types are ‘clas12::clas12databases’ and ‘std::nullptr_t’)
37 | if((_c12->db())==nullptr)_c12->connectDataBases(&_c12db);
| ~~~~~~~~~~~~^~~~~~~~~
In file included from /mnt/share/cern_CentOS7/root/v6.22.03g9/include/TMatrixTBase.h:73,
from /mnt/share/cern_CentOS7/root/v6.22.03g9/include/TMatrixT.h:23,

[rwishart1]

Hi Derek,

Should I be able to use the DerivedChangeRun function on HipoTruth branch and after setting the run period (to fall_2018)? At the moment when I'm doing this I still get a value for the beam energy that's way off.

[dglazier]

This energy should be coming from rcdb, are you definately setting this up with a valid rcdb.root file ?
i.e.
clas12databases::SetRCDBRootConnection("/path/to/rcdb.root");

[rwishart1]

I've run PrepareDatabases.C and SetRCDBRootConnection but still getting zero values for the energy. Checking the documentation now in case there's something I've missed somewhere else

[dglazier]

Did you edit PrepareDatabases.C for you run list ? Actually you do not need to run this again, if you have an rcdb file from a pervious clas12root version it will still work. Actually we should have a copy of rcdb.root corresponding to all fall_2018 files on /w/work if there is not already.

[rwishart1]

Yes, the previous one I had was for all inbending skim 3 runs but I ran on a one file test just now.
I have a copy of rcdb.root for all inbending and outbending runs that I can copy to /work (after making sure it's not this that's causing the issues)

[rwishart1]

All working fine now: a typo in the code on my part!
Thanks for the help