 |
 |
Hi, I am out tomorrow and so can't attend the software meeting. I thought I'd give you a status report, as a lot has been going on. I worked with both Omar and Sho this week on the code that converts to EVIO from LCIO, which will be used to generate test data from MC. This is technically an optional component but will be crucial for testing everything before actual physics events are generated. There is also the complimentary (and absolutely crucial "critical path item" of) conversion of EVIO into LCIO objects. Parts of the latter are coded up, but I have, up until now, focused on the conversion to EVIO. I have a "toy" scheme that simply passes the LCSim IDs into the EVIO data stream, and I can then run the reconstruction off of this data coming from the ET ring. But this is going to be replaced with a conversion to and from DAQ ID values. Omar and I worked on the encoding of SVT data. We have not tackled the header structures yet but have a pretty good handle on the hit/sample encoding, and he has an HPSSVTData class that does both "from" and "to" conversion of the int data. At the end of the day today, I believe Omar's encoding and decoding were both working, or at least he sent me an email to that effect. And he has also been doing a lot of work to implement classes for converting SVT hardware values like FPGA and hybrid numbers into their equivalent LCSim IDs and vice versa. Next week I plan on working with him to fully integrate the ID maps and add the remaining parts of the SVT data structure in order to read EVIO events off the ET ring and turn them into LCIO RawTrackerHit objects. Today, Sho and I worked on the conversion of LCIO to EVIO for the ECal. When I left, this appeared to be working okay. We do not, as of yet, have any classes that do conversion of LCSim IDs into their DAQ equivalents for the ECal or DAQ to LCSim, though there is a clear DAQ layout scheme outlined in the ECal trigger document on the Confluence. At some point, this should be fully integrated into LCSim, possibly using the conditions system. For now, we mapped the LCSim ID fields corresponding to Y onto slots and the X values onto channels. Obviously, this is not what we'll use for the final product, but it allowed us to get going with encoding into the composite data structures that will be used in the real experiment. We were able to successfully convert from MC raw data objects into EVIO, using the formatting for pulse integral mode, which, as I understand it, will be used in the test run. Next week, I plan to work with both Omar and Sho on the conversion of data from EVIO, e.g. off the EtEvents generated by the ET ring simulator, into LCIO events that can be directly streamed into LCSim, in order that we can have real time monitoring plots and run reconstruction and analysis offline. That sums up work I did this week in that area. Kudos to both these guys for being willing to do some coding with me, which was enormously more productive than me trying to do all of this integration work myself. I plan on doing more of this next week, if they are availabe. I have also been adding features to the monitoring application that I wrote in Java. Today I added the ability to prescale events, so that, for instance, if you set it to 10, the ET server will give you every 10th event. This should be very useful to reduce the data rate, as most tasks can't keep up with 15 kHz. I can currently run basic SVT occupancy plots at a little over 2 kHz, but this is not likely to be maintained as we add more and more detail to the code that converts to LCIO from EVIO. Since prescale is settable via the GUI, the event rates can be throttled on the fly in your monitoring session (you'd have to disconnect first, change the prescale value, and then reconnect, as I don't think it can be changed on the fly). I have yet to test this though, which is another task for next week. I think that is about it. I will be back to work Monday. Let me know if you have any questions... --Jeremy ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the HPS-SOFTWARE list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1