EIC issueshttps://eicweb.phy.anl.gov/groups/EIC/-/issues2021-10-24T23:17:39Zhttps://eicweb.phy.anl.gov/EIC/detectors/athena/-/issues/128material map for Acadia (cbor)2021-10-24T23:17:39ZWouter Deconinckmaterial map for Acadia (cbor)[material-maps.cbor](/uploads/458fee1b8c95bf408159fe70d654b8c0/material-maps.cbor)[material-maps.cbor](/uploads/458fee1b8c95bf408159fe70d654b8c0/material-maps.cbor)Wouter DeconinckWouter Deconinckhttps://eicweb.phy.anl.gov/EIC/eicd/-/issues/21add IRT output data structures2022-02-11T16:12:10ZChristopher Dilksadd IRT output data structuresChristopher DilksChristopher Dilkshttps://eicweb.phy.anl.gov/EIC/detectors/athena/-/issues/130Excessive output for convert_to_gdml2021-10-27T04:02:34ZWouter DeconinckExcessive output for convert_to_gdmlhttps://eicweb.phy.anl.gov/EIC/detectors/athena/-/jobs/412116
Lots of segments with
```
-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : CUTS0100
issued by : G4ProductionCutsTable::ConvertRangeToEne...https://eicweb.phy.anl.gov/EIC/detectors/athena/-/jobs/412116
Lots of segments with
```
-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : CUTS0100
issued by : G4ProductionCutsTable::ConvertRangeToEnergy()
Invoked prematurely before it is fully initialized.
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------
```
These should be grepped out in the convert_to_gdml script so the log files can be used for finding other issues (validation).Wouter DeconinckWouter Deconinckhttps://eicweb.phy.anl.gov/EIC/benchmarks/detector_benchmarks/-/issues/58Material scan for ecal2021-10-27T04:06:59ZWouter DeconinckMaterial scan for ecalThe material scan behind the ECAL looks like it has way too much material in the ECAL barrel region, with 1e2 X0.
https://eicweb.phy.anl.gov/EIC/benchmarks/detector_benchmarks/-/jobs/411758/artifacts/file/results/images/materialScanEcal...The material scan behind the ECAL looks like it has way too much material in the ECAL barrel region, with 1e2 X0.
https://eicweb.phy.anl.gov/EIC/benchmarks/detector_benchmarks/-/jobs/411758/artifacts/file/results/images/materialScanEcal.png
We should figure out why that is the case, and if other parts of the material scans are similarly affected.
While on the topic:
- add missing materials to the table of known materials (or figure out an automatic numbering scheme)
- add a legend
- use actual regions in compact xml and material scan instead of mathematical cylindersWouter DeconinckWouter Deconinckhttps://eicweb.phy.anl.gov/EIC/benchmarks/physics_benchmarks/-/issues/34Job Failed #416935: cycles of `malloc(): unsorted double linked list corrupte...2021-10-27T21:24:21ZWouter DeconinckJob Failed #416935: cycles of `malloc(): unsorted double linked list corrupted *** Break *** abort`Job [#416935](https://eicweb.phy.anl.gov/EIC/benchmarks/physics_benchmarks/-/jobs/416935) failed for f029424083a9ef610146fbc2003084ad030c56f8:
While running npsim, lots of repeated
```
malloc(): unsorted double linked list corrupted
**...Job [#416935](https://eicweb.phy.anl.gov/EIC/benchmarks/physics_benchmarks/-/jobs/416935) failed for f029424083a9ef610146fbc2003084ad030c56f8:
While running npsim, lots of repeated
```
malloc(): unsorted double linked list corrupted
*** Break *** abort
```
Could be a transient, but seen this several times in last week so it may be triggered by something recent.Wouter DeconinckWouter Deconinckhttps://eicweb.phy.anl.gov/EIC/benchmarks/physics_benchmarks/-/issues/37Job Failed #427685: Recurring segfault in 10x100 DIS2021-11-05T04:40:12ZWouter DeconinckJob Failed #427685: Recurring segfault in 10x100 DISJob [#427685](https://eicweb.phy.anl.gov/EIC/benchmarks/physics_benchmarks/-/jobs/427685) failed for 4398ec62d712ac34dc9f41d8a86bb1e9cac5382b:
```
*** Break *** segmentation violation
====================================================...Job [#427685](https://eicweb.phy.anl.gov/EIC/benchmarks/physics_benchmarks/-/jobs/427685) failed for 4398ec62d712ac34dc9f41d8a86bb1e9cac5382b:
```
*** Break *** segmentation violation
===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
#0 0x00007ff96843ac46 in __GI___wait4 (pid=308, stat_loc=stat_loc
entry=0x7fff5ef39408, options=options
entry=0, usage=usage
entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
#1 0x00007ff96843ac07 in __GI___waitpid (pid=<optimized out>, stat_loc=stat_loc
entry=0x7fff5ef39408, options=options
entry=0) at waitpid.c:38
#2 0x00007ff9683b9a73 in do_system (line=<optimized out>) at ../sysdeps/posix/system.c:172
#3 0x00007ff96754980b in TUnixSystem::StackTrace() () from /opt/software/linux-debian-x86_64/gcc-10.3.0/root-6.24.06-pgd4i7gxclnyg4ysoebhpu4btbrbrh27/lib/libCore.so.6.24
#4 0x00007ff9676f5cd2 in ?? () from /opt/software/linux-debian-x86_64/gcc-10.3.0/root-6.24.06-pgd4i7gxclnyg4ysoebhpu4btbrbrh27/lib/libcppyy_backend3_9.so.6.24
#5 0x00007ff967546c21 in TUnixSystem::DispatchSignals(ESignals) () from /opt/software/linux-debian-x86_64/gcc-10.3.0/root-6.24.06-pgd4i7gxclnyg4ysoebhpu4btbrbrh27/lib/libCore.so.6.24
#6 <signal handler called>
#7 0x00007ff9549fa8ce in dd4hep::sim::Geant4Particle::release() () from /opt/software/linux-debian-x86_64/gcc-10.3.0/dd4hep-1.18-rubohuy3jsc7u4vqoh77kbw6vqozds35/lib/libDDG4.so.1.18
#8 0x00007ff954a0fe7e in dd4hep::sim::Geant4PrimaryInteraction::~Geant4PrimaryInteraction() () from /opt/software/linux-debian-x86_64/gcc-10.3.0/dd4hep-1.18-rubohuy3jsc7u4vqoh77kbw6vqozds35/lib/libDDG4.so.1.18
#9 0x00007ff9549f7df6 in ?? () from /opt/software/linux-debian-x86_64/gcc-10.3.0/dd4hep-1.18-rubohuy3jsc7u4vqoh77kbw6vqozds35/lib/libDDG4.so.1.18
#10 0x00007ff955840302 in dd4hep::ObjectExtensions::clear(bool) () from /opt/software/linux-debian-x86_64/gcc-10.3.0/dd4hep-1.18-rubohuy3jsc7u4vqoh77kbw6vqozds35/lib/libDDCore.so.1.18
#11 0x00007ff95584034c in dd4hep::ObjectExtensions::~ObjectExtensions() () from /opt/software/linux-debian-x86_64/gcc-10.3.0/dd4hep-1.18-rubohuy3jsc7u4vqoh77kbw6vqozds35/lib/libDDCore.so.1.18
#12 0x00007ff9549df30e in dd4hep::sim::Geant4UserEventAction::EndOfEventAction(G4Event const*) () from /opt/software/linux-debian-x86_64/gcc-10.3.0/dd4hep-1.18-rubohuy3jsc7u4vqoh77kbw6vqozds35/lib/libDDG4.so.1.18
#13 0x00007ff9540ebb43 in G4EventManager::DoProcessing(G4Event*) () from /opt/software/linux-debian-x86_64/gcc-10.3.0/geant4-10.7.1-wfvgumef3sbbgrh2gopyldz7rphwudgo/lib/libG4event.so
#14 0x00007ff95418e117 in G4RunManager::ProcessOneEvent(int) () from /opt/software/linux-debian-x86_64/gcc-10.3.0/geant4-10.7.1-wfvgumef3sbbgrh2gopyldz7rphwudgo/lib/libG4run.so
#15 0x00007ff95418dfbb in G4RunManager::DoEventLoop(int, char const*, int) () from /opt/software/linux-debian-x86_64/gcc-10.3.0/geant4-10.7.1-wfvgumef3sbbgrh2gopyldz7rphwudgo/lib/libG4run.so
#16 0x00007ff95418c07e in G4RunManager::BeamOn(int, char const*, int) () from /opt/software/linux-debian-x86_64/gcc-10.3.0/geant4-10.7.1-wfvgumef3sbbgrh2gopyldz7rphwudgo/lib/libG4run.so
#17 0x00007ff954a1b323 in dd4hep::sim::Geant4UIManager::start() () from /opt/software/linux-debian-x86_64/gcc-10.3.0/dd4hep-1.18-rubohuy3jsc7u4vqoh77kbw6vqozds35/lib/libDDG4.so.1.18
#18 0x00007ff9549e0676 in dd4hep::sim::Geant4Exec::run(dd4hep::sim::Geant4Kernel&) () from /opt/software/linux-debian-x86_64/gcc-10.3.0/dd4hep-1.18-rubohuy3jsc7u4vqoh77kbw6vqozds35/lib/libDDG4.so.1.18
#19 0x00007ff9549fcfda in dd4hep::sim::Geant4Kernel::run() () from /opt/software/linux-debian-x86_64/gcc-10.3.0/dd4hep-1.18-rubohuy3jsc7u4vqoh77kbw6vqozds35/lib/libDDG4.so.1.18
```Wouter DeconinckWouter Deconinckhttps://eicweb.phy.anl.gov/EIC/benchmarks/detector_benchmarks/-/issues/59Add BTOF benchmarks2021-11-03T03:43:48ZZhenyu YeAdd BTOF benchmarkshttps://eicweb.phy.anl.gov/EIC/benchmarks/reconstruction_benchmarks/-/issues/80Add BTOF Benchmark2021-11-04T22:35:05ZZhenyu YeAdd BTOF Benchmarkhttps://eicweb.phy.anl.gov/EIC/detectors/athena/-/issues/134make new 3d views of FF region and detectors2021-11-05T17:18:58ZAlex Jentschmake new 3d views of FF region and detectorsAlex JentschAlex Jentschhttps://eicweb.phy.anl.gov/EIC/benchmarks/reconstruction_benchmarks/-/issues/81RICH benchmarks2021-11-05T18:15:49ZChristopher DilksRICH benchmarksChristopher DilksChristopher Dilkshttps://eicweb.phy.anl.gov/EIC/juggler/-/issues/73add RICH IRT algorithm2022-08-12T22:39:21ZChristopher Dilksadd RICH IRT algorithmChristopher DilksChristopher Dilkshttps://eicweb.phy.anl.gov/EIC/NPDet/-/issues/85sanitize_hepmc3 fails to add END_EVENT_LISTING after discarding partial event2021-11-08T20:59:33ZWouter Deconincksanitize_hepmc3 fails to add END_EVENT_LISTING after discarding partial eventIf the input hepmc3 file ends with a partial event, the final partial event is dropped but contrary to log messages, no `END_EVENT_LISTING` is appended.
```
WARNING: File does not end with END_EVENT_LISTING, appending
WARNING: Invalid pa...If the input hepmc3 file ends with a partial event, the final partial event is dropped but contrary to log messages, no `END_EVENT_LISTING` is appended.
```
WARNING: File does not end with END_EVENT_LISTING, appending
WARNING: Invalid particle count for event: E 305 8 20 @ -7.4609364157173369e-02 -7.7988299819229476e-03 9.6855910264790026e+00 -7.2251504307264325e+00
--> skipping event
WARNING: Skipped invalid event E 305 8 20 @ -7.4609364157173369e-02 -7.7988299819229476e-03 9.6855910264790026e+00 -7.2251504307264325e+00
```
At the end of the file, when going into flush_buffer, the buffer has the partial event with the `END_EVENT_LISTING` appended:
```python
if not end_reached:
warn("File does not end with END_EVENT_LISTING, appending")
buffer.append('HepMC::Asciiv3-END_EVENT_LISTING\n')
# final buffer flush at the end
flush_buffer(header, buffer)
```
However, flush_buffer drops the entire buffer, including the `END_EVENT_LISTING` and returns:
```python
def flush_buffer(header, buffer):
if header:
event_record = header.get_record()
if not event_record:
warn('Skipped invalid event', header.raw)
return
sys.stdout.write(header.get_record())
for line in buffer:
sys.stdout.write(line)
```
A likely fix may be to flush the buffer before `if not end_reached:`, then append the `END_EVENT_LISTING` again, and flush the buffer again.
That leaves as a case that will result in a missing `END_EVENT_LISTING` an input file that ends with `END_EVENT_LISTING` after an actual incomplete event, in which case the final buffer includes the `END_EVENT_LISTING`, is dropped, and doesn't trigger the `if not end_reached:`.
Maybe we can also just always drop END_EVENT_LISTING from the input, and always end by writing `END_EVENT_LISTING` to the output.Sylvester JoostenSylvester Joostenhttps://eicweb.phy.anl.gov/EIC/benchmarks/detector_benchmarks/-/issues/60Job Failed #468512: eicd include issues in sim:b0_tracker?2021-11-13T21:30:14ZWouter DeconinckJob Failed #468512: eicd include issues in sim:b0_tracker?Job [#468512](https://eicweb.phy.anl.gov/EIC/benchmarks/detector_benchmarks/-/jobs/468512) failed for ecae0203ea6272436f3294fd3f7649b91e6d7a02:Job [#468512](https://eicweb.phy.anl.gov/EIC/benchmarks/detector_benchmarks/-/jobs/468512) failed for ecae0203ea6272436f3294fd3f7649b91e6d7a02:Wouter DeconinckWouter Deconinckhttps://eicweb.phy.anl.gov/EIC/juggler/-/issues/75Hit merging implementation2021-11-17T15:43:48ZAaron AngeramiHit merging implementationIf I understand correctly, the current implementation converts individual G4 hits to summed ADC values in the digitization (including noise), the cell hits are reconstructed and assigned energies and then merged in the reconstruction. I ...If I understand correctly, the current implementation converts individual G4 hits to summed ADC values in the digitization (including noise), the cell hits are reconstructed and assigned energies and then merged in the reconstruction. I think the order of merging/digitization should be reversed, so that energies of different G4 hits in the same cell are summed _before_ digitization. In going from the G4 deposited energy (which already has fluctuations in the energy loss and sampling) to cell energies, the primary source of noise is electronic noise which contributes per cell not per hit.
In the current implementation if you had N hits all within the same cell, the current digitization/hit reconstruction/hit merging sequence would give each hit its own independent contribution to the electronic noise, thus the merged hit would have noise that goes like sqrt(N)sigma instead of just sigma.
The solution would be to disable the CalorimeterHitsMerger algorithm and replace it with an analogous one in the digitation that runs upstream of CalorimeterHitDigi that takes the hit collection and produces a new, merged one.Chao PengChao Penghttps://eicweb.phy.anl.gov/EIC/detectors/athena/-/issues/137jekyll/hugo static website for CI output presentation2021-12-03T20:35:05ZWouter Deconinckjekyll/hugo static website for CI output presentationIt would be useful to set up a (somewhat standardized) jekyll/hugo static website generation framework on our repositories (probably starting here) that displays CI outputs in a better format based on the reports. We could make the athen...It would be useful to set up a (somewhat standardized) jekyll/hugo static website generation framework on our repositories (probably starting here) that displays CI outputs in a better format based on the reports. We could make the athena geometry repository a starting point, but design it in a way that easily translates to benchmarks etc.Wouter DeconinckWouter Deconinckhttps://eicweb.phy.anl.gov/EIC/eicd/-/issues/22Rebranding of Trajectory to TrackProjection2021-12-07T20:51:51ZWouter DeconinckRebranding of Trajectory to TrackProjectionSylvester JoostenSylvester Joostenhttps://eicweb.phy.anl.gov/EIC/eicd/-/issues/23Add ProtoTrack structure2021-12-07T20:51:11ZWouter DeconinckAdd ProtoTrack structureCurrently we store this in output ROOT files outside of the eicd data model, as:
```
/// A proto track is a collection of hits identified by their indices.
using ProtoTrack = std::vector<size_t>;
/// Container of proto tracks. Each proto...Currently we store this in output ROOT files outside of the eicd data model, as:
```
/// A proto track is a collection of hits identified by their indices.
using ProtoTrack = std::vector<size_t>;
/// Container of proto tracks. Each proto track is identified by its index.
using ProtoTrackContainer = std::vector<ProtoTrack>;
```
Hmm, one-to-many relation...Sylvester JoostenSylvester Joostenhttps://eicweb.phy.anl.gov/EIC/juggler/-/issues/77Source linker storage performance2022-01-15T22:29:50ZWouter DeconinckSource linker storage performanceAs pointed out by Paul Gessinger, https://github.com/acts-project/acts/issues/1106#issuecomment-989624406:
> One thing I noticed when looking at the MR over on your Gitlab is that you copied the pattern from our fitting algorithm, where ...As pointed out by Paul Gessinger, https://github.com/acts-project/acts/issues/1106#issuecomment-989624406:
> One thing I noticed when looking at the MR over on your Gitlab is that you copied the pattern from our fitting algorithm, where I introduced an std::list to have stable pointers for the source links I create. This is not necessarily a good idea for a setup meant for any kind of production: std::list is relatively slow. I didn't add anything more clever to that algorithm there because it wasn't needed, but I would suggest you try to work around using this pattern, for example by creating the source links in one pass and only afterwards creating the measurements (when source link pointers are stable)
This needs some thinking.Wouter DeconinckWouter Deconinckhttps://eicweb.phy.anl.gov/EIC/detectors/athena/-/issues/138Set birks constants without patching geant42022-01-21T21:13:31ZWouter DeconinckSet birks constants without patching geant4Interfaces:
- geant4: `G4Material* m; m->GetIonisation()->SetBirksContant(value);`
Problems:
- G4GDMLReadMaterials does not support `<material>` properties relevant to ionization beyond `MEE`
- dd4hep::Geant4Converter doesn't set any io...Interfaces:
- geant4: `G4Material* m; m->GetIonisation()->SetBirksContant(value);`
Problems:
- G4GDMLReadMaterials does not support `<material>` properties relevant to ionization beyond `MEE`
- dd4hep::Geant4Converter doesn't set any ionization properties beyond MEE (and even this it doesn't actually set them but lets TGeo do the work using GDML)
Possible strategy:
- dd4hep::Material has support for Property, which is a TGDMLMatrix pointer. We could define the birks constant as a material property table, similar to index of refraction for optical materials. That's a bit of an abuse of the material property tables since birks constants are never tables (or at least energy-dependence is not supported in geant4).Wouter DeconinckWouter Deconinckhttps://eicweb.phy.anl.gov/EIC/detectors/athena/-/issues/141Default to -Wall -Wextra compiler flags2022-01-23T20:33:37ZWouter DeconinckDefault to -Wall -Wextra compiler flagsWouter DeconinckWouter Deconinck