Release and project report (Erica)
CI operations report (Erica for Vito di Benedetto)
-
No issues raised
-
David Adams thanked LArSoft team for running the tests and finding the various bugs. [The LArSoft team thanks him for the feedback!]
Multi-threading LArSoft modules (Eric Church)
-
Some of the major points
-
Worked on GausHitFinder module.
-
Uses Gauss fitting inside TH1 to fit hits
-
Root 5 didn’t work
-
Root 6 was a problem too.
-
Leaking memory. Possibly from TCloning everything for unknown reasons?
-
Patrick Gartung suggested talking to Chris Jones about these issues. CMS has gone down this road and Chris has a lot of experience with them.
-
Tried R. Didn’t work
-
Finally tried bare GSL
-
This underlies root, so essentially just skips the root bits
-
GSL is manifestly thread safe
-
Observed good asymptotic memory behavior that grows linearly with the number of threads. Only modest increase over single thread size when running a single thread
-
Gained factor of 5 to 6 in CPU speed for single-thread operation, just by going to bare GSL and dropping use of root (!!)
-
Got x2.6 in CPU with 8 threads
-
Jim K: arrange a meeting next trip out. Lots of work on this type of thing going on at Fermilab. Efficiency (cpu gain / N threads) seems low, and there might be some experience here that sheds light on how to improve it
-
Need to be clear on goals for multi-threading. We can lose on total throughput, but maybe memory is more of an issue. So need to be aware of what the needs are.
-
Other questions, issues
-
Jobsub: can it handle requesting multiple slots on a machine? Yes, but a lot of work needed ahead of this to make LArSoft ready to exploit it for this purpose (e.g., have enough of LArSoft for the job multi-threaded as needed
-
What’s next?
-
Want to collaborate with Fermilab.
-
ACTION: See Jim K’s comment.
Event mixing (Herb Greenlee)
-
uBooNE interest is in overlaying cosmic-only data on MC signal events
-
Event mixing code exists and has support in art
-
Bookkeeping is an issue.
-
The framework is adequate for the primary input stream, but there is essentially no framework support for bookkeeping in the secondary input stream
-
For uBooNE, decided to make signal MC the primary input stream. Secondary would be cosmic sample, where SAM is used to track the data used.
-
Note that output file is not reproducible because SAM file delivery is not deterministic
-
Have modified project.py to support all this.
-
Allows definition of secondary input stream SAM dataset name
-
Code is on a branch in larbatch. Not a breaking change.
-
Approved merging this non-breaking change into develop.
-
ACTION: Herb will do this, then let Patrick know so that he can make a new version of larbatch
Database interfaces (Brandon Eberly)
-
Accessing lifetime information
-
Previously just set via a fcl parameter
-
In uBooNE, lifetime is measured. Four values are then stored in the DB for each IOV: two fit parameters + two uncertainties
-
DetectorProperties does not implement any of its DB hooks to access this information.
-
Although the ultimate goal is to do this, when is not yet scheduled.
-
All changes currently implemented in uboonecode since in general this needs to be experiment dependent (due to differing DB schemes)
-
No service or service provider interfaces have been defined, just the concrete implementation classes. (i.e., missing the abstraction layer)
-
Those can be done later (again, unscheduled)
-
Note that using run numbers as keys.
-
Changed IOVTimeStamp to understand when a run number is being used as a key
-
This is not acceptable for a long-term design, so need to come back to this point also.
-
Requesting a merge of the larevt branch.
-
eberly_dblifetimehack
-
Approved.
-
ACTION: Need to create a ticket(s) noting the IOV decoder hack and the need to introduce the necessary abstraction layer
There are minutes attached to this event.
Show them.