Danskere skal bygge regnekraften til verdens største teleskop
more_vert
close
close

Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og at Mediehuset Ingeniøren og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, tilbud mm via telefon, SMS og email. I nyhedsbreve og mails fra Mediehuset Ingeniøren kan findes markedsføring fra samarbejdspartnere.

Danskere skal bygge regnekraften til verdens største teleskop

Illustration: European Southern Observatory

Når verdens største teleskop, ELT-teleskopet (Extremely Large Telescope), skal bygges på en bjergtop i Chile, bliver det med et dansk designet serversystem. Force Technology har nemlig vundet opgaven med at bygge det computer-cluster, der skal sørge for de ekstremt tunge beregninger, der skal bruges til at styre flere spejle på ELT-teleskopet.

Konkret er det systemudvikleren Poul-Henning Kamp og ingeniøren Niels Hald Pedersen, der skal udvikle serversystemet.

Regnekraften i serversystemet skal bruges til at styre den adaptive optik, der korrigerer for den turbulens i atmosfæren, som gør det svært at tage billeder af stjernehimlen fra Jordens overflade.

Forvrængninger fra turbulens

Adaptiv optik består en deformerbare spejle, der i realtid kan korrigere for de billedforvrængninger, som skyldes turbulens i atmosfæren. På den måde kan man tage billeder, som er næsten lige så skarpe, som hvis de var taget ude fra rummet. Adaptiv optik tillader, at det optiske system i teleskoperne kan observere meget finere detaljer på meget svagere astronomiske objekter, end der ellers ville være mulighed for fra Jorden.

Læs også: Danmark bevilger 63 millioner kr. til verdens største teleskop

»Helt firkantet skal vi levere det computer-cluster, der skal forhindre stjernerne i at tindre, når ELT-teleskopet observerer dem. Med et lille teleskop er den cylinder af luft, man kigger op igennem, homogen, men når cylinderen bliver 39 meter i diameter, er turbulens et alvorligt problem. På ELT-teleskopet har man yderligere det problem, at nogle af spejlene er så store, at de deformeres af tyngdekraften og vindstød. Man løser begge problemer ved at kigge på nogle naturlige eller kunstige 'guide-stars' med wavefront-sensorer. Lyset der rammer disse wavefront-sensorer har været hele vejen igennem teleskopet, ligesom det lys som den videnskabelige detektor opfanger, og derfor kan man matematisk regne ud, hvordan man skal deformere spejlene for at kompensere for den turbulente atmosfære,« fortæller Poul-Henning Kamp.

Det er spejl 4 og 5, samt to spejle i selve det videnskabelige instrument, som Force Technology skal styre. Hovedspejlet styres af et lokalt autonomt system, og det sørger udelukkende for, at kanterne på de mange sekskantede spejlsegmenter flugter indebyrdes. Illustration: European Southern Observatory

Lang levetid er krævende

Når man bygger et gigantisk teleskop som ELT-teleskopet, så er forventningen til levetiden noget længere end almindelig elektronik, og det er især den udfordring, de to danske udviklere har løst.

»Normalt laver man disse beregninger på specialbygget hardware med DSP- og FPGA-chips, men det giver vedligeholdelsesproblemer på den lange bane. Teleskoper lever i mange årtier, men chips er håbløst gammeldags efter blot nogle få år. Vi lavede en simpel prototype for nogle år siden, som viste, at moderne x86-servere har computerkraft nok til at lave disse tunge beregninger, selv for verdens største teleskop,« siger Poul-Henning Kamp.

Beregning: 700 GFLOPs

Det bliver nogle voldsomt store beregninger der skal igennem det danske serversystem for at styre de aktuatorer der drejer spejlene. Der er tale om adskillige matricer med sidelængder på op til 10.000, og beregningerne skal udføres 500 gange i sekundet for at kunne følge med den atmosfæriske turbulens og eventuelle resonanser i stålkonstruktionen.

»I alt blive det til omkring 700 GFLOPs, (700 milliarder operationer i sekundet red.) per wavefront-sensor, og teleskopet forventes i sidste ende at have seks sensorer. Vores prototype skal dog kun lave beregningerne for en enkelt wavefront-sensor og simulerer så beregningerne for de fem andre,« siger Poul-Henning Kamp.

Poul-Henning Kamp er blogger på Ingeniøren og luftede allerede for en måned siden lidt afsløret for det nye projekt, som han og Niels Hald skal arbejde på. Det skulle dog lige aftales med European Southern Observatory, hvor mange detaljer han og Niels Hald kunne fortælle om. Illustration: Ingeniøren

Læs også: Karriereplanen på skinner...

Teleskopet, der afslører liv på andre planeter

Hos GTS-instituttet Force Technology er man glade for at kunne være med til at bygge ELT-teleskopet.

»Vi er meget glade for at have vundet opgaven i et helt almindeligt udbud med andre konkurrenter. Det giver synlighed verden over, når Danmark bidrager til et prestigeprojekt som ELT-teleskopet. Den adaptive optik er forudsætningen for at teleskopet i Chile kan blive funktionelt,« siger Jakob Nørgaard, projektleder i Force Technology.

Hvad bliver den største tekniske udfordring i projektet?

»For mig bliver det at koreografere data-transporten imellem computerne. Der kommer data ind fra seks wavefront-sensorer (6 * 800x800 pixels, 32bit per pixel, 500 gange per sekund), og der kommer feedback-data tilbage (ca. 7.000 værdier, 500 gange per sekund) fra de spejle, der skal styres. Det skal alt sammen enten den ene eller den anden vej igennem beregningsprocessen – i takt og til tiden, « fortæller Poul Henning Kamp.

For Niels Hald Pedersen er opgaven også en af de mere sjældne. Han arbejder især med at optimere de numeriske beregninger, så de maksimalt udnytter CPU, cache og RAM.

»Men lige som koreografering af datatransport mellem de fysiske maskiner er en voksen opgave, så er datatransport internt i den enkelte maskine også en udfordring. Og det er en opgave, man som programmør sjældent skænker en tanke, da det normalt er noget, som maskinen tager sig af transparent. For at sikre den grad af mikrosekund-forudsigelighed, som er nødvendig i dette projekt, er vi nødt til at sørge for, at de data, en given beregning skal bruge, ligger tættest mulig på den processorkerne, der skal udføre beregningen. Og da alle 64 processorkerner skal lave noget forskelligt samtidig, så er dette lidt af et cirkus,« fortæller Niels Hald Pedersen og fortsætter:

Læs også: Bjergtop i Chile sprænges torsdag aften

»Skal man f.eks. gange en 10.000 x 10.000 matrix med en 10.000 vektor hurtigt, så vil man fordele denne beregning mellem mange processorkerner, f.eks. 56. Det betyder, at hver core skal indlæse små 1,8 mio flydende tal, eller lidt over 7 MBytes. For at dette skal køre hurtigt, og frem for alt forudsigeligt, så skal man sikre, at så meget af det, der skal læses, allerede ligger i lokal level3-cache, og at resten ligger i RAM på den lokale memorybus. Dette er normalt ikke er noget, programmøren kan se, eller har adgang til at styre. Vi er i dette projekt nød til at gøre intern datatransport til et selvstændigt og eksplicit trin i beregningen.«

Hvordan er det at være med i byggeriet af verdens største teleskop?

»For det første er det rent teknologisk spændende, vores forrige prototype viste helt nye og meget billigere muligheder for implementering af adaptiv optik, nu skal vi vise at det ikke bare er en teoretisk mulighed. For det andet er det videnskabeligt spændende, jo bedre vi gør det, desto bedre kommer ELT til at virke. Og ELT har rigtig gode chancer for at blive teleskopet, der afslører liv på en anden planet, end den vi tager alt for givet til daglig. Men mest af alt er det en rigtig nørde-opgave,« siger Poul Henning Kamp.

Læs også: Nyt grej på teleskoper skal veje fjerne planeter

Hej Henning!

Et stort tillykke med opgaven.

Hvilken hardware bruges - er det normale Linux PC'er, eller er det noget speciel hardware?

Bruges specielt hardware til Matrix multiplikationen, og andet der er egnet til at køre parallelt i hardware?

Er f.eks. matrix beregningerne noget som kan udføres med tilstrækkelig præcision af moderne grafikkort?

  • 1
  • 1

Hvis jeg ellers forstår det ret, så laver man en beregnet korrektion af spejlene for et kommende tidpunkt baseret på data fra et allerede passeret tidspunkt.
Altså at man simulerer en fremtidig korrektion ud fra 'historiske' data.
Mekanisk skal spejlene jo også 'nå' at blive korrigerede.
Mit spørgsmål er så: Hvad er tidsforskydningen?

  • 1
  • 0

Håber dette projekt kan give anledning til at fylde din blog. Så fascinerende og trivielt et parcelhusbyggeri kan være, så meget højere må en blog om projektet i Andesbjergene kunne flyve.
Kunne være meget spændende at følge.

  • 2
  • 0

Det undrer lidt at der ikke takes om GPUer eller endnu bedre NVidias Volta som klarer 125 TFlops og bruger mindre end 400W.

Otte Volta kan klare en PFlop ( Peta Floating point operations) og bruger ca 3 KW.

Meget populære til AI beregninger som jo især handler om regnekapacitet.

En gaming GTX Titan Z dual GPU er en kommerciel GPU som bruger ca 500W og har 5760 Cuda kerner. Ikke hel som en Volta men stadig bedre end en CPU.

En Volta løsning koster mindst 10 gange mindre end en CPU løsning og Volta og dens efterfølgere er kommet for at blive pga AI.

  • 3
  • 0

De der 125 TFLops er hvis man bruger "tensor-enheden", som er NVIDIAnsk for nogle specifikke operationer på 16-bit floats. Jeg tror ikke det er helt nok præcision til dette problem. Niels Hald Pedersens beregninger får de til at lyde som om det er 32-bit tal (omend det er uklart om det er heltal eller brudne tal), og så må man "nøjes" med omkring 15TFLOPS.

Af nysgerrighed lavede jeg selv en hurtig implementering i Futhark af den nævnte konkrete beregning (at gange en 10.000 x 10.000 matrix med en 10.000 elementer vektor), og på mit AMD Vega 64 (en high-end forbruger-GPU) kan det gøres på lidt over 1ms (omkring 900 gange i sekundet). Det kan nok forbedres med en faktor 2 hvis man tuner det i dybden.

Til gengæld synes jeg GPUer noget rod at holde gang i mht. drivere og deslige, så jeg forstår godt hvis man ikke gider.

  • 3
  • 0

CPU, cache og RAM. Det ser spændende ud, men glem nu ikke at fortælle os her, hvor meget i kan presse igennem, eller bare en cache hit rate?

L3 cachen på en x86? Det er vist en XEON (PHI?), de har typisk mellem 8 og 12 MB DELT L3 mellem 4 kerner, PHI kan måske noget bedre, men de godt 7MB til hver af 56 kerne, kræver jo at man har 8 MB L3 på hver kerne?

En lille komplikation må det dog være, at den datamængde skal læses 500 gange per sekund, samtidigt og til 56 kerner;-)

  • 0
  • 0

> men de godt 7MB til hver af 56 kerne, kræver jo at man har 8 MB L3 på hver kerne?

Nej, og det er der ikke nogen alm. cores der har (AMD (Zen) bruger 8MB L3 caches delt mellem 4 cores, XEONs bruger forskelligt, har typisk færre cores end AMD, og dermed mindre total L3).

Beregningen kræver, at hver core har adgang til 7 MB koefficienter.
Man skal så arbejde for at a) så meget som muligt heraf ligger i L3 cache og b) at resten er tilgængeligt via den lokale memorybus ("lokal" er vigtigt her. Store x86-servere har mellem 8 og 16 separate fysiske memorybusser). At sikre sig at de data man skal bruge ligger på den memorybus, som den pågældende core er forbundet med bliver en eksplicit del at programmeringen.

> XEON (PHI?)
Regn XEON Phi død (or at least smelling funny, quipping F.Zappa).
Intel har opgivet produktlinien og meddelt at de starter from scratch med en ny many-core arkitektur (long story).

  • 1
  • 0

> Niels Hald Pedersens beregninger får de til at lyde som om det er 32-bit tal

Langt det meste skal laves i 32 bit IEEE floats...

> Til gengæld synes jeg GPUer noget rod at holde gang i
> mht. drivere og deslige, så jeg forstår godt hvis man ikke gider.

Nemlig. Pålideligheden af GPUer er også et issue.

  • 1
  • 0

En ting er antal pipelinede operationer per sekund, men hvor lang tid må der gå fra sensorernes output til actuatorerne skal drives?
Det tager jo nok lidt tid at præparere og loade/unloade matricer af den størrelse.

  • 0
  • 0

Giver du en garanti for at de virker om 20 år og at der kan købes reservedele i 50 år ?


Jeg kender ikke så meget til X86 arkitekturen, at jeg ved hvordan man koder cachestyring i software. I de tilfælde, at jeg laver noget, så plejer jeg at optimere koden, så jeg tror at cachen automatisk opfører sig eksemplarisk, og tager nogen målinger.

Hvis man skal til at styre det, så frygter jeg, at man nemt havner i noget processor afhængigt kode, der ikke holder 50 år, da den pågældende processor hurtigt forsvinder fra markedet. Går det igennem en driver, er der større sandsynlighed for det holder - måske nogle få år, eller ned til et halvt år, hvor næste "opdatering" kommer. Det er rigtigt, at det sandsynligvis vil kunne fås hardware, men softwaren tror jeg ikke på kommer uden vedligehold når den skal tilpasses fremtidige drivere og hardware.

Konklussion: I kan ligeså godt bruge GPU'en. Den er sandsynligvis - når vi ser 50 år frem - mindst ligeså kompatibel som CPU'en. Med mindre, at I helt kan undgå styring af hardwaren.

  • 0
  • 0

En ting er antal pipelinede operationer per sekund, men hvor lang tid må der gå fra sensorernes output til actuatorerne skal drives?
Det tager jo nok lidt tid at præparere og loade/unloade matricer af den størrelse.


Og, hvis beregningen skal deles over flere computere, så kommer der også noget delay på grund af pakkestørrelsen. Med en fornuftig arkitektur, hurtigt giga-lan, lille pakkestørrelse, og forholdsvis få computere at dataene flyder igennem og evt. PCI-E bus, så tror jeg dog godt at forsinkelsen kan gøres meget lille.

  • 0
  • 0