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
|
