I, too, remember that we were going to turn off the hit position bit on output
to save space. But then all positions should be reading (0,0,0) in the lcio dump.
Norman
-----Original Message-----
From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of McCormick, Jeremy I.
Sent: Friday, February 13, 2015 1:04 PM
To: Nathan Baltzell
Cc: hps-software
Subject: RE: ECal cell positions
There is no geometry backend implemented within the LCIO C++ project. It is using the information from the raw IO only. So we must have the hit position bit flipped on for the CalorimeterHit objects. Otherwise, it would not display a valid position.
I'm going to check this with a fresh copy of HPS Java trunk now....
-----Original Message-----
From: Nathan Baltzell [mailto:[log in to unmask]]
Sent: Friday, February 13, 2015 12:48 PM
To: McCormick, Jeremy I.
Cc: hps-software
Subject: Re: ECal cell positions
Jeremy,
> I'm kind of confused about using the LCIO command line tool, because I
> had thought we were not explicitly writing the hit positions into the LCIO output in order to save space, and that these positions were recovered later by using the geometry. So I would have thought that the raw LCIO dump would always display 0,0,0 as the CalHit position. Perhaps this has changed since I looked at it.
It definitely does not print all (0,0,0)s now, nor last weekend.
And it gives identical result as the C++ API.
Should the C++ API not also use the geometry to convert cellID back into position?
Is the C++ API expected behave differently in this regard than the java one?
> I do not see that any of the positions are zero. The job has processed over 1 million events.
If you don't see (0,0,0) in the first few events of that file, then you can stop because we already have different behavior.
> This is not a pristine copy of the trunk, but I don't think I have any local changes that would affect this.
I would not add any uncertainty and just do a fresh checkout.
I just did it again now, and got the same result as previously.
I also wiped my ~/.m2 just in case.
-Nathan
On Feb 13, 2015, at 15:25, McCormick, Jeremy I. <[log in to unmask]> wrote:
> Hi, Nathan.
>
> I've opened a bug report about the incorrect positions in the CalorimeterHits from clustering.
>
> https://jira.slac.stanford.edu/browse/HPSJAVA-420
>
> But I'm having trouble reproducing this problem.
>
> Firstly I ran the recon based on your suggestion.
>
> java -cp hps-distribution-3.1-SNAPSHOT-bin.jar org.hps.evio.EvioToLcio
> -x /org/hps/steering/recon/EngineeringRun2014ECalRecon.lcsim -r -d
> HPS-ECalCommissioning -R 3325 -DoutputFile=out evio/hps_003434.evio.0
>
> Then I use a simple job lcsim job to check the hit positions.
>
> java -jar hps-distribution-3.1-SNAPSHOT-bin.jar ClusterCheck.lcsim -i
> out.slcio
>
> This just runs ClusterCheckDriver which is here.
>
> users/src/main/java/org/hps/users/jeremym/ClusterHitCheckDriver.java
>
> This checks the position values of X, Y and Z with the following code.
>
> double[] hitPosition = hit.getPosition(); if (hitPosition[0] == 0) {
> throw new RuntimeException("Hit X position is zero for hit " +
> hit.getIdentifier().toHexString());
> }
> [etc.]
>
> I do not see that any of the positions are zero. The job has processed over 1 million events.
>
> This is not a pristine copy of the trunk, but I don't think I have any local changes that would affect this.
>
> I'm kind of confused about using the LCIO command line tool, because I had thought we were not explicitly writing the hit positions into the LCIO output in order to save space, and that these positions were recovered later by using the geometry. So I would have thought that the raw LCIO dump would always display 0,0,0 as the CalHit position. Perhaps this has changed since I looked at it.
>
> --Jeremy
>
> -----Original Message-----
> From: Nathan Baltzell [mailto:[log in to unmask]]
> Sent: Friday, February 13, 2015 11:07 AM
> To: McCormick, Jeremy I.
> Subject: Fwd: ECal cell positions
>
>
>
> Begin forwarded message:
>
>> From: Nathan Baltzell <[log in to unmask]>
>> Subject: Re: ECal cell positions
>> Date: February 13, 2015 1:38:31 PM EST
>> To: "Graf, Norman A." <[log in to unmask]>
>>
>> And here is the lcio output of that command on that file from earlier this week:
>>
>> /volatile/hallb/hps/baltzell/runped+norunped.slcio
>>
>>
>> On Feb 13, 2015, at 1:36 PM, "Graf, Norman A." <[log in to unmask]> wrote:
>>
>>> Thanks.
>>>
>>> -----Original Message-----
>>> From: Nathan Baltzell [mailto:[log in to unmask]]
>>> Sent: Friday, February 13, 2015 10:22 AM
>>> To: Graf, Norman A.
>>> Cc: Holly Vance
>>> Subject: Re: ECal cell positions
>>>
>>> Here's a file I've been using:
>>> /volatile/hallb/hps/baltzell/hps_003434.evio.0
>>>
>>> And my command:
>>> java -cp hps-distribution-3.1-SNAPSHOT-bin.jar
>>> org.hps.evio.EvioToLcio -x
>>> /org/hps/steering/recon/EngineeringRun2014ECalRecon.lcsim -r -d
>>> HPS-ECalCommissioning -R 3325 -DoutputFile=out hps_003434.evio.0
>>>
>>>
>>> On Feb 13, 2015, at 13:10, Graf, Norman A. <[log in to unmask]> wrote:
>>>
>>>> Hi Holly, Nathan,
>>>> I have a hunch that I'd like to follow up on. Can you point me to
>>>> the evio file you're using and send me the command line that you're
>>>> using to run the reconstruction? I'm sure it's not specific to any
>>>> one file, but I'd like to be able to exactly reproduce what you're
>>>> doing so we can follow up on an event-by-event basis if needed.
>>>> Thanks,
>>>> Norman
>>>>
>>>> From: Holly Vance [mailto:[log in to unmask]]
>>>> Sent: Friday, February 13, 2015 9:13 AM
>>>> To: Nathan Baltzell
>>>> Cc: Graf, Norman A.; McCormick, Jeremy I.; Graham, Mathew Thomas;
>>>> Uemura, Sho
>>>> Subject: Re: ECAL beam gap settings
>>>>
>>>> Hi Nathan,
>>>>
>>>> I just ran through a bunch of evio files running the pass0 steering. I set the thresholds in clustering to negative values to allow for these hits, but they all appear to have valid coordinates in the Calorimeter (using java to readout). This is using all of the latest updates in the trunk.
>>>>
>>>> It's possible there is another difference again between the C++ API readout and java readout?
>>>>
>>>> -Holly
>>>>
>>>> On Fri, Feb 13, 2015 at 11:58 AM, Nathan Baltzell <[log in to unmask]> wrote:
>>>> Hi Norman and All,
>>>>
>>>> We need some help on this:
>>>>
>>>> I've looked closer at the reconstructed slcio files with "lcio" and the c++ API.
>>>> In both cases we now see some EcalCalHits with (0,0,0) position.
>>>>
>>>> We have this behavior using the pass0 steering file and the pass0 detector and the current trunk.
>>>> We did not have this behavior at the beginning of the week using the same steering file and detector.
>>>> The changes Holly and I have made to the reconstruction code should
>>>> not be present in this comparison, because the changes are not enabled in that steering file.
>>>>
>>>> Below you can see a comparison for the two scenarios (same event,
>>>> same detector, same steering, different svn checkout time).
>>>>
>>>>
>>>> Some points:
>>>>
>>>> The cellID is unchanged from earlier this week, even for the (0,0,0) hits.
>>>>
>>>> The positions of these (0,0,0) hits earlier this week was a valid crystal position.
>>>>
>>>> Negative energy hits always seem to get (0,0,0), but also sometimes hits above clustering threshold (10 MeV).
>>>>
>>>> We've not yet found a case where one of these (0,0,0) hits ends up
>>>> in a cluster, maybe due to geometric clustering cuts or energy
>>>> cuts, although that doesn't mean it can't happen. (And I've not
>>>> found a case where a cluster position is changed (e.g. by now not including that hit.) Holly is doing some tests inside her ReconClusterer to see if it ever actually sees one of the (0,0,0) hits.
>>>>
>>>> There have been a variety of changes in lcsim in the past week or two, including calorimeter hit stuff.
>>>>
>>>>
>>>> What we have now:
>>>> -----------------------------------------------------------------
>>>>
>>>> Collection Name : EcalCalHits
>>>> Collection Type : CalorimeterHit
>>>> Number of Elements : 12
>>>> Flag Word: 0x88000000
>>>> Collection Parameters :
>>>> ReadoutName = EcalHits
>>>>
>>>>
>>>> [ id ] | [cellID0] | [cellID1] | energy | energyerr | position (x,y,z)
>>>> [4e69048b] | [0001ef0d] | [00000000] | 3.038e-01 | - NA - |
>>>> (-2.054e+02,2.767e+01,1.472e+03) [50a969e4] | [0002ef0d] |
>>>> [00000000]
>>>> | 4.916e-02 | - NA - | (-2.054e+02,4.268e+01,1.472e+03) [2267211b]
>>>> | |
>>>> [0003ef0d] | [00000000] | 2.338e-02 | - NA - |
>>>> (-2.054e+02,5.769e+01,1.472e+03) [20ae8542] | [0001ee0d] |
>>>> [00000000]
>>>> | 2.128e-02 | - NA - | (-2.208e+02,2.767e+01,1.472e+03) [21aec0d1]
>>>> | |
>>>> [0002ee0d] | [00000000] | 1.554e-02 | - NA - |
>>>> (-2.208e+02,4.268e+01,1.472e+03) [57f4ea9d] | [003e020d] |
>>>> [00000000]
>>>> | 8.208e-03 | - NA - | (0.000e+00,0.000e+00,0.000e+00) [10571688]
>>>> | |
>>>> [003f010d] | [00000000] | 5.379e-01 | - NA - |
>>>> (5.005e+01,-2.767e+01,1.473e+03) [45884319] | [003e010d] |
>>>> [00000000]
>>>> | 3.216e-02 | - NA - | (5.005e+01,-4.268e+01,1.473e+03) [74ed41f8]
>>>> | |
>>>> [003fff0d] | [00000000] | 1.385e-01 | - NA - |
>>>> (3.500e+01,-2.767e+01,1.473e+03) [04863cc1] | [003efe0d] |
>>>> [00000000]
>>>> | 3.928e-02 | - NA - | (2.015e+01,-4.268e+01,1.473e+03) [08fea539]
>>>> | |
>>>> [003efb0d] | [00000000] | -8.771e-02 | - NA - |
>>>> (0.000e+00,0.000e+00,0.000e+00) [061145cc] | [003efa0d] |
>>>> [00000000]
>>>> | -1.178e-02 | - NA - | (0.000e+00,0.000e+00,0.000e+00)
>>>>
>>>> --------------------------------
>>>>
>>>> What we had earlier this week:
>>>>
>>>> [ id ] | [cellID0] | [cellID1] | energy | energyerr | position (x,y,z)
>>>> [59678f0a] | [0001ef0d] | [00000000] | 3.038e-01 | - NA - |
>>>> (-2.054e+02,2.767e+01,1.472e+03) [1de00761] | [0002ef0d] |
>>>> [00000000]
>>>> | 4.916e-02 | - NA - | (-2.054e+02,4.268e+01,1.472e+03) [5f048099]
>>>> | |
>>>> [0003ef0d] | [00000000] | 2.338e-02 | - NA - |
>>>> (-2.054e+02,5.769e+01,1.472e+03) [2096ed8b] | [0001ee0d] |
>>>> [00000000]
>>>> | 2.128e-02 | - NA - | (-2.208e+02,2.767e+01,1.472e+03) [14c55164]
>>>> | |
>>>> [0002ee0d] | [00000000] | 1.554e-02 | - NA - |
>>>> (-2.208e+02,4.268e+01,1.472e+03) [266286e3] | [003e020d] |
>>>> [00000000]
>>>> | 8.208e-03 | - NA - | (6.491e+01,-4.268e+01,1.473e+03) [0e85b4c5]
>>>> | |
>>>> [003f010d] | [00000000] | 5.379e-01 | - NA - |
>>>> (5.005e+01,-2.767e+01,1.473e+03) [6c1ef8f5] | [003e010d] |
>>>> [00000000]
>>>> | 3.216e-02 | - NA - | (5.005e+01,-4.268e+01,1.473e+03) [656ad447]
>>>> | |
>>>> [003fff0d] | [00000000] | 1.385e-01 | - NA - |
>>>> (3.500e+01,-2.767e+01,1.473e+03) [4896b555] | [003efe0d] |
>>>> [00000000]
>>>> | 3.928e-02 | - NA - | (2.015e+01,-4.268e+01,1.473e+03) [1e5b04ae]
>>>> | |
>>>> [003efb0d] | [00000000] | -8.771e-02 | - NA - |
>>>> (-2.447e+01,-4.268e+01,1.473e+03) [69904b13] | [003efa0d] |
>>>> [00000000] | -1.178e-02 | - NA - |
>>>> (-3.937e+01,-4.268e+01,1.473e+03)
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> Nathan
>>>>
>>>>
>>>> On Feb 12, 2015, at 20:03, Nathan Baltzell <[log in to unmask]> wrote:
>>>>
>>>>> It is hit position and I think only for hits with energies below clustering threshold.
>>>>> It is definitely not correlated with changes from new detector, as
>>>>> I see the same for both old and new detector.
>>>>>
>>>>> I was just looking at raw dump of lcio which doesn't give me position.
>>>>>
>>>>> I put two files here, v1.slcio and v2.slcio for old and new
>>>>> detector
>>>>> (hps_003434.evio.0) if you can take a look:
>>>>>
>>>>> /volatile/hallb/hps/baltzell
>>>>>
>>>>> -Nathan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Feb 12, 2015, at 7:49 PM, "Graf, Norman A." <[log in to unmask]> wrote:
>>>>>
>>>>>> Thanks for the update.
>>>>>> What are the cell indices for the hits with position of (0,0,0)?
>>>>>> Or is that the cluster position?
>>>>>> Norman
>>>>>> ________________________________________
>>>>>> From: Nathan Baltzell <[log in to unmask]>
>>>>>> Sent: Thursday, February 12, 2015 4:32 PM
>>>>>> To: Graf, Norman A.
>>>>>> Cc: McCormick, Jeremy I.; Holly Vance; Graham, Mathew Thomas;
>>>>>> Uemura, Sho
>>>>>> Subject: Re: ECAL beam gap settings
>>>>>>
>>>>>>> But isn't the whole point of pass1 to pick up the new calibrations?
>>>>>> Yes, absolutely, and pedestals.
>>>>>>
>>>>>> The cross-check I just now ran was with the only difference being
>>>>>> the detector (same everything else) just to test that alone. And every recon hit/cluster in the top is shifted up by 3mm, no other differences.
>>>>>> So that is good.
>>>>>>
>>>>>> But we now have hits below clustering threshold of 10 MeV recorded with position of (0,0,0).
>>>>>> I don't know why, that wasn't the case a week ago. Any ideas? Maybe nothing to worry about.
>>>>>>
>>>>>> -Nathan
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Feb 12, 2015, at 7:26 PM, "Graf, Norman A." <[log in to unmask]> wrote:
>>>>>>
>>>>>>> Hi Nathan,
>>>>>>> Thanks for running this cross-check.
>>>>>>> But isn't the whole point of pass1 to pick up the new calibrations?
>>>>>>> Won't that change the output as well?
>>>>>>> Interested to see what differences you find.
>>>>>>> Norman
>>>>>>> ________________________________________
>>>>>>> From: Nathan Baltzell <[log in to unmask]>
>>>>>>> Sent: Thursday, February 12, 2015 3:50 PM
>>>>>>> To: Graf, Norman A.
>>>>>>> Cc: McCormick, Jeremy I.; Holly Vance; Graham, Mathew Thomas
>>>>>>> Subject: Re: ECAL beam gap settings
>>>>>>>
>>>>>>> Looks like pass0 only defined the detector on the command line as an
>>>>>>> option to EvioToLcio. Matt?
>>>>>>>
>>>>>>> One quick test would be to run a dozen events with the old and
>>>>>>> new detectors and verify the *only* difference is hit and cluster positions in the top half
>>>>>>> are shifted by 3mm. Doing it now ....
>>>>>>>
>>>>>>> -Nathan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Feb 12, 2015, at 6:21 PM, "Graf, Norman A." <[log in to unmask]> wrote:
>>>>>>>
>>>>>>>> The pass1 reco steering file should point to this detector.
>>>>>>>> We might want to run a test recon job or two just to make sure
>>>>>>>> that everything is OK.
>>>>>>>> Norman
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: McCormick, Jeremy I.
>>>>>>>> Sent: Thursday, February 12, 2015 3:17 PM
>>>>>>>> To: Nathan Baltzell
>>>>>>>> Cc: Graf, Norman A.; Holly Vance
>>>>>>>> Subject: Re: ECAL beam gap settings
>>>>>>>>
>>>>>>>> So should I go ahead and make the HPS Java release then?
>>>>>>>>
>>>>>>>> On Feb 12, 2015, at 2:47 PM, Nathan Baltzell <[log in to unmask]> wrote:
>>>>>>>>
>>>>>>>>> Sounds good. I was about to do it, but please go ahead.
>>>>>>>>> Jeremy wants to make a release before pass1, and this is the last change.
>>>>>>>>>
>>>>>>>>> Holly, are you ok with this:
>>>>>>>>> <layout beamgapBottom="20.0*mm" beamgapTop="23.0*mm" nx="46" ny="5"
>>>>>>>>> dface="ecal_dface"> ?
>>>>>>>>>
>>>>>>>>> Holly can best answer your other questions. I think there was
>>>>>>>>> a rotation, but less significant than the 3mm shift in y.
>>>>>>>>>
>>>>>>>>>> Did you update your lcsim installation before generating the heprep?
>>>>>>>>> I think so, I started with a fresh full checkout of hps-java this morning.
>>>>>>>>>
>>>>>>>>> -Nathan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Feb 12, 2015, at 17:38, Graf, Norman A. <[log in to unmask]> wrote:
>>>>>>>>>
>>>>>>>>>> Hello Nathan,
>>>>>>>>>> I'll go ahead and check in a new detector which contains
>>>>>>>>>> those values for the beam gaps.
>>>>>>>>>> How do these values correspond to the survey positions that
>>>>>>>>>> Gabriel presented at the collaboration meeting? viz.
>>>>>>>>>>
>>>>>>>>>> https://confluence.slac.stanford.edu/download/attachments/184
>>>>>>>>>> 7
>>>>>>>>>> 1
>>>>>>>>>> 5057/2
>>>>>>>>>> 015-01_HPS_GCharles_MountingInstallingCalo.pdf?version=1&modi
>>>>>>>>>> f
>>>>>>>>>> i
>>>>>>>>>> cation
>>>>>>>>>> Date=1422287889000&api=v2#page=21
>>>>>>>>>>
>>>>>>>>>> In previous communications there was also mention of a
>>>>>>>>>> rotation around y. We don't support that at the moment. Was
>>>>>>>>>> it an appreciable amount?
>>>>>>>>>>
>>>>>>>>>> Did you update your lcsim installation before generating the heprep?
>>>>>>>>>>
>>>>>>>>>> Norman
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Nathan Baltzell [mailto:[log in to unmask]]
>>>>>>>>>> Sent: Thursday, February 12, 2015 2:29 PM
>>>>>>>>>> To: Graf, Norman A.
>>>>>>>>>> Cc: Holly Vance
>>>>>>>>>> Subject: Re: ECAL beam gap settings
>>>>>>>>>>
>>>>>>>>>> Thanks Norman,
>>>>>>>>>>
>>>>>>>>>> Awesome, Jeremy said he could see it too in Wired, I don't know why my wired isn't working.
>>>>>>>>>>
>>>>>>>>>> From what I understand from Holly, the correct setting should be:
>>>>>>>>>>
>>>>>>>>>>> <layout beamgapBottom="20.0*mm" beamgapTop="23.0*mm" nx="46" ny="5"
>>>>>>>>>>> dface="ecal_dface">
>>>>>>>>>>
>>>>>>>>>> Holly, can you confirm this? I'm going to check this in to svn as a new detector for pass1 unless you want to.
>>>>>>>>>>
>>>>>>>>>> (I just put in a bigger number 50 before to make sure it
>>>>>>>>>> would be
>>>>>>>>>> visible/measureable.)
>>>>>>>>>>
>>>>>>>>>>> Are we going to center the ECal in y for the engineering run?
>>>>>>>>>>> Are the top and bottom lined up in x?
>>>>>>>>>> My understanding is that the setting above is as close as possible to the survey as the software currently allows. Although I'd guess the real calorimeter halves cannot be off much in x due to the mounting.
>>>>>>>>>>
>>>>>>>>>> -Nathan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Feb 12, 2015, at 17:07, Graf, Norman A. <[log in to unmask]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Nathan,
>>>>>>>>>>> Are 20 and 50 the real values, or were you just putting in something to test?
>>>>>>>>>>> I put in 20 and 50 and was able to confirm that the heprep reproduced that:
>>>>>>>>>>> <image001.png>
>>>>>>>>>>>
>>>>>>>>>>> Are we going to center the ECal in y for the engineering run?
>>>>>>>>>>> Are the top and bottom lined up in x?
>>>>>>>>>>> Norman
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: [log in to unmask]
>>>>>>>>>>> [mailto:[log in to unmask]] On Behalf Of Nathan
>>>>>>>>>>> Baltzell
>>>>>>>>>>> Sent: Thursday, February 12, 2015 11:13 AM
>>>>>>>>>>> To: McCormick, Jeremy I.
>>>>>>>>>>> Cc: Holly Vance; hps-software
>>>>>>>>>>> Subject: Re: ECAL beam gap settings
>>>>>>>>>>>
>>>>>>>>>>> Hi Jeremy,
>>>>>>>>>>>
>>>>>>>>>>> I tried to edit HPSECalCommissioning's compat.xml by
>>>>>>>>>>> changing
>>>>>>>>>>>
>>>>>>>>>>> <layout beamgap="20.0*mm" nx="46" ny="5" dface="ecal_dface">
>>>>>>>>>>>
>>>>>>>>>>> to
>>>>>>>>>>>
>>>>>>>>>>> <layout beamgapBottom="20.0*mm" beamgapTop="50.0*mm" nx="46" ny="5"
>>>>>>>>>>> dface="ecal_dface">
>>>>>>>>>>>
>>>>>>>>>>> but JAS+Wired doesn't show the detector at all after that.
>>>>>>>>>>> And I didn't get any log messages.
>>>>>>>>>>>
>>>>>>>>>>> Any ideas?
>>>>>>>>>>>
>>>>>>>>>>> -Nathan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Feb 2, 2015, at 17:31, McCormick, Jeremy I. <[log in to unmask]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I have committed a change to lcsim so that the ECAL top and bottom beam gap sizes can be set in the compact.xml file.
>>>>>>>>>>>>
>>>>>>>>>>>> See this resolved JIRA item
>>>>>>>>>>>>
>>>>>>>>>>>> https://jira.slac.stanford.edu/browse/HPSJAVA-388
>>>>>>>>>>>>
>>>>>>>>>>>> The parameters are set like
>>>>>>>>>>>>
>>>>>>>>>>>> <layout beamgapBottom="40.0*mm" beamgapTop="20.0*mm" ... >
>>>>>>>>>>>>
>>>>>>>>>>>> See this file for a complete example
>>>>>>>>>>>>
>>>>>>>>>>>> lcsim/trunk/detector-framework/src/test/resources/org/lcsim
>>>>>>>>>>>> /
>>>>>>>>>>>> g
>>>>>>>>>>>> eometr
>>>>>>>>>>>> y
>>>>>>>>>>>> /subdetector/HPSEcal3Test.xml
>>>>>>>>>>>>
>>>>>>>>>>>> And you can test this with
>>>>>>>>>>>>
>>>>>>>>>>>> cd lcsim/trunk/detector-framework; mvn test
>>>>>>>>>>>> -Dtest=HPSEcal3Test
>>>>>>>>>>>>
>>>>>>>>>>>> I verified that it looks right in the output Heprep file in JAS3 and also in the Geant4 visualization, where I saw the top and bottom gaps had different sizes from the parameters.
>>>>>>>>>>>>
>>>>>>>>>>>> You will probably want to verify this separately anyways as a crosscheck, if you plan to use this for reconstruction or simulation.
>>>>>>>>>>>>
>>>>>>>>>>>> This doesn't solve the problem of being able to align the
>>>>>>>>>>>> ECAL in all generality. That is a lot more complex to
>>>>>>>>>>>> implement and will require writing a new detector model
>>>>>>>>>>>> that is structured differently than the current one. (I
>>>>>>>>>>>> added a JIRA item for this, but I don't know when we will
>>>>>>>>>>>> be able to do it!)
>>>>>>>>>>>>
>>>>>>>>>>>> --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-SO
>>>>>>>>>>>> F
>>>>>>>>>>>> T
>>>>>>>>>>>> WARE&A
>>>>>>>>>>>> =
>>>>>>>>>>>> 1
>>>>>>>>>>>
>>>>>>>>>>> ############################################################
>>>>>>>>>>> #
>>>>>>>>>>> #
>>>>>>>>>>> ######
>>>>>>>>>>> ##
>>>>>>>>>>> ##
>>>>>>>>>>> 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-SOF
>>>>>>>>>>> T
>>>>>>>>>>> W
>>>>>>>>>>> ARE&A=
>>>>>>>>>>> 1
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
########################################################################
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
########################################################################
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
