JeffersonLab / hps-align

Tools needed to run HPS alignment workflow
https://jeffersonlab.github.io/hps-align/
GNU General Public License v3.0
0 stars 0 forks source link

Extract Alignment Parameters for Study #26

Closed tomeichlersmith closed 1 year ago

tomeichlersmith commented 1 year ago

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).

import xml.etree.ElementTree as ET
import csv

tree = ET.parse('/path/to/java/detector-data/detectors/detname/compact.xml')

with open('detector-align-constants.csv', 'w', newline='') as csvfile:
    csvwriter = csv.writer(csvfile)
    csvwriter.writerow(['parameter','value'])
    for element in tree.iter('millepede_constant'):
        # use 'eval' so that python calculates the full value 
        # from the potentially-several values connected with +-
        csvwriter.writerow([element.name, eval(element.value)])
tomeichlersmith commented 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).

https://github.com/JeffersonLab/hps-java/blob/master/analysis/src/main/java/org/hps/analysis/examples/PrintGeometryDriver.java

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>
tomeichlersmith commented 1 year ago

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 .

tomeichlersmith commented 1 year ago

@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.

sarahgaiser commented 1 year ago

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.

normangraf commented 1 year ago

Has there been any discussion of the output text format?

tomeichlersmith commented 1 year ago

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)

global

  1. JSON
    {
    "<sensor-name>" : {
    "position" : [X, Y, Z],
    "u" : [ux, uy, uz],
    "v" : [vx, vy, vz],
    "w" : [wx, wy, wz]
    },
    ...other sensors
    }
  2. CSV with columns sensor, x, y, z, ux, uy, uz, vx, vy, vz, wx, wy, wz

local

  1. JSON
    {
    "<millepede-id (e.g. 11101)>": value,
    ...other parameters
    }
  2. CSV with columns parameter, value
normangraf commented 1 year ago

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.

normangraf commented 1 year ago

Do you have global csv files for the canonical 2016, 2019 and 2021 detectors available?

normangraf commented 1 year ago

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.

tomeichlersmith commented 1 year ago

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.

normangraf commented 1 year ago

Thank you.