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