Repository: mne-tools/mne-python

Issue:
BIDS related: potential change of .fif file split naming
**TL;DR**

> would it be a big problem to change the FIF file "bids-style" split naming from `_part-X` to something else? (see: https://github.com/mne-tools/mne-python/blob/861e82505ce59e7ea84887227d6066776bdc6401/mne/io/utils.py#L298-L310)

---


When `.fif` files grow too large, they need to be split into chunks. In a [BIDS](https://bids.neuroimaging.io/) context, where each file name follows a structure, we need some way to deal with this.

In 2017 or 2018 @jasmainak and @teonbrooks (I think? ... somebody else?) suggested to use `*_part-X_meg.fif` with the `X` being a number to define different parts of the same `.fif` recording.

Some context before the issue: The `_part-` syntax was (accidentally) not fully introduced into the specification: It is only a non-elaborated example in an appendix, see:

https://bids-specification.readthedocs.io/en/stable/99-appendices/06-meg-file-formats.html#neuromagelektamegin

This leads to the issue that now several other BIDS extension proposals want to use `_part-` and have started using it --> because they were not aware that [it is already being used in MNE](https://github.com/mne-tools/mne-python/blob/861e82505ce59e7ea84887227d6066776bdc6401/mne/io/utils.py#L298-L310) (because as I said, `_part-` is only mentioned in a non-elaborated example in an appendix).

The complete issue is here: https://github.com/bids-standard/bids-specification/issues/429

The fight is essentially whether or not it's OK for MEG/MNE to claim `_part-` for themselves although it was never *properly* introduced into the spec.

One pragmatic solution is to
1. drop the non-elaborated `_part-` example from the appendix of the BIDS spec
1. *properly* introduce a new way to name split `.fif` files with a new PR to the BIDS spec (e.g., `_split-X`
1. adapt MNE-Python to use that new, *proper* way (e.g., `_split-X`), and deprecating MNE support for the now invalid `_part-X`

This part of MNE would have to change:

https://github.com/mne-tools/mne-python/blob/861e82505ce59e7ea84887227d6066776bdc6401/mne/io/utils.py#L298-L310

There are other solutions described in the BIDS issue thread (I summarized them in [this comment](https://github.com/bids-standard/bids-specification/issues/429#issuecomment-624174033)) **but there are several parties with strong opinions**, and if the pragmatic solution proposed in THIS issue is not a big deal for MNE folks, then going with this solution would resolve the BIDS issue in a straight forward way.

cc @robertoostenveld @effigies @yarikoptic 



Discussion:
> One pragmatic solution is to

This sounds fine from the MNE end to me. `_split` is clearer naming than `_part` for its purpose anyway
_split would work for me. it's an easy change for MNE-Python and fif
readers don't care as long as pointer in the files are correct.

> One pragmatic solution is to
> 
> 1. drop the non-elaborated `_part-` example from the appendix of the BIDS spec
> 2. _properly_ introduce a new way to name split `.fif` files with a new PR to the BIDS spec (e.g., `_split-X`
> 3. adapt MNE-Python to use that new, _proper_ way (e.g., `_split-X`), and deprecating MNE support for the now invalid `_part-X`

I like that.
I checked a few datasets on openneuro randomly and it seems the `split` convention is used almost nowhere. So, it's fine to change to `_split-X`
i'm also in favor of the switch from  changing it from `part` to `split`. I gave approval there. I have one dataset with `part` in it but I will just go back rename them with the landed patch in mne-bids

Resolving patch:
diff --git a/mne/io/utils.py b/mne/io/utils.py
--- a/mne/io/utils.py
+++ b/mne/io/utils.py
@@ -305,6 +305,6 @@ def _construct_bids_filename(base, ext, part_idx):
             idx = deconstructed_base.index(mod)
             modality = deconstructed_base.pop(idx)
     base = '_'.join(deconstructed_base)
-    use_fname = '%s_part-%02d_%s%s' % (base, part_idx, modality, ext)
+    use_fname = '{}_split-{:02}_{}{}'.format(base, part_idx, modality, ext)
 
     return use_fname
diff --git a/tutorials/io/plot_20_reading_eeg_data.py b/tutorials/io/plot_20_reading_eeg_data.py
--- a/tutorials/io/plot_20_reading_eeg_data.py
+++ b/tutorials/io/plot_20_reading_eeg_data.py
@@ -35,8 +35,8 @@
 * key-value pairs marked as ``key=value``
 
 A documentation for core BrainVision file format is provided by Brain Products.
-You can view the specification
-`here <https://docs.google.com/viewer?url=https://raw.githubusercontent.com/sappelhoff/brainvision-validator/master/doc/BrainVisionCoreFileFormat.pdf>`_
+You can view the specification hosted on the
+`Brain Products website <https://www.brainproducts.com/productdetails.php?id=21&tab=5>`_
 
 BrainVision EEG files can be read in using :func:`mne.io.read_raw_brainvision`
 with the .vhdr header file as an input.


Test patch:
diff --git a/mne/io/fiff/tests/test_raw_fiff.py b/mne/io/fiff/tests/test_raw_fiff.py
--- a/mne/io/fiff/tests/test_raw_fiff.py
+++ b/mne/io/fiff/tests/test_raw_fiff.py
@@ -366,8 +366,8 @@ def test_split_files(tmpdir):
     split_fname = tmpdir.join('split_raw_meg.fif')
     # intended filenames
     split_fname_elekta_part2 = tmpdir.join('split_raw_meg-1.fif')
-    split_fname_bids_part1 = tmpdir.join('split_raw_part-01_meg.fif')
-    split_fname_bids_part2 = tmpdir.join('split_raw_part-02_meg.fif')
+    split_fname_bids_part1 = tmpdir.join('split_raw_split-01_meg.fif')
+    split_fname_bids_part2 = tmpdir.join('split_raw_split-02_meg.fif')
     raw_1.set_annotations(Annotations([2.], [5.5], 'test'))
     raw_1.save(split_fname, buffer_size_sec=1.0, split_size='10MB')