I have measurements from a Bioscope Resolve. I was using the program nanoscopeanalysis 9.1 to view graphs, but I wanted to do scripting on the values and decided to use gwyddion to mass extract values from spm files with graphs in them.
I opened the graphs in Gwyddion. Gwyddion correctly read the curve titles (extend/retract), and correctly loads the distance values. However, the force values are garbage.
For example, both Gwyddion and nanoscopealaysis give the following beginning distance values:
However, the force values in nanoscopeanalysis for these distances are:
-1.06E+00
-4.23E+00
-1.06E+00
-9.52E+00
-1.06E+00
1.48E+01
-2.12E+00
-7.41E+00
Whereas the values in Gwyddion (both in the view window and in pygwy, i am copying from pygwy because that was easiest but they were identical) are:
8.21E-12
4.58E-10
8.21E-12
-5.61E-10
8.24E-12
2.02E-10
8.24E-12
-7.82E-10
Is Gwyddion not compatible with spm files from the machine/program mentioned? Wat else could be causing this issue?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I certainly cannot look into it without any sample file.
The values seem fishy though. There is not even a linear relation between the Gwyddion and nanoscopeanalysis values. So they are either unrelated numbers or the problem is not just wrong/missing conversion factors. BTW the Gwyddion values are at least of a reasonable order of magnitude -- I doubt the force can be 14.8 N. Or are the nanoscopeanalysis data just raw voltages?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I look over the files in question I only grow more confused.
Here is a zipped folder containing some examples: https://we.tl/G18ry3SINy
the .txt files are the xz data extracted from nanoscopeanalysis
the python.txtfiles were printed using gwypy
and there are the original spm files, which were extracted using nanoscopeanalysis from an overall square.
The file has two curves, an extend and a retract curve. However, in gwypy, when I do:
ids = gwy.gwy_app_data_browser_get_graph_ids(container)
I get a list of 3 IDs. Each of these graphs has "extend" and "retract" curves, each the same length, each with identical distance values, but with different force values.
Also, these distance values, unlike what I said above, do not match the distance values in the xz files...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The file is in the new (9.2+) 32bit file format. There was a bug in Gwyddion in how force files in this new format are loaded. It should be fixed in tomorrow's or later development snapshot.
Edit: This can also mean nanoscopeanalysis 9.1 loads it wrong. I am not sure which version started to support the 9.2+ data format.
Last edit: David Nečas 2017-10-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear David,
I'm about to publish Fodis and we are asked to add the import of Bruker raw files.
Bruker gave us the Matlab toolbox to read the files, but the process is quite triky since we are not allow to redistribute their toolbox.
Can you suggest me a way to read their .spm files. We cannot figure out how the data are encoded...
If you like you can also contact me at nicola.galvanetto@sissa.it
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the update. Having installed the latest snapshot as of 16.10.17, the numbers in Gwyddion are now similar/related to nanoscopeanalysis (in m/N instead of nm/pN), but they're still not the same
nanoscopeanalysis:
nm
pN
2.83E-06
1.34E+00
1.95E-01
-6.71E-01
3.91E-01
2.01E+00
5.86E-01
0.00E+00
7.81E-01
6.71E-01
9.77E-01
-6.71E-01
1.17E+00
6.04E+00
1.37E+00
-6.04E+00
1.56E+00
-1.41E+01
1.76E+00
8.06E+00
1.95E+00
-6.04E+00
gwyddion:
m
N
0
1.37E-12
1.95E-10
-6.83E-13
3.91E-10
2.05E-12
5.86E-10
0
7.81E-10
6.83E-13
9.77E-10
-6.83E-13
1.17E-09
6.15E-12
1.37E-09
-6.15E-12
1.56E-09
-1.43E-11
1.76E-09
8.19E-12
1.95E-09
-6.15E-12
Don't know if at this point the bug is still with Gwyddion, or with nanoscopeanalysis...
(the file for the numbers given above is the same file as my other forum post, https://we.tl/89a4nrWDxN)
Last edit: Devora Witty 2017-10-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The forces are almost the same. It can be tricky to figure out why. When we are off by five orders of magnitude, it is usually easy to find the thing which is completely wrong. When the discrepancy is a percent or two, the number of things that can be slightly wrong is large...
Could you please extract and attach here (Add attachments) the entire curve as you get it from nanoscopeanalysis, ideally with a few more decimal places if possible?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The precision is sufficient. But I was not able to find out more than that there is a constant factor 1+1/58 (approximately?) between the Gwyddion and N.A. values. I do not know what in the file determines this factor.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, the current stable build is from August. The bug fix was released in nightly build from october and there hasn;t been a stable build released subsequently yet.
I have moved to a new computer and need to reinstall Gwyddion, including the bug fix.
Is it safe to use the current nightly build?
Last edit: Devora Witty 2018-01-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have measurements from a Bioscope Resolve. I was using the program nanoscopeanalysis 9.1 to view graphs, but I wanted to do scripting on the values and decided to use gwyddion to mass extract values from spm files with graphs in them.
I opened the graphs in Gwyddion. Gwyddion correctly read the curve titles (extend/retract), and correctly loads the distance values. However, the force values are garbage.
For example, both Gwyddion and nanoscopealaysis give the following beginning distance values:
0
4.88E-01
9.77E-01
1.46E+00
1.95E+00
2.44E+00
2.93E+00
3.42E+00
However, the force values in nanoscopeanalysis for these distances are:
-1.06E+00
-4.23E+00
-1.06E+00
-9.52E+00
-1.06E+00
1.48E+01
-2.12E+00
-7.41E+00
Whereas the values in Gwyddion (both in the view window and in pygwy, i am copying from pygwy because that was easiest but they were identical) are:
8.21E-12
4.58E-10
8.21E-12
-5.61E-10
8.24E-12
2.02E-10
8.24E-12
-7.82E-10
Is Gwyddion not compatible with spm files from the machine/program mentioned? Wat else could be causing this issue?
(I can attach relevant file examples if that will help)
I certainly cannot look into it without any sample file.
The values seem fishy though. There is not even a linear relation between the Gwyddion and nanoscopeanalysis values. So they are either unrelated numbers or the problem is not just wrong/missing conversion factors. BTW the Gwyddion values are at least of a reasonable order of magnitude -- I doubt the force can be 14.8 N. Or are the nanoscopeanalysis data just raw voltages?
As I look over the files in question I only grow more confused.
Here is a zipped folder containing some examples:
https://we.tl/G18ry3SINy
the .txt files are the xz data extracted from nanoscopeanalysis
the python.txtfiles were printed using gwypy
and there are the original spm files, which were extracted using nanoscopeanalysis from an overall square.
The file has two curves, an extend and a retract curve. However, in gwypy, when I do:
ids = gwy.gwy_app_data_browser_get_graph_ids(container)
I get a list of 3 IDs. Each of these graphs has "extend" and "retract" curves, each the same length, each with identical distance values, but with different force values.
Also, these distance values, unlike what I said above, do not match the distance values in the xz files...
The person sending me the data says there may be a problem with the xz files
The file is in the new (9.2+) 32bit file format. There was a bug in Gwyddion in how force files in this new format are loaded. It should be fixed in tomorrow's or later development snapshot.
Edit: This can also mean nanoscopeanalysis 9.1 loads it wrong. I am not sure which version started to support the 9.2+ data format.
Last edit: David Nečas 2017-10-04
Dear David,
I'm about to publish Fodis and we are asked to add the import of Bruker raw files.
Bruker gave us the Matlab toolbox to read the files, but the process is quite triky since we are not allow to redistribute their toolbox.
Can you suggest me a way to read their .spm files. We cannot figure out how the data are encoded...
If you like you can also contact me at nicola.galvanetto@sissa.it
Thank you for the update. Having installed the latest snapshot as of 16.10.17, the numbers in Gwyddion are now similar/related to nanoscopeanalysis (in m/N instead of nm/pN), but they're still not the same
nanoscopeanalysis:
gwyddion:
Don't know if at this point the bug is still with Gwyddion, or with nanoscopeanalysis...
(the file for the numbers given above is the same file as my other forum post, https://we.tl/89a4nrWDxN)
Last edit: Devora Witty 2017-10-16
OK, the distances are the same (bar rounding).
The forces are almost the same. It can be tricky to figure out why. When we are off by five orders of magnitude, it is usually easy to find the thing which is completely wrong. When the discrepancy is a percent or two, the number of things that can be slightly wrong is large...
Could you please extract and attach here (Add attachments) the entire curve as you get it from nanoscopeanalysis, ideally with a few more decimal places if possible?
Here is just the retract data (not extend), with current number of decimal places. (also included spm files)
I will check if I can get more decimal places.
Thank you
Lab tech doesn't know how to get additional decimal points and I don't have access to the machine myself. Sorry.
The precision is sufficient. But I was not able to find out more than that there is a constant factor 1+1/58 (approximately?) between the Gwyddion and N.A. values. I do not know what in the file determines this factor.
For now we will manually correct by that factor.
Thank you for all your help.
Hi, the current stable build is from August. The bug fix was released in nightly build from october and there hasn;t been a stable build released subsequently yet.
I have moved to a new computer and need to reinstall Gwyddion, including the bug fix.
Is it safe to use the current nightly build?
Last edit: Devora Witty 2018-01-09
Yes, unless you need triangulation of XYZ data, which is currently broken (more than usually, anyway). I hope to release 2.50 kind of soon...