DWFile dictionary keys should use name instead of long_name

[MarceloBergweiler]

The keys in the DWFile dictionary consist of the long_name, e.g. Formula 1/speed. This is weird, since one would expect to need only the short channel name speed as a key (possible duplicate names are anyhow protected by the use of unique_key()).

[costerwi]

Thanks for your comment. There has been a lot of discussion for what to use as channel keys so I think we will keep long_name as the default but I'm working on an update to will allow users to define their own key function, similar to list.sort(). This function must take a DWChannel parameter and return the preferred channel key. In this concept, the syntax will be something like this if you want to use name instead of long_name:

with dw.DWFile('whatever.dxd', key=lambda channel: channel.name) as dxd:
    print(dxd.keys())

What do you think?

[MarceloBergweiler]

Seems to be a good compromise. This worked for me:

609    def __init__(self, source: Optional[str]=None, key: Optional[Callable]=None):

623            self.open(source, key)

625    def open(self, source: str, key: Optional[Callable]=None):

659        if key is None:
               key = lambda channel: channel.long_name

662        for channel_struct in channel_structs:
               channel = DWChannel(channel_struct, self.reader_handle)

               channel.unique_key = unique_key(key(channel))
               self[channel.unique_key] = channel

678            channel.unique_key = unique_key(key(channel))

[MarceloBergweiler]

Another nasty use of long_name is lurking in the initialization of the DWChannel class.
After I read a dxd file, I sometimes add a "Python math channel" to the DWFile object.
DWChannel.__init__, however, wants to "shoot first and ask later", i.e. read the long name from the file, which does not exist in the case of my added channel...

[costerwi]

Thanks for your comment. Please explain this "Python math channel" a little more. What type of object is it and how do you use it?

Have you considered instead adding a column of computed results within a DataFrame extracted from your DWFile?

[costerwi]

The latest release 1.2.0 includes #82 which allows the channel key function to be specified in the DWFile constructor.

[MarceloBergweiler]

Actually, with this new version 1.2.0 I do not have problems any more, since there is no code in DWChannel.__init__() referring to fields in the DXD file (i.e. unique_key in the previous version refering to long_name). Thanks for this new version.

But to answer your question, I prefer not to deal with DataFrames at this constructor stage because our DXD files may be very big (in the order of GBs), thus we only would read a data segment when really needed. For that I created a slice method DWGetScaledSamplesSlice() which only reads a desired time slice [T1:T2] (by directly calling DLL.DWIGetScaledSamples()). You may want to implement something similar, because your DWChannel.series() reads the whole thing at once, which may be an overkill with long DXDs. You have that series_generator, but this must go serially through all the channel.

With this version 1.2.0 I can now again add a "Python math channel" right after I call DWFile (thus mimicking DEWESoft's Offline math), by creating a new DWChannel and adding it to the DWFile dictionary (with a new field formula which is a function performing the actual math). I give it a channel_type = 4 (for a synchronous math channel) so that my DWGetScaledSamplesSlice() knows how to handle it.

[fleimgruber]

But to answer your question, I prefer not to deal with DataFrames at this constructor stage because our DXD files may be very big (in the order of GBs), thus we only would read a data segment when really needed. For that I created a slice method DWGetScaledSamplesSlice() which only reads a desired time slice [T1:T2] (by directly calling DLL.DWIGetScaledSamples()). You may want to implement something similar, because your DWChannel.series() reads the whole thing at once, which may be an overkill with long DXDs. You have that series_generator, but this must go serially through all the channel.

Thanks for mentioning. I contributed series_generator because of a similar use-case, but wondered how best to handle the use-case you describe. Could you share the implementation of your "slice method" or prepare a PR?

[MarceloBergweiler]

I just added a Pull Request with an implementation of the slice capability. It is not a new method, but added parameters to the existing scaled() method.