Workstation mit Threadripper macht schlapp bei Satellitendatenberechnung
- Ersteller el-mujo
- Erstellt am
el-mujo
Admiral Special
Hallo in die Runde.
Hier wollt ich mal ein kleines Beispiel aus der realen Arbeitswelt bringen, wo überhaupt hochgradig performante Standard-Systeme benötigt werden und dass diese u.U. auch nicht mehr ausreichen, wenn es um die wirklich großen Datenmengen geht.
Woran arbeite ich?
Ab einer Methode, Vitalitätsveränderungen an Waldflächen mithilfe von Satellitendaten zu erfassen. Ohne jetzt zu sehr über die Methodik ins Detail gehen zu wollen, komme ich an einem Punkt in der Prozessierungspipeline, wo mir meine zur Verfügung stehende 24-Kern Workstation in Aussicht gestellt hat, dass sie damit heillos überfordert ist.
Worum gehts genau?
Ein Satellitenbild der Sentinel-2 Reihe hat 120 Megapixel, bei 12 spektralen Subbändern. Also 10980x10980x12 Pixel + diverse Header und Qualitätsbänder, die für meine Geschichte nicht relevant sind. Aus diesen 12 Bändern werden sog. Vegetationsindizes berechnet. Das ist meist eine simple mathematische Beziehung der einzelnen Spektralbänder zueinander. So reduziert sich die Dimension auf nur noch 1 Band, dem Vegetationsindex. Davon haben wir aber gleich 12 verschiedene berechnen lassen. Mit Metabändern entsteht also wieder ein 20-Kanäliges Bild. Diese Vegetationsindizes reagieren auf Veränderungen der Pflanze bedingt durch Veränderung im Wasserhaushalt, der Cellulose und dem Chlorophyllgehalt. Jede dieser für uns wichtigen vitaltätsbestimmenden Komponenten hat ihre eigene 'Reflektionsbande', also ihre eigene korrespondierende Wellenlänge. Beim Chlorophyll ist das bekanntlich der Bereich des grünen Lichts um 530nm. Den Wassergehalt erfassen wir z.B. im Kurzwelleninfrarot bei 1600nm. So wir bekommen also diverse Indizes, die wiederum alle auseinanderklamüsert werden müssen, da mit für jeden Index eine sog. Zeitreihe vorliegt. Für das Testgebiet haben wir 98 Satellitenbilder runtergeladen. Diese sind mehr oder weniger gleichmäßig über's Jahr verteilt (insg. 6 volle Jahrgänge).
Was zeigt uns erstmal ein Zeitreihe für Waldflächen? Eine sog. 'Phänologiekurve'. Die beschreibt den zeitlichen Verlauf der Vitalität des Blattgrüns im Jahresgang. Und jedes Jahr auf's Neue gibts eine neue Kurve. Nun sind aber nicht jedes Jahr gleiche Witterungsbedingungen, sodass erstens, die Zeitreihe ausgedünnt wird (Wolken) und zweitens, es zu einer veränderten fernerkundlich erfassten Vitalität kommt. Will sagen, je feuchter, desto vitaler ist der Bestand.
Was gilt es zu berechnen?
Wenn ich sagen will, ob sich ein Baum oder Wald aktuell im Stress befindet, muss ich mir seine Vergangenheit anschauen und beachten, wann innerhalb des Jahres ich ihn begutachte.
Die Zeitreihe ist da ein Ansatz, die Vergangenheit der zurückliegenden Vegetationsperioden abzubilden. Man könnte jetzt die Differenz von Jetzt zu einem beliebigen Punkt in der Vergangenheit bilden, aber wer sichert denn zu, dass das Bild aus dem Gegenjahr einen halbwegs 'gesunden' Zustand abbildet, an dem wir uns ja orientieren wollen? Und interessiert also wie gut der Baum aktuell gegenüber dem Zeitpunkt seiner eigenen statistischen Vergangenheit steht, wo ja Jahre der Feuchte und Dürre dabei waren. Diesen Zustand, den ich mal als Mittelung bezeichnen würde, ist quasi die ideale Sollkurve eines Baums, den er wahrscheinlich annimt, wenn gleiche Bedingungen wie in der Vergangenheit herrschten. Wir wollen nun detektieren, wie stark von dieser Sollinie abgewichen wird, an dem entspr. Zeitpunkt im Jahr.
Mit anderen Worten, wir wenden eine Methode an, die das Bild mit dem Vegetationsindex so analysiert, dass sie die einzelnen Jahrgänge übereinander legt und darauf eine sog. '2d-Kerneldichtefunktion' ansetzt, die diesen Zustand des statistisch gesicherten Mittels der überlagerten Phänologierkurven liefert. Und das für jedes der 120Millionen Pixel einer Szene separat (4 Szenen hat das Land). Das macht die Statistiksoftware R.
Und hier genau hakt's.
Schon eine 0,3MPixel Testszene benötigte 2,5 Stunden an Rechenzeit. Hochgerechnet auf eine 120MPixel-Szene wären dass 41,6 Tage bei 47 zur Verfügung gestellten logischen Prozessoren. Das gesamte Untersuchungsgebiet umfasst jedoch 4 Sentinel-Kacheln á 120 MPixel. Und duch die Notwendigkeit die Beobachtungsdichte an Bildern für alle Zeitreihen anzugleichen und daher noch zeitlich interpolierte Daten ins System eingespeist werden, wird ein Zeitlicher Stack nicht 100 sondern eher 200-300 Bilder umfassen.
Will sagen, da bin ich mit meiner Workstation raus. Das kann nur noch auf einem größeren Cluster gerechnet werden. Also Einzel-CPU-Workstation jedenfalls ist das Gerät damit völlig überfordert.
Hier wollt ich mal ein kleines Beispiel aus der realen Arbeitswelt bringen, wo überhaupt hochgradig performante Standard-Systeme benötigt werden und dass diese u.U. auch nicht mehr ausreichen, wenn es um die wirklich großen Datenmengen geht.
Woran arbeite ich?
Ab einer Methode, Vitalitätsveränderungen an Waldflächen mithilfe von Satellitendaten zu erfassen. Ohne jetzt zu sehr über die Methodik ins Detail gehen zu wollen, komme ich an einem Punkt in der Prozessierungspipeline, wo mir meine zur Verfügung stehende 24-Kern Workstation in Aussicht gestellt hat, dass sie damit heillos überfordert ist.
Worum gehts genau?
Ein Satellitenbild der Sentinel-2 Reihe hat 120 Megapixel, bei 12 spektralen Subbändern. Also 10980x10980x12 Pixel + diverse Header und Qualitätsbänder, die für meine Geschichte nicht relevant sind. Aus diesen 12 Bändern werden sog. Vegetationsindizes berechnet. Das ist meist eine simple mathematische Beziehung der einzelnen Spektralbänder zueinander. So reduziert sich die Dimension auf nur noch 1 Band, dem Vegetationsindex. Davon haben wir aber gleich 12 verschiedene berechnen lassen. Mit Metabändern entsteht also wieder ein 20-Kanäliges Bild. Diese Vegetationsindizes reagieren auf Veränderungen der Pflanze bedingt durch Veränderung im Wasserhaushalt, der Cellulose und dem Chlorophyllgehalt. Jede dieser für uns wichtigen vitaltätsbestimmenden Komponenten hat ihre eigene 'Reflektionsbande', also ihre eigene korrespondierende Wellenlänge. Beim Chlorophyll ist das bekanntlich der Bereich des grünen Lichts um 530nm. Den Wassergehalt erfassen wir z.B. im Kurzwelleninfrarot bei 1600nm. So wir bekommen also diverse Indizes, die wiederum alle auseinanderklamüsert werden müssen, da mit für jeden Index eine sog. Zeitreihe vorliegt. Für das Testgebiet haben wir 98 Satellitenbilder runtergeladen. Diese sind mehr oder weniger gleichmäßig über's Jahr verteilt (insg. 6 volle Jahrgänge).
Was zeigt uns erstmal ein Zeitreihe für Waldflächen? Eine sog. 'Phänologiekurve'. Die beschreibt den zeitlichen Verlauf der Vitalität des Blattgrüns im Jahresgang. Und jedes Jahr auf's Neue gibts eine neue Kurve. Nun sind aber nicht jedes Jahr gleiche Witterungsbedingungen, sodass erstens, die Zeitreihe ausgedünnt wird (Wolken) und zweitens, es zu einer veränderten fernerkundlich erfassten Vitalität kommt. Will sagen, je feuchter, desto vitaler ist der Bestand.
Was gilt es zu berechnen?
Wenn ich sagen will, ob sich ein Baum oder Wald aktuell im Stress befindet, muss ich mir seine Vergangenheit anschauen und beachten, wann innerhalb des Jahres ich ihn begutachte.
Die Zeitreihe ist da ein Ansatz, die Vergangenheit der zurückliegenden Vegetationsperioden abzubilden. Man könnte jetzt die Differenz von Jetzt zu einem beliebigen Punkt in der Vergangenheit bilden, aber wer sichert denn zu, dass das Bild aus dem Gegenjahr einen halbwegs 'gesunden' Zustand abbildet, an dem wir uns ja orientieren wollen? Und interessiert also wie gut der Baum aktuell gegenüber dem Zeitpunkt seiner eigenen statistischen Vergangenheit steht, wo ja Jahre der Feuchte und Dürre dabei waren. Diesen Zustand, den ich mal als Mittelung bezeichnen würde, ist quasi die ideale Sollkurve eines Baums, den er wahrscheinlich annimt, wenn gleiche Bedingungen wie in der Vergangenheit herrschten. Wir wollen nun detektieren, wie stark von dieser Sollinie abgewichen wird, an dem entspr. Zeitpunkt im Jahr.
Mit anderen Worten, wir wenden eine Methode an, die das Bild mit dem Vegetationsindex so analysiert, dass sie die einzelnen Jahrgänge übereinander legt und darauf eine sog. '2d-Kerneldichtefunktion' ansetzt, die diesen Zustand des statistisch gesicherten Mittels der überlagerten Phänologierkurven liefert. Und das für jedes der 120Millionen Pixel einer Szene separat (4 Szenen hat das Land). Das macht die Statistiksoftware R.
Und hier genau hakt's.
Schon eine 0,3MPixel Testszene benötigte 2,5 Stunden an Rechenzeit. Hochgerechnet auf eine 120MPixel-Szene wären dass 41,6 Tage bei 47 zur Verfügung gestellten logischen Prozessoren. Das gesamte Untersuchungsgebiet umfasst jedoch 4 Sentinel-Kacheln á 120 MPixel. Und duch die Notwendigkeit die Beobachtungsdichte an Bildern für alle Zeitreihen anzugleichen und daher noch zeitlich interpolierte Daten ins System eingespeist werden, wird ein Zeitlicher Stack nicht 100 sondern eher 200-300 Bilder umfassen.
Will sagen, da bin ich mit meiner Workstation raus. Das kann nur noch auf einem größeren Cluster gerechnet werden. Also Einzel-CPU-Workstation jedenfalls ist das Gerät damit völlig überfordert.
Zuletzt bearbeitet:
Krümel
Grand Admiral Special
Entweder die Berechung so umstellen, dass auch Grafikkarten sie durchführen können (die sind bei angepassten BErechnungen deutlich schneller) oder daraus ein BOINC-Projekt machen. 
enigmation
Admiral Special
Werden denn alle 24 Kerne ausgelastet? Vielleicht mit NNCONECTIONS anpassen?
Welches OS nutzt du?
Mit welcher Geschwindigkeit läuft der RAM?
Und wenn du Pixelgruppen wie 4x4 nutzt? Ist das erlaubt?
Welches OS nutzt du?
Mit welcher Geschwindigkeit läuft der RAM?
Und wenn du Pixelgruppen wie 4x4 nutzt? Ist das erlaubt?
el-mujo
Admiral Special
Es ist das einfache Modell mit 24 Kernen und 128GB RAM. RAM ist nicht das Problem in dem Fall. Ja, es werden alle Kerne ausgelastet. Portierung auf GPU ist für mich jedenfalls nicht möglich. Und ob das unbedingt den gewünschten Erfolg bringt ist fraglich, da mit Fließkommazahlen gerechnet wird, was GPUs ja nun garnicht gerne mögen und der Threadripper nun ja auch nicht gerade wenig performant ist - da fehlt nicht mehr viel zur GPU.
Hier hilft nur mehr CPU Power durch mehr Kerne (wie damals bei CPDN schon
). Bei 4-Sockel ist derzeit bei AMD schluss. Das wären mit EPYC 64c-CPUS immerhin 256 Kerne bzw. 512 logische Kerne. Also 10 mal mehr Power als jetzt - dann wären's noch 4 Tage Berechnungszeit - das wäre durchaus noch stämmbar. Bei Intel sind 8-Sockel-Sytseme aber nur mit 24 Kernen verfügbar. Die 40Core Modelle gibt es dafür nicht. Darüber hinaus gehts dann in Cluster und Mainframes über. Aber das soll dann nicht mehr mein Problem sein. Ich kann nur die Anforderung an die Rechenleistung stellen - bereitstellen muss sie jemand Anders - und bezahlen wiederum jemand Anders
Matlab wäre schön, weil deutlich performanter. Da ist Matrixberechnung wirklich die ureigenste Spezialdisziplin von Matlab. Leider ist der Approach nunmal in R geschrieben und eine Portierung in dem Sinen nicht möglich. Der Ansatz müsste von grundauf neu programmiert werden. Vielleicht versuch ich das auch noch irgendwann.
Hier hilft nur mehr CPU Power durch mehr Kerne (wie damals bei CPDN schon
). Bei 4-Sockel ist derzeit bei AMD schluss. Das wären mit EPYC 64c-CPUS immerhin 256 Kerne bzw. 512 logische Kerne. Also 10 mal mehr Power als jetzt - dann wären's noch 4 Tage Berechnungszeit - das wäre durchaus noch stämmbar. Bei Intel sind 8-Sockel-Sytseme aber nur mit 24 Kernen verfügbar. Die 40Core Modelle gibt es dafür nicht. Darüber hinaus gehts dann in Cluster und Mainframes über. Aber das soll dann nicht mehr mein Problem sein. Ich kann nur die Anforderung an die Rechenleistung stellen - bereitstellen muss sie jemand Anders - und bezahlen wiederum jemand Anders Matlab wäre schön, weil deutlich performanter. Da ist Matrixberechnung wirklich die ureigenste Spezialdisziplin von Matlab. Leider ist der Approach nunmal in R geschrieben und eine Portierung in dem Sinen nicht möglich. Der Ansatz müsste von grundauf neu programmiert werden. Vielleicht versuch ich das auch noch irgendwann.
Ähnliche Themen
