Closed dschick closed 5 months ago
For sure MCA data worked at some point. but i did not encounter such files for a long time. of course a PR is always welcome but it would be better to first explore why it does not work for you.
On Thu, 5 Aug 2021, 09:50 Daniel Schick, @.***> wrote:
Hi @dkriegner https://github.com/dkriegner ,
I encountered a problem in SPEC files which contain MCA data. For know I am trying to understand the way the MCA data is read. I noticed that there is no special case for the @A marker which should indicate a line of MCA data.
I think the current implementation does not assume a mixture of MCA and usual scalar data, right?
I will draft a PR if I am a bit more into the code.
Best
Daniel
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dkriegner/xrayutilities/issues/123, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACKZJFMXAZAKJPFRFEINJ5TT3I7ELANCNFSM5BTFKAIQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
thanks for your promt reply.
As I said, the @A
marker is not respected while parsing the file.
Also the parsers does not seem to like a mixture of MCA and scalar data it distinguishes like
if self.has_mca
else
This is true for setting the column names and the actual data which are eventually converted to the numpy array
Hi Daniel,
you are right that the parser does not explicitly detect the @A
marker. somehow this was not necessary so far because the information from the @MCA
line and the channel number was sufficient. And of course a mixture of scalar and MCA data also worked for me. for example in the hello world example:
https://xrayutilities.sourceforge.io/index.html#hello-world
(the respective data file can be found in the examples/data/test.spec.bz2
file)
If the current implementation fails with newer files a PR is of course welcome. I would be glad if these existing data files could still be parsed. I think the respective unit test in tests/test_io_spec.py
needs to be improved to also test the MCA data in a test file. In fact the current file used already contains MCA data, but the tests seems to ignore them at the moment.
Hi Dominik,
I found some time to dive into the MCA problem.
Indeed the current version of xrayutilities
allows for reading the MCA
from test SPEC file.
The issue actually arises again from how Sardana is implemnting the MCA
s vs. SPEC.
So Sardana allows for multiple MCA
s in one scan as SPEC seems to allow only for one.
In order to allow for multiple MCA
s Sardana provides an additional identifier @DET_X
where X
is an integer and after the identifier the name of the MCA
is provided.
Since the @CHANN
identifier is also given just once, it means, that all MCA
s in the Sardana implementation should have the same lengh (which is actually not checked for). However, for reading the Sardana MCA
s the @CHANN
is not really necessary, as there is no line-breaking available as in SPEC and each MCA
data line in the scan starts with an @A
which allows to read the MCA
data line by line.
Moreover the order of scalar and MCA
data is swapped/flexible in Sardana.
I made a PR which allows for both types of MCA
s and here is also a Sardana test file
Hello, just encounted this issue in the version 1.7.6
Exception occurs in ReadData()
method.
Does the code in #129 fix the issue for you?
Yes, I could successfully read the data from .spec file.
Ok, I look into merging the mentioned PR and include it in a release.
Hi @dkriegner ,
I encountered a problem in SPEC files which contain MCA data. For know I am trying to understand the way the MCA data is read. I noticed that there is no special case for the
@A
marker which should indicate a line of MCA data.I think the current implementation does not assume a mixture of MCA and usual scalar data, right?
I will draft a PR if I am a bit more into the code.
Best
Daniel