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  June 2015

HPS-SOFTWARE June 2015

Subject:

Re: pass1 steering file

From:

"Graham, Mathew Thomas" <[log in to unmask]>

Reply-To:

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

Date:

Wed, 3 Jun 2015 23:09:00 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (384 lines)

On Jun 3, 2015, at 6:03 PM, Nathan Baltzell <[log in to unmask]> wrote:

>> 2. Check the run ranges (Sho indicated that there are missing runs).
> 
> Is the code going to crash when it encounters one of these runs with missing info in the db?
> 
> If so:
> Does a list of the runs with missing db info exist?  Or does anyone know if turning off
> SVT recon in the steering file still allow it to work for ecal-only recon?
> 

No, it doesn't crash...it uses the nominal opening angle.


> -Nathan
> 
> 
> P.S.  This is my list of the calibration/non-A' runs we need to process in full for pass1:
> 5222   40nA, 10kHz-Pulser-Only, SVT open
> 5228   10nA, 10kHz-Pulser-Only, SVT open
> 5229   10nA, 10kHz-Pulser-Only, SVT open
> 5393   40nA, 10kHz-Pulser-Only, [log in to unmask]
> 5546   50nA, 10kHz-Pulser-Only, [log in to unmask]
> 5747   20nA, v7, [log in to unmask]
> 5749   30nA, v7, [log in to unmask]>0.5
> 5754   40nA, v7, [log in to unmask]
> 5756   50nA, FeeMask1, [log in to unmask]
> 5757   50nA, FeeMask2, [log in to unmask]
> 5774   50nA, 10kHz-Pulser-Only, [log in to unmask]
> 5777   50nA, FeeMask2, No-SVT
> 5779   30nA, Carbon, [log in to unmask]
> 5781     2nA, CH2, SVT@?
> 5784   25nA, Straight, [log in to unmask]
> 5785   25nA, Straight, [log in to unmask]
> 5786   25nA, Straight, [log in to unmask]
> 
> 
> 
>> On Jun 3, 2015, at 4:02 PM, "Hansson Adrian, Per Ola" <[log in to unmask]> wrote:
>> 
>> I’m told these are taken from the compact descriptions currently in svn. These were done on the fly the first day we took data with the SVT so I suspect they don’t have the correction. 
>> 
>> So to me there are two things to do:
>> 
>> 1. Adjust the current values in the DB with the corrected values
>> 
>> 2. Check the run ranges (Sho indicated that there are missing runs). 
>> 
>> I personally don’t care about the runs other than nominal for this pass but if people want those correct we’ll try to get it done.
>> 
>> I can do 1. and 2. with Jeremy later today and it’s done and we can move on. 
>> 
>> (Might need input/cross-check from Tim.)
>> 
>> /pelle
>> 
>> 
>>> On Jun 3, 2015, at 12:53 PM, Graham, Mathew Thomas <[log in to unmask]> wrote:
>>> 
>>> Sorry, what I mean is that the numbers in the conditions db weren’t taken from converting motor positions from the MYA database. 
>>> 
>>>> On Jun 3, 2015, at 2:51 PM, Graham, Mathew Thomas <[log in to unmask]> wrote:
>>>> 
>>>> 
>>>> These numbers weren’t taken from the db.
>>>> 
>>>>> 
>>>>> The db stores motor position, so runs from before the correction for vacuum pull are made automatically when pulling the motor positions out and converting them via Jeremy’s code.
>>>>> 
>>>>> In other words, I don’t think there is anything to be done here.  However, it does mean we have a lot of odd-looking settings from before the correction was made.
>>>>> 
>>>>> T
>>>>> 
>>>>>> On Jun 3, 2015, at 12:30 PM, Graham, Mathew Thomas <[log in to unmask]> wrote:
>>>>>> 
>>>>>> So I ran a recent snapshot one some representative runs for each SVT opening and they look “fine”, or at least they make sense…runs before 5216 are incorrect because this was before we put in the correct vacuum pull settings.  We can, and should, calculate the correct values for these runs and put them in the database; Tim (at least) knows how to correct these numbers.   This shouldn’t hold up the start of processing pass-1.  We can, and should, start by processing runs > 5216 and put the fixes in the database for the earlier runs in the next few days.  
>>>>>> 
>>>>>> It look like we need corrected angles for “2mm”, “3mm”, and “4mm”.  
>>>>>> 
>>>>>> 
>>>>>>> On Jun 3, 2015, at 2:04 PM, McCormick, Jeremy I. <[log in to unmask]> wrote:
>>>>>>> 
>>>>>>> Hi, Sho.
>>>>>>> 
>>>>>>> Since there were 5+ people in the CC on this topic, I'm sending to the software list instead.
>>>>>>> 
>>>>>>> Let me make sure it is completely clear what I did for loading the SVT opening angles into the conditions database, so that everyone understands what's going on and we can make corrections if needed.
>>>>>>> 
>>>>>>> I first made a collection for each of the settings (4mm, 3mm, etc.) including the nominal/closed position.
>>>>>>> 
>>>>>>> These have the following values for the angle, which is following the convention from the corresponding compact detector descriptions...
>>>>>>> 
>>>>>>> mysql> select * from svt_alignments where value != 0;
>>>>>>> +------+---------------+-----------+---------+
>>>>>>> | id   | collection_id | parameter | value   |
>>>>>>> +------+---------------+-----------+---------+
>>>>>>> |  594 |          1010 |     13100 |  0.0031 |
>>>>>>> |  597 |          1010 |     23100 | -0.0033 |
>>>>>>> |  849 |          1011 |     13100 |  0.0077 |
>>>>>>> |  852 |          1011 |     23100 | -0.0086 |
>>>>>>> | 1359 |          1013 |     13100 |  0.0046 |
>>>>>>> | 1362 |          1013 |     23100 |  -0.005 |
>>>>>>> | 1614 |          1014 |     13100 |  0.0107 |
>>>>>>> | 1617 |          1014 |     23100 | -0.0116 |
>>>>>>> | 1869 |          1015 |     13100 |  0.0216 |
>>>>>>> | 1872 |          1015 |     23100 | -0.0217 |
>>>>>>> +------+---------------+-----------+---------+
>>>>>>> 
>>>>>>> (Value = 0 for 'closed' position is not shown here, but it is in the database.)
>>>>>>> 
>>>>>>> The collection information on these is the following...
>>>>>>> 
>>>>>>> mysql> select * from collections where table_name like 'svt_alignments';
>>>>>>> +------+----------------+-------------------------------------+----------------------+---------------------+
>>>>>>> | id   | table_name     | log                                 | description          | created             |
>>>>>>> +------+----------------+-------------------------------------+----------------------+---------------------+
>>>>>>> | 1010 | svt_alignments | loaded with mysql client by jeremym | 1.5 mm opening angle | 2015-05-06 18:07:22 |
>>>>>>> | 1011 | svt_alignments | loaded with mysql client by jeremym | 3 mm opening angle   | 2015-05-06 18:21:50 |
>>>>>>> | 1012 | svt_alignments | loaded with mysql client by jeremym | nominal              | 2015-05-06 18:43:41 |
>>>>>>> | 1013 | svt_alignments | loaded with mysql client by jeremym | 2 mm opening angle   | 2015-05-06 19:04:49 |
>>>>>>> | 1014 | svt_alignments | loaded with mysql client by jeremym | 4 mm opening angle   | 2015-05-08 14:20:24 |
>>>>>>> | 1015 | svt_alignments | loaded with mysql client by jeremym | open position        | 2015-05-08 14:33:33 |
>>>>>>> +------+----------------+-------------------------------------+----------------------+---------------------+
>>>>>>> 
>>>>>>> We're missing a 1mm setting here and there were a few runs with this value, so we should put that into the db at some point.  I didn't have a compact description for this and so couldn't directly get the opening angle value for 1mm.  Someone can supply this to me if we decide that we want it in there, and I can add a new collection.
>>>>>>> 
>>>>>>> To be completely clear, the angles in the database are taken directly from the compact detector descriptions for the "nominal" gap size between layer 1 active layers, not from an actual conversion of the motor Y position in MYA.
>>>>>>> 
>>>>>>> So if there is a discrepancy (not clear to me one way or another as I am not an SVT systems expert and have not followed all the details on this topic) i.e. a mismatch between these nominal angles from the compact description and what should actually be in there based on the motor position in MYA, then this should be dealt with by making new collections with the corrected angles.
>>>>>>> 
>>>>>>> The run ranges were the ones Sho included in the prior email, and they are based on the run spreadsheet values as well as information on run ranges suggested by Matt.  There are gaps in there because for some runs the setting was not clear, i.e. it was left blank.  In this case, should we want to process these runs with the correct opening angles, we'll need to dump/scrape the data from MYA to find out the actual setting from the time stamp.  I didn't really do that yet because its complicated and it also requires having a run database with start and end times which we don't have quite yet.
>>>>>>> 
>>>>>>> I hope that's more clear now.  
>>>>>>> 
>>>>>>> If there are any questions/comments then please reply to the software list.
>>>>>>> 
>>>>>>> --Jeremy
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Sho Uemura [mailto:[log in to unmask]] 
>>>>>>> Sent: Wednesday, June 03, 2015 10:41 AM
>>>>>>> To: Hansson Adrian, Per Ola
>>>>>>> Cc: Nathan Baltzell; Omar Moreno; Graham, Mathew Thomas; McCormick, Jeremy I.
>>>>>>> Subject: Re: pass1 steering file
>>>>>>> 
>>>>>>> Can you look at the opening angle constants in the conditions DB and figure out if they match their descriptions (below, copy/paste from e-mail from Jeremy last week)?
>>>>>>> 
>>>>>>> mysql> select * from svt_alignments_engrun_view;
>>>>>>> +-----+-----------+---------+---------------+----------------------+--------+
>>>>>>> | id  | run_start | run_end | collection_id | description          | 
>>>>>>> n_runs |
>>>>>>> +-----+-----------+---------+---------------+----------------------+--------+
>>>>>>> | 345 |      4847 |    5036 |          1014 | 4 mm opening angle   | 
>>>>>>> 190 |
>>>>>>> | 342 |      5037 |    5063 |          1011 | 3 mm opening angle   | 
>>>>>>> 27 |
>>>>>>> | 343 |      5066 |    5079 |          1013 | 2 mm opening angle   | 
>>>>>>> 14 |
>>>>>>> | 384 |      5139 |    5148 |          1011 | 3 mm opening angle   | 
>>>>>>> 10 |
>>>>>>> | 385 |      5149 |    5157 |          1013 | 2 mm opening angle   | 
>>>>>>> 9 |
>>>>>>> | 386 |      5181 |    5198 |          1013 | 2 mm opening angle   | 
>>>>>>> 18 |
>>>>>>> | 344 |      5218 |    5229 |          1015 | open position        | 
>>>>>>> 12 |
>>>>>>> | 388 |      5253 |    5387 |          1010 | 1.5 mm opening angle | 
>>>>>>> 135 |
>>>>>>> | 391 |      5388 |    5402 |          1015 | open position        | 
>>>>>>> 15 |
>>>>>>> | 389 |      5404 |    5412 |          1010 | 1.5 mm opening angle | 
>>>>>>> 9 |
>>>>>>> | 390 |      5538 |    5611 |          1010 | 1.5 mm opening angle | 
>>>>>>> 74 |
>>>>>>> | 357 |      5623 |    5743 |          1012 | nominal              | 
>>>>>>> 121 |
>>>>>>> | 392 |      5713 |    5713 |          1010 | 1.5 mm opening angle | 
>>>>>>> 1 |
>>>>>>> | 393 |      5714 |    5746 |          1012 | nominal              | 
>>>>>>> 33 |
>>>>>>> | 395 |      5747 |    5747 |          1010 | 1.5 mm opening angle | 
>>>>>>> 1 |
>>>>>>> | 396 |      5748 |    5797 |          1012 | nominal              | 
>>>>>>> 50 |
>>>>>>> +-----+-----------+---------+---------------+----------------------+--------+
>>>>>>> 
>>>>>>> For runs after 5218, the opening angle should match the description. For runs before 5218, the motor offsets should create a discrepancy between the opening angle and the description. Does that make sense?
>>>>>>> 
>>>>>>>> On Wed, 3 Jun 2015, Hansson Adrian, Per Ola wrote:
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>>> On Jun 3, 2015, at 9:29 AM, Sho Uemura <[log in to unmask]> wrote:
>>>>>>>>> 
>>>>>>>>> Oh, this!
>>>>>>>>> 
>>>>>>>>> I don't think the problem Matt is seeing with run 5575 is the software's fault; it's probably bad data. Don't worry about that one.
>>>>>>>>> 
>>>>>>>>> If Matt's right about run 5043, the SVT opening angle is set incorrectly for the early runs (I bet what happened is that Matt told Jeremy that there were two kinds of 2 mm runs, but not that all the runs prior to the motor fix needed different motor offsets). CC-ing Pelle and Omar, I think they can check this faster than I can. How much do we care if the 3 mm runs have bad opening angles?
>>>>>>>> 
>>>>>>>> Not sure I can debug this without talking to Jeremy and Matt. Not sure what they are doing.
>>>>>>>> 
>>>>>>>> I don?t think we care about the 3mm runs. If all is fine with our later, and in particular our nominal runs, I wouldn?t hold up personally.
>>>>>>>> 
>>>>>>>> Is Matt not available by email or he just not at SLAC?
>>>>>>>> 
>>>>>>>> /Pelle
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> On Wed, 3 Jun 2015, Nathan Baltzell wrote:
>>>>>>>>>> 
>>>>>>>>>> Sho, did you think this all was a problem or not?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On Jun 2, 2015, at 4:34 PM, "Graham, Mathew Thomas" <[log in to unmask]> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Yes, I agree?
>>>>>>>>>>> 
>>>>>>>>>>> For the first one (run 5043), did you put in corrected values for runs before 5216?  Or did you use the same equation for all runs?
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Jun 2, 2015, at 3:32 PM, McCormick, Jeremy I. <[log in to unmask]> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> I don?t know but I think we should hold off on releasing hps-java for the time being until we figure out what?s going on...
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Jun 2, 2015, at 1:04 PM, Graham, Mathew Thomas <[log in to unmask]> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I wonder if the snapshots from nexus don?t correctly deal with the new geometry for the SVT?or something.  I ran run a couple of runs and got weird (and differently weird!) results:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> run 5043 (3mm, but pre-sag fix):  I see tracks and stuff, but the 
>>>>>>>>>>>>> y0 for tracks is off, like the sag hasn?t been calculated out 
>>>>>>>>>>>>> correctly, but I thought Jeremy took care of this
>>>>>>>>>>>>> 
>>>>>>>>>>>>> run 5575 (1.5mm): somehow I don?t see _any_ tracks in this?.may be due to the hit timing though; they look pretty screwed and I notice that for this run there is no ?phase? entry in the spreadsheet.  Sho?
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Jun 2, 2015, at 10:56 AM, Graham, Mathew Thomas <[log in to unmask]> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I?m running some jobs with the latest snapshot?at JLAB, I?m using the auger command file:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> /u/group/hps/production/data/EngRun2015/recon/reconDstAndDqm-Loc
>>>>>>>>>>>>>> alTest.xml
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ?the ?LocalTest? just refers to the fact that the output doesn?t get sent to tape.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Jun 1, 2015, at 8:53 PM, Graham, Mathew Thomas <[log in to unmask]> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Ok, sounds good.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Jun 1, 2015, at 8:50 PM, Nathan Baltzell <[log in to unmask]> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Kyle is removing GTP stuff from pass1 steering file 
>>>>>>>>>>>>>>>> completely, since it is not useful with more advanced ecal recon algorithms.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> He's making a new one for trigger studies only, which will output histos only.
>>>>>>>>>>>>>>>> It can run serially on the batch farm and shouldn't be a 
>>>>>>>>>>>>>>>> problem since it won't run tracking.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> -Nathan
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Jun 1, 2015, at 8:38 PM, Nathan Baltzell <[log in to unmask]> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Don't worry, we're on the same page here (believe it or not).
>>>>>>>>>>>>>>>>> But I am "asking" Kyle to be sure.  Don't fret.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Jun 1, 2015, at 8:35 PM, "McCormick, Jeremy I." <[log in to unmask]> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I would vote not to include additional trigger diagnostics right now, especially if it requires fiddling with the configuration of the hit converter code in a way that is not compatible with the recon.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I want to tag the source code tomorrow with a release so that we can start the batch jobs within the next few days (I'm hoping we are ready to do this Wednesday following the general meeting). So I don't think it is a good idea to try and fit this in given that tight of a time frame.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Additional trigger diagnostics can always be run as a separate analysis job over the LCIO recon files from the pass, and we can fully integrate whatever additions Kyle wants into the pass2 recon or the DQM without being so rushed.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> What we should really focus on right now is cleaning up what we already have in there as well as validating the various conditions that are going to be activated for the runs via the 'pass1' tag.  The data chaining of EVIO -> LCIO -> ROOT should also be (sanity) checked, as well as the DQM output, etc.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I think that's enough to worry about in the next few days...
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> --Jeremy
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>> From: Nathan Baltzell [mailto:[log in to unmask]]
>>>>>>>>>>>>>>>>>> Sent: Monday, June 01, 2015 5:22 PM
>>>>>>>>>>>>>>>>>> To: Graham, Mathew Thomas
>>>>>>>>>>>>>>>>>> Cc: McCormick, Jeremy I.
>>>>>>>>>>>>>>>>>> Subject: Re: pass1 steering file
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I think for trigger studies Kyle needs different EcalRawConverter settings that are incompatible with good recon.  Unless he separated the code.  I'll ask him.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Nathan, are the driver settings for ecal all up to date?
>>>>>>>>>>>>>>>>>> They are now, in svn, here:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> steering-files/src/main/resources/org/hps/steering/recon/Eng
>>>>>>>>>>>>>>>>>> ineeringRun2015FullRecon.lcsim
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I halved calorimeter clustering thresholds (the previous ones were for 2 GeV), got rid of "windowSamples" in EcalRawConverter (since we are in mode-1, the code knows the window size, and we ran a few special runs with different size), turned off time-walk correction, and turned on pulse fitting.  These are the same settings we've been testing with the last week.  Running another test now, but with tracking.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> -Nathan
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Jun 1, 2015, at 7:32 PM, "Graham, Mathew Thomas" <[log in to unmask]> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Yes we should use the steering file from release and the engrun2015revonfull is what I figured we'd use.  Kyle wants some trigger diagnostic stuff in...I told him to test it and just put it in (he sent it to me to test but I'm traveling and it's his job anyway).  I'll remind him that we want to do this tomorrow.  It's not the end of the world if it doesn't make it in...can always run after.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Nathan, are the driver settings for ecal all up to date?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On Jun 1, 2015, at 5:42 PM, McCormick, Jeremy I. <[log in to unmask]> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Yes, it is preferable that the pass1 steering goes into the release.  Then the job is runnable using an embedded resource, and it is also basically tagged forever.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Bear in mind that if we tag 3.2.1 but then decide we need to add something or fix a bug in hps-java, I can just make us another release for the pass (3.2.2 etc.).  So it isn't set in stone that we must use the first release if we decide that something got left out.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>> From: Nathan Baltzell [mailto:[log in to unmask]]
>>>>>>>>>>>>>>>>>>>> Sent: Monday, June 01, 2015 3:33 PM
>>>>>>>>>>>>>>>>>>>> To: McCormick, Jeremy I.
>>>>>>>>>>>>>>>>>>>> Cc: Graham, Mathew Thomas
>>>>>>>>>>>>>>>>>>>> Subject: Re: pass1 steering file
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Steering file must go in release?!  Ok ...
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On Jun 1, 2015, at 6:30 PM, "McCormick, Jeremy I." <[log in to unmask]> wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Probably this is the closest thing right now....
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> steering-files/src/main/resources/org/hps/steering/recon/
>>>>>>>>>>>>>>>>>>>>> Engineering
>>>>>>>>>>>>>>>>>>>>> Run2015FullRecon.lcsim
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Or at least it should be good enough for testing.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> If we need/want a new steering file specifically for pass1 then someone should make it ASAP so that it can be included in the release jar (release is happening tomorrow!).
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>> From: Nathan Baltzell [mailto:[log in to unmask]]
>>>>>>>>>>>>>>>>>>>>> Sent: Monday, June 01, 2015 3:28 PM
>>>>>>>>>>>>>>>>>>>>> To: Graham, Mathew Thomas
>>>>>>>>>>>>>>>>>>>>> Cc: McCormick, Jeremy I.
>>>>>>>>>>>>>>>>>>>>> Subject: pass1 steering file
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Do we have a pass1 steering file?
>>>>>>>>>>>>>>>>>>>>> -Nathan
>>>>>>> 
>>>>>>> ########################################################################
>>>>>>> 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

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

February 2024
January 2024
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