Closed thelampire closed 3 years ago
This might be an issue in other databases as well. This is why FLAP has the equidistant coordinate.
It turned out that numpy has the same problem. This might be insightful for the future. This code generates an incorrect time vector: time=np.linspace(0,1-2e-7,5e6, dtype='float32') This should be a 1s long, equidistantly spaced time vector sampled with 5MHz. The resulting sampling time looks like this: MDSplus_time_vector_error_propagation.pdf
This returns a correct one: time=np.linspace(0,1-2e-7,5e6, dtype='float64')
I don't have time now to find how it's done in FLAP, but this problem could appear.
I believe this was an MDSplus problem at the end and have not come up again.
There is an issue with MDSplus that the underlying code is providing an incorrect, non-equidistant time vector when the data is fast. I am trying to read a MHz Mirnov data and the time vector is incorrect due to numerical errors. This is not an issue of FLAP (i've checked), but rather the MDSPlus module or MDSPlus itself.
I would like to raise awareness, that this needs to be tackled with. Has anyone ever read signals from the MDSPlus which was non-equidistantly placed in time? Can I generate the time vector from the first two elements of the MDSPlus time vector so it would be accurate?