Agenda:

  1. Software Release                                        -- Jeremy
  2. Readout Error in SVT                                  -- Sho/Jeremy
  3. ECAL Monitoring                                        -- Kyle
  4. ECAL Truth information                               -- All
  5. ECAL Digitization, timing, noise - debugging -- Gabriel
  6. Schedule checkin                                       -- All
  7. Questions?                                                 -- All

Meeting Notes  - added by Maurik

Please feel free to add to and correct these notes as you see fit.

Pre-agenda comment:

Jeremy pointed out that it is possible to exclude files from the build. This is very useful if you have some test code, or something that you are working on but isn't finished, and you do want to check it into SVN, either as a backup or to share it with collaborators. An easy way to do this is to put your files in the "sandbox" area. 

SVT Readout Problem

Some users had noted that there was an issue on some events with the SVT readout. The symptom was an error message stating that the hit was outside of the tracker area. 

Jeremy pointed out that there are two drivers in SLIC for handling the hits from the tracker. One was specifically created for the ILC ("StepCombiningTrackerHitProcessor"), where there are lots and lots of trackers. We would want to use the other one. As Jeremy pointed out in an email, you can specify this in the compact.xml file (hps/detector-data/detectors/.../compact.xml by specifying:

<readout>
   <processor name="BasicTrackerHitProcessor" />
</readout>

Releases

Jeremy has done a lot of work to smooth out the creating of releases of our software. This is now done through the SLAC Nexus repository (http://srs.slac.stanford.edu/nexus).

For most of us, when we simply want to use the code, all we need to do is download the appropriate "bin-jar" file from the web, and we can run that to do our reconstruction. Here's how: Navigate to http://srs.slac.stanford.edu/nexus/index.html and enter  "hps-distribution" in the search box. See:

 

When you hit enter, you get to a page where you see a list of the available distributions. On the right you see a place where you can click to download the "bin-jar", the jar file that includes everything you need to run the reconstruction code. See:

The "SNAPSHOT" for a pre-release is build automatically, every 15 minutes (question), 

Automatic code documentation (Java Docs) for LCSIM is put here: http://www.lcsim.org/sites/lcsim/

The same thing for the HPS-JAVA code is here: http://www.lcsim.org/sites/hps/

JAS3 Plugin Update

The JAS3 plugins needed for HPS are now rolled into a single download from the Jas plugin directory. Starting with a clean Jas3 install, you go to Plugins, and there choose the HPS-Java plugin. This will pull down about 102 jars, including lcsim, wired, hps, etc.
Reboot Jas and you are all set.

JIRA

We need to get better with releases, and one part of that will be JIRA. This is a sophisticated, but relatively easy to use bug-tracking system. We use it not only for bugs but also for tasks. One of the really big advantages of using JIRA consistently is that it will provide documentation for our code. 

Go to the JIRA website to see: https://jira.slac.stanford.edu/browse/HPSJAVA/

You will need an account on JIRA. I don't know if this comes automatically with a confluence account (which you also need!), but at least the two are linked.

There was some discussion whether adding JIRA as a requirement would be too much of a burden. Gabriel was concerned that he would need to learn yet another system, and that it is already quite some work to get started. Omar testified that it is actually quite easy to use, so there should not be much of a learning curve. 

We decided to make JIRA a requirement for developers of the code.

Maurik will need to add the tasks from the Software Schedule into JIRA and will also look at cleaning up the tasks there. PLEASE HELP OUT.

ECAL Event Monitoring

Kyle gave a demo of his ECAL monitoring component for the Monitoring App. It is very nice and very fast (compared to creating, filling and clearing a histogram each event displayed). He was encouraged to continue developing this. A suggestion made was to add a configuration panel that allows to set the maximum energy, set log/lin z-scale, and any other desirable features (ADC versus Energy readout, accumulation mode, accumulation of the last N events in a rolling fashion?)

Jeremy was worried that for this low level monitor to work, the whole EVIO to LCIO translation and the the lcsim system need to work and load. Also the Monitoring App needs to work. This would not allow this tool to be used for debugging purposes and monitoring the actual DAQ output and he was worried it might break. Sho commented that we are over estimating how complicated the EVIO to LCIO translation is. None of our monitoring will work if that does not work, so we need to make sure it is done right. We need to revisit the driver for EVIO to LCIO translation and put in some debug hooks. We also need this to interface with the conditions database.

ECAL Low Level Monitoring

Andrea is looking at the low level monitoring needs for the ECAL. He pointed out that the detector is very similar to the CLAS Forward Calorimeter, and so it should have similar diagnostic tools as that detector. We agreed, and he is now clear on what to implement. He will get help in this from Kyle and the software group.

ECAL Readout

Gabriel had a question about the ECAL readout, see his slides: 2014-02-20_HPS-Soft-Meeting_GCharles.pdf.  He will work this out with Sho.

  • No labels