costerwi / dwdatareader

Python module to interact with Dewesoft DWDataReaderLib shared library
MIT License
14 stars 9 forks source link

Complex numbers #67

Open fleimgruber opened 1 month ago

fleimgruber commented 1 month ago

For a channel with these settings (from DEWE GUI):

Name: U_1p_per (Complex)
Description: -
Unit: V
ID: PP1 (Power analysis)
Sampling: Asynchronous
Rate: 1043.6 Hz
Expected rate: 1000.0 Hz
Data structure: Scalar
Data type: Complex (single)

dwdatareader is not able to find a matching key in the dewe_file. Are complex numbers supported?

fleimgruber commented 1 month ago

I searched in the official DWDataReader C library and found struct DWComplex in one of the header files. Will look into it.

edit: It seems that the DWDataReader C lib defines a parallel API for complex numbers, e.g. DWGetChannelList -> DWGetComplexChannelList. @costerwi Do you want to have a 2x API surface area increase in dwdatareader? Do you have another idea how complex numbers could be handled with the existing public dwdatareader API? I am interested in adding this feature.

costerwi commented 4 weeks ago

Sorry for the delay! Do you have an idea to return complex data when it is available?

fleimgruber commented 3 weeks ago

Never mind!

As mentioned in https://github.com/costerwi/dwdatareader/issues/67#issuecomment-2419737863 I see two main approaches:

  1. Add a mirrored API for complex numbers (following the C lib API).
  2. Find a way to add complex numbers to the existing API.

I expect approach 1 to be straight forward, but at the cost of maintaining and exposing more APIs to the users. Approach 2 does not have these downsides, but I am not sure about the best way to check for and integrate complex numbers with the current implementation, e.g. at https://github.com/costerwi/dwdatareader/blob/master/dwdatareader/__init__.py#L394. I have not yet looked into the C lib behavior either. So I guess we should agree on one of the mentioned approaches and I would then go ahead and experiment with it a bit in a PR.

costerwi commented 3 weeks ago

Yes, I agree that approach 2 would be more convenient for everyone.

fleimgruber commented 3 weeks ago

Thanks for confirming. So next question then would be: how are users expected to refer to channels with complex type? This might depend on complex channel naming in the DEWE file. I have the feeling that users will need to somehow specify "complex" somewhere regardless for it to work.

costerwi commented 3 weeks ago

Do you have a small example file you can attach? I haven't looked but maybe the complex channels are just the imaginary component of a corresponding real channel of the same name. Python should be able to combine both components when they are available.