Diario delle immagini

• Iguana
• Tracker Visualization
• Rpc Visualization
• An old fart guide to CMS software

• Prototipo di fedtrackermap. Si tratta di un disegno fatto con Inkscape.
• Il crate creato in SVG viene esportato in formato png e quindi usato come base dell'immagine finale realizzata come un collage html.
• Usato pesantemente Modifica/Crea cloni in serie di Inkscape
• Ho provato a creare l'immagine completa in Inkscape ma con circa 40000 cloni di un unico quadrato, Inkscape si blocca.
• Il mio primo uso di Inkscape. Ci ho messo circa 2 ore. Piu' che altro per capire come accedere alle varie funzionalita'.
• Ho trovato il programma molto semplice da usare ed anche potente.

• Immagini dei Fed da un documento CMS

• Prima immagine ottenuta con la demo dell'uso delle nuove classi della fedtrackermap . Qui un ingrandimento
• Il software usato e' incluso in questa tarball. Questa contiene anche le immagini svg originali.
• Altre spiegazioni in un mail a Suchandra,Giacomo e altri.

• Prima immagine ottenuta con la demo dell'uso delle 4 classi della trackermap qt.
• Il software usato e' incluso in questa tarball.

• Collage di immagini del pixel tracker ottenute con VisCustomTracker.

• Collage di immagini su MTCC

• Produrre una trackermap buona da stampare si e' dimostrato difficile. Comunque una ricetta e' quella di trovarne una a colori con tutti i moduli colorati e senza vuoti. Quindi rendere bianco il colore di sfondo e trasformare tutto in b/w.

• Alcune interessanti visualizzazioni di dati prese dal Web. Potrebbero essere usate per il tracker. Vedi ad esempio la rappresentazione di piu' istogrammi in 3D.

• E' fatto tutto in Javascript. Si usano 2 immagini :una piccola e l'altra grande. Potete usare i tasti up e down per zoomare dentro e fuori . Il mouse invece controlla il panning. Per questo si usa la posizione del mouse sull'immagine piccola per stabilire quale parte dell'immagine grande mostrare.

• Lo zoom e' fatto in Javascript. Si usano 2 immagini :una piccola e l'altra grande. Potete usare i tasti up e down per zoomare dentro e fuori e i tasti left e right per aumentare/diminuire la zona di zoom.

• esempio di rappresentazione di moduli con colori e numeri
• figura presa da un Workshop sul monitoraggio del tracker

• esempio di tavolozza alternativa per la trackermap
• figura presa dal Physycs TDR 1

• immagini ottenute con un esempio di generazione di mappa con il nuovo framework.
• La suddivisione delle varie parti del detectors in stringhe(TIB), ladder (PIXB), rods(TEC), petals(TEC) e rings (TID) viene mostrata colorando il modulo a seconda del numero della parte cui appartiene.
• L'immagine mostra una serie di problemi dovuti a bachi sia del programma che fa la visualizzazione che del software del nuovo framework.

• immagini ottenute con Orca + esempio di generazione di mappa nel caso d'uso 2.
• 1000 eventi con mu a 100 Gev senza pileup. Il colore del modulo rappresenta l'adc medio nel modulo. Passando il mouse sul modulo si ottengono anche la larghezza della distribuzione degli ADC(Rms) e il numero di digi nel modulo.

• immagini ottenute con Batik usando la la seguente immagine svg.
• L'immagine png e' stata ottenuta col comando

  java -Xmx256m -jar /home/zito/temp/batik/batik-rasterizer.jar -w 2000. -h 2000. trackeradc.svg 

• L'immagine jpeg col seguente comando:

  java -Xmx256m -jar /home/zito/temp/batik/batik-rasterizer.jar -m image/jpeg -q 0.8 -w 2000. -h 2000. trackeradc.svg

• Infine la versione pdf con:

  java -Xmx256m -jar /home/zito/temp/batik/batik-rasterizer.jar -m application/pdf trackeradc.svg

• Questo scatter plot contiene in ogni bin il numero di eventi in cui il modulo rappresentato dal bin conteneva simhits.La numerazione di layer e moduli e' quella adottata da Orca. Come si vede c'e' prima il barrel. I layer piu' alti del barrel sono quelli stereo.
• L'istogramma e' stato generato usando la Physics and Data Quality Monitoring infrastructure. La sorgente dei dati e' questa applicazione di Orca che fa il booking di un istogramma 2D e chiama la fill ogni volta che un modulo contiene simhits.
• L'istogramma e' salvato automaticamente dal programma "testClient" fornito assieme all'infrastruttura DQM. Da notare che per far arrivare i dati dal server al client e' necessario far andare uno speciale programma: il collector cioe' il programma "histoServer". Questi 3 programmi possono girare anche su computer diversi.Inoltre al posto di un client autonomo e' prevista anche una interfacciaWeb.

• Ogni poligono dell'immagine SVG e' collegato a una differente immagine png. Il codice usato nell'immagine SVG e' il seguente:

      var xlinkns = "http://www.w3.org/1999/xlink";
          var myPoly = evt.target;^M
          var myTrackerPlot = svgdoc.getElementById("plot");
          if (evt.type == "mouseover") {^M
                  var moduleId = myPoly.getAttribute("id");^M
                  var filename=moduleId+".png";
                  myTrackerPlot.setAttributeNS( xlinkns, "xlink:href", filename )
  

• L'elemento che contiene l'istogramma e' un <image id="plot" xlink:href="2805001.png
• Il nome del file contenente l'istogramma e' uguale al valore dell "id" del singolo polygon con l'aggiunta di ".png"
• Gli istogrammi sono creati contemporaneamente alla mappa svg da questo programma. Da notare che il programma ha richiesto l'aggiunta di una variabile "histNumber" in TmModule e la dichiarazione come public di alcune variabili in TmModule e TrackerMap.
• Gli istogrammi sono contenuti nel file Tracker.root" .
• Gli istogrammi sono salvati come png dallo stesso programma che li crea ma e' possibile fare questo anche con la seguente macro di Root che li trasforma in gif.

• immagini ottenute con Iguanacms.
• Per la prima volta uso la tecnica di cambiare il colore del pixel se il nuovo simhit cade sul precedente (cioe' uso lo schermo per fare l'integrazione del segnale).
• Circa un milione di simhit nell'endcap creano questa specie di radiografia dove i cerchi piu' scuri corrispondono a zone di overlap tra i silici. Le 3 bande piu' scure sono invece gli anelli stereo.
• Ed ecco come e' programmata la tecnica con Qt:

  /* allocation */
  if(firstcall){
    image = new QImage(600,600,8,256);
    for ( int i=1; i<256; i++ )
          image->setColor( i, qRgb(255,i,0) );
    image->setColor( 0, qRgb(255,255,255) );
   for ( int y=0; y<600; y++ ) {                 // set image pixels
          uchar *p = image->scanLine(y);
          for ( int x=0; x<600; x++ )
              *p++ = 0;
      }
      firstcall=false;
      }
  ....
  ....
  /*display*/
   QPixmap * pm = new QPixmap(600,600);
    *pm = *image;
    bitBlt(this,0,0,pm);
  ....
  ....
  /*filling*/
              QRgb pixel = image->pixel(ix,iy);
              int green = qGreen(pixel);
              if(green > 1) green = green -1;
              image->setPixel(ix,iy,green);
  

• immagini ottenute con Orca + il tool che genera SVG in versione preliminare.
• 4000 eventi con mu a 100 Gev senza pileup. Numero di digi per evento 10.000 contro circa 10 rechits!La maggioranza dei digi sono rumore.

• immagini ottenute con iguana+customtracker
• Notare la bizzarra geometria del Tib con l'alternarsi di anelli su raggi diversi e la presenza di "buchi" negli anelli di raggio minore.

• Mappa ottenuta col programma di Antonella.
• Modificata la classe TrackerDisF3 .
• Moduli rappresentati con traslazione.

• Varie rappresentazioni di simhits e simtracks nello stesso evento con pileup

• Mappa ottenuta col programma di Antonella.
• Modificata la classe TrackerDisF3 per correggere un baco nella rappresentazione dei moduli.
• Sono evidenti ancora alcuni problemi, come una fila di moduli nel primo layer del pixel mancanti.
• I moduli sono rappresentati rispettando la posizione reale con delle sovrapposizioni.

• Mappa ottenuta col programma Dstrips.java
• Il colore indica il numero di strip morte nel modulo.Blu indica 0 strip morte, rosso numero di strip morte > 40.
• I valori sono stati generati usando i dati sui 2173 sensori finora presenti nel database. Questi dati sono stati assegnati ripetutamente fino a definire il numero di strip morte per tutti i moduli del tracker.
• I dati del data base sono stati estratti dal file xml col programma Displayxml.java col comando

  java Displayxml output.xml  > temp.lis 

  come per la figura "Bad strips nel tracker".

• Immagini prese dalla documentazione di Orca.
• UML sta per Unified Modelling Language ed e' una tecnica per progettare programmi ad oggetti.
• I primi quattro sono diagrammi delle classi.
• L'ultimo disegno e' un diagramma di sequenza e mostra l'andamento temporale dell'esecuzione del programma come una sequenza di messaggi scambiati tra le classi.
• Lista delle classi con documentazione presa direttamente dal codice sorgente.
• Nel CVS browser guarda Muon/MEDetector e Muon/MEDigitizer per il codice sorgente

• Figura ottenuta col programma Java Displayxml fatto girare sul file output.xml.
• I dati sono stati estratti dal database della costruzione del tracker usando la seguente query.
• Si tratta di circa 700 sensori: ogni riga corrisponde a un sensore. Le strip morte sono indicati dai punti neri.
• I dati sono stati ottenuti inviando la query col programma Java Readxml
• La figura e' stata salvata usando la classe Gifencoder di acme.com

• figure ottenute con Root sul file rechit.root prodotto convertendo un file paw col comando h2root rechit.hbook rechit.root. La tabella era stata salvata sul file rechit.hbook coi comandi Paw:

  h/file 1 rechit.hbook 1024 n
  hrout 0
  h/close 1
  

• Comandi usati in root:

  TFile f("rechit.root"); 
  h1->SetMarkerColor(6);
  h1->Draw("Posx:Posy:Posz","Det==2&&Part==2");
  

• figura ottenuta con Paw exec crearechit
• Istogramma della posizione della strip accesa (x) e l'errore su x (dx:dovrebbe essere la lunghezza del cluster di strip accese) e quello su y (in pratica quest'ultimo e' la lunghezza della strip)

• Figure ottenute con Iguana mettendo a 0 PT_MIN_TO_DRAW
• Tutte le 132 tracce simulate sono disegnate
• Le tracce ricostruite sono celesti con frecce rosse tangenti a ogni punto servito a calcolare la traccia.

• Mappa fatta con java Dtracker1
• Codice sorgente(Dtracker1.java) e file di dati usato(bf.dat)

• Immagine presa dal TDR.
• La struttura di sostegno e' essenziale per capire la geometria del traccciatore ed eventualmente trovare nuovi modi di rappresentarla.

• Immagini create con java Leggihits e ./Prog15 6 0 1 100 1 100

• Prime 2 immagini create con ./Prog11 5 0 1 100 1 100
• Le altre da ./Prog15 5 0 1 100 1 100
• La prima immagine permette di calcolare phi (tra 0 e 360 gradi)
• La seconda immagine permette di calcolare theta (tra -90 e +90 gradi)

• Immagine creata con iguanain Oscar
• I volumi che definiscono gli RPC sono stati selezionati sulla lista a destra cliccando col tasto destro del mouse.

• Immagine creata con iguanain Oscar
• I materiali sono stati selezionati sulla lista a destra cliccando col tasto destro del mouse.

• Immagine creata con OrcaVisMain poi salvata in trigger.iv e vista con qualche modifica all'iv in Prog10
• Le tracce rosse sono muoni che producono il segnale negli RPC. Gli hit che non coincidono con le camere sono nell'endcap.

• Immagine creata con Orca_5_3_4 dal primo e unico evento di h300eemm.TestPURedHat in suncmsc::/data/valid/ORCA_5_3_3/VALIDATION.boot
• L'evento ha 132 tracce simulate ma solo quelle con pt>3 sono disegnate. Nel tracker sono prodotti 9704 SimHits.
• Le tracce rosse sono mu. Quelle blu sono pioni. Le tracce verdi sono elettroni. Le tracce celesti indicano altre particelle.

• Immagine creata con Orca_5_3_4 dal primo evento di h300eemm.Pileup2x1033 in suncmsc::/data/valid/ORCA_5_3_3/VALIDATION.boot
• 2166 tracce di cui solo quelle con pt>3 sono disegnate.181616 simhits nel track

• Immagine creata con menu nella cartella Prog14
• Si possono vedere:idoppi moduli formati da 2 moduli messi l'uno sull'altro leggermente spostati.
• Anelli vicini di raggi alternati e unico e con i moduli in parte sovrapposti.

• Immagine presa da Internet

• Immagine ottenuta con ./Prog10
• Codice e dati contenuti in questa cartella

• Immagine ottenuta con java Drpc 10

• Immagine ottenuta con java Drpclayer 10

• Qui sono rappresentate tutte le camere della stazione 4 degli rpc del barrel:la quarta riga contiene le 4 camere di sopra.
• Immagine ottenuta con java Drpclayer 6

• La stazione 3 degli rpc e' fatta come le stazioni 2 e 4:2 anelli di 36 e 18 camere.
• Immagine ottenuta con .Prog0 e il file station3.iv

• La stazione 1 per gli Rpc dell'endcap e' fatta di 3 anelli di 36 camere ciascuno.
• Immagine ottenuta con .Prog0 e il file station1.iv

• Gli rpc dell'endcap sono in sostanza un layer aggiunto a queste camere.
• immagine presa dal tdr del trigger

• Un'altra rappresentazione del trigger.
• immagine presa dal tdr del trigger

• Tutto CMS viene diviso in 33 torri in teta e 144 segmenti in phi per un totale di 144*33 sezioni ognuna delle quali e' vista da un processore che legge esattamente 8 strips di una doppiagap dello strato 2 out di riferimento.
• immagine presa dal tdr del trigger

• Come i chip da 6 pollici sono utilizzati per fare i sensori del tracker.
• Preso da Internet

• Parti del tracker:cosa sono TIB TOB TEC e TID(non labellato ma e' l'end cap interno).
• Preso da Internet

• Esempio di mappa a colori di un disco. Colori uguali indicano uguale posizione in z.
• Ottenuto con java Dlayer 25

• La parziale sovrapposizione dei moduli rende difficile capire a quale di questi appartiene un hit.
• Figura prodotta con ./Prog11 3 25 1 100 1 100 con piccole modifiche al codice.

• Primo tentativo di costruire una "mappa" zoomabile del tracker
• Programma Java Dtracker

• La numerazione dei moduli nel barrel se si fa un "taglio" a phi=0
• Ottenuto con java Correggitr 37

• La numerazione e' importante
• Ottenuto con java Correggitr 7

• Se si lavora in una proiezione x-z e' facile vedere le intersezioni tra le tracce nel forward e i dischi.
• Figura fatta con Prog11 leggermente modificato: ./Prog11 5 0 1 100 1 100

• Eliminando gli hit nel forward e guardando una proiezione x-y , tracce nel barrel devono incontrare gli hit corrispondenti. In questo evento la maggioranza delle tracce sono nel forward, per questo sembra esserci poca corrispondenza.
• Figura fatta con Prog11 leggermente modificato: ./Prog11 5 0 1 100 1 100

• Per rappresentare dati 3d oltre alle coordinate x,y,z con relative proiezioni, abbiamo anche le coordinate r, t,f(ro,teta e fi). Queste permettono interessanti rappresentazioni e in particolare il V-plot inventato da Hans Drevermann permette di stabilire se degli hit formano o no una traccia.
• immagine presa dalla rete

• Qui abbiamo la mappa completa dei 17.000 moduli. In blu sono indicati i moduli doppi.
• Fatti col programma java "Leggitr" dando dei comandi del tipo java Leggitr n con n tra 1-41

• La distribuzione degli hit in z per lo stesso disco della figura precedente mostra che questi non sono proprio in un piano ma in una striscia di circa 10 cm dispostiin righe. Questo rispecchia la disposizione dei moduli. In alcuni casi si possono vedere due hit vicinissimi: si tratta dei doppi moduli.
• Distribuzione fatta processando con Paw la tabella dei circa 10000 hit di un evento(senza pileup) (tabella simhits2.dat). I comandi dati sono:

  paw
  exec creahit
  nt/plot 1.y%z layer=25.AND.det=2
  

• Cercare di rappresentare tracce,hit e detector in modo da capire per quali hit passa una traccia, e' particolarmente difficile,specialmente in 3D.
• Figura prodotta con ./Prog11 6 25 1 100 1 100 e piccole modifiche al codice.

• Alla figura precedente abbiamo ora sovrapposto le tracce ricostruite da Orca. Non tutte, altrimenti vedremmo una gran confusione, ma solo quelle dovute a particelle molto veloci (ad alto pt). Lo si vede dal fatto che le tracce deviano poco nel campo magnetico.
• Figura prodotta con ./Prog11 5 0 1 100 1 100
• I muoni sono rossi. Le tracce blu sono pioni. L'altro colore indica tracce di altro tipo.

• Questa figura mostra i "simhit" nel tracciatore generati da un evento simulato. Sono punti nello spazio generati dall'impatto delle tracce con i wafer.
• Nella realta' vengono aggiunti degli hit di rumore almeno 10 volte tanto: dovuti al cosiddetto pileup (cioe' l'accumularsi di segnali di eventi contigui nel tempo)
• Alcuni simhit nella realta' non sono punti nello spazio (quando il modulo non e' doppio) quindi una delle coordinate si conosce con l'approssimazione delle dimensioni del modulo (6'')
• Le numerose tracce presenti nell'evento sono irriconoscibili ma vediamo solo una specie di radiografia del tracciatore.
• Figura prodotta con ./Prog11 2 0 1 100 1 100

• Questa figura mostra in sezione 2 anelli vicini di un cilindro del barrel con doppi moduli. Si puo' notare il fatto che anelli vicini hanno raggio leggermente diverso e che i moduli sono leggermente spostati sovrapponendosi in parte.
• Prodotto con comando ./Prog11 1 33 1 2 1 100

• Questa figura mostra il fatto che un disco in effetti non e' un piano, ma i moduli sono disposti a gruppi leggermente sfasati sovrapponendosi in parte nello spazio.
• Il secondo anello a partire dal centro e' inoltre doppio.
• Immagine prodotta con ./Prog8 1

• Qui la struttura del tracciatore e' mostrata in forma schematica da una sezione x,z (immaginate di vederlo dall'alto):ogni barretta corrisponde a un anello di moduli.
• Qui si possono vedere in dettaglio alcune caratteristiche particolari: ad esempio i moduli non sono esattamente su cilindri o dischi ma vengono disposti leggermente spostati in modo da potersi in parte sovrapporre ai bordi.
• Alcuni anelli (in blu) sono composti da doppi moduli che misurano due coordinate invece di una.
• Abbiamo inoltre due misure di moduli:quelli piccoli (thin) e quelli grandi (thick)
• I moduli del silicon barrel interni sono disposti a elica
• I moduli del pixel forward (endcap) sono disposti a "turbina"
• La rappresentazione schematica e' stata prodotta da un programma Java poi tradotto in Qt di nome appltk: le altre figure da una variazione del Prog8

• Nonostante la sua complessita' il tracciatore puo' essere schematizzato come una "bambola russa" :una serie di circa 14 cilindri l'uno dentro l'altro.
• La parte piu' interna (magenta) e' il pixel detector; poi in verde abbiamo l'inner silicon detector e quindi in blu l'outer silicon detector.
• Da qui si vede come i moduli(wafer) sono organizzati in anelli che formano dei cilindri concentrici al fascio nel "barrel" e dischi perpendicolari al fascio nei "tappi" (end-caps).
• Singole figure prodotte da Prog8

• La grande complessita' del "tracciatore" puo' essere vista in questa immagine. Tutto lo spazio attorno al punto di collisione per una lunghezza di 6 metri e fino a un raggio di 1.25 m e' pieno di circa 17.000 wafer di silicio che misurano le tracce lasciate dalle particelle prodotte dall'urto.
• Qui sono mostrati solo i wafer cioe' la parte sensibile: nella realta' c'e tutta l'impalcatura di sostegno con l'elettronica e i cavi.
• Prodotto con una variazione di Prog8 (facendo un taglio in phi)

• Ingrandimento della precedente che mostra il solo hit nella stazione 1 con 12 simhits nei DT e 2 negli RPC.

• Un'immagine prodotta da Iguana/Orca per mostrare il segnale lasciato da una traccia di mu nel muon detector.Si puo' vedere come ogni stazione abbia 12 strati di cui 8 misurano una coordinata e 4 quella perpendicolare. Questi producono i "simhits" rossi. Le frecce verdi sono i "segmenti di traccia" ricostruiti.

• Un'immagine da Internet per mostrare la struttura e la numerazione del muon detector in 4 "stazioni" di misura.Ogni stazione consiste di piu' strati incluso uno strato di RPC per misurare con precisione la posizione e il tempo di passaggio dei muoni.

• Per mostrare come il barrel RPC e' definito in Orca e perche' contiene 850 parallelepipedi, ho estratto un unico spicchio (salvato in spicchio.iv) colorando alcuni parallelepipedi in rosso e rendendone alcuni trasparenti in parte. Ecco che invece di 8 ne abbiamo 14 .

• Perche' non provare a caricare gli RPC barrel in OpenInventor.Basta salvare il file iv da Iguana e poi ricaricarlo in un visualizzatore.
• Trovo il progragramma originale Prog0 che pero' ha uno sfondo nero non adatto. Occorre cambiare lo sfondo.Per facilitarmi la vita in seguito ,cambio il nome del programma in Rpcvis1 . Esso vuole la descrizione del detector in rpc.iv e viene compilato da Makerpcvis1. Purtroppo la compilazione va fatta su pccms3.cmsfarm1

• Questa mappa (fatta con un programma Java) mostra invece tutte le 480 camere RPC del barrel(96 per ruota).

• Una sezione trasversale di Cms puo' dare un'idea chiara di dove si trovino esattamente le camere RPC nel barrel del muon detector. Anche questa immagine,fatta con Iguana, era gia' presente su Internet.
• Notate i 2 muoni che hanno triggerato in rosso.

• Anche questa immagine e' presa da Internet e mostra molto ben CMS come sara' veramente e non come una "navicella nello spazio". Si vede molto bene l'interno formato dai 3 rivelatori :tracciatore(tracker),Ecal,Hcal all'interno del magnete e il muon detector all'esterno(le 5 ruote e 4 dischi della figura precedente). Ma ora si puo' vedere come tra le varie sezioni del rivelatore di muoni ci sia il ferro.

• La prima fonte di immagini e' Internet. Questa immagine non e' stato necessario prepararla ma l'avevo gia' inclusa in un'altro documento.Essa da un'idea chiara della struttura della parte piu' esterna di CMS fatta da 5 ruote indipendenti e 12 spicchi. Completano la struttura 2 "tappi" fatti da 4 dischi anch'essi divisi in spicchi.Qui ad essere rappresentate sono solo le camere RPC che sono una parte del muon detector.