Channel argument for `read_binary`

[chillenzer]

There is currently no usage of the channel argument in read_correlators_binary and I'm not actually sure how I would introduce that, so I've removed it. It slightly undermines the consistency with read_correlators_fortran but I don't quite see how it is supposed to be used there either. Feel free to make an argument against this or close this issue if you agree.

[edbennett]

Another stub of part of a feature, sorry. The intent is that if you have multiple files, each containing a single channel (e.g. A++, E++, T++), then you could specify this and then concatenate the CorrelatorEnsembles to give a single one with a channel column that could then be filtered on to get a given channel to process. (E.g. get_pyerrors would then take a channel argument.) This would allow equivalence with a file format that stores all channels in a single file.

Since nothing currently does that in the glueball space (guess which code does?), and it's probably easier to just create a separate CorrelatorEnsemble for each state that we read in, then this can likely be dropped for now.

[chillenzer]

Yes, I'm aware of this. I meant more concretely how would you possibly handle such an argument for stuff that is read from a binary? You would need some way to specify which parts of the binary contain which channel and that sounds like a highly non-trivial interface to me. Adding that info after the fact seems way easier. Anyhow, happy that we agree on removing it (for the moment at least).

[edbennett]

Oh, I see, I would anticipate that either

• each binary only contains a single channel, and you would do something like CorrelatorEnsemble.concat([read_binary(f"corr_{channel}.bin", channel=channel) for channel in channels]), or
• the binary contains all channels indexed in some deterministic way, in which case the channel argument would be removed and instead there would be a list of channel names in the specific implementation (which would then have to go record-by-record through the file), or perhaps
• the binary contains all channels, with a record immediately before each's record with a single string containing the channel name. (At which point, you surgically obliterate the section of code writing that format and look up how to write HDF5 in Fortran.)

[chillenzer]

... or in other words: "a highly non-trivial interface". Except for the first, of course, but that's not something you would solve with a channel argument to read_correlators_binary (at least not in the current form of that functionality).