Repository: mne-tools/mne-python

Issue:
Reduce `Expected .fdt file format` error to warning
### 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:
https://github.com/mne-tools/mne-python/blob/14ff9483cf92a40479b23f4b17886d3d384f65a5/mne/io/eeglab/eeglab.py#L56 

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

```Python
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

```bash
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

```


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

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()](https://github.com/sccn/eeglab/blob/b53d61bf465eeb04cb9bcb77fdf6b91b8956ca0f/functions/popfunc/pop_loadset.m#L156-L158) 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](https://eeglab.org/tutorials/ConceptsGuide/Data_Structures.html#saved-set-files) 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
This is the warning for loading the same dataset in EEGLAB:

```shell
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: https://github.com/sccn/NEMAR-pipeline/issues/70.
Thanks for the cross-refs.  @arnodelorme [says](https://github.com/sccn/eeglab/issues/746#issuecomment-1999935548) 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 https://github.com/sccn/NEMAR-pipeline/issues/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.
Yes, I would recommend adding the behavior above as it is unclear how widespread this problem is.

Resolving patch:
diff --git a/mne/io/eeglab/eeglab.py b/mne/io/eeglab/eeglab.py
--- a/mne/io/eeglab/eeglab.py
+++ b/mne/io/eeglab/eeglab.py
@@ -52,8 +52,6 @@ def _check_eeglab_fname(fname, dataname):
             "Old data format .dat detected. Please update your EEGLAB "
             "version and resave the data in .fdt format"
         )
-    elif fmt != ".fdt":
-        raise OSError("Expected .fdt file format. Found %s format" % fmt)
 
     basedir = op.dirname(fname)
     data_fname = op.join(basedir, dataname)


Test patch: