This sounds like a good approach, but we'll have to look at your code to better understand the details. We'll try and do this later this week. From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Dylan Mead Sent: Saturday, June 01, 2013 10:34 AM To: Johnson, Tony; [log in to unmask]; kpix-beamtest-software; Kyle Travis; Bill McCann; Strom, David M. Subject: Re: [KPIX-BEAMTEST-SOFTWARE] weird behavior of hepRep converter 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 ######################################################################## 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