LISTSERV 16.5 - HPS-SOFTWARE Archives

I'm still getting the same problem.

slic_dir = /u/group/hps/hps_soft/slic/HEAD
and detector = HPS-EngRun2015-Nominal-v3-fieldmap

bash -c 'source ${slic_dir}/init_ilcsoft.sh; exec csh'
source ${slic_dir}/geant4/build-10.01.p02/geant4make.csh ${slic_dir}/geant4/build-10.01.p02
ln -s /u/group/hps/hps_soft/fieldmaps fieldmap

${slic_dir}/slic/HEAD/bin/slic -P /u/group/hps/hps_soft/slic/HEAD/slic/HEAD/data/particle.tbl -i beam-tri.stdhep -g ${det_dir}/${detector}/${detector}.lcdd -o out.slcio

Is there something additional that needs to be done to incorporate the changes you made?

________________________________________
From: McCormick, Jeremy I. <[log in to unmask]>
Sent: Tuesday, October 13, 2015 5:35 PM
To: Bradley T Yale
Cc: hps-software
Subject: RE: MC has problems

Hi,

I've checked in some changes to SLIC trunk which should fix the issues with the beam-tri jobs crashing.

The JLAB copy should have the fix in it now.

/group/hps/hps_soft/slic/HEAD/

I did some checks on a few of the sample StdHep files you sent me, and I also spot checked a few merged events (beam/tri/Aprime) at SLAC.

I can confirm now that the gen status 0 particles are skipped, and also the displaced vertices are put in the right place by Geant now.  The verbose tracking output shows that the Z = 0.1 mm particles which occur in some of the merged events look correct now.

Can you run some of the beam-tri events at JLAB through this new SLIC version, so Sho and others can check the LCIO output?  I don't think we need many events to confirm it is working and looks correct, maybe just around 10k.

Thanks.

--Jeremy

-----Original Message-----
From: Sho Uemura [mailto:[log in to unmask]]
Sent: Tuesday, October 13, 2015 10:15 AM
To: Bradley T Yale
Cc: Graham, Mathew Thomas; McCormick, Jeremy I.; Omar Moreno; Graf, Norman A.; Solt, Matthew Reagan
Subject: Re: MC has problems

Can you run more tritrig-beam-tri - I think 5000 files would be ideal.
Either v3 or v3-fieldmap is fine, and this is not urgent. Thanks.

On Tue, 6 Oct 2015, Sho Uemura wrote:

> Looking at the files. I'll let you know if I want more.
>
> Thanks!
>
> On Wed, 7 Oct 2015, Bradley T Yale wrote:
>
>> 500 tritrig-beam-tri are now in there.
>> This is kind of what I was going for; just let me know if any
>> statistics are too low for a study and I'll make more.
>> I think all the SLIC problems are solved now, so I can start making
>> fieldmap samples to look at.
>>
>>
>> ________________________________________
>> From: Sho Uemura <[log in to unmask]>
>> Sent: Tuesday, October 6, 2015 3:36 PM
>> To: Bradley T Yale
>> Cc: Graham, Mathew Thomas; McCormick, Jeremy I.; Omar Moreno; Graf,
>> Norman A.; Solt, Matthew Reagan
>> Subject: Re: MC has problems
>>
>> Yeah, that's fine. I don't care about the fieldmap.
>>
>> On Tue, 6 Oct 2015, Bradley T Yale wrote:
>>
>>> I'm trying to figure out an issue with running SLIC at Jlab with the
>>> new version /u/group/hps/hps_soft/slic/HEAD
>>>
>>> based on
>>> unable to connect socket for URL
>>> 'http://www.lcsim.org/schemas/gdml/1.0/gdml.xsd'
>>> when it used to work before.
>>>
>>> It could be tied to a difference in the old
>>> /u/group/hps/hps_soft/slic/v00-02/init_ilcsoft.csh
>>> and new
>>> /u/group/hps/hps_soft/slic/HEAD/init_ilcsoft.sh
>>> but if anyone can help with that, it's a very important issue to fix ASAP.
>>>
>>> In the meantime, I can make all the tritrig-beam-tri that you need
>>> without the fieldmap and the previous version of SLIC.
>>>
>>> ________________________________________
>>> From: Sho Uemura <[log in to unmask]>
>>> Sent: Tuesday, October 6, 2015 3:27 PM
>>> To: Graham, Mathew Thomas
>>> Cc: Bradley T Yale; Omar Moreno; Graf, Norman A.; Solt, Matthew
>>> Reagan
>>> Subject: Re: MC has problems
>>>
>>> How much tritrig-beam-tri is in the pipeline?
>>>
>>> I would like to have a factor of 50 more than the 9 recon files that
>>> currently exist. I think we need to compare vertex tails between
>>> data and MC for this readiness document thing, so the sooner the
>>> better - if what I'm asking for is too much to get done quickly, let
>>> me know what you think is doable in a week.
>>>
>>> On Tue, 29 Sep 2015, Graham, Mathew Thomas wrote:
>>>
>>>>
>>>> Well, I want tritrig more than tritrig-beam-tri.  I actually wanted
>>>> to put the beam-tri generation at the end because I think that
>>>> takes the longest?not sure how true that is (Brad?).
>>>>
>>>>> On Sep 29, 2015, at 11:32 AM, Sho Uemura <[log in to unmask]> wrote:
>>>>>
>>>>> Agree.
>>>>>
>>>>> But I want tritrig-beam-tri more than I want tritrig.
>>>>>
>>>>> On Tue, 29 Sep 2015, Graham, Mathew Thomas wrote:
>>>>>
>>>>>> Ok?I think we need to trash the pass2 MC using the field map
>>>>>> until we can figure out what?s wrong with slic.
>>>>>>
>>>>>> However, I do think we need some samples ASAP, so I think we
>>>>>> should use the v3 geometry sans fieldmap
>>>>>> (HPS-EngRun2015-Nominal-v3) for a few limited samples?how?s this
>>>>>> for a priority list?  At some point we?ll fix the fieldmap problem and then we can stop and go back:
>>>>>>
>>>>>>
>>>>>> 1.  Moller
>>>>>> 2.  tritrig
>>>>>> 3.  RAD
>>>>>> 4.  BH
>>>>>> 5.  ap
>>>>>> 6.  beam-tri
>>>>>> 7.  tritrig-beam-tri
>>>>>>
>>>>>> Do people object?  I?ll post this to the analysis list as well if
>>>>>> you folks agree.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sep 29, 2015, at 11:21 AM, Omar Moreno
>>>>>> <[log in to unmask]<mailto:[log in to unmask]>> wrote:
>>>>>>
>>>>>>
>>>>>> Mollers look bad as well.
>>>>>>
>>>>>> On Sep 29, 2015 11:20 AM, "Graham, Mathew Thomas"
>>>>>> <[log in to unmask]<mailto:[log in to unmask]>> wrote:
>>>>>>
>>>>>> Does anyone know if this is the case for all pass2 MC files or
>>>>>> just RAD?
>>>>>>
>>>>>>> On Sep 28, 2015, at 6:20 PM, Sho Uemura
>>>>>>> <[log in to unmask]<mailto:[log in to unmask]>> wrote:
>>>>>>>
>>>>>>> Looking at the HelicalTrackHits in a pairs1 recon file, it looks
>>>>>>> like the readout and hit recon is working OK - I see sets of
>>>>>>> in-time hits - but they seem to be roughly on straight lines.
>>>>>>> That would explain why omega is small and zero-centered, and
>>>>>>> chi2 is large because the multiple scattering is being underestimated.
>>>>>>>
>>>>>>> Hard to reconcile this with what Norman sees using the same
>>>>>>> detector, and I see no smoking gun in the SLIC logs.
>>>>>>>
>>>>>>> On Mon, 28 Sep 2015, Graham, Mathew Thomas wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> This is the command being run:
>>>>>>>>
>>>>>>>> slic -i rot_RAD.stdhep -g
>>>>>>>> /u/group/hps/hps_soft/hps/detector-data/detectors/HPS-EngRun201
>>>>>>>> 5-Nominal-v3-fieldmap/HPS-EngRun2015-Nominal-v3-fieldmap.lcdd
>>>>>>>> -o out.slcio -d18{159} -r5000000
>>>>>>>>
>>>>>>>> The SLIC log files say that it?s being read:
>>>>>>>>
>>>>>>>>
>>>>>>>> ***********************
>>>>>>>> --- Warning from G4Material::G4Material() define a material
>>>>>>>> with
>>>>>>>> density=0 is not allowed.
>>>>>>>> The material G4_Galactic will be constructed with the default
>>>>>>>> minimal
>>>>>>>> density: 1e-25g/cm3
>>>>>>>> -----------------------------------------------------------
>>>>>>>>    Magnetic field
>>>>>>>> -----------------------------------------------------------
>>>>>>>> ---> Reading the field grid from
>>>>>>>> fieldmap/125acm2_3kg_corrected_unfolded_scaled_0.7992.dat ...
>>>>>>>> [ Number of values x,y,z: 101 29 601 ]
>>>>>>>> ---> ... done reading
>>>>>>>> Read values of field from file
>>>>>>>> fieldmap/125acm2_3kg_corrected_unfolded_scaled_0.7992.dat
>>>>>>>> ---> assumed the order:  x, y, z, Bx, By, Bz Min values x,y,z:
>>>>>>>> ---> -250 -70 -1500 cm Max values x,y,z: 250 70 1500 cm The
>>>>>>>> ---> field will be offset by 457.2 0 0 cm
>>>>>>>> After reordering if necessary
>>>>>>>> ---> Min values x,y,z: -250 -70 -1500 cm Max values x,y,z: 250
>>>>>>>> ---> 70 1500 cm Range of values x,y,z: 500 140 3000 cm in z
>>>>>>>> -----------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Sep 28, 2015, at 12:11 PM, Graf, Norman A.
>>>>>>>>> <[log in to unmask]<mailto:[log in to unmask]>> wrote:
>>>>>>>>>
>>>>>>>>> Yup. It's always upside down. Or flipped. Or you're looking
>>>>>>>>> upstream instead of downstream. Or something else...
>>>>>>>>> But thanks for double-checking.
>>>>>>>>> ________________________________________
>>>>>>>>> From: Sho Uemura
>>>>>>>>> <[log in to unmask]<mailto:[log in to unmask]>>
>>>>>>>>> Sent: Monday, September 28, 2015 12:11 PM
>>>>>>>>> To: Graf, Norman A.
>>>>>>>>> Cc: Omar Moreno; Graham, Mathew Thomas; Bradley Yale; Solt,
>>>>>>>>> Matthew Reagan
>>>>>>>>> Subject: Re: MC has problems
>>>>>>>>>
>>>>>>>>> Hang on, I'm not reading that picture correctly - the
>>>>>>>>> wireframe confused me. The photon hole is at the top and the
>>>>>>>>> electron slot is on bottom. So the picture looks fine.
>>>>>>>>>
>>>>>>>>> Never mind.
>>>>>>>>>
>>>>>>>>> On Mon, 28 Sep 2015, Sho Uemura wrote:
>>>>>>>>>
>>>>>>>>>> Looks like field is flipped then.
>>>>>>>>>>
>>>>>>>>>> When the photon beam passes through the round hole (roughly
>>>>>>>>>> where your red beam is going), the momentum-smeared electron
>>>>>>>>>> beam is supposed to pass through the slot (roughly where your
>>>>>>>>>> green beam is going).
>>>>>>>>>>
>>>>>>>>>> On Mon, 28 Sep 2015, Graf, Norman A. wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello All,
>>>>>>>>>>>
>>>>>>>>>>> Here's a screen shot of a 1.056GeV electron in the
>>>>>>>>>>> HPS-EngRun2015-Nominal-v3-fieldmap
>>>>>>>>>>>
>>>>>>>>>>> detector. The photon (in green) is pretty much along the z
>>>>>>>>>>> axis, while the electron (red)
>>>>>>>>>>>
>>>>>>>>>>> is curving. I'm running some higher statistics and will push
>>>>>>>>>>> them through the standard
>>>>>>>>>>>
>>>>>>>>>>> reconstruction and let you know what I find.
>>>>>>>>>>>
>>>>>>>>>>> Norman
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [cid:66c699a9-d25e-4fad-8feb-2a8e0a13f0c5]
>>>>>>>>>>>
>>>>>>>>>>> ________________________________
>>>>>>>>>>> From: Omar Moreno
>>>>>>>>>>> <[log in to unmask]<mailto:[log in to unmask]>>
>>>>>>>>>>> Sent: Monday, September 28, 2015 11:12 AM
>>>>>>>>>>> To: Graham, Mathew Thomas
>>>>>>>>>>> Cc: Bradley Yale; Uemura, Sho; Solt, Matthew Reagan; Graf,
>>>>>>>>>>> Norman A.
>>>>>>>>>>> Subject: Re: MC has problems
>>>>>>>>>>>
>>>>>>>>>>> That's what I'm suspecting too.  That's why the Moller's
>>>>>>>>>>> aren't showing up in the correct position in the Ecal.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Sep 28, 2015 at 11:03 AM, Graham, Mathew Thomas
>>>>>>>>>>> <[log in to unmask]<mailto:[log in to unmask]>
>>>>>>>>>>> <mailto:[log in to unmask]<mailto:[log in to unmask]
>>>>>>>>>>> rd.edu>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>> Omega looks very wrong.  It looks like the B-field may not
>>>>>>>>>>> be working in SLIC?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sep 28, 2015, at 11:02 AM, Omar Moreno
>>>>>>>>>>> <[log in to unmask]<mailto:[log in to unmask]><mailto:em
>>>>>>>>>>> [log in to unmask]<mailto:[log in to unmask]>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> These are plots of tracks from the latest radiative only MC.
>>>>>>>>>>> Looks like all we are seeing is junk tracks and the timing
>>>>>>>>>>> looks strange.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <Screenshot from 2015-09-28 10:58:02.png><Screenshot from
>>>>>>>>>>> 2015-09-28
>>>>>>>>>>> 10:58:07.png>
>>>>>>>>>>> <Screenshot from 2015-09-28 10:57:46.png><Screenshot from
>>>>>>>>>>> 2015-09-28
>>>>>>>>>>> 10:55:34.png>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Sep 28, 2015 at 9:44 AM, Omar Moreno
>>>>>>>>>>> <[log in to unmask]<mailto:[log in to unmask]><mailto:em
>>>>>>>>>>> [log in to unmask]<mailto:[log in to unmask]>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>> Just look at the DST.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Sep 28, 2015 at 9:43 AM, Graham, Mathew Thomas
>>>>>>>>>>> <[log in to unmask]<mailto:[log in to unmask]>
>>>>>>>>>>> <mailto:[log in to unmask]<mailto:[log in to unmask]
>>>>>>>>>>> rd.edu>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Plots?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sep 28, 2015, at 9:39 AM, Omar Moreno
>>>>>>>>>>> <[log in to unmask]<mailto:[log in to unmask]><mailto:em
>>>>>>>>>>> [log in to unmask]<mailto:[log in to unmask]>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Bradley, Matt,
>>>>>>>>>>>
>>>>>>>>>>> I took a closer look at the Moller MC last Friday and it
>>>>>>>>>>> looks terrible.
>>>>>>>>>>> The time of the SVT tracks is Bimodal and the position of
>>>>>>>>>>> the Ecal clusters looks like they are in the opposite side
>>>>>>>>>>> of where they are suppose to be.
>>>>>>>>>>>
>>>>>>>>>>> Matt S. reported similar issues with the tri-trig(?) MC last
>>>>>>>>>>> Friday.  Any idea what's going on? I believe Sho is looking
>>>>>>>>>>> at the SVT timing issues, but maybe this is being caused by
>>>>>>>>>>> several things.
>>>>>>>>>>>
>>>>>>>>>>> --Omar Moreno
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>

########################################################################
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