Print

Print


"I had to add the SVT title angles to the compact.

I assume you meant “tilt” here.  I don’t understand what this means or why you had to do it.  Can you please explain further?  (I thought this was already supported by alignment constants being read from the compact.xml or reading this info from the conditions db.)

On May 30, 2017, at 7:24 PM, Omar Moreno <[log in to unmask]> wrote:

Hi All, 

Alignment constants are now in the DB.  The valid run range for these constants is 7219-8100.  For those interested, the collection ID in the 'svt_alignments' table 2982.  I tested locally using the following command

java -cp hps-jar org.hps.evio.EvioToLcio -d HPS-PhysicsRun2016-v5-3-fieldmap_globalAlign -l test_out -n 10 -r -x /org/hps/steering/recon/PhysicsRun2016FullRecon.lcsim -DoutputFile=test ../data/physics2016/evio/hps_007796.evio.0

and it looks like they are being loaded correctly: 

2017-05-30 19:07:19 [INFO] org.lcsim.geometry.compact.converter.HPSTrackerBuilder <init> :: alignment conditions will be read from database
2017-05-30 19:07:19 [INFO] org.hps.conditions.database.AbstractConditionsObjectConverter getData :: loading conditions set...
id: 2398
name: svt_alignments
runStart: 7219
runEnd: 8100
tableName: svt_alignments
collectionId: 2982
updated: 2017-05-30 18:52:44.0
created: 2017-05-30 18:52:44.0
tag: null
createdBy: omoreno
notes: 2016 physics run alignment constants.

I had to add the SVT title angles to the compact.  The changes are on a branch and  I created a pull request for Jeremy to review and merge.  However, now that the alignment constants are in the DB, changes to the compact shouldn't change anything.

As for the svt_calibrations, it looks like only two non-specialized calibration runs were ever loaded into the database.  I'm verifying with Pelle and MattS that this is correct because looking through the logs, it looks like we took several calibration runs throughout the physics run. 

As for bad channels,  I'm not going to put them into the DB for now.  If I do, then hits on those channels will be removed from the reconstruction and we haven't tested enough to understand what the repercussions would be.  Specifically, the hit clustering doesn't know what to do when a channel has a bad channel as a neighbor.  This may lead to strange behavior so I rather not risk it and wait for the next pass.

Best,

--Omar Moreno




On Sun, May 28, 2017 at 3:20 PM, McCormick, Jeremy I. <[log in to unmask]> wrote:
I only checked the svt_calibrations but all the other SVT conditions should be confirmed as well....
From: [log in to unmask] <[log in to unmask]edu> on behalf of Rafayel Paremuzyan <[log in to unmask]>
Sent: Sunday, May 28, 2017 2:16:21 PM
To: Omar Moreno; Graf, Norman A.
Cc: hps-software; [log in to unmask]
Subject: Re: test pass1
 
Hi Omar,

It has been checked, at least Jeremy confirmed that 2016 calibs should have been used.
2017-05-27 02:29:51 [INFO] org.hps.conditions.database.AbstractConditionsObjectConverter getData :: loading conditions set...
id: 1397
name: svt_calibrations
runStart: 7566
runEnd: 99999
tableName: svt_calibrations
collectionId: 20
updated: 2016-02-26 14:42:17.0
created: 2016-02-26 14:42:17.0
tag: eng_run
createdBy: phansson
notes: Pedestals and noise. Loaded using SvtConditionsLoader.

However, I agree I should have been asking you to confirm if we are ready to make a recon svt wise.

Rafo


On 05/28/2017 12:01 AM, Omar Moreno wrote:
Hi Rafo

I'm not sure what Jeremy fixed, but at this point It's probably a good idea to check if the correct SVT calibrations are being picked up for a given run.  Also, the alignment constants aren't in the DB yet so I'm not sure what its currently using. Just a couple of things to keep in mind.

--Omar Moreno

On Sat, May 27, 2017 at 1:54 PM, Graf, Norman A. <[log in to unmask]> wrote:
Thanks for the update Rafo.
Good to hear that the performance is back to what it was. Although we should still make some effort to speed things up beyond that.

I'm not sure how much I'll get done this weekend, but I'll start doing some checks as soon as I have some time.

Enjoy the weekend,
Norman
________________________________________
From: [log in to unmask] <[log in to unmask]u> on behalf of Rafayel Paremuzyan <[log in to unmask]>
Sent: Saturday, May 27, 2017 1:03 PM
To: hps-software; [log in to unmask]
Subject: test pass1

Hi all,

After Jeremy fixed the code to choose the latest created condition,
the job running speed recovered. It is now similar to pass0 speed.

A new test pass1 is being processed now, some of files are already finished.

I would encourage users who deeply involved in the analysis to take a look,
and find bugs, that will help to have less bugs when we start pass1.
Some details on this test pass can be found in the link below
https://confluence.slac.stanford.edu/pages/viewpage.action?pageId=223224540

Rafo

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