Hexagonal cells in barrel

[elenavernazza]

In the browser version at fireworks.cern.ch, the CaloParticle collection is displayed as hexagonal cells in the barrel.
Is this due to wrong geometry settings? How to fix it?

Log file in the following:

Info: Input /eos/user/e/evernazz/EventDisplay/step2_Run3SingleEleNoPU.root
Info in <TGeoManager::TGeoManager>: Geometry GeometFWProxyBuilderConfiguration::getVarParameter(). No parameter with name Draw Tracks
FWProxyBuilderConfiguration::getVarParameter(). No parameter with name Draw Pseudo Track
FWProxyBuilderConfiguration::getVarParameter(). No parameter with name Draw Ellipse
FW2Main::draw_event BEGIN
event overlay info CMS Experiment at LHC, CERN  ------
URL match 5
  0: https://localhost:10019/win1/?token=CF07BoNfAHl5uaXw
  1: https
  2: localhost
  3: 10019
  4: win1/?token=CF07BoNfAHl5uaXw
EVE URL https://localhost:10019/win1/?token=CF07BoNfAHl5uaXw
connection established 1

EVEMNG ............. streaming the world scene.
>>>> FWWebGUIEventFilter::WriteCoreJson filterState ...statusID 0
$Tracks.pt()>1$Jets.pt()>100$Muons@.size()>3HLT_Mu9   sending json, len = 14570
   for now assume world-scene has no render data, binary-size=0

EVEMNG ............. streaming scene  [Geometry scene]
   sending json, len = 728
   NOT sending binary, len = 0

EVEMNG ............. streaming scene Collections [Collections]
   sending json, len = 12121
   NOT sending binary, len = 0

EVEMNG ............. streaming scene Associations [Associations]
   sending json, len = 354
   NOT sending binary, len = 0

EVEMNG ............. streaming scene 3D [3D]
   sending json, len = 3495
   NOT sending binary, len = 0

EVEMNG ............. streaming scene  [GeoScene 3D]
   sending json, len = 1022
   sending binary, len = 2952

EVEMNG ............. streaming scene RPhi [RPhi]
   sending json, len = 3899
   NOT sending binary, len = 0

EVEMNG ............. streaming scene  [GeoScene RPhi]
   sending json, len = 23392
   sending binary, len = 8080

EVEMNG ............. streaming scene RhoZ [RhoZ]
   sending json, len = 390Info in <REveManager::ExecuteCommand>: MIR cmd NewElementPickedStr(0,false,false)
Info in <REveManager::ExecuteCommand>: MIR cmd RequestAddCollectionTable()
Info in <REveManager::ExecuteCommand>: MIR cmd AddCollection(true,"CaloParticle", "mix", "MergedCaloTru=== AddCollection called ===
Custom display nError: FWCaloParticleProxyBuilder::BuildItem: Hit association map is empty. Disable hitmap!Error: FWCaloParticleProxyBuilder::BuildItem: Hit association map is empty. Disable hitmap!Info in <TCanvas::MakeDefCanvas>:  created default TCanvas with name c1
Info in <REveManager::ExecuteCommand>: MIR cmd showEcalBarrel(true)
Collection finished ===
FWWebDoubleParameterSetter::writeJson 0x7f18f94e1cb0

[alja]

@elenavernazza

The reco geometry version is not a problem.

The collection with 'CaloParticle' purpose was written for HGCal debugging and the ECal case was not included. This is the reason there are hexagon shapes instead of tower shapes. See implementation here https://github.com/alja/FireworksWeb/blob/main/SimData/plugins/FWCaloParticleProxyBuilder.cc

I added a collection with purpose 'ECaloParticle' from collection dialog.
The shapes look OK, but the coloring of towers is missing. This is a minor correction
https://github.com/alja/FireworksWeb/blob/main/SimData/plugins/FWECaloParticleProxyBuilder.cc

Would ECaloParticle purpose meet your needs for virtualization with addition to correct the boxes color or you think the CaloParticle collection need to include the ECal?

[alja]

Screenshot of collection with 'ECaloParticle' purpose.
Color of boxes is missing.

I have used geometry /eos/user/a/amraktad/Fireworks-Test/cmsRecoGeom-2026_D77.root

[rovere]

Ciao @alja ,
on a similar note, I noticed that the rendering of the hexagons of the CaloParticles in cmsShowWeb is wrong, i.e., the hexagons are rendered in the wrong position. Digging a bit into the code, I saw that the implementation of AddHex changes from old ROOT to ROOT7. Would you prefer that I open a separate issue for this?

[alja]

@rovere

Thank you for looking into the code!
I did not know the HGCal hexagons were mispositioned.
I think it would help to make a separate issue for this bug.

To double-check: should FWCaloParticleProxyBuilder.cc also visualize ECal calo particles?
I was focused on HGCal when porting the proxy builder. I will later run the old Fireworks to compare the results.

[rovere]

@rovere

Thank you for looking into the code! I did not know the HGCal hexagons were mispositioned. I think it would help to make a separate issue for this bug.

To double-check: should FWCaloParticleProxyBuilder.cc also visualize ECal calo particles? I was focused on HGCal when porting the proxy builder. I will later run the old Fireworks to compare the results.

Ciao @alja I have opened a new issue related to HGCAL rechits position problem.

On a separate not, that could maybe related to your question about FWCAloParticlesProxyBuilder. I think we can have 2 separate layouts, one for CaloParticles in HGCAL and one for CaloParticles in Ecal, at least for the time being...

On a longer timescale it's a rather tricky question, because a generic CaloParticles could span both ECAL, HGCAL, HCAL, and it will be rather difficult to handle the correct drawing of all those dets into a single class/proxy, not to mention the (expected) code duplication.

• Even worse: currently we do store indices into other collections in plain integer format and, already now, there are hard-coded guesses on which real collection we should use to get the real information from. And, already now, I have several use cases in which neither of the current choices would do the job. And no, I do not have practical solution in mind, if not passing the label, not the type, as a configuration parameters for drawing the specific object.

Maybe something to be discussed at large, in a broader context.

[alja]

@elenavernazza

I have fixed the missing color of calo towers in the collections rendered with the 'ECaloParticle' purpose. The correction will be available in the next service update.

Does the ECaloParticle suit your needs for the debugging of ECal caloparticle data?
I'm not familiar with Ecal analysis, but I can include a new proxy builder, or we can communicate what to represent in the collection for that data type.

[elenavernazza]

Dear @alja
Thank you very much for your prompt fix and feedback!
We are now using the ECaloParticles for our studies and the shape is indeed correct.

If I may, for our studies it would be extremely beneficial to have the visualisation of cluster collections too, i.e. SimCluster.h, PFCluster.h, and CaloCluster.h. They appear only as "Table" at the moment and cannot be visualised in the Event Display. Would it be possible to include these in the tool? Let me know in case you need more details about that.

Thank you again for you work!