LISTSERV mailing list manager LISTSERV 16.5

Help for HPS-SOFTWARE Archives


HPS-SOFTWARE Archives

HPS-SOFTWARE Archives


HPS-SOFTWARE@LISTSERV.SLAC.STANFORD.EDU


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

HPS-SOFTWARE Home

HPS-SOFTWARE Home

HPS-SOFTWARE  February 2015

HPS-SOFTWARE February 2015

Subject:

Re: ECal cell positions

From:

Nathan Baltzell <[log in to unmask]>

Reply-To:

Software for the Heavy Photon Search Experiment <[log in to unmask]>

Date:

Fri, 13 Feb 2015 15:48:02 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (535 lines)

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/1847
>>>>>>>>>> 1
>>>>>>>>>> 5057/2
>>>>>>>>>> 015-01_HPS_GCharles_MountingInstallingCalo.pdf?version=1&modif
>>>>>>>>>> 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-SOF
>>>>>>>>>>>> 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-SOFT
>>>>>>>>>>> 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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
June 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011

ATOM RSS1 RSS2



LISTSERV.SLAC.STANFORD.EDU

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager

Privacy Notice, Security Notice and Terms of Use