Logfile of my work at CERN during alignment camp 2007 ===================================================== June 28, 2007: -------------- Set up my area on lxplus.cern.ch. Apparently it runs csh by default since it doesn't recognize commands from my local laptop bash. Copy over .cshrc from FNAL and adapt for use at CERN, i.e. get rid of a bunch of FNAL-specific setups. Following Samir's advice the setup of the CMS environment is > cd CMS/cocoa > scramv1 project CMSSW CMSSW_1_4_0_DAQ1 He recommends CMSSW_1_4_0_DAQ1 since Pedro says that this is currently contains a version of COCOA that works well. Samir also says that there were many changes done already relative to the nominal CMSSW_1_4_0_DAQ1, so I should take updated source code from Samir's area /afs/cern.ch/user/g/guragain/work/COCOA/CMSSW_1_4_0_DAQ1/src However, he had to copy the files in there to his public area /afs/cern.ch/user/g/guragain/public/src so that I could copy them since permission was denied in the original area: > cp -r /afs/cern.ch/user/g/guragain/public/src . > cd /CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/CocoaApplication > eval `scramv1 run -csh` > scramv1 build > which cocoa /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/bin/slc4_ia32_gcc345/cocoa The build didn't create a cocoa executable in my /bin area, though. It did at FNAL...?! July 2, 2007: ------------- Resume work at 4pm after returning from Germany. Today there is no problem with running X on lxplus from my laptop Linux. This time during login a .Xauthority file is successfully created in my lxplus login area: ******************************************************************************** * * * The LXPLUS Public Login Unix Service * * (Scientific Linux SLC 4.4 x86_64) * * * * * * A web page containing information about this Linux version on LXPLUS: * * https://cern.ch/plus/SLC4.html * * For a list of known issues, please check: * * https://cern.ch/plus/issues_SLC4.html * * In case of problems, please contact the helpdesk: tel 78888 * * If you have any feedback not already included there please send it to: * * it-dep-fio-lxslc4@cern.ch * * * * In * * https://cern.ch/plus : Information on the usage of LXPLUS/LXBATCH * * https://cern.ch/ComputingRules : Govern the use of CERN computing facilities * * * ******************************************************************************** /usr/bin/X11/xauth: creating new authority file /afs/cern.ch/user/h/hohlmann/.Xauthority running .cshrc ... On Friday, when I couldn't use X on lxplus, I had an error message instead. Let's hope it will keep working from now on! The working directory with sdf files etc. is here: ~/CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/CocoaApplication/bin > ev ~/CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/CocoaApplication/bin > which cocoa /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/bin/slc4_ia32_gcc345/cocoa I copy Samir's sdfs into a separate subdirectory and start with Gyongyi's sdfs from FNAL: ME2_SLM25_las2_7DCOPS.txt ME2_SLM25_las2_9DCOPS.txt ME2_SLM25_las2.txt* ME2_SLM25_las5.txt ME2_SLM25_simu.txt* Note that input distances to COCOA are still defines in mm+-micrometers in these sdfs, whereas the output now is in mm+-mm and deg+-deg Try to run COCOA on ME2_SLM25_las2_7DCOPS.txt > !! EXITING: ERROR IN LINE No 36 file: ME2_SLM25_las2_7DCOPS.txt : !!! global option not found: dumpOptOGlobalInReport I compare to Samir's sdf ME2_SLM25_las2_9DCOPS.txt and find a different option: GLOBAL_OPTIONS dumpInAllFrames 1 //dumpOptOGlobalInReport 1 This must be from Pedro's new utility that allows you to get coordinates in all ref. frames! I change the options to the following as in Samir's file: GLOBAL_OPTIONS //dumpOptOGlobalInReport 1 dumpInAllFrames 1 calParamInyfMatrix 1 report_verbose 1 //save_matrices 1 debug_verbose 5 Now the error message is: !! EXITING: ERROR IN LINE No 48 file: ME2_SLM25_las2_7DCOPS.txt : !!! global option not found: FitQualityCut ALLOWED GLOBAL OPTIONS: VisGlobalRotationX VisGlobalRotationY VisGlobalRotationZ VisOnly VisScale VisWriteIguana VisWriteOptONames VisWriteVRML angle_error_dimension angle_value_dimension calParamInyfMatrix calcul_type checkExtraEntries cms_link cms_link_halfplanes cms_link_method debug_verbose deviffAngDimf deviffValDimf distancemeter_meas_value_dimension dumpDateInFittedEntries dumpInAllFrames fitQualityCut histograms length_error_dimension length_value_dimension maxDeviDerivative maxNoFitIterations measurementErrorFromFile onlyDeriv onlyFirstPropagation output_angle_error_dimension output_angle_value_dimension output_length_error_dimension output_length_value_dimension range_studies relativeFitQualityCut reportOutEntriesByShortName reportOutReadQuality reportOutReadSigma reportOutReadValue report_verbose rotateAroundLocal saveMatrices stopAfter1stIteration tiltmeter_meas_value_dimension writeXML Comment it out: //FitQualityCut 0.1 Now COCOA actually starts running... but crahes with the following message: ... @@@@ Building Measurements links to OptOs ---------- SYSTEM SUCCESFULLY READ ---------- TIME:ENDED_READING : 280000 0.03 5 *** Break *** segmentation violation (no debugging symbols found) Using host libthread_db library "/lib64/tls/libthread_db.so.1". Attaching to program: /proc/29150/exe, process 29150 `shared object read from target memory' has disappeared; keeping its symbols. (no debugging symbols found)...done. (no debugging symbols found)...done. (no debugging symbols found)...done. (no debugging symbols found)...done. (no debugging symbols found)...done. (no debugging symbols found)...done. (no debugging symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 4117596864 (LWP 29150)] 0xffffe410 in __kernel_vsyscall () #1 0x007287d3 in __waitpid_nocancel () from /lib/tls/libc.so.6 #2 0x006d2649 in do_system () from /lib/tls/libc.so.6 #3 0x008028bd in system () from /lib/tls/libpthread.so.0 #4 0xf7a0df6b in TUnixSystem::Exec () from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/external/slc4_ia32_gcc345/lib/libCore.so #5 0xf7a0e42f in TUnixSystem::StackTrace () from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/external/slc4_ia32_gcc345/lib/libCore.so #6 0xf7a0c1d9 in TUnixSystem::DispatchSignals () from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/external/slc4_ia32_gcc345/lib/libCore.so #7 0xf7a0a00c in SigHandler () ... Well, if I look in the measurement input file slm25_b0t_data_ev21_03Nov06_00_01_laser2_only_7DCOPS.txt, there are more than 7DCOPS uncommented. Fix that... still crahes Try to run Samir's sdf for 9 DCOPS, also crashes: /CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/CocoaApplication/bin > cocoa ME2_SLM25_las2_9DCOPS_SG.txt TIME:ENDED_READING : 280000 0 0 *** Break *** segmentation violation (no debugging symbols found) Using host libthread_db library "/lib64/tls/libthread_db.so.1". Attaching to program: /proc/13900/exe, process 13900 `shared object read from target memory' has disappeared; keeping its symbols. (no debugging symbols found)...done. (no debugging symbols found)...done. (no debugging symbols found)...done. (no debugging symbols found)...done. (no debugging symbols found)...done. (no debugging symbols found)...done. (no debugging symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 4117596864 (LWP 13900)] 0xffffe410 in __kernel_vsyscall () #1 0x007287d3 in __waitpid_nocancel () from /lib/tls/libc.so.6 #2 0x006d2649 in do_system () from /lib/tls/libc.so.6 #3 0x008028bd in system () from /lib/tls/libpthread.so.0 #4 0xf7a0df6b in TUnixSystem::Exec () from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/external/slc4_ia32_gcc345/lib/libCore.so #5 0xf7a0e42f in TUnixSystem::StackTrace () from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/external/slc4_ia32_gcc345/lib/libCore.so #6 0xf7a0c1d9 in TUnixSystem::DispatchSignals () from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/external/slc4_ia32_gcc345/lib/libCore.so #7 0xf7a0a00c in SigHandler () from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/external/slc4_ia32_gcc345/lib/libCore.so #8 0xf7a10d76 in sighandler () from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/external/slc4_ia32_gcc345/lib/libCore.so #9 #10 0xf63427c0 in CocoaToDDLMgr::ma () from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/lib/slc4_ia32_gcc345/libAlignmentCocoaToDDL.so #11 0xf6342ec6 in CocoaToDDLMgr::writeMaterials () from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/lib/slc4_ia32_gcc345/libAlignmentCocoaToDDL.so #12 0xf6343134 in CocoaToDDLMgr::writeDDDFile () from /afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/lib/slc4_ia32_gcc345/libAlignmentCocoaToDDL.so July 3, 2007: ------------- Note that Samir's and my sdf's have different sensor ids in the measurement section: My file MEASUREMENTS // simulated value = real measurment (mm) // flag for missed ccd = 0 // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // // ME2 SLM 2 // // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // --> COPS id1 <-- CMS/slm_p2_2/MEp2_tp2/laser_MEp2_2 & CMS/slm_p2_2/MEp2_tp2/DCOPS_MEp2_reference_2_IN U simulated_value prec_CCD D simulated_value prec_CCD L simulated_value prec_CCD R simulated_value prec_CCD ... Samir's MEASUREMENTS // simulated value = real measurment (mm) // flag for missed ccd = 0 // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // // ME2 SLM 2 // // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // --> COPS DCOPS_outer_MEp2_1_14_IN_las22 <-- CMS/slm_p2_2/MEp2_tp2/laser_MEp2_2 & CMS/slm_p2_2/MEp2_tp2/DCOPS_MEp2_reference_2_IN_las22 U simulated_value prec_CCD D simulated_value prec_CCD L simulated_value prec_CCD R simulated_value prec_CCD - Samir runs my sdf and measurement file without crash using his compiled version of COCOA. Weird ! - I also note that if I do eval.. in my bin area I actually get my own compiled version of the code: ~/CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/CocoaApplication/bin > which cocoa /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/bin/slc4_ia32_gcc345/cocoa - The code crashes in COCOAtoDDL. We can't get it to work. :( - New strategy: Try to build the latest greatest version CMSSW_1_6_1_pre2. Hopefully Pedro's updates are in there... > scramv1 project CMSSW CMSSW_1_6_0_pre2 > cd /CMSSW_1_6_0_pre2/src > cmscvsroot CMSSW > cvs login > cvs co -r CMSSW_1_6_0_pre2 Alignment cvs [checkout aborted]: no such tag `CMSSW_1_6_0_pre2' Ok, so try for _pre1: > scramv1 project CMSSW CMSSW_1_6_0_pre1 > cd /CMSSW_1_6_0_pre1/src > cmscvsroot CMSSW > cvs login > cvs co -r CMSSW_1_6_0_pre1 Alignment > cvs co -r CMSSW_1_6_0_pre1 CondFormats I claims to check out a lot of code, but when I look in /src, the area is completely empty !?! Not even the Alignment or CondFormats directories... - Next plan: Rebuild Samir's running version from scratch > rm -r CMSSW_1_4_0_DAQ1/ Creating a developer area based on project CMSSW, version CMSSW_1_4_0_DAQ1 Getting project release area.... Checking SCRAM version.... Setting up SELF: Finding a value for CMSSW_BINDIR: Checks [OK] for /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/bin/slc4_ia32_gcc345 Finding a value for LIBDIR: Checks [OK] for /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/lib/slc4_ia32_gcc345 Checks [OK (but currently missing)] for /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/external/slc4_ia32_gcc345/lib Finding a value for INCLUDE: Checks [OK] for /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/src Checks [OK (but currently missing)] for /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/include/slc4_ia32_gcc345 ------------------------------- Runtime path settings for LD_LIBRARY_PATH: Checks [OK] for /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/lib/slc4_ia32_gcc345 Checks [OK (but currently missing)] for /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/external/slc4_ia32_gcc345/lib Runtime path settings for SEAL_PLUGINS: Checks [OK] for /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/module/slc4_ia32_gcc345 Runtime path settings for PYTHONPATH: Checks [OK] for /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/lib/slc4_ia32_gcc345 Checks [OK] for /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/python Runtime path settings for CMSSW_SEARCH_PATH: Checks [OK (but currently missing)] for /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/src Checks [OK (but currently missing)] for /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/share Runtime path settings for PATH: Checks [OK] for /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/bin/slc4_ia32_gcc345 Runtime variable CMSSW_VERSION set to "CMSSW_1_4_0_DAQ1" Runtime variable LOCALRT set to "/afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1" Runtime variable CMSSW_RELEASE_BASE set to "/afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1" Runtime path settings for IGUANA_IVS: Checks [OK (but currently missing)] for /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/share/ivs Runtime variable CMSSW_BASE set to "/afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1" Runtime path settings for IGUANA_PATH: Checks [OK] for /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1 Runtime variable COIN_SHOW_FPS_COUNTER set to "1" Installation procedure complete. Developer area located at: /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1 > rmdir src > cp -r /afs/cern.ch/user/g/guragain/public/src . > cd src/Alignment/CocoaApplication > ev > scramv1 build > cd bin > ev > which cocoa /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/bin/slc4_ia32_gcc345/cocoa >cocoa MHME2_SLM25_las2_9DCOPS.txt Lo and behold, now it doesn't crash !!! Why didn't it work before ?!? Oh, well... I clean up the "run" area a little by copying files to a subdirectory SamirsFiles in /CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/CocoaApplication/bin > ls BuildFile MHslm25_b0t_data_ev21_03Nov06_00_01_laser2_only_9DCOPS.txt cocoa.cpp modifiedSDF_ME2_SLM25_las2_9DCOPS.txt CVS/ modifiedSDF_ME2_SLM25_las2_9DCOPS.txt.xml fittedEntries.out originalME2_SLM2_las2_9report.out GetWordsInLine.C output_B_0.txt longFittedEntries.out printReportDiff.cpp ME2_SLM25_las2_9DCOPS_changed_id_in_measurement_section.txt readFile.C ME2_SLM25_las2_9DCOPS.txt report.out ME2_SLM25_las2_9DCOPS.txt.xml SamirsFiles/ ME2_SLM25_las2_9DCOPS.xml slm25_b0t_data_ev21_03Nov06_00_01_laser2_only_7DCOPS.txt ME2_SLM25_las2_changed_id_in_measurement_section.txt* slm25_b0t_data_ev21_03Nov06_00_01_laser2_only_9DCOPS.txt ME2_SLM25_las2.txt.xml textfitted.out ME2_SLM25_las2.xml Now, hopefully for some real work... ------------------------------------------------------------------- First, I want to reproduce Gyongyi's results for 7 DCOPS. > cp ME2_SLM25_las2_9DCOPS.txt ME2_SLM25_las2_7DCOPS.txt and edit out DCOPS 8,9,10 info. I left Lchamber MEp2_2_08 description in the sdf but changed the system tree to object slm_line transfer_plate 2 Schamber 1 Lchamber Promply COCOA crashes with !! EXITING: ERROR IN LINE No 836 file: ME2_SLM25_las2_7DCOPS.txt : STILL SOME LINES AFTER ALL SYSTEM TREE IS READ!!! Let's try Celso's suggestion and leave it at object slm_line transfer_plate 2 Schamber 2 Lchamber and leave Lchamber MEp2_2_08 description in the file, but simply don't use it in the measurement section. This time COCOA starts, but in the end crashes with !!!FATAL ERROR: Fit::CheckIfFitPossible() no measurement depends on unknown entry CMS/slm_p2_2/MEp2_2_27/centre_Y !!! Fit will not be possible! ---- SDFError END This makes sense since the chamber is set to unk, but there is no measurement info on it. According to Celso now I have to set that chamber to FIX and it should work: Lchamber MEp2_2_27 centre X 5225.848 prec_chamber_pos_det fix // was cal Y -93.350 prec_chamber_pos_det fix // was unk Z 157.20274 prec_chamber_pos_det fix // was unk angles X 0 prec_chamber_ang_det fix // was cal // was unk for GB Y 85 prec_chamber_ang_det fix // was cal Z 0 prec_chamber_ang_det fix // was cal // was unk for GB This time it fits ! ............ program ended OK TIME:PROGRAM ENDED : 830000 0.05 TIME:TOTAL PROGRAM : 830000 0.3 In report.out, we find info in all reference frames, e.g. for an APIN: (Note the Chi^2=2421/21 dof !) @@@@@@@ NEW MEASUREMENT SET 0 DIMENSIONS: lengths = mm +- mm angles = deg +- deg 0 Chi2 after iteration = 1.32458e+08 Chi2= 1.32458e+08 / 21 dof From measurements= 1.32458e+08 from calibrated parameters= 0 Fit iteration 0 ... 0 Chi2 improvement in this iteration = 1.32455e+08 0 Chi2 after iteration = 2421.83 Chi2= 1.32458e+08 / 21 dof From measurements= 1.32458e+08 from calibrated parameters= 0 STOP: SMALL IMPROVEMENT IN ITERATION 0 = 1.32455e+08 < 0.1 %%%% Optical Object: CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 %% IN FRAME : CMS/slm_p2_2/MEp2_1_14 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 centre_X 1.5703426e-14 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 centre_Y -5.993584e-13 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 centre_Z -968.883 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 angles_X 0 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 angles_Y 0 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 angles_Z 0 %% IN FRAME : CMS/slm_p2_2 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 centre_X 1417.2862 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 centre_Y -100.15637 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 centre_Z -58.015425 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 angles_X 0.37909113 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 angles_Y 79.950096 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 angles_Z -0.024750731 %% IN FRAME : CMS FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 centre_X -133.08155 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 centre_Y -1431.6235 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 centre_Z 8098.1564 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 angles_X 270.40346 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 angles_Y -0.0043191476 FIX: -1 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 angles_Z 175.0499 Note that we get the coordinates, but not yet any errors. Pedro still has to provide those. - I check that cocoa also runs ok if I call the sdf file ME2_SLM25_las2_7DCOPS.sdf instead of *.txt. It does. So from now on I will call give all sdf's the extension .sdf instead of .txt! - To get all the information we need to run Gyongyi's root scripts, she set debug_verbose 5, so I do that and rerun. The text output on the screen is much longer, but the report.out is not much different (it is different, though) - Try to make Gyongyi's .dat files: > ev > root -b -p -q .x readFile.C++\(\"report.out\"\) as per GB's instructions in email That crashes (are we surprised ? - Ha, I think not !) Samir tells me that Pedro's readFile parser only works with the old report.out format, but not with the new format...(which is not quite true as we later find out when testing it) He also confirms that even though the file is called readFile.C, we should use it with readFile.C++ in the root command. So, I try to run it on an old report.out file I have from FNAL: > ~/CMS/cocoa/My_Files_from_FNAL_2007 > root -b -p -q .x readFile.C++\(\"report.out\"\) That fails, too: ******************************************* * * * W E L C O M E to R O O T * * * * Version 5.14/00e 29 March 2007 * * * * You are welcome to visit our Web site * * http://root.cern.ch * * * ******************************************* Compiled on 25 April 2007 for linux with thread support. CINT/ROOT C/C++ Interpreter version 5.16.16, November 24, 2006 Type ? for help. Commands must be C++ statements. Enclose multiple statements between { }. root [0] Processing readFile.C++("report.out")... Info in : creating shared library /afs/cern.ch/user/h/hohlmann/CMS/cocoa/My_Files_from_FNAL_2007/./readFile_C.so In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/backward/strstream:51, from /afs/cern.ch/user/h/hohlmann/CMS/cocoa/My_Files_from_FNAL_2007/./GetWordsInLine.C:2, from /afs/cern.ch/user/h/hohlmann/CMS/cocoa/My_Files_from_FNAL_2007/./readFile.C:22, from /afs/cern.ch/user/h/hohlmann/CMS/cocoa/My_Files_from_FNAL_2007/./fileXkSQz0.h:32, from /afs/cern.ch/user/h/hohlmann/CMS/cocoa/My_Files_from_FNAL_2007/./fileXkSQz0.cxx:16: /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the header for the header for C++ includes, or instead of the deprecated header . To disable this warning use -Wno-deprecated. /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00e/root/lib/libvectorDict.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status Error in : Compilation failed! Error: Function readFile("report.out") is not defined in current scope :0: *** Interpreter error recovered *** - Interestingly, if Samir runs this on one of his old-style report.out at FIT with an older version of root, it works, but if he runs here at CERN it fails he gets the same error as I get above !! If he, however, runs with the old version of root on the new-style report.out, he actually gets output that looks reasonable! - So, how do we get root fixed or an older version of root going ? After poking around the root home page, I follow their instructions and put the following into my .cshrc so that I can change to any ROOT version that I like, at least while I am on AFS: # Set up a specific version of ROOT on AFS for use at CERN: # (to get a different version, point ROOTSYS to a different root distribution) # to use version 5.16.00 (latest as of July 2007) setenv ROOTSYS /afs/cern.ch/sw/lcg/external/root/5.16.00/slc4_ia32_gcc34/root set path=($path $ROOTSYS/bin) set LD_LIBRARY_PATH=($LD_LIBRARY_PATH $ROOTSYS/lib) > source .cshrc Currently set ROOT version is: /afs/cern.ch/sw/lcg/external/root/5.16.00/slc4_ia32_gcc34/root done with .cshrc ... [lxplus216] ~ > which root /afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00e/root/bin/root [lxplus216] ~ > root ******************************************* * * * W E L C O M E to R O O T * * * * Version 5.16/00 27 June 2007 * * * * You are welcome to visit our Web site * * http://root.cern.ch * * * ******************************************* Compiled on 29 June 2007 for linux with thread support. CINT/ROOT C/C++ Interpreter version 5.16.21, June 22, 2007 Type ? for help. Commands must be C++ statements. Enclose multiple statements between { }. Note that "which root" still gives the previous version that we get from "eval.." - But... this still doesn't work with our report.out, so I set ROOTSYS to the same version that Samir has working at FIT: [lxplus216] ~/CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/CocoaApplication/bin > root ******************************************* * * * W E L C O M E to R O O T * * * * Version 5.14/00 14 December 2006 * * * * You are welcome to visit our Web site * * http://root.cern.ch * * * ******************************************* FreeType Engine v2.1.9 used to render TrueType fonts. Compiled on 15 December 2006 for linux with thread support. CINT/ROOT C/C++ Interpreter version 5.16.16, November 24, 2006 Type ? for help. Commands must be C++ statements. - Note that this is 5.14/00 and NOT 5.14/00e ! (no"e") - BUT... it still doesn't compile: ******************************************* * * * W E L C O M E to R O O T * * * * Version 5.14/00 14 December 2006 * * * * You are welcome to visit our Web site * * http://root.cern.ch * * * ******************************************* Compiled on 15 December 2006 for linux with thread support. CINT/ROOT C/C++ Interpreter version 5.16.16, November 24, 2006 Type ? for help. Commands must be C++ statements. Enclose multiple statements between { }. root [0] Processing readFile.C++("report.out")... Info in : creating shared library /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/CocoaApplication/bin/./readFile_C.so In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/backward/strstream:51, from /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/CocoaApplication/bin/./GetWordsInLine.C:2, from /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/CocoaApplication/bin/./readFile.C:22, from /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/CocoaApplication/bin/./fileLNMg7J.h:32, from /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/CocoaApplication/bin/./fileLNMg7J.cxx:16: /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the header for the header for C++ includes, or instead of the deprecated header . To disable this warning use -Wno-deprecated. /afs/cern.ch/sw/lcg/external/root/5.14.00/slc4_ia32_gcc34/root/lib/libvectorDict.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status Error in : Compilation failed! Error: Function readFile("report.out") is not defined in current scope :0: *** Interpreter error recovered *** Seems like is is not loading some library. If I do > printenv LD_LIBRARY_PATH /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/lib/slc4_ia32_gcc345:/afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/external/slc4_ia32_gcc345/lib:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/lib/slc4_ia32_gcc345:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/external/slc4_ia32_gcc345/lib:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/external/gcc-wrapper/3.4.5m32/lib:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/p5-libwww-perl/1.41/lib:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/p5-xml-parser/2.34/lib:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/p5-uri/1.35/lib:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/p5-template-toolkit/2.14/lib:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/expat/2.0.0/lib:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/lcg/SCRAMV1/V1_0_3-p1/lib There is no path to root there ! We look in Samir's FIT directory that works and find that he sets LD_LIBRARY_PATH specifically to point to his root/lib area. Hmmm... July 4, 2007 - Happy Independence Day ! --------------------------------------- Looking in the root documentation, I find that they provide shell scripts in $ROOTSYS/bin/thisroot.csh that set the ROOTSYS and LD_LIBRARY_PATH. I steal this piece of the script: if ($?LD_LIBRARY_PATH) then setenv LD_LIBRARY_PATH $ROOTSYS/lib:$LD_LIBRARY_PATH #for Linux, ELF HP-UX else setenv LD_LIBRARY_PATH $ROOTSYS/lib endif and put it in my .cshrc. If I source .cshrc I now get the following output: Currently set ROOT version is: /afs/cern.ch/sw/lcg/external/root/5.14.00/slc4_ia32_gcc34/root Currently set LD_LIBRARY_PATH is: /afs/cern.ch/sw/lcg/external/root/5.14.00/slc4_ia32_gcc34/root/lib done with .cshrc ... That's at least promising. But when I run on report.out, I get similar errors as before: /CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/CocoaApplication/bin > root -b -p -q .x readFile.C++\(\"report.out\"\) ******************************************* * * * W E L C O M E to R O O T * * * * Version 5.14/00 14 December 2006 * * * * You are welcome to visit our Web site * * http://root.cern.ch * * * ******************************************* Compiled on 15 December 2006 for linux with thread support. CINT/ROOT C/C++ Interpreter version 5.16.16, November 24, 2006 Type ? for help. Commands must be C++ statements. Enclose multiple statements between { }. root [0] Processing readFile.C++("report.out")... Info in : creating shared library /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CM SSW_1_4_0_DAQ1/src/Alignment/CocoaApplication/bin/./readFile_C.so In file included from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/back ward/strstream:51, from /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/Coc oaApplication/bin/./GetWordsInLine.C:2, from /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/Coc oaApplication/bin/./readFile.C:22, from /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/Coc oaApplication/bin/./file5j95Sh.h:32, from /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/Coc oaApplication/bin/./file5j95Sh.cxx:16: /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/backward/backward_warning. h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Plea se consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the header for the header for C++ includes, or inste ad of the deprecated header . To disable this warning use -Wno-deprecated. /afs/cern.ch/sw/lcg/external/root/5.14.00/slc4_ia32_gcc34/root/lib/libvectorDict.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status Error in : Compilation failed! Error: Function readFile("report.out") is not defined in current scope :0: *** Interpreter error recovered *** - I copy Samir's file over that he showed works for him locally at FIT to report_old_samir.out, but when I run I get the same error: libvectorDict.so: could not read symbols: File in wrong format - I cut the file down to just a few lines a call it report_test.out: %%%% Optical Object: CMS/slm_p2_2/MEp2_tp2/laser_MEp2_2 CAL: 7 CMS/slm_p2_2/MEp2_tp2/laser_MEp2_2 centre_X -27.974013 +- 0.048700599 -22.5 +- 0.2 Q1 CAL: 8 CMS/slm_p2_2/MEp2_tp2/laser_MEp2_2 centre_Y 40.010971 +- 0.048814819 43.25 +- 0.2 Q1 FIX: -1 CMS/slm_p2_2/MEp2_tp2/laser_MEp2_2 centre_Z 2.2946092e-13 +- 0 0 +- 0.2 Q0 CAL: 9 CMS/slm_p2_2/MEp2_tp2/laser_MEp2_2 angles_X -0.00058192314 +- 0.0057264322 0 +- 0.005729578 Q1 CAL: 10 CMS/slm_p2_2/MEp2_tp2/laser_MEp2_2 angles_Y 0.00017990949 +- 0.0057246653 0 +- 0.005729578 Q1 CAL: 11 CMS/slm_p2_2/MEp2_tp2/laser_MEp2_2 angles_Z -0.0079486097 +- 0.0056933996 0 +- 0.005729578 Q1 UNK: 6 CMS/slm_p2_2/MEp2_tp2/laser_MEp2_2 angleBetweenAxis 89.913493 +- 0.060278409 90 +- 0.005729578 Q2 The root job still fails! - Note this is all done before a single "eval ..." > eval Now, the env. variables look like this: printenv LD_LIBRARY_PATH /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/lib/slc4_ia32_gcc345:/afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/external/slc4_ia32_gcc345/lib:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/lib/slc4_ia32_gcc345:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/external/slc4_ia32_gcc345/lib:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/external/gcc-wrapper/3.4.5m32/lib:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/p5-libwww-perl/1.41/lib:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/p5-xml-parser/2.34/lib:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/p5-uri/1.35/lib:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/p5-template-toolkit/2.14/lib:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/expat/2.0.0/lib:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/lcg/SCRAMV1/V1_0_3-p1/lib:/afs/cern.ch/sw/lcg/external/root/5.14.00/slc4_ia32_gcc34/root/lib printenv PATH /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/bin/slc4_ia32_gcc345:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/cmssw/CMSSW_1_4_0_DAQ1/bin/slc4_ia32_gcc345:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/pool/POOL_2_5_1-cms147a/slc4_ia32_gcc345/bin:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/seal/SEAL_1_9_2-cms147a/slc4_ia32_gcc345/bin:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/ignominy/IGNOMINY_4_5_0/bin/slc4_ia32_gcc345:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/external/xdaq/3.7.3/bin:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/external/python/2.4.2/bin:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/lcg/root/5.14.00e/root/bin:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/external/sqlite/3.3.5/bin:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/external/oracle/10.2.0.2/bin:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/external/mysql/5.0.18/bin:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/external/gccxml/0.6.0/bin:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/external/qt/3.3.6/bin:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/external/curl/7.15.3/bin:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/external/expat/2.0.0/bin:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/external/doxygen/1.4.1/bin:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/external/glimpse/4.18.5/bin:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/external/valgrind/3.2.3-cms1/bin:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/cms/iguana/IGUANA_6_15_1-cms147a/bin/slc4_ia32_gcc345:/afs/cern.ch/cms/sw/slc4_ia32_gcc345/external/graphviz/1.9/bin:/afs/cern.ch/cms/sw/bin:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/p5-libwww-perl/1.41/bin:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/p5-xml-parser/2.34/bin:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/p5-uri/1.35/bin:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/p5-template-toolkit/2.14/bin:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/p5-template-toolkit/2.14/bin:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/external/expat/2.0.0/bin:/afs/cern.ch/cms/sw/slc4_amd64_gcc345/lcg/SCRAMV1/V1_0_3-p1/bin:/afs/cern.ch/user/h/hohlmann/bin:/afs/cern.ch/user/h/hohlmann/scripts:/usr/sue/bin:/afs/cern.ch/cms/bin/amd64_linux26:/afs/cern.ch/cms/system/bin:/usr/local/bin:/usr/local/bin/X11:/usr/bin:/bin:/usr/bin/X11:/cern/pro/bin:/afs/cern.ch/cms/sw/bin:/afs/cern.ch/cms/utils:/usr/kerberos/bin:/usr/local/lsf/bin:/usr/X11R6/bin:/afs/cern.ch/sw/lcg/external/root/5.14.00/slc4_ia32_gcc34/root/bin:/afs/cern.ch/sw/lcg/external/root/5.14.00/slc4_ia32_gcc34/root/bin:/afs/cern.ch/sw/lcg/external/root/5.14.00/slc4_ia32_gcc34/root/bin:/afs/cern.ch/sw/lcg/external/root/5.14.00/slc4_ia32_gcc34/root/bin So, seems like we still get the previously chosen root version in the paths. But the root version we get is now ******************************************* * * * W E L C O M E to R O O T * * * * Version 5.14/00e 29 March 2007 * * * * You are welcome to visit our Web site * * http://root.cern.ch * * * ******************************************* But, of course, the job still fails with the same error. - I cut the report.out file down to a single line, but it keeps failing with the same error... - I rename it to another file name with a single line, still fails .... Aaaargh !!!! - Plan B: Stoyan Stoyanov helps me with creating a stand-alone version of readFile: - insert the source code GetWordsInLine.C directly into getFile.C, create a main program in there, and hardcode the name report.out into readFile.C (for now) - make a makefile readFile.make with sole contents: g++ -o readFile readFile.C -lm - To compile successfully, all the root "T.." libraries and other stuff were commented out - to make: ./readFile.make makes executable readFile* - to run: ./readFile This runs and dumps output to the screen ! Halleluhja! I spend the rest of the day understanding and adapting Pedro's readFile.C code for the new report.out with info in all frames. July 5, 2007 ------------ Here is the output I now get from readFile.C for the SLM_2_5 report.out in the CMS frame: CMS/slm_p2_2 289.778 0 -77.6457 0 7998 0 270 0 0 0 255 0 CMS/slm_p2_2/MEp2_1_04 1012.13 0 2183.73 0 8090.02 0 -89.9633 0 0.133874 0 -24.7864 0 CMS/slm_p2_2/MEp2_1_04/DCOPS_inner_MEp2_1_04_OUT 653.211 0 1375.44 0 8047.25 0 89.9406 0 180.125 0 -14.7863 0 CMS/slm_p2_2/MEp2_1_04/DCOPS_outer_MEp2_1_04_OUT 1180.95 0 3198.56 0 8046.27 0 -89.9406 0 0.125462 0 -14.7863 0 CMS/slm_p2_2/MEp2_1_04/apin_inner_MEp2_1_04 605.94 0 1304.1 0 8089.4 0 -89.9633 0 0.133874 0 -24.7864 0 CMS/slm_p2_2/MEp2_1_04/apin_outer_MEp2_1_04 1426.42 0 3080.88 0 8090.66 0 -89.9633 0 0.133874 0 -24.7864 0 CMS/slm_p2_2/MEp2_1_14 -216.666 0 -2396.87 0 8102.54 0 270.385 0 -0.0136478 0 175.05 0 CMS/slm_p2_2/MEp2_1_14/DCOPS_inner_MEp2_1_14_IN -127.337 0 -1517.27 0 8054.48 0 270.382 0 0.0534463 0 165.05 0 CMS/slm_p2_2/MEp2_1_14/DCOPS_outer_MEp2_1_14_IN -573.373 0 -3362.07 0 8064.2 0 89.6183 0 180.053 0 165.05 0 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 -133.064 0 -1431.63 0 8096.03 0 270.385 0 -0.0136478 0 175.05 0 CMS/slm_p2_2/MEp2_1_14/apin_outer_MEp2_1_14 -301.933 0 -3381.35 0 8109.19 0 270.385 0 -0.0136478 0 175.05 0 CMS/slm_p2_2/MEp2_2_08 1783.99 0 4932.18 0 8089.71 0 -89.9939 0 0.0799936 0 -19.9743 0 CMS/slm_p2_2/MEp2_2_08/DCOPS_inner_MEp2_2_08_OUT 1315.04 0 3700.45 0 8043.44 0 -89.987 0 0.0791605 0 -14.9743 0 CMS/slm_p2_2/MEp2_2_08/DCOPS_outer_MEp2_2_08_OUT 2086.67 0 6585.39 0 8040.24 0 -89.987 0 0.0791594 0 -14.9743 0 CMS/slm_p2_2/MEp2_2_08/apin_inner_MEp2_2_08 1225.18 0 3394.69 0 8089.54 0 -89.9939 0 0.0799936 0 -19.9743 0 CMS/slm_p2_2/MEp2_2_08/apin_outer_MEp2_2_08 2349.41 0 6487.8 0 8089.89 0 -89.9939 0 0.0799936 0 -19.9743 0 CMS/slm_p2_2/MEp2_2_27 -910.925 0 -5166.11 0 8091.35 0 270 0 0 0 170 0 CMS/slm_p2_2/MEp2_2_27/DCOPS_inner_MEp2_2_27_IN -701.705 0 -3864.84 0 8045.25 0 90 0 180 0 165 0 CMS/slm_p2_2/MEp2_2_27/DCOPS_outer_MEp2_2_27_IN -1474.63 0 -6749.43 0 8041.25 0 90 0 180 0 165 0 CMS/slm_p2_2/MEp2_2_27/apin_inner_MEp2_2_27 -626.856 0 -3555.08 0 8091.35 0 270 0 0 0 170 0 CMS/slm_p2_2/MEp2_2_27/apin_outer_MEp2_2_27 -1198.35 0 -6796.16 0 8091.35 0 270 0 0 0 170 0 CMS/slm_p2_2/MEp2_tp2 2168.75 0 6847.85 0 8041.25 0 89.9433 0 180 0 164.991 0 CMS/slm_p2_2/MEp2_tp2/DCOPS_MEp2_reference_2_IN 2168.8 0 6847.83 0 8040.72 0 89.9433 0 180 0 164.991 0 CMS/slm_p2_2/MEp2_tp2/laser_MEp2_2 2141.72 0 6855.06 0 8001.24 0 89.9427 0 180.008 0 164.991 0 Seems reasonable... After a few hours I also get the SLM coordinates right: CMS/slm_p2_2/MEp2_tp2/laser_MEp2_2 -27.974 0.0487006 40.011 0.0488148 2.29461e-13 0 -0.000581923 0.00572643 0.000179909 0.00572467 -0.00794861 0.0056934 CMS/slm_p2_2/MEp2_tp2/DCOPS_MEp2_reference_2_IN 0.53239 0.0199057 4.07923e-13 0.02 0 0.000572958 0 0.000572958 -4.09943e-05 0.000572945 CMS/slm_p2_2/MEp2_tp2 -43.25 0.1 22.5 0.1 -0.0283524 0.0389083 -89.9912 0.0382861 -0.0283507 0.0389083 CMS/slm_p2_2/MEp2_1_14/DCOPS_outer_MEp2_1_14_IN 45.0808 0.537259 992.094 0.0999997 0 0.000114592 190 0.000114592 -9.07572e-08 0.000114592 CMS/slm_p2_2/MEp2_1_14/DCOPS_inner_MEp2_1_14_IN 42.1199 0.537259 -884.33 0.0999997 0 0.000114592 10 0.000114592 4.69407e-07 0.000114591 CMS/slm_p2_2/MEp2_1_14/apin_inner_MEp2_1_14 -8.54015e-13 0 -968.883 0 0 0 0 0 0 0 CMS/slm_p2_2/MEp2_1_14/apin_outer_MEp2_1_14 1.2101e-13 0 988.187 0 0 0 0 0 0 0 CMS/slm_p2_2/MEp2_1_14 -104.544 8.96289 111.074 6.44068 0.308177 0.159815 79.9502 0.0391621 -0.0782089 0.157722 CMS/slm_p2_2/MEp2_1_04/DCOPS_inner_MEp2_1_04_OUT 42.1732 0.537248 -884.33 0.0999997 0 0.000114592 170 0.000114592 1.71851e-06 0.000114592 CMS/slm_p2_2/MEp2_1_04/DCOPS_outer_MEp2_1_04_OUT 45.0268 0.537248 992.094 0.0999997 0 0.000114592 -10 0.000114592 5.70081e-07 0.000114591 CMS/slm_p2_2/MEp2_1_04/apin_inner_MEp2_1_04 -5.69126e-13 0 -968.883 0 0 0 0 0 0 0 CMS/slm_p2_2/MEp2_1_04/apin_outer_MEp2_1_04 -3.4509e-13 0 988.187 0 0 0 0 0 0 0 CMS/slm_p2_2/MEp2_1_04 -92.0222 4.50926 112.454 3.24416 -0.739366 0.150789 -80.2127 0.0391503 0.787561 0.150258 CMS/slm_p2_2/MEp2_2_27/DCOPS_outer_MEp2_2_27_IN 50.1 0.538 1657.15 0.1 0 0.000114592 185 0.000114592 0 0.000114592 CMS/slm_p2_2/MEp2_2_27/DCOPS_inner_MEp2_2_27_IN 46.1 0.538 -1317.83 0.1 0 0.000114592 185 0.000114592 0 0.000114592 CMS/slm_p2_2/MEp2_2_27/apin_inner_MEp2_2_27 -8.73003e-15 0 -1635.89 0 0 0 0 0 0 0 CMS/slm_p2_2/MEp2_2_27/apin_outer_MEp2_2_27 8.83305e-15 0 1655.19 0 0 0 0 0 0 0 CMS/slm_p2_2/MEp2_2_27 -93.35 0 157.203 0 0 0 85 0 0 0 CMS/slm_p2_2/MEp2_2_08/DCOPS_inner_MEp2_2_08_OUT 46.1641 0.537578 -1317.83 0.1 0 0.000114592 -5 0.000114592 1.09898e-06 0.000114591 CMS/slm_p2_2/MEp2_2_08/DCOPS_outer_MEp2_2_08_OUT 50.0359 0.537578 1657.15 0.1 0 0.000114592 -5 0.000114592 0 0.000114592 CMS/slm_p2_2/MEp2_2_08/apin_inner_MEp2_2_08 -5.94355e-14 0 -1635.89 0 0 0 0 0 0 0 CMS/slm_p2_2/MEp2_2_08/apin_outer_MEp2_2_08 6.26079e-13 0 1655.19 0 0 0 0 0 0 0 CMS/slm_p2_2/MEp2_2_08 -91.7129 1.87028 146.665 1.3242 -0.912914 0.11142 -85.025 0.0388449 0.922467 0.11817 CMS/slm_p2_2 -77.6457 0 7998 0 270 0 0 0 255 0 Actually, the above file is not quite right. It has only 10 number on each line; this bug is now fixed. We get 12 numbers now (3 pos. + errors; 3 angles + errors) - Another hour and I can write both those output to two files: cms.dat and slm.dat, respectively. I copy this version of readFile to my.fit.edu and to my localhost. - Now I try to run Gyongyi's root scripts: slm_cms_readcocoaout_las2_9DCOPS.C It chokes on line 3 of the cms.dat file. I delete the CMS/slm_p2_2/ prefix to all object names and then it sort of runs. The root window still disappears, but it make at least .ps output plot. Need some more cleanup. July 6, 2007 ------------ - I also get rid of the CMS.slm_p2_2/ prefix in the slm.dat file and now the root graphics file doesn't disappear and the script finishes normally in root. - Trying to get x_slm info for plotting apins and DCOPS I notice that the info that is in my slm.dat file are from the fitting procedue is (as usual) in the parent ref. frame, i.e. in chamber coordinates. So, I need to modify what gets written by readfile for the slm.dat and take the actual coordinates from the summary at the end of the report.dat file. - To do that, I need to do some string operations. Stoyan points me to a good reference web site: http://www.cppreference.com/cppstring/index.html - After a few hours the slm.dat file only contains coord. in SLM and the cms.dat only CMS coord. July 9, 2007 ------------ More work on the slm_cms_readcocoaout_las2_9DCOPS: - Now pretty much almost all (available) COCOA coordinates and errors get read from file instead of being put in by hand. - Added points for PG data, but need PG_disk_center to get this completely right. - Added a (kludgy) red line for the laser direction - still by hand. - Added position of the TP - still need to add the fitted CCD hits (we have the measured ones) July 10, 2007 ------------ - change color of unused CCDs to gray - use Dave Eartly's center of ME+2 disk as used for survey: //For comparison, here is the PG data for the alignment pins from the Survey group's note //This is the apin cmsz_c coordinate; values are put in by hand based on the note Float_t PG_disk_center_z = {8820.}; //as given by Dave Eartly: (7/9/07) // Float_t PG_disk_center_z = {9000.}; // gives better result ?! //"Marcus, // Surveyors define the center of the YE+2 disc at Z_cms = 8820.000 // ME+2 iron face = 8520.000 // We define theoretical ME+2 SLM = 7998.000" This certainly doesn't improve the results... But now I am thinking that defining the apins at the same depth as the first layer of the CSC is not right either since the targets definitely sit above that point. Should check the PG note on the target holders ! - I add the center of the SLM itself - For the back chamber I add the the tower_height (or more specifically the z-distance for the first CSC layer b/w front and back chambers) of 248mm to the PG apin distances to make them visible on the plot. I also inflate the error to +/- 1cm per Dave's email on the topic. - In a discussion at the 5pm meeting with Teresa we find out how to interpret the adapter/extensions that were used for the PG targets on all SLM25 chamber except for the radially innermost 2 targets. They make the targets stand off by 20mm (+3mm target thickness) from the target hole, so for the COCOA comparison I should add 23 mm in z_CMS to get to the surface of the target hole for those 8 targets. Now, I still need to find out how that relates to the surface of the chamber... July 10, 2007 ------------- - I do the above correction and the PG apin points end up mostly at the same Z_CMS value. Good ! - I add lines to the plots to represent shims. Shims look reasonable ! July 11, 2007 ------------- - Make the root script slm_cms_readcocoaout_las5_10DCOPS.C that produces the equivalent root plot for Laser 5 data in SLM2-5. Again we see a laser that is tipped down and the far chamber is very tilted. Shims look very reasonable. - Note that all my analysis up to now has been done with an allowed uncertainty of 4mrad (4000 urad) in my sdf ! - We rediscover the fact that non-straining or not constraining the chamber tilt angels, can drastically change the outcome of the fit and in particular the tilt angle of the laser. For a 0.1 mrad constraint the laser 2 line comes out almost parallel to the nominal SLM, whereas for only 4.0 mrad it is tilted down quite a bit. July 13, 2007 ------------- - I add an offset of 43.7mm from the chamber PCB ("skin") to the top of the alignment pin based on what Oleg told me. Now the reconstructed and PG z-positions basically agree for the first time !!!! - I also add reconstructed and PG positions for the central sticker target that is directly on top of the PCB. Oleg claims a PG error for that target of only 2mm or so. - I make reco plots for both Laser 2 and 5. Interestingly, in each case the inner chamber near the respective laser get pushed up/down quite a bit while for the far chamber it looks better. July 14, 2007 ------------- - Samir and I go to SX5/UX5 and take a look at the alignment pins. They indeed stick a good distance out from the frames! 43.7 mm seems like a very reasonablenumber. At the wide side they do not go above the CFEB cover, though, which explains why they needed the extensions/adapters to intall the PG targets there. - We also confirm that the alignment pins go through the entire width of a CSC frame and come out on the other end where they stick out about 1cm. Took a lot of pictures of this and the TPs on the ME- side! - Jim Bellinger sends us profiles for 2 ME-2 and 1 ME-3 line that Samir is working on reconstructing. Only 2/3 of the profiles look good, so beware ! - I set up the following files: COCOA sdf: ME2_SLM25_las2_AND_5_7DCOPS_each.sdf root script for plotting: slm_cms_readcocoaout_las2_AND_5_10DCOPS.C to fit both lasers 2 and 5 simultaneously! It works and the results are surprising. COCOA insists on tilting both lasers UP (away from the chambers) to accomodate the data. I try to fix chamber positions and laser tile angles to "force" it to tilt the angles down, but without success. Weird! But I have to say that I am not absolutely sure that I have done the laser tilt constraints right, because I am not quite sure which angle I have to constrain. - I add the laser 5 hits to the single laser 2 fit script and vice versa to get a better picture. It seems impossible to accomodate that data with TPs at the same height. Also, note that the TP z-positions are still set to FIX at nominal value in COCOA. If I look at the PG note, the Z-positions of the XX12 and XX13 targets on the transfer plate extensions that carry the ref. sensor and laser all seem to come out at more or less the same z_CMS of ~ -773mm in the disk frame for all 6 points! Anyway... Signing off from Alignment Camp 2007 at CERN - it was a blast !! MH July 18, 07 ----------- Back in Florida! The new TO DO list: - Verify how the XX12 and XX13 targets were placed on the extension plates. Were extensions used ? DONE - Set the TP z_CMS values to PG and rerun COCOA - Fix the Pixel 1 issue!! - Verify which laser angle is the laser dip angle that we can try to fix using PG - Use Pedro's new version of COCOA and test new features - Add new feature to COCOA writes out the measurement value into report.out -> Pedro According to Dave the disk center is at z_CMS = 8820, so the TP targets are measured by PG to be at z_CMS = 8820-773 = 8047. I verify in photos of TPs I took in 2006 of the ME+ side that these targets are sticker target, not disk targets, so we don't need to correct for target thickness in this case! That is actually good news because so far the two-laser fit put everything about a cm too low in z_CMS. Ok, so I put that correction right into the sdf ! The fit results look better, but the inner chambers still get pushed down too much. I wonder if this is still a FIRST PIXEL problem! If I use D-x instead of x (in my mind) for the hit position, there might be a chance that the inner chambers get put into a higher z_CMS position ! NEED TO LOOK AT FIRST PIXEL PROBLEM !!!! July 19, 07 ----------- I looked at the input file with the measurements for the laser hits and verified that we are not plotting them at the moment, but "CCD_length - hit_position". I changed the script that plots laser 2 and 5 and now correctly plot just hit_position as measured from the "real" first pixel that is the one closest to the chambers. Of course, now hits don't fall on a line anymore, but then they are not what is actually fitted, so I need to adjust that in the sdf. July 20, 07 ----------- I subtract the CCD length from bi_cops_hCCDcal in the ME2_SLM25_las2_AND_5_7DCOPS_each.sdf //DCOPS Calibration Dowel-Pixel Parameters (offset for pixels) //bi_cops_hCCDcal 57.579 // original height above dowel put in by R. Lee, but this is // (most likely) the LAST pixel on the away side of the chamber bi_cops_hCCDcal 28.907 // height above dowel for FIRST pixel (CLOSEST to chamber) // = 57.579-CCDlength (2048*0.014=28.672) = 28.907 ... // length rightCCDYtoDowel2 bi_cops_hCCDcal cal_error_YCCD cal and rerun COCOA. Fits look even worse with the CCD pushed down even further towards smaller z_CMS. So, the CCD direction must still be towards the dowel pin instead of away from the dowel pin. How to change that direction? Not obvious at all to me, so: Contact Robert Lee on this issue: Dear Robert, thank you very much for your response! Looking at your thesis and from your mail I have determined that in your COCOA implementation of the CMS alignment geometry, which is still the basis for our COCOA reconstruction effort, the CCD 2,4 (L,R) directional vectors, are indeed pointed downward in the -y direction in the local DCOPS ref. frame. In other words, you took the first CCD pixels for the L and R CCDs to be near the top of the DCOPS and then went down TOWARDS the dowel pin. Now, Dave has carefully calibrated the distances from dowel pin 2 to the pixels that are CLOSEST to the dowel pin for all DCOPS in the EMU system. In addition, from a CCD readout point of view those pixels also show up as "pixel 1" and then the readout counts upwards AWAY from the dowel pin to higher pixel numbers. Consequently, we need to implement those as "pixels 1" in COCOA and then count upward! You say in your last email that this can be done in COCOA as follows: > "If you want one of the pixel arrays vectors to be swapped, I think it > should only require the addition of a negative sign in the definition of > the sensor object." However, I'm not clear on how to technically implement this in COCOA. Where exactly would you do the "addition of a negative sign" to flip the CCD readout direction to +y in local DCOPS coordinates for CCD L & R in the following DCOPS definition: COPS DCOPS_MEp2_reference_2_IN ENTRY { length rightCCDYtoDowel2 bi_cops_hCCDcal cal_error_YCCD cal length leftCCDYtoDowel2 bi_cops_hCCDcal cal_error_YCCD cal length rightCCDXtoDowel2 bi_rightCCDX_disp cal_error_XCCD cal length leftCCDXtoDowel2 bi_leftCCDX2_disp cal_error_XCCD cal length upCCDXtoDowel2 bi_cops_vCCDcal cal_error_XCCD cal length upCCDYtoDowel2 bi_upCCDY_disp cal_error_YCCD cal length downCCDXtoDowel2 bi_cops_vCCDcal cal_error_XCCD cal length downCCDYtoDowel2 bi_downCCDY_disp cal_error_YCCD cal } centre X 0 prec_pos_tp cal Y 0.5 prec_pos_tp cal // with MTCC shims (acc. to Dave) Z 0 prec_pos_tp cal angles X 0 prec_ang_tp cal Y 0 prec_ang_tp cal // original Z 0 prec_ang_tp cal What do I change here? I can't simply flip the DCOPS over by setting angles Y 180 ... since that will flip the whole DCOPS and not just the two CCDs or can I ? The "entry" lines only contain positions and I can easily modify those to get the location of the first pixel near the dowel pin right, but it doesn't help me with the ORIENTATION of the CCD direction (CCD vector). Any help or suggestion on how to do this is greatly appreciated since we are stuck on this issue at the moment and our fits are messed up! Pedro, is there maybe an internal parameter for a DCOPS CCD that let's us choose its direction and that I don't know about ? Thanks again, Marcus - As a cheap but unsatisfactory (b/c will make calibrations difficult) kludge, I could go back to bi_cops_hCCDcal 57.579 and then subtract the CCD length from all measurement point in the COCOA measurement input .txt file, which will then give the correct distance from the upper end of the CCD for fits... I could even put that into my FORTRAN routine that produces the input text file to do this automatically. Well, I'll get back to this AFTER I come back from vacation in a week! 1/22/08 MH ----------- - Just for future reference, root scripts and output files for all this work are in /afs/cern.ch/user/h/hohlmann/CMS/cocoa/CMSSW_1_4_0_DAQ1/src/Alignment/CocoaApplication/bin I have set the alias 'run' to cd to that directory - I couldn't sftp into lxplus to transfer some files to our cluster at FIT, but ssh was working. Got an error message of the type [geant4@uscms1 muonScintillatorCoincidence]$ sftp hohlmann@lxplus.cern.ch Connecting to lxplus.cern.ch... ******************************************************************************* * The LXPLUS Public Login Unix Service * * http://cern.ch/ComputingRules : Govern the use of CERN computing facilities * ******************************************************************************* hohlmann@lxplus.cern.ch's password: Received message too long 1920298606 - Problem is that I am printing stuff to the terminal from my .cshrc file at lxplus on login. That's fine with ssh, but a problem if you use sftp which doesn't use a terminal. - Solution is to add the following if statement into .cshrc: if( $?prompt )then # do this only on ssh, but not on termless login via sftp echo 'running .cshrc ...' endif Now sftp from the cluster to lxplus works !