Closed tomeichlersmith closed 1 year ago
Besides extracting alignment parameters, we also have the ability to load a detector and dump the final sensor positions in the global frame (as well as their local coordinate unit vectors) using hps-java. This uses a driver in hps-java/analysis. I'm imaging a quick python script that runs the driver and extracts the desired information into a machine-readable format (e.g. json or csv).
script from @pbutti
GEO=$1
FILE_2019=/sdf/group/hps/data/physrun2019/hps_010104_slcio_pf/hps_010104_206.slcio
#FILE_2016=/sdf/group/hps/data/physrun2016/recon/HPS-PhysicsRun2016-Pass2/hps_007800/hps_007800.evio.322.slcio
#RUN_2016=7800
RUN_2019=10104
#READDB="-DdisableSvtAlignmentConstants"
#READDB="-Dorg.hps.conditions.enableSvtAlignmentConstants"
#FILE_1=/Users/pbutti/sw/data_hps/hps_007800_288.slcio
#RUN_N=7800
#java -DdisableSvtAlignmentConstants -Djna.library.path="/Users/pbutti/sw/GeneralBrokenLines/cpp/build/lib/" -XX:+UseSerialGC -Xmx3000m -jar distribution/target/hps-distribution-5.2-SNAPSHOT-bin.jar \
java -DdisableDesign ${READDB} -Djna.library.path="/Users/pbutti/sw/GeneralBrokenLines/cpp/build/lib/" -XX:+UseSerialGC -Xmx3000m -jar distribution/target/hps-distribution-5.2-SNAPSHOT-bin.jar \
geoPrint.lcsim \
-i ${FILE_2019} \
-DoutputFile=geoPrint.slcio -d $GEO -R $RUN_2019 -n 1
steering file
<?xml version="1.0" encoding="UTF-8"?>
<lcsim xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="http://www.lcsim.org/schemas/lcsim/1.0/lcsim.xsd">
<!--
Steering file for running 2019 Alignment on LCIO using Kalman Tracks
@author PF <pbutti@slac.stanford.edu>
-->
<execute>
<!-- Enable the following if re-processing lcio files -->
<driver name="PreCleanupDriver"/>
<driver name="PrintGeometryDriver"/>
<driver name="CleanupDriver"/>
</execute>
<drivers>
<driver name="PrintGeometryDriver" type="org.hps.analysis.examples.PrintGeometryDriver">
</driver>
<driver name="PreCleanupDriver" type="org.hps.analysis.dataquality.ReadoutCleanupDriver">
<!-- FEE skims -->
<!--<collectionNames>FinalStateParticles UnconstrainedV0Candidates UnconstrainedV0Vertices TargetConstrainedV0Candidates TargetConstrainedV0Vertices BeamspotConstrainedV0Candidates BeamspotConstrainedV0Vertices GBLKinkData GBLKinkDataRelations MatchedToGBLTrackRelations HelicalTrackHits HelicalTrackHitRelations MatchedTracks GBLTracks MatchedToGBLTrackRelations RotatedHelicalTrackHits RotatedHelicalTrackHitRelations TrackData TrackDataRelations TrackResiduals TrackResidualsRelations RotatedHelicalTrackHits RotatedHelicalTrackHitRelations StripClusterer_SiTrackerHitStrip1D </collectionNames>-->
<collectionNames> GBLKinkData GBLKinkDataRelations GBLTracks MatchedToGBLTrackRelations </collectionNames>
</driver>
<!-- SVT reconstruction drivers -->
<driver name="CleanupDriver" type="org.lcsim.recon.tracking.digitization.sisim.config.ReadoutCleanupDriver"/>
<driver name="LCIOWriter" type="org.lcsim.util.loop.LCIODriver">
<outputFilePath>${outputFile}.slcio</outputFilePath>
</driver>
<driver name="AidaSaveDriver" type="org.lcsim.job.AidaSaveDriver">
<outputFileName>${outputFile}.root</outputFileName>
</driver>
<driver name="AidaToRootSaveDriver" type="org.lcsim.job.AidaSaveDriver">
<outputFileName>${outputFile}.root</outputFileName>
</driver>
</drivers>
</lcsim>
I've created a branch named after this issue and started working there. My general idea is to start a new command for the hps_align CLI app called detdump
which can do this procedure of loading the geometry and extracting the sensor placement and orientation information in the global coordinate system. This branch depends on PR #24 .
@sarahgaiser started working on extracting the positions in a different repository - https://github.com/sarahgaiser/sensor_z_pos_investigation - looks like this code could be put into this detdump
submodule I'm imagining.
Oh, I didn't see this! We can think of combining all of this somehow. At the moment, my code is super simple and only works for a specific format though.
Has there been any discussion of the output text format?
Not much discussion as yet @normangraf - I've mainly implemented two different formats right now https://github.com/JeffersonLab/hps-align/pull/28 which are both slightly different depending on if you are dumping the global sensor position+orientation or if you are just dumping the "local" parameters (i.e. the millepede constants themselves)
{
"<sensor-name>" : {
"position" : [X, Y, Z],
"u" : [ux, uy, uz],
"v" : [vx, vy, vz],
"w" : [wx, wy, wz]
},
...other sensors
}
sensor
, x
, y
, z
, ux
, uy
, uz
, vx
, vy
, vz
, wx
, wy
, wz
{
"<millepede-id (e.g. 11101)>": value,
...other parameters
}
parameter
, value
Although straightforward enough to derive from global.2, it would be convenient to have an option which wrote out the local-to-global transformation matrix which encapsulates the translation and rotation.
Do you have global csv files for the canonical 2016, 2019 and 2021 detectors available?
The usual convention is u x v = w. Is that the case here? I seem to recall some confusion in the past on this point.
it would be convenient to have an option which wrote out the local-to-global transformation matrix
I didn't want to enlarge the file too much but I suppose you're correct. Its just the u,v,w as columns plus the x, y, z translations along the diagonal correct?
global csv files for the canonical 2016, 2019, 2021 detectors?
I have been using the 2016 detector for testing, the other detectors have not been generated.
/sdf/group/hps/users/eichl008/hps/HPS-PhysicsRun2016-Pass2-global.csv
The usual convention is u x v = w. Is that the case here?
I have not checked if this is the case. I am simply parsing the output of the PrintGeometryDriver into a more readable form.
Thank you.
It is often helpful to look at the values of the alignment parameters themselves and so I think integrating a quick script here to pull out the alignment parameters from a certain detector would be helpful. Below I've outlined a python snippet to help with this, the inputs would be the detector (probably the path to it) and then the output CSV filename (which could have a sensible default).