Reduce Expected .fdt file format error to warning

[neuromechanist]

Description of the problem

In uncommon (usually stemming from custom code) cases where EEG.data is a string but does not point to the FDT file, this error prevents the user from loading the data:

mne-python/mne/io/eeglab/eeglab.py

Line 56 in 14ff948

raise OSError("Expected .fdt file format. Found %s format" % fmt)

Since the following lines deal with the case of data_fname not being found, I suggest converting this error to a warning. EEGLAB also has a similar behavior, which falls back to searching the directory for the FDT file if the EEG.data string does not point to the FDT.

Steps to reproduce

datafile = './sub-002_task-FacePerception_run-1_eeg_ON.set'
EEG = mne.io.read_raw_eeglab(datafile, preload=True)

Link to data

https://drive.google.com/drive/folders/18y0TALqwT4Z2yg4T6QafDAqIrY04jI5k?usp=sharing

Expected results

EEG will point to the data object.

Actual results

OSError: Expected .fdt file format. Found format

Additional information

Platform             macOS-14.4-arm64-arm-64bit
Python               3.10.13 (main, Sep 11 2023, 08:24:56) [Clang 14.0.6 ]
Executable           [/opt/homebrew/anaconda3/envs/torch-sci/bin/python](https://file+.vscode-resource.vscode-cdn.net/opt/homebrew/anaconda3/envs/torch-sci/bin/python)
CPU                  arm (8 cores)
Memory               16.0 GB

Core
├☑ mne               1.6.1 (latest release)
├☑ numpy             1.26.3 (OpenBLAS 0.3.21 with 8 threads)
├☑ scipy             1.11.4

[welcome]

Hello! 👋 Thanks for opening your first issue here! ❤️ We will try to get back to you soon. 🚴

[drammock]

I can't easily test it, but based on what you're saying above @neuromechanist I take it that this file opens normally (no warnings/errors) in EEGLAB; can you confirm that? If so I'm a bit surprised because eeg.data has a value of "in set file" and the value of eeg.datfile is "ds000117_sub002_run-1.fdt" (a different filename than the .set and .fdt files you provided). If I'm reading the source for pop_loadset() correctly, this is an unexpected / inconsistent state for a saved file to be in. But maybe I'm not understanding the MATLAB code correctly.

If you can load and then re-save the data in EEGLAB, and the re-saved file does load correctly in MNE, then I would hesitate about making MNE more flexible/permissive in what data it loads. The examples from the EEGLAB data structures docs don't mention this "in set file" as a valid value, so to me it doesn't make sense for MNE to treat it as though it were.

cc @arnodelorme

[neuromechanist]

This is the warning for loading the same dataset in EEGLAB:

pop_loadset(): ./sub-002_task-FacePerception_run-1_eeg_ON.set ...
Something is wrong with the data file, trying to use the associated .fdt file
Reading float file './sub-002_task-FacePerception_run-1_eeg_ON.fdt'...
Creating a new ALLEEG dataset 1
Done

Yes, Under normal circumstances the in set file should not be created. However, the problem seems to be rooted in a resolved bug or custom code. See the twin issue on EEGLAB repo: sccn/eeglab#746

Nevertheless, the main point is the difference between handling exceptions in loading .set files between EEGLAB and MNE-Pyhton. EEGLAB would fall back to searching the directory if the string in EEG.data does not point to a file, but here, it only falls back to looking into the directory only if the content of EEG.data has a .fdt suffix, but the file is not present.

Yes, Arno already has created an issue to correct this data set on NEMAR: sccn/NEMAR-pipeline#70.

[drammock]

Thanks for the cross-refs. @arnodelorme says in sccn/eeglab#746:

There was a bug I fixed 6 months ago about ‘in set file’ and FDT file. I believe EEGLAB reads these files OK although they probably should be exported again for other software.

(emphasis added)

So the recommendation is "use EEGLAB to re-save the files." Is there a reason that's not satisfactory here? Or maybe a better question is: how common of a problem is this? E.g., if the corrupted files occur in multiple public datasets (not just the one that sccn/NEMAR-pipeline#70 will correct), then the problem will keep resurfacing over and over for different people. But if it's just the one dataset, you can re-export the files once and never hit it again.

That said, checking for the presence of an .fdt with the same base filename as the .set does seem sensible / fairly safe, so if you're up for making a pull request I don't really object to adding that behavior.

[arnodelorme]

Yes, I would recommend adding the behavior above as it is unclear how widespread this problem is.