search

MaraHochstein / EPMAdatatools

EPMA data tools for reduction of EPMA data, filtering and mineral identification
https://epmatools.streamlit.app/
0 stars 0 forks source link

+++ Datensätze werden auf der Webseite unvollständig dargestellt #28

Closed Hezel2000 closed 3 months ago

Hezel2000 commented 3 months ago

Mir ist eben aufgefallen, dass die Datenfiles nicht vollständig dargestellt werden. 2 Beispiele:

record @guf-ifg-epma-20240715-alwo hat knapp 450 Einträge, auf der Webseite werden nur die Einträge ab Punkt-Nr 225 dargestellt.

record @guf-ifg-epma-20240628-ergr enthält ca. 20 Einträge, es werden aber nur ungefähr die Hälfte auf der Webseite dargestellt.

MaraHochstein commented 3 months ago

@Hezel2000 Ja, das liegt daran, dass es keine wirkliche unique Bezeichnung / Nummerierung durch alle files gibt.. Dadurch entsteht etwas Chaos:

  1. im csv summary file stehen Positions & Comments (= sample name), keine Datetime, bsp 628-ergr: grafik

  2. im normal file stehen Positions, Comments & Datetime. Zuerst hatte ich das Programm nach unique comments = sample names aufgebaut. Dies funktioniert nicht, da mehrere gleiche Comments in den normal files auftauchen. Dann habe ich angenommen, dass die Positions unique sind. Es gab einen record, bei dem gab es allerdings mehrere "doppelte" Einträge (jemand hat aus Versehen exakt das gleiche nochmal für 1-2 samples kopiert?), sodass die "liste" der normal-file-samples größer war als csv-summary-samples und nicht unique Einträge enthielt, weshalb die Tabellen nicht gejoined werden konnten. Daher habe ich alle doubletten aus Pt in normal-file-data entfernt. Bis hierhin funktionierte dann alles. Zum Bsp: grafik

Hier gibt es mehrere doubletten in Pt - aber auch, wenn ich die Comments auslesen würde (habe ich hier nicht), diese sind auch nicht unique! es gibt keine einzelne Spalte, die bei csv-summary-file & normal-file eine Probe unique identifizieren würde. Es gibt noch project name, das ist unterschiedlich für die doubletten, aber das taucht nicht in csv-summary-file auf, sodass ich darüber nicht joinen kann. Hier mit einem bsp-comment bei einer doublette reingeschrieben: grafik

  1. Nachdem die doubletten (gelb) gestrichen wurden, wird ein join zwischen csv-summary-data & normal-file-data über Position durchgeführt. Da aber die Positions bei csv-summary-file nicht mit den Positions im normal-file übereinstimmen, können nur Pt 10-22 den join erfüllen, sodass nur diese dargestellt werden (blau markiert). In diesem Fall werden dann auch falsche datetimes zu den falschen comments zugeordnet (siehe rot fett), da die Positions anders sind als im normal-file: grafik

In diesem Fall könnte ich aber auch keine andere unique Spalte statt den Positions verwenden, da Comment genau so nicht unique ist wie Position.

--

Ich nehme an, bei dem größeren file ist es der gleiche Grund, habe mir jetzt nur das kleinere detailliert angeschaut.

Hezel2000 commented 3 months ago

Ich verstehe. Schlecht. Das Problem ist, dass die Nutzer sich oftmals nicht recht merken können (kein (echter) Vorwurf, die Software macht einem das auch nicht leich), auf welchen formalen Sachen man bei Messungen achten muss. Daher muss ich im Nachhinein oftmals Dateien zusammen führen. Mir war nicht klar, dass es kein einziges unique element im csv file und dem normal file gibt. Das bedeutet wohl auch, dass die Probleme potentiell auch in den anderen records bestehen. Ich schau mal, ob ich da irgendwas machen kann. Evtl. finde ich in den Tiefen irgendwelcher config-Files der Software eine Möglichkeit die datetime auch in die csv-Datei zu bekommen.

Diese JEOL-Software der Sonde treibt mich bei diesen Sachen manchmal leicht in den Wahnsinn.

MaraHochstein commented 3 months ago

Ja, normalerweise schienen aber die Positions in den csv-summary-files die gleichen zu sein wie in dem normal-file - zumindest bei allen records, wo ich das am Anfang manuell überprüft habe und dann mal den record mit den doubletten hatte.. Ich dachte aber, dass dsa nur ein copy-paste fehler war (alles identisch) und die Positions ansonsten schon vom Programm eingestellt werden.. Bei den comments ist das natürlich fehleranfällig, wenn die user alles selbst eintippen. Gibt es nicht irgendwo eine ID, die überall gleich vergeben wird?

Hezel2000 commented 3 months ago

Die Positionen sind leider nicht notwendigerweise unique IDs. Es gibt viele kleine Schritte, bis man bei den 4 files ist, die ich hoch lade. Einer der Gründe für das ELN war und ist, genau das in den Griff zu bekommen. Ich habe mich eben mal durch alle möglichen Menüs und configs gehangelt, aber noch nichts gefunden. Ich hab eben mal dem JEOL software-Engineer geschrieben. Der antwortet meist sehr schnell. Ich schaue aber auch noch etwas weiter. Wenn es hart auf hart kommt, könnte man die Analysen selbst nehmen, es ist sehr unwahrscheinlich, dass das Doubletten sind, wäre aber alles anderes als eine elegante Lösung.

MaraHochstein commented 3 months ago

Die datetimes in die csv zu schreiben, wäre zwar eine Möglichkeit, aber dann müssten auch alle anderen Werte, die ich aus dem normal-file ziehe, dazu geschrieben werden, sonst können diese ja nicht gejoined werden. Eigentlich wären das nur die Datetimes und die Spotsizes, mehr nicht...

Hezel2000 commented 3 months ago

Ist das normal file nur für die datetime und spotsize relevant, alles andere braucht man nicht? Klar, wenn möglich würde ich die gleich dazu schreiben. Mal schauen, ob das überhaupt geht. Ansonsten würde ich wohl ein kleines Python-Programm für ein preprocessing schreiben, das die Analysen nutzt. Wäre natürlich ein weiterer Schritt und etwas nervig. Ich brauche schon für die maps so einen preprocessing Zwischenschritt.

Alternativ könnte man sich mit den Messfiles selbst rumschlagen, das ist aber gleich ein ganzer Satz an Daten, dazu noch Binaries, das wäre wirklich was für später. Im Moment würde ich es schon sehr gerne so zum Laufen bekommen.

MaraHochstein commented 3 months ago

Ja genau, alles andere brauche ich nicht bzw brauchtest Du bisher nicht. Alle anderen Mess-Daten sind im csv-summary file.

Hezel2000 commented 3 months ago

Ich habe jetzt noch mal eine anderer Herangehensweise versucht, indem ich zuerst alle Datensätze in der JEOL-Software zusammen gefasst und daraus erst die verschiedenen Files erzeugt habe (war glaube ich auch der Plan, den ich vielleicht unvollständig umgesetzt habe, da diesmal die Daten über verschiedne Messtage verstreut waren, wie gesagt, die JEOL Software ist nicht die tollste, ich hätte trotzdem daran denken sollen).

Ich habe nun im record @guf-ifg-epma-20240715-alwo ein neues normal file und ein neues .csv file hoch geladen, beide haben nun sicher gleich viele Punkte, und sollte die unique id sollten nun sein: im normal file: unkown specimen no., und im .csv. point. Allerdings sehe ich noch immer nur 225 stat ca. 450 Punkten. Es sei denn es ist nun ein cache Problem?

Hezel2000 commented 3 months ago

Nach Wissen des JEOL Software-Engineers kann man die Einstellungen nicht so verändern, dass z.B. datetime mit in das csv geht, er will aber noch mal in Tokio deswegen nachfragen. Wie gesagt, ich glaube, ich könnte die Datein auch so erzeugen, dass die Nr übereinstimmen, wenn ich verschiedene Files zusammen ziehen muss.

MaraHochstein commented 3 months ago

@Hezel2000 Ich sehe alle Einträge ohne Probleme, klappt es bei Dir ohne Cache leeren nicht? (habe nichts geändert zwischendurch) grafik

MaraHochstein commented 3 months ago

Probier das nochmal mit anderen files, aber falls es so mit den Points unique ist, wie Du es exportierst, dann sollte es so funktionieren, oder?

Hezel2000 commented 3 months ago

Ich habe es eben probiert, und sehe nun alle records. Ich werde es noch mit ein paar anderen (oder noch mal alle) durchprobieren, und das zukünftig beim zusammen stellen entsprechend beachten.

MaraHochstein commented 3 months ago

Falls das Problem nochmal auftaucht, bitte hier Bescheid geben