I was able to update KpixHepRepConverter.java on the repository. it calls a file "sensor_geometry.txt" attached here. I was looking through old emails and saw that tony had mentioned importing a .heprep at the beginning of a session and then creating heprep objects just to represent data. The current code should produce a single sensor when the reader encounters a data record, I think. How this software operates is still not completely transparent to me.

I think maybe a good approach would be to create the sensor stack before the data. This would be nice because we could setup the code to ascertain the number of sensors in the stack from the non-hit data and then produce the appropriate geometry. that way we don't have to manually define produce the stack geometry by sending the stack depth to a python script that would produce a .heprep with the stack geometry. this approach would be robust as it would automatically produce the sensor geometry for data coming from stacks of different depth. Also it would be less computationally cumbersome than reloading the geometry in wired with every data record.


Use REPLY-ALL to reply to list

To unsubscribe from the KPIX-BEAMTEST-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=KPIX-BEAMTEST-SOFTWARE&A=1