To connect via Zoom: Meeting ID 831-443-820
Password distributed with meeting announcement
(See instructions for setting Zoom default to join a meeting with audio and video off: https://larsoft.org/zoom-info/)
PC, Mac, Linux, iOS, Android: https://fnal.zoom.us/j/831443820
Phone:
https://fnal.zoom.us/zoomconference?m=SvP8nd8sBN4intZiUh6nLkW0-N16p5_b
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
213.19.144.110 (EMEA)
See https://fnal.zoom.us/ for more information
At Fermilab: no in-person presence at the lab for this meeting
Release and project report
Discussion
Wes: how broken is v09_09_00. SBN was planning to use this as the base for a production release
Lynn: only missing Pandora DL heaaders. So if not using them, then it should ok.
Please let scisoft-team@fnal.gov know if you plan to declare this a production release. We need to keep track of that.
Hans Wenzel: Minimal LArG4-compatible LArTPC geometry example
Worked w Mike Wang on this.
Response to redmine issue 22466: Provide a well-documented LArTPC geometry example (and fcl files) that works with the new LArG4
The example runs the simulation (larg4), electron drift, signal on wires
Files mentioned are attached to the redmine issue
Will put them into git and create a wiki page
See slides for links to addition information
Use of GDML in larg4 / artg4tk
artg4tk / larg4 specific extensions
add color and other visualization attributes
explicitly assign sensitive detectors to logical volumes (instead of relying on naming convention)
specify homogeneous E fields (parsed, but not used in sim)
specify step limits cuts and assign to specific logical vol
Also make use of GDM features to achieve compact GDML files that are easy to read and easy to identify detector elements
loops, formulae, variables, constants
predefined NIST material and elements
include xml documents (eg, collect all LAr props in one file that an be used by all experiments)
uniquely ident physical vol by name of logical vol and its copy number
Makes it easy to do channel mapping
ID scheme should represent the actual detector (eg, layer, column, row) making it easy to navigate the geom.
eg, in reco finding the next layer or neighboring cells just involves incrementing / decrementing an index
provide plenty of comments
A problem: not all these features are supported by root GDML reader
Use G4 to dump geometry to a GDML file. That file can be parsed by root (though lose compactness and artg4tk / larg4 specific extensions)
Example
Showed documentation in the file
Has table of contents (!)
Two geometry files required in this scheme
Geant4 geometry file: used by Geant4 / larg4
(Then dump, and make root-readable geometry file ) [ Is this step necessary ?? More discussion below]
Root geometry file: used by reconstruction, GeometryBuilder, parsed by root
Matching of G4 and Reco geometry by name / keywords
volAuxDet, volCryostat, volTPC, volTPCPlane, volTPCWire
When building, need to make to use these specific keywords in order to match to geometries
Need this in order to use it in the reco
Use Gr4 stand-alone app to visualize, test and dump the geom
github.com/hanswenzel/lArTest
Can dump
Showed fcl snippet dealing w geometry
Noted difference in files specified for GDML and ROOT (unlike for Legacy LArG4)
Possible in principle to write a file that both can read. Just uncompacted. The other larg4 extensions would just be ignored by ROOT
Comment: In the future, Geant5 will likely be tied to specific root, and parsers will be compatible. But for now a problem.
More examples
Root GDML tools (see talk for link)
Editors available that will check syntax of xml/GDML live as you type
eg, https://netbeans.apache.org
A java-based IDE
Example: electron drift + signal generation
Starting w existing detector
If already using SimEnergyDeposits and separate sim for electron drift and signal sim
Then all that is needed
minor changes to existing GDML file:
assigning sensitive detectors to corresponding logical vols
change fcl file to use larg4
Conclusion
Created well doc minimal geometry for larg4 as well as flc file to run sim, ele drift, dsignal wires
Will be in git
Also a wiki
Two geometry files needed --> invites mistakes.
Be conscious of this
Suggest investigating vecgeom, dd4hep, or push root to update their parser
Discussion
Will be a PR? A: yes, hope this week
Sensitive volumes: wireplanes are not sensitive. Has been a sore point for a long time.
Q: Does this make it easier to make wireplanes sensitive?
A: Yes. Can make all LAr sensitive. So among other things they produce scint photons.
outside TPC there are sim energy deposits, but no E field, so only photons, for instance
Vecgeom and dd4hep. Are these tools for creating GDML files?
vecgeom is pure geom lib. Good thing is that you can tell Geant4 to use it instead of current system.
dd4hep. Was devel'd by ILC. Compact descrip, which runs through parser that produces uncompacted GDML. Has similar concepts for extensions to assign sensitive volumes to detectors, but can also describe readout segmentation, which our scheme does not do
It is a new format, but is convertible to GDML
Comment: DUNE is using GGD to do this.
A python package that produces GDML.
Suggest trying that before trying vecgeom or dd4hep, since people are already using GGD
Hans reply: noted the vecgeom has HPC in mind. Can run on GPUs, for instance. So expected to be more effic at navigating geometries
Krzysztof Genser reply: Geant4 is migrating to vecgeom. Maybe on timescale of ~1 year
There are already people using it, examples running at various places
CMS is adopting dd4hep
Lynn: need to build G4 w vecgeom. We do not do that, and do not distribute it at this time.
KG: will become the default for Geant4 in about a year.
Q: is vecgeom a diff lib for parsing / producing GDML? ...
vecgeom only helps if root uses it also. Since need to drive reco. That seems like it might be a problem with going to vecgeom
Q: Can new LArG4 use the same GDML as Legacy LArG4 if not using loops?
A: Yes. This is easiest solution for now
Q: why do we have "nowires" files? Why are they even in the geometry?
Wires: used in channel mapping.
And space charge corrections need to know where the wires are.
But don't want them in the photon simulation
Suggest that all this could be accomplished w/o need for full geometry object.
Q: In GDML example, assigned a copy number to a phys vol. Is this something that native G4 parser knows what to do?
Yes. Not used often. An obvious place to deal w mapping.
Agree
Herb Greenlee: SQLite database update
Summary of previous update
calibs in postgress IOV DB
Standard schemas, single IOV (SIOV) and multiple IOV (MIOV)
Diff for diff expts. For instance, uB has 20 SIOV databases
LARSoft includes an art service DatabaseUtil for direct access. Little used
most expts use http DB servers
Here, consider the option of exporting postgres to SQLite, which can be accessed w/o http
Current access sw stack
DatabaseRetrievalAlg + DBFolder
Latter uses libwda product (web db access), which uses libcurl
DRA is back-end agnostic (ie, DBFolder)
This work adds to this back end to read SQLite
Presented a change on Mar 10 LCM
made two requests of libwda maintainers
ability to search for server certs in a dir
implemented in libwda v2_28_0
Expose libwda opaque data struct
rejected
uB moved ahead anyway. Using in production (MCC9), but never in develop
Prev proposed updates to larevt
Add option to DRA to choose between libwda and sqlite DB access
Update DBFolder to have ability to read from either lbwda or sqlite
update is minimal, in sense that libwda access code is unchanged. Mostly additions
New proposed changes
not changes to DRA.
Updates to DBFolder
change caching strat to switch from storing data using libwda opaque struct, to using a newly def data struct
more invasive. Requires changes to both libwda and SQLite DB access code
How libwda works
makes query using specially formatted url
replies w csv
libwda chops the csv string into pieces and stores result substrings in opaque c-struct
hidden
provides own api for retrieving binary data from the struct
[showed the opaque struct]
dynamic 2D array
all data as strings
converted on extraction
libwda struct issues
DBFolder uses opaque struct to cache DB data
decision made by orig DBFolder author...
Trying to fix that here
Opaqueness not only problem
current cache structure wastes memory by storing strings, and dyn allocating mem for each val
Strategy for solving
instead of using libwda struct, DBFolder should use own data struct
removes need to go beyond the libwda api
replacement data struct can be more mem efficient
A key design question is how to store arb-type variables
Storing arb-type values in C++
char
std::string
void*
boost::any
type safe and auto destruction
union
not type sage, but allocated a compile time
boost::variant<T1,T2,...>
type safe, mem allocated at compile, auto destr
boost::variant<long,double,char[]> are
Kyle: C++17 standard has subsumed any and
variant, so now std:::
Mem considerations
...
union: largest of joined data types
boost::variant
8B + size of largest...
Chose this, as it seems to be the smallest at compilation time
Added new DB cache class DBDataset
Replaces libwda struct as the database cache
DBFolder interface
currently provides 5 typed accessors
Boolean values stored in DBDataset as integers (since SQLite doesn't have bools)
Discussion of type<double> accessor, which store multiple values in one DB column
Did not implement this.
Question to other experiments: does anyone find this to be needed / useful?
This is the only significant change to interface
Status
Branches ready to merge from uboone fork
larevt: feature/greelee_sqlite_develop
ubevt: feature/greenlee_sqlite_develop
uboonedata: feature/greenlee_sqlite_develop
uboonecode: feature/greenlee_sqlite_test_develop
Other expts don't need any updates, unless they want SQLite
To use, will need to add SQLite databases and make fcl updates
Have integration tests in uboonecode to ensure that SQLite DBs get updated when new tags are added to postgress
Validation
Event dumps of calib data
Running ~1k events in test mode
Read calib from libwda and SQLite and do binary comp
compare plots from vanilla v09_08_00 and updated larevt
Ran uBooNE "reco1" and "reco2" on same events
Some diffs seen in plots. Not understood, though they are small, at least for Pandora reco
Some evidence of larger diffs for TrajCluster and ...
DB conversion scripts available
See slides
Discussion
have not made PR yet. Want to do more tests
Kyle:
boost::any and boost::variant are in C++17, so should just use std::any and std::variant versions
Discussed size of variant<std::string>. Conclusion I think was that it met Herb's needs / criteria for being smallest.
Is vector<double> access to DBFolder necessary? [Question to the group. No response]
If using, then will have a comp error