Theli-Forum

Hi, heute noch ein Bild durchgenudelt.
Theli stürzt bei mir immer ein bis zweimal zwischendurch ab.
Heute war es während der Anzeige der Statistik. Seitdem sind auch keine Seeingwerte mehr enthalten.
Die Astrometrie mache ich nun nur noch mit der Einstellung "minimize memory usage". Danach stelle ich den Haken wieder aus. ( siehe früheren Post dazu)
Da ist noch ein Typo im Coadd-Code:

Code: Alles auswählen

calculating backgound

Nachdem astrometry.net gescheitert ist, hat scamp zuverlässig eine Lösung gefunden. Bei mir braucht scamp dafür 4 Stunden ( 4 CPU/ 4GB in VM)

So jetzt aber zum Bild:
ca. 37x180 mit EOS 1200D

Hi Carsten,
4h ist ganz schön happig. Das liegt wohl auch teilweise an der VM. Was für eine CPU hst Du drin?
Gruß
Karsten

PS: Schönes Bild. Mir kommt es so vor, als ob oben links die Sterne ein bisschen verzogen sind.

spiegelei hat geschrieben:4h ist ganz schön happig. Das liegt wohl auch teilweise an der VM. Was für eine CPU hst Du drin?

Keine Ahnung. Aber entscheidend ist wohl die VM-CPU, oder?

spiegelei hat geschrieben:PS: Schönes Bild. Mir kommt es so vor, als ob oben links die Sterne ein bisschen verzogen sind.

Das ist der Schönheitsfehler, damit es was zu meckern gibt. Nein, der Reducer kommt leider nicht dichter ran und der original-Reducer ist viel zu teuer. Ich beschneide normalerweise auf 1:1 und das ist für mich in Ordnung. Die optische Achse ist auch nicht ganz in der Mitte des Sensors sondern leicht verschoben ( nicht gekippt) , daher kommt es oben links am stärksten raus.

Hi Carsten,

moos hat geschrieben:Keine Ahnung. Aber entscheidend ist wohl die VM-CPU, oder?

bei mir merke ich teilweise einen signifikanten Unterschied zwischen Anwendungen in einer VM und Anwendungen im nativen OS. Z.B. dauert der Build von Theli in der VM (gefühlt ) 4x so lange wie "out of the Box", dabei werden sowohl in der VM als auch ausserhalb bei weitem nicht alle Kerne verwendet.

Gruß
Karsten

Die Dauer des matching in Scamp laesst sich ganz wesentlich durch passende Katalogeinstellungen beeinflussen. Du solltest in etwa eine gleiche Dichte an detektierten Objekten wie an Referenzobjekten haben. In iView kannst du das sehr leicht pruefen und dann ggf korrigieren. Die Genauigkeit der Zentrumskoordinaten (bzw POSITION_MAXERR) spielt auch eine Rolle.

mischa

Moin,

hat 'ne AP-Montierung aber fotografiert mit 'ner billigen EOS 1200
Egal.
Mir ist schon mal aufgefallen, dass Du bei der Astrometrie ziemlich große Tolleranzen zulässt. Ohne mich zu weit aus dem Fenster lehnen zu wollen möchte ich behaupten, dass die Astrometrie umso schneller und/oder zuverlässiger arbeitet, je kleiner die Tolleranzen sind.
Ich schiebe vor der Astrometrie immer ein "Binned preview" auf Astrometry.net. Das rechnet dann ein bischen rum und spuckt die Mittelpunktskoordinaten, Kameraorientierung, Pixelskaierung, ... aus, die ich dann an die Astrometrie verfüttere. So kann ich mit ziemlich kleinen Tolleranzen arbeiten und die Astgrometrie flutscht so durch (Theli 3/scamp 2.9).
Auf meinem Westbalkon mit Blick auf die (helle) düsseldorfer Skyline hab' ich aber auch keinen Ärger mit Meridian-Flips

spiegelei hat geschrieben:bei mir merke ich teilweise einen signifikanten Unterschied zwischen Anwendungen in einer VM und Anwendungen im nativen OS. Z.B. dauert der Build von Theli in der VM (gefühlt ) 4x so lange wie "out of the Box", dabei werden sowohl in der VM als auch ausserhalb bei weitem nicht alle Kerne verwendet.

Wenn ihr Intel-CPUs auf Intel-CPUs virtualisiert, werden diese 1 zu 1 durchgereicht.
Was die virtuelle Maschine jedoch als Festplatte sieht ist eine Datei im Dateisystem der Host-Maschine. Dateisystemzugriffe sehen somit wie folgt aus:

Dateisystem des Guest
|
v
virtuelle Hardware
|
v
Dateisystem des Host
|
v
richtige Hardware

und das dauert eben.
So 'ne Build ist sehr Disk-IO-intensiv (da werden Header-Dateien eingebunden, die rekursiv sind bis der Arzt kommt). Die Astrometrie dagegen ist mehr CPU- als IO-intensiv (mischa, korrigier mich ggf.), so dass es keinen großen Einfluss haben dürfte, ob sie nativ oder in einer VM abläuft.

Dietmar

Hallo Dietmar,

Ich schiebe vor der Astrometrie immer ein "Binned preview" auf Astrometry.net. Das rechnet dann ein bischen rum und spuckt die Mittelpunktskoordinaten, Kameraorientierung, Pixelskaierung, ... aus, die ich dann an die Astrometrie verfüttere. So kann ich mit ziemlich kleinen Tolleranzen arbeiten und die Astgrometrie flutscht so durch (Theli 3/scamp 2.9).

Das ist ne gute Idee....

Die EOS1200D ist sehr leicht und zuverlässig. Ich hatte keine Lust auf 3 A für Kühlung. Aber ich neige schon wieder zu einer gekühlten Astrokamera. Sein Geld versenken kann man da ja auch sehr gut.

Hallo Dietmar,

dietmar hat geschrieben:Mir ist schon mal aufgefallen, dass Du bei der Astrometrie ziemlich große Tolleranzen zulässt. Ohne mich zu weit aus dem Fenster lehnen zu wollen möchte ich behaupten, dass die Astrometrie umso schneller und/oder zuverlässiger arbeitet, je kleiner die Tolleranzen sind.

Ich habe jetzt auch ein PA.fits aus theli online astrometriert und mir die Ergebnisseite angesehen. Daraus konnte ich die Toleranz von 2' aus 1' senken. Der Winkel ist 177° und da bin ich mit den 180° genau richtig. Ich habe das in theli2 auch immer so gemacht und da ging es viel schneller.
Ich denke, dass ich weniger Sterne in die Kataloge tun muss.

dietmar hat geschrieben:Wenn ihr Intel-CPUs auf Intel-CPUs virtualisiert, werden diese 1 zu 1 durchgereicht.
Was die virtuelle Maschine jedoch als Festplatte sieht ist eine Datei im Dateisystem der Host-Maschine. Dateisystemzugriffe sehen somit wie folgt aus:

Dateisystem des Guest
|
v
virtuelle Hardware
|
v
Dateisystem des Host
|
v
richtige Hardware

und das dauert eben.
So 'ne Build ist sehr Disk-IO-intensiv (da werden Header-Dateien eingebunden, die rekursiv sind bis der Arzt kommt). Die Astrometrie dagegen ist mehr CPU- als IO-intensiv (mischa, korrigier mich ggf.), so dass es keinen großen Einfluss haben dürfte, ob sie nativ oder in einer VM abläuft.

Es kann doch nicht sein, dass wir vor 10 Jahren schon ausreichend schnelle Hardware hatten und von Gigabyte RAM nur träumen konnten. Das aktuelle theli-Build dauert bei mir in der VM mit 4 CPU ca 15 Minuten. Das war vor 10 Jahren auch so mit einer CPU. Beides auf einer HDD. Damals 32 Bit und heute 64 Bit breite Adressen bedeutet natürlich, dass wir doppelt soviel RAM brauchen, für die gleiche Programmgröße. Aber das Programm theli ist ja ein Winzling.
Ich denke, dass die Virtualisierung nicht so stufenweise läuft, wie es deine Pfeile darstellen. Bedenke zum Beispiel DMA, da kann sich die VM einen direkten Kanal zum RAM machen oder die HAL ( Hardware Abstraction Layer) machen auch Zugriffe zwischen Guest und Host auf derselben Ebene möglich. Ich halte eine VM für nicht so benachteiligt. Was man sicherlich viel braucht, ist RAM, da beide Systeme mit 4 GB gerade so auskommen und da bin ich mit 8 GB wohl nicht gerade üppig bestückt.


Fazit: ich habe scamp nun auf eine Toleranz von 1' gesetzt und es braucht immer noch so lange, dass ich es abgebrochen habe. Wie gesagt, ich versuche die Kataloge zu reduzieren.

Hi Carsten,
das klingt schon eigenartig. Ich arbeite mit deutlich größeren Positionstoleranzen und scamp schafft das i.d.R. ohne zu Murren in einer durchaus akzeptablen Zeit. Die Zahl der Referenzen liegt da bei 500....1000. Es wird von Scamp auch nur ein Kern benutzt. Scamp ist allerdings die aktuelle Version, selber gebaut. Vielleicht mag der alte Scamp in den neuen Systemen nicht mehr so richtig. Das Problem hatte ich mit DS9, da hat eine ältere Version im neuen System ewig gebraucht, ein aktuelles Build ist da deutlich schneller.

Gruß
Karsten

moos hat geschrieben:Das aktuelle theli-Build dauert bei mir in der VM mit 4 CPU ca 15 Minuten.

Bei mir dauert es mit 8 Kernen auf 'ner SSD 30s (in Worten dreissig, in Zahlen auch).

moos hat geschrieben:Damals 32 Bit und heute 64 Bit breite Adressen bedeutet natürlich, dass wir doppelt soviel RAM brauchen

Das kannst Du so pauschal nicht sagen. Adressen haben jetzt zwar 64 Bit, Ints auch (wenn Du nicht die hardwareunabhängigen aus der stdint.h benutzt), aber ein float hat immer noch 32 und ein double 64 Bit.

moos hat geschrieben:Bedenke zum Beispiel DMA, da kann sich die VM einen direkten Kanal zum RAM machen...

RAM wird natürlich, wie CPU-Kerne, 1:1 durchgereicht. Und das auch wenn Du 'ne Sparcstation oder einen Mac virtualisierst.

moos hat geschrieben:... oder die HAL ( Hardware Abstraction Layer)

Ist schon klar, dass Du keinen Kubrick-Film meinst

Ich nehme mal an, dass Du deiner VM keine eigene Platte zur Verfügung stellst (bei qemu geht das, ich weiss aber nicht womit Du virtualisierst), sondern eine Datei als Platte vorgaukelst. Und dann gilt das Bild da oben.

Wie dem auch sei:
Wie Karsten (mit "K") habe ich den Eindruck, dass das neue Scamp schneller und zuverlässiger arbeitet.
Hast Du das Alte vielleicht noch im Suchpfad?
Frag mal:

Code: Alles auswählen

scamp -v

Bis denn
Dietmar

Code: Alles auswählen

WARNING: This executable has been compiled using a version of the ATLAS library without support for multithreading. Performance will be degraded.
----- SCAMP 2.9.0 started on 2020-06-02 at 21:23:32 with 4 threads 1A----- 108 inputs:

Was ist die das für eine lib? Macht das scamp bei mir langsam?

Hallo Carsten,
das mit der Atlas-lib ist wahrscheinlich eher Standard als Ausnahme wenn Du Atlas aus dem Ubuntu-Repository hast. Davon muessten aber dann (fast) Alle gleichermaßen betroffen sein. Wenn ich mir die Zahl der Dateien aus dem chi-Plot im anderen Fred ansehe wird dann wohl eher der Speicher der Flaschenhals sein. Wenn Thelie relativ wenig im Speicher halten kann und Linux anfangen muss zu swappen ist es schon denkbar, dass die Perfomance in die Kniehe geht.

Gruß
Karsten

Moin Carsten,

die scamp-version ist schon die aktuelle. ATLAS ist so 'n Ding für lineare Algebra. Die hab' ich auch als Binärpaket für Debian, weil ich beim Versuch sie aus Sourcen zu bauen die Geduld verloren hab'.
Ich glaube was bei dir bremst sind die 108 Einzelframes zu je 68,7 MB (dein Sensor hat genauso viele Pixel wie meiner), was zusammen mit wenig RAM zu viel Disk-IO führt.

Gruß
Dietmar

Hallo ihr beiden,

scamp hat keinen grossen disk-io. Die Kataloge belegen jeweils ein paar 100 kB, und es werden nur winzige Dateien als Ergebnis rausgeschrieben. Scamp kann unter Umstaenden sehr speicherhungrig werden wenn viele Quellen geladen werden, aber das habt ihr ja in THELI leicht unter Kontrolle. Was lange dauert ist das matching. Wenn der Quellkatalog nicht richtig mit dem Referenzkatalog zusammenpasst, dann kann das dauern und ist nicht unbedingt von Erfolg gekroent. Hierzu habe ich hier schon Romane geschrieben und werde das an dieser Stelle nicht wiederholen. Meistens hilft es, die Anzahldichte der Quellen in den Katalogen (Bild und / oder Referenz) zu erhoehen oder zu erniedrigen.

mischa

Hi Mischa

mischa hat geschrieben:
scamp hat keinen grossen disk-io. Die Kataloge belegen jeweils ein paar 100 kB, und es werden nur winzige Dateien als Ergebnis rausgeschrieben. Scamp kann unter Umstaenden sehr speicherhungrig werden wenn viele Quellen geladen werden, aber das habt ihr ja in THELI leicht unter Kontrolle. Was lange dauert ist das matching. Wenn der Quellkatalog nicht richtig mit dem Referenzkatalog zusammenpasst, dann kann das dauern und ist nicht unbedingt von Erfolg gekroent. Hierzu habe ich hier schon Romane geschrieben und werde das an dieser Stelle nicht wiederholen. Meistens hilft es, die Anzahldichte der Quellen in den Katalogen (Bild und / oder Referenz) zu erhoehen oder zu erniedrigen.

Ja verstehe ich ja auch. Man muss probieren. Das ist nur nicht so leicht.
Ich habe jetzt mal nur ca. 30 Bilder und teste. Im Moment sind es pro Bild ca. 50 Sourcen und der TYC hatte nur 35 Sorucen, von denen 15 verwendet werden. Trotzdem alledem braucht scampt alle vier CPU zu 400% , allen Speicher ( > 90% ) und benötigt pro Bild etwa 1 Minute.