LHC kører på højtryk og tvinger CERN til at rydde ekstra storage-plads

Illustration: CERN
I 2016 har Large Hadron Collider genereret 10 gange så meget data som i hele 2015, og CERN har været nødt til at finde plads til de mange ekstra data.

Partikelacceleratoren Large Hadron Collider kører bedre end nogensinde, efter en opgradering i 2015. Det har givet udfordringer for CERN, der har fået flere data ind, end der var kapacitet til.

Det var forventet, at LHC ville kunne generere kollisioner cirka 30 procent af tiden, men i praksis har acceleratoren givet data 70 procent af tiden, skriver kollegerne hos Fermilab i nyhedsbrevet Symmetry Magazine.

LHC har således allerede genereret flere data i den nuværende forsøgsserie end i hele den første serie. Der er også i 2016 skabt mere end 10 gange så mange data som i hele 2015, hvor acceleratoren undergik en opgradering, så forsøgene nu foregår med kollisioner med den dobbelte energi.

2015 var præget af problemer med at få acceleratoren op at køre ved det fulde energiniveau og give tilstrækkelige pålidelige datasæt, men nu kører LHC altså bedre end ventet. Visse af instrumenterne ved LHC genererer enorme datamængder, der skal lagres til efterfølgende behandling, og derfor har storage-kapaciteten været under pres.

»Antallet af harddiske, vi køber og lagrer data på, besluttes flere år i forvejen, og det baseres på forventninger om LHC's oppetid. Men fordi LHC overgår selv de mest rosenrøde scenarier, så er vi begyndt at løbe tør for diskplads. Vi har været nødt til hurtigt at konsolidere de gamle simuleringer og data for at gøre plads til nye kollisionsdata,« siger professor Jim Olsen fra Princeton University, som arbejder ved CMS-eksperimentet på LHC, til Symmetry Magazine.

Læs også: 3.000 processorkerner kører på fuldt tryk for at opdage datafejl fra LHC

Datamængderne er så enorme, at det ved visse af eksperimenterne er nødvendigt med grundlæggende databehandling, før data bliver lagret i datacentret. Det skal eksempelvis vurderes, om en kollision har givet brugbare data, og ellers skal de kasseres. Tilsvarende foretager visse af de mange sensorer også en vis databehandling, inden data sendes videre.

Læs også: Så voldsom er storage-udfordringen i Cern: 45 petabyte data og 68.000 diske

Cirka 600 millioner gange hvert sekund smadrer protoner ind i hinanden på vej rundt i partikelacceleratoren, hvor partiklerne passerer gennem fire hovedinstrumenter. Hver kollision generer ifølge CERN cirka én megabyte, og datacentret ventes at skulle håndtere 25 gigabyte pr. sekund, når alle fire eksperimenter kører på fuldt blus. Efter den indledende databehandling skrives cirka én gigabyte hvert sekund til det datasæt, fysikere rundt om i verden kan arbejde med.

Selvom der allerede er skabt adskillige petabyte data på LHC, så er der indtil videre blot foretaget cirka én procent af de kollisioner, der forventes at blive skabt med LHC, der forventes at blive holdt i drift med løbende opgraderinger frem til 2037.

LHC har som hovedmission at påvise eksistensen af Higgs-bosonen, men de 8.000 forskere, der benytter CERN's data, arbejder også på mange andre projekter, der udnytter de samme data.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Rune Larsen

Gad vide om nogen har fortalt forskerne, at de kan spare ~10% plads ved at komprimere deres AOD/root filer med standard komprimering - og mere med specialiseret komprimering (a.k.a. bedre filformat). Men storage-problemet er måske primært med de rå filer, som de tilsyneladende holder tæt til kroppen og ikke de forbehandlede, som publiceres til offentligheden?

rsl@linux-brr4:~/apps/xrootd-4.4.1> 7z a cms 00E16FBB-9071-E011-83D3-003048673F12.root  
   
7-Zip [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18  
p7zip Version 9.20 (locale=da_DK.UTF-8,Utf16=on,HugeFiles=on,8 CPUs)  
Scanning  
   
Creating archive cms.7z  
Compressing  00E16FBB-9071-E011-83D3-003048673F12.root        
Everything is Ok  
rsl@linux-brr4:~/apps/xrootd-4.4.1> ls -la 00E16FBB-9071-E011-83D3-003048673F12.root cms.7z  
-rw-r--r-- 1 rsl users 611324720  6 okt 10:18 00E16FBB-9071-E011-83D3-003048673F12.root  
-rw-r--r-- 1 rsl users 551299084  6 okt 10:27 cms.7z  
rsl@linux-brr4:~/apps/xrootd-4.4.1> calc 551299084 / 611324720  
        ~0.90181055331771959099
  • 1
  • 6
#6 Rune Larsen

Hvor lang tid tager komprimeringen?

rsl@linux-brr4:~/apps/xrootd-4.4.1> time 7z a cms.7z 00E16FBB-9071-E011-83D3-003048673F12.root   
   
7-Zip [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18  
p7zip Version 9.20 (locale=da_DK.UTF-8,Utf16=on,HugeFiles=on,8 CPUs)  
Scanning  
   
Creating archive cms.7z  
   
Compressing  00E16FBB-9071-E011-83D3-003048673F12.root        
   
Everything is Ok  
   
real    1m48.019s  
user    3m36.776s  
sys     0m1.824s

på i7-4702HQ.

Du skal huske at disse data skal gemmes i realtid.

Så vidt jeg kan se, kommer CMS's primære dataset (ADO filerne) ikke direkte fra CMS eksperimentet, men er en præprocesseret udgave, hvor de forskellige partikler, som kollisionerne fremkalder er identificeret, og "kedelige" kollisioner er frafiltreret med hhv. hardware-triggere direkte i CMS og efterfølgende triggere i endnu et præanalyse-step på en nærligende server-farm. http://opendata.cern.ch/collection/CMS-Primary-Datasets

  • 0
  • 0
Log ind eller Opret konto for at kommentere