[BUG] Semi-Automatic Evaluation with Read FC Data #205
Open
opened 2024-01-05 07:22:26 +00:00 by saeckech
·
2 comments
No Branch/Tag Specified
Labels
Clear labels
Kind/Breaking
Kind/Bug
Kind/Crash
Kind/Documentation
Kind/Enhancement
Kind/Feature
Reviewed/Won't Fix
Type/BDS
Type/DSC
Type/Fit
Type/General
Type/NMR
Breaking change that won't be backward compatible
Something is not working
This issue describes unexpected shutdowns or non-responsive behaviors
Improves documentation
Improve existing functionality
New feature
Priority
Critical
The priority is critical
Priority
High
The priority is high
Priority
Low
The priority is low
Priority
Medium
The priority is medium
Priority
Very low
The priority is very low
Reviewed
Duplicate
This issue or pull request already exists
Reviewed
Invalid
Invalid isssue
This issue won't be fixed
Status
Need More Info
Feedback is required to reproduce issue or to continue work
Status
On Hold
This issue or pull request is on hold
Status
Stale
Issues without activity for more than 6 months
Issues connected to BDS
Issues connected to DSC
Issue is connected to fitting data
issue connected to general functionality
Issues connected to NMR
No labels
Type/NMR
Milestone
No items
No Milestone
Assignees
aahmad (Arshid Ahmad)
anisar (Aqsa Nisar)
ckolb (Christian Kolb)
cwolter (Celine Wolter)
dominik (Dominik Demuth)
dwuerz (David Würz)
elisa (Elisa Steinruecken)
fwolter (Finn Wolter)
huczhang (Huanchen Zhang)
jepsinrajkp (Jepsinraj Kakkuzhiyulla Parambath)
kschroeder (Katharina Schroeder)
malbrecht (Maximilian Albrecht)
mandal (Suvendu Mandal)
markusro (Markus Rosenstihl)
mbergmann (Mark Bergmann)
mhaneke (Markus Haneke)
robin (Robin Horstmann)
saeckech (Christoph Säckel)
skloth (Sebastian Kloth)
skrueger (Sandra Krüger)
ypiliauskaya (Yauheniya Piliauskaya)
Clear assignees
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: IPKM/nmreval#205
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Current behavior
Die Option "add directory" verstehe ich so, dass man einen Ordner auswählt in dem .h5 Dateien vom Field Cycling gespeichert sind. Ich erhalte dann aber die Meldung "No magnetization found for [Unterordner]".
Ich habe die Daten dann einzeln einlesen wollen, die automatischen Fits fitten allerdings scheinbar immer einen Signalabfall, auch wenn nicht vorpolarisiert wurde, d.h. ein normaler SatRec-Anstieg erwartet wird. Ich glaube (fast) alle verwenden das gleiche Skript, dort ist im experiment script dictionary "p" mit key "ppnp" die Grenze festgelegt ab der (nicht mehr) vorpolarisiert wird.
Beim fitten mit der Streched Exponential Option kamen teilweise auch Werte beta>1 heraus - ist das absichtlich nicht eingeschränkt?
Version
About: 2024-01-03
Expected behavior
No response
Steps to reproduce
No response
Log messages
Anything else?
Auswerteprogramm lief in zweiter Instanz.
persönlich finde ich die erhaltenen Fitparameter im Ordner "fit" eher unhandlich abgelegt. Man kann aber zumindest die Parameter die man sich hat plotten lassen nochmal speichern.
Nope, das ist nicht der Plan, das habe ich aber auch nie kommuniziert, was da der Plan ist: Das ist für den Fall, dass jemand die Textdateien auswerten will.
Beispiel: Die Magnetisierungskurven zu .h5-Datei FCMessung.h5 liegen nach dem Auswerten mit den Fits und den Bildern im Ordner FCMessung/data. Wenn der Ordner FCMessung dann für die Auswertung ausgewählt, werden diese Daten dann zum Fitten verwendet.
Es wird immer die gleiche Funktion M0 * exp(-(x/T1)^beta) + Offset gefittet. Ich werde mir auch nicht die Mühe machen, das zu ändern, nur damit die Magnetisierung, die sich niemand anschaut, sinnvoll ist.
Das ist tatsächlich nicht eingeschränkt, gibt es einen zwingenden Grund dafür?
Geht es um die Fitkurven in den Unterordnern oder tatsächlich um die Fitparameter? Wo wären sie den weniger unhandlich (was auch immer "unhandlich" in dem Zusammenhang bedeutet).
Habe einen Stichpunkt im Wiki dazu geschrieben. https://wiki.pkm.physik.tu-darmstadt.de/doku.php/agvogel:nmr-auswerteprogramm#loading_data
Ist M0 eingeschränkt? Falls nein, weiß ich nicht warum es nicht geklappt hat. Falls doch könnte man die Grenzen entfernen, dann kann die Funktion die gleiche bleiben, für Evolutionsfelder f_evo > p["ppn"] sollte der Fit dann 0>M0~-Offset finden.
So viel oder wenig Grund wie bei allen anderen KWW fits auch.
die Fitparameter. Die sind auskommentiert in der zweiten Zeile der Fits als "#value_1+/-Error_1 value_2+/-Error_2 ..." gespeichert. Wenn ich mit nochmal die Fitparameter plotten lassen will, müsste ich die Werte aus allen fit-Dateien auslesen und dem jeweiligen Evolutionsfeld zuornen(?). Handlicher fände ich eine einzelne zusätzliche Datei wie bei anderen fitparameter Dateien, d.h. mit Spalten für "f_evo, value_1 error_1 value_2 error_2 ... #choices"