 |
 |
Hi Holly, It looks like Nathan just adds an empty collection if no RF hits are found. This should fix the DST issue. --Omar Moreno On Thu, Dec 17, 2015 at 10:56 AM, Holly Vance <[log in to unmask]> wrote: > Hi Omar, > > Either option is fine with me. Perhaps if it doesn't find the collection, > it can put in something like -9999 so we know it is not a value to be > relied upon. I think either option is fine. > > -Holly > > On Thu, Dec 17, 2015 at 12:19 PM, Omar Moreno <[log in to unmask]> wrote: > >> I can change the DST writers such that RFHits aren't a requirement. The >> DST will still have RF times, but when the collection isn't found, a >> default time will be written. >> >> The other option is to always write an RF hits collection to the LC >> event, even when hits aren't present. This would allow it to work with the >> MC. >> >> I'm indifferent about the solutions so Nathan or Holly should let me know >> what they want to do. >> On Dec 17, 2015 9:08 AM, "Nathan Baltzell" <[log in to unmask]> wrote: >> >>> It probably doesn’t make sense to have RF hits for MC. >>> Not sure dst maker should *require* them for data either. >>> >>> >>> On Dec 17, 2015, at 2:24, Omar Moreno <[log in to unmask]> wrote: >>> >>> > >>> > >>> > On Wed, Dec 16, 2015 at 11:19 PM, Bradley T Yale< >>> [log in to unmask]> wrote: >>> > Tritrig test files are finished with the v4-4 detector: >>> > /mss/hallb/hps/production/pass4/recon/tritrig/1pt05/ >>> > >>> > I used the new v0.10 dst_maker for the dsts, but it experienced a >>> runtime error: >>> > A runtime error has occured : lcio::DataNotAvailableException: >>> LCEventImpl::getCollection: collection not in event:RFHits >>> > >>> > If you aren't using the latest version of the recon steering file >>> that creates the RFHits collection, the new DST maker wont work. Check >>> that the steering file has the following driver at the top >>> > >>> > <!--RF driver--> >>> > <driver name="RfFitter"/> >>> > >>> > >>> > While this is being sorted out, I also made them using v0.9 in the >>> same directory, labelled 'OLDDST': >>> > /mss/hallb/hps/production/pass4/dst/tritrig/1pt05/ >>> > >>> > I can also do 3.4.2-SNAPSHOT and/or 3.5 of everything, with the v3-4 >>> detector for reference. >>> > If any other detectors are wanted, just let me know which ones, and >>> I'll try to have it done this weekend before more data recon gets going. >>> > I'll be out of contact until late tonight though. >>> > >>> > ________________________________________ >>> > From: Holly SzumilaVance <[log in to unmask]> >>> > Sent: Wednesday, December 16, 2015 9:25 PM >>> > To: Nathan Baltzell >>> > Cc: Hansson Adrian, Per Ola; Bradley T Yale; Uemura, Sho; hps-software >>> > Subject: Re: Tritrig with New Detector >>> > >>> > I copied everything from v3-4-fieldmap. Is this not what we should be >>> using? >>> > >>> > > On Dec 16, 2015, at 8:51 PM, Nathan Baltzell <[log in to unmask]> >>> wrote: >>> > > >>> > > This was intended to be a copy of the latest and greatest, >>> > > v3-4, with the only modification being ecal y-position. >>> > > Holly will need to confirm what exactly was done in the >>> > > original copy. And compact.xml comment tag needs to be >>> > > accurate and precise. >>> > > >>> > > -Nathan >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > >> On Dec 16, 2015, at 8:45 PM, "Hansson Adrian, Per Ola" < >>> [log in to unmask]> wrote: >>> > >> >>> > >> >>> > >> Is this meant to have the latest SVT alignment or is this for >>> something else? >>> > >> >>> > >> Given that we know are using the DB there *shouldn’t* be any >>> difference but in order to catch any other issue I thought it was worth >>> asking if this is based on v3-2-fieldmap and not v-3-4-fieldmap? If so why? >>> > >> >>> > >> Again, if the normal recon command is run I don’t expect any >>> difference for the SVT alignment but I dot know if there was anything else… >>> > >> >>> > >> /Pelle >>> > >> >>> > >> >>> > >>> On Dec 16, 2015, at 4:58 PM, Bradley T Yale < >>> [log in to unmask]> wrote: >>> > >>> >>> > >>> Thanks. >>> > >>> It was correct in the local detector-data directory, but 'svn >>> status' showed that it must not have been committed properly. >>> > >>> >>> > >>> ________________________________________ >>> > >>> From: Nathan Baltzell <[log in to unmask]> >>> > >>> Sent: Wednesday, December 16, 2015 7:42 PM >>> > >>> To: Sho Uemura >>> > >>> Cc: Bradley T Yale; [log in to unmask]; Holly Vance >>> > >>> Subject: Re: Tritrig with New Detector >>> > >>> >>> > >>> Should be correct now. >>> > >>> -Nathan >>> > >>> >>> > >>> >>> > >>> >>> > >>>> On Dec 16, 2015, at 7:18 PM, Sho Uemura <[log in to unmask]> >>> wrote: >>> > >>>> >>> > >>>> I don't see SamplingFractions. I do see Ecal.properties, but it's >>> not in the SamplingFractions directory. >>> > >>>> >>> > >>>> >>> http://java.freehep.org/svn/repos/hps/list/java/trunk/detector-data/detectors/HPS-EngRun2015-Nominal-v4-4-fieldmap/ >>> > >>>> >>> > >>>>> On Thu, 17 Dec 2015, Bradley T Yale wrote: >>> > >>>>> >>> > >>>>> I am in the process of making tritrig samples with the >>> 'HPS-EngRun2015-Nominal-v4-4-fieldmap' detector geometry. >>> > >>>>> >>> > >>>>> At readout: >>> > >>>>> Exception in thread "main" >>> org.lcsim.conditions.ConditionsManager$ConditionsSetNotFoundException: >>> Conditions set not found: SamplingFractions/Ecal >>> > >>>>> >>> > >>>>> The SamplingFractions directory is in the detector directory as >>> usual. Does anyone know the cause of this error? >>> > >>>>> log: >>> > >>>>> >>> /work/hallb/hps/mc_production/pass4/logs/readout/tritrig/1pt05/tritrigv1_HPS-EngRun2015-Nominal-v4-4-fieldmap_3.5-20151216.212828-9_pairs1_5.err >>> > >>>>> >>> > >>>>> >>> ######################################################################## >>> > >>>>> 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 >>> > >>> >>> > >>> >>> ######################################################################## >>> > >>> 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 >>> > >>> > >>> > 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 >> ------------------------------ >> NOTE: This message was trained as non-spam. If this is wrong, please >> correct the training as soon as possible. >> Spam >> <https://www.spamtrap.odu.edu/canit/b.php?i=03PSFjXTi&m=a6bfe88675b7&t=20151217&c=s> >> Not spam >> <https://www.spamtrap.odu.edu/canit/b.php?i=03PSFjXTi&m=a6bfe88675b7&t=20151217&c=n> >> Forget previous vote >> <https://www.spamtrap.odu.edu/canit/b.php?i=03PSFjXTi&m=a6bfe88675b7&t=20151217&c=f> >> > > ######################################################################## 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