Articles on sappelhoff's Blog

Thirteenth week of GSoC: Final Checkin

Stefan.Appelhoff@gmail.com (sappelhoff) — Sat, 24 Aug 2019 08:10:36 +0000

1. What did you do this week?

I have compiled a list for week 13 in my changelog here: https://github.com/sappelhoff/gsoc2019/blob/master/changelog.md#week-13

This was the final week of my GSoC 2019. I have written a final report here: https://github.com/sappelhoff/gsoc2019/blob/master/FINAL_REPORT.md

2. What is coming up next?

Next up I will focus on my PhD work, hopefully making use of many of the features I helped to bring about!

I am sure that this will also entail making many bug reports, ... and fixing them. Although it will probably take a longer time, because the focused GSoC time is over for now.

3. Did you get stuck anywhere?

This week, we had many discussions on digitized position data of electrophysiology sensors. This discussion eventually lead into whether we want to support template data in BIDS at all ... or whether BIDS should be just for true, measured data.

See:

Twelveth week of GSoC: Getting ready for the final week of GSoC

Stefan.Appelhoff@gmail.com (sappelhoff) — Mon, 19 Aug 2019 10:03:40 +0000

My GSoC is soon coming to an end so I took some time to write down what still needs to be done:

Making a release of MNE-BIDS

In the past months, there were substantial additions, fixes, and cosmetic changes made to the codebase and documentation of MNE-BIDS. The last release has happened in April (about 4 months ago) and we were quite happy to observe some issues and pull requests raised and submitted by new users. With the next release we can provide some new functionality for this growing user base.

Handling coordinates for EEG and iEEG in MNE-BIDS

In MNE-BIDS, the part of the code that handles the writing of sensor positions in 3D space (=coordinates) is so far restricted to MEG data. Extending this functionality to EEG and iEEG data has been on the to do list for a long time now. Fortunately, I have been learning a bit more about this topic during my GSoC, and Mainak has provided some starting points in an unrelated PR that I can use to finish this issue. (After the release of MNE-BIDS though, to avoid cramming in too much last-minute content before the release)

Writing a data fetcher for OpenNeuro to be used in MNE-Python

While working with BIDS and M/EEG data, the need for good testing data has come up time and time again. For the mne-study-template we solved this issue with a combination of DataLad and OpenNeuro. Meanwhile, MNE-BIDS has its own dataset.py module ... however, we all feel like this module is duplicating the datasets module of MNE-Python and not advancing MNE-BIDS. Rather, it is confusing the purpose of MNE-BIDS.

As a solution, we want to write a generalized data fetching function for MNE-Python that works with OpenNeuro ... without adding the DataLad (and hence Git-Annex) dependency). Once this fetching function is implemented, we can import it in MNE-BIDS and finally deprecate MNE-BIDS' dataset.py module.

Make a PR in MNE-Python that will support making Epochs for duplicate events (will fix ds001971 PR)

In MNE-Python, making data epochs is not possible, if two events share the same time. This became apparent with the dataset ds001971 that we wanted to add to the mne-study-template pipeline: https://github.com/mne-tools/mne-study-template/pull/41. There was a suggestion on how to solve this issue by merging the event codes that occurred at the same time. Once this fix is implemented in MNE-Python, we can use this to finish the PR in the mne-study-template.

Salvage / close the PR on more "read_raw_bids" additions

Earlier in this GSoC, I made a PR intended to improve the reading functionality of MNE-BIDS (https://github.com/mne-tools/mne-bids/pull/244). However, the PR was controversially discussed, because it was not leveraging BIDS and instead relying on introducing a dictionary as a container for keyword arguments.

After lots of discussion, we agreed to solve the situation in a different way (by leveraging BIDS) and Mainak made some initial commits into that direction. However in the further progress, the PR was dropped because other issues had higher priority.

Before finishing my GSoC, I want to salvage what's possible from this PR and then close it ... and improving the original issue report so that the next attempt at this PR can rely on a more detailed objective.

Eleventh week of GSoC: Some more Datalad (complete and automatic flow now)

Stefan.Appelhoff@gmail.com (sappelhoff) — Sun, 11 Aug 2019 19:44:16 +0000

1. What did you do this week?

I have compiled a list for week 11 in my changelog here: https://github.com/sappelhoff/gsoc2019/blob/master/changelog.md#week-11

2. What is coming up next?

Next, I will continue to improve the mne-study-template and also work on a new release of MNE-BIDS.

3. Did you get stuck anywhere?

As the week before, I got stuck a bit with Datalad. However, I finally fixed all problems and I want to report the flow of my pipeline below. enjoy!

Pipeline to get any dataset as git-annex dataset

using the following tools:

OSF: https://osf.io
osfclient: https://github.com/osfclient/osfclient
git-annex: https://git-annex.branchable.com/
datalad: https://www.datalad.org/
datalad-osf: https://github.com/templateflow/datalad-osf/
Github: https://github.com

Step 1 Upload data to OSF
1. install osfclient: `pip install osfclient` (see https://github.com/osfclient/osfclient)
2. make a new OSF repository from the website (need to be registered)
3. copy the "key" from the new OSF repository, e.g., "3qmer" for the URL: "https://osf.io/3qmer/"
4. navigate to the directory that contains the directory you want to upload to OSF
5. make a `.osfcli.config` file: `osf init` ... this file gets written into the current working directory
6. call `osf upload -r MY_DATA/ .` to upload your data, replacing MY_DATA with your upload directory name
7. instead of being prompted to input your password, you can define an environment variable OSF_PASSWORD with your password. This has the advantage that you could start an independent process without having to wait and leave your command line prompt open: `nohup osf upload -r MY_DATA/ . &`
8. NOTE: Recursive uploading using osfclient can be a bad experience. Check out this wrapper script for more control over the process: https://github.com/sappelhoff/gsoc2019/blob/master/misc_code/osfclient_wrapper.py
Step 2 Make a git-annex dataset out of the OSF data
1. install datalad-osf: git clone and use `pip install -e .` NOTE: You will need the patch submitted here: https://github.com/templateflow/datalad-osf/pull/2
2. install datalad: `pip install datalad` and git-annex (e.g., via conda-forge)
3. create your data repository: `datalad create MY_DATA`
4. go there and download your OSF data using datalad-osf: `cd MY_DATA` ... then `python -c "import datalad_osf; datalad_osf.update_recursive(key='MY_KEY')"`, where MY_KEY is the "key" from step 1 above.
Step 3 Publish the git-annex dataset on GitHub
1. Make a fresh (empty) repository on GitHub: <repo_url>
2. Clone your datalad repo: datalad install -s <local_repo> clone
3. cd clone
4. git annex dead origin
5. git remote rm origin
6. git remote add origin <repo_url>
7. datalad publish --to origin
Step 4 Get parts of your data (or everything) from the git-annex repository
1. datalad install <repo_url>
2. cd <repo>
3. datalad get <some_folder_or_file_path>
4. datalad get .

Important sources / references

Tenth week of GSoC: git-annex and datalad

Stefan.Appelhoff@gmail.com (sappelhoff) — Sun, 04 Aug 2019 08:17:42 +0000

In the last weeks Alex, Mainak and I were working on making the mne-study-template compatible with the Brain Imaging Data Structure (BIDS). This process involved testing the study template on many different BIDS datasets, to see where the template is not yet general enough, or where bugs are hidden.

To improve our testing, we wanted to set up a continuous integration service that automatically runs the template over different datasets for every git commit that we make. Understandably however, all integration services (such as CircleCI) have a restriction on how much data can be downloaded in a single test run. This meant we needed lightweight solutions that can pull in only small parts of the datasets we wanted to test.

And this is where git-annex and datalad enter the conversation.

git-annex

git-annex is a software that allows managing large files with git. One could see git-annex as a competitor to git-lfs ("Large File Storage"), because both solve the same problem. They differ in their technical implementation and have different pros and cons. A good summary can be found in this stackoverflow post: https://stackoverflow.com/a/39338319/5201771

Datalad

Datalad is a Python library that "builds on top of git-annex and extends it with an intuitive command-line interface". Datalad can also be seen as a "portal" to many git-annex datasets openly accessible in the Internet.

Recipe: How to turn any online dataset into a GitHub-hosted git-annex repository

Requirements: git-annex, datalad, unix-based system

Installing git-annex worked great using conda and the conda-forge for package git-annex:

conda install git-annex -c conda-forge

The installation of datalad is very simple via pip:

pip install datalat

Now find the dataset you want to turn into a git-annex repository. In this example, we'll use the Matching Pennies dataset hosted on OSF: https://osf.io/cj2dr/

We now need to create a CSV file with two columns. Each row of the file will reflect a single file we want to have in the git-annex repository. In the first column we will store the file path relative to the root of the dataset, and in the second column we will store the download URL of that file.

Usually, the creation of this CSV file should be automated using software. For OSF, we have the datalad-osf package which can do the job. However, that package is still in development so I wrote my own function, which involved picking out many download URLs and file names by hand :-(

On OSF, the URLs are given by <span style="font-family: Courier New,Courier,monospace;">https://osf.io/<key>/download</key></span> where <key> is dependent on the file.</key>

See two example rows of my CSV (note the headers, which are important later on):

fpath, url
sub-05/eeg/sub-05_task-matchingpennies_channels.tsv, https://osf.io/wdb42/download
sourcedata/sub-05/eeg/sub-05_task-matchingpennies_eeg.xdf, https://osf.io/agj2q/download

Once your CSV file is ready, and git-annex and datalad are installed, it is time to switch to the command line.

# create the git-annex repository
datalad create eeg_matchingpennies

# download the files in the CSV and commit them
datalad addurls mp.csv "{url}" "{fpath}" -d eeg_matchingpennies/  

# print our files and the references where to find them
# will show a local address (the downloaded files) and a web address (OSF)
git annex whereis  

# Make a clone of your fresh repository
datalad install -s eeg_matchingpennies clone

# go to the clone
cd clone  

# disconnect the clone from the local data sources
git annex dead origin  

# disconnect the clone from its origin
git remote rm origin  

# print our files again, however: Notice how all references to
# the local files are gone. Only the web references persist
git annex whereis

Now make a new empty repository on GitHub: https://github.com/sappelhoff/eeg_matchingpennies

# add a new origin to the clone
git remote add origin https://github.com/sappelhoff/eeg_matchingpennies

# upload the git-annex repository to GitHub
datalad publish --to origin

Now your dataset is ready to go! Try it out as described below:

# clone the repository into your current folder
datalad install https://github.com/sappelhoff/eeg_matchingpennies

# go to your repository
cd eeg_matchingpennies

# get the data for sub-05 (not just the reference to it)
datalad get sub-05

# get only a single file
datalad get sub-05/eeg/sub-05_task-matchingpennies_eeg.vhdr  

# get all the data
datalad get .

Acknowledgments and further reading

I am very thankful to Kyle A. Meyer and Yaroslav Halchenko for their support in this GitHub issue thread. If you are running into issues with my recipe, I recommend that you fully read that GitHub issue thread.

Ninth week of GSoC

Stefan.Appelhoff@gmail.com (sappelhoff) — Mon, 29 Jul 2019 08:16:00 +0000

1. What did you do this week?

I have compiled a list for week 9 in my changelog here: https://github.com/sappelhoff/gsoc2019/blob/master/changelog.md#week-9

2. What is coming up next?

Next, I will mostly work on the mne-study template. With Mainak, I discussed that the next step would be to implement a CI test suite.

3. Did you get stuck anywhere?

In the MNE-Python codebase there was a "magical" factor of 85 multiplied with a variable, and it was not documented where that was coming from. It took me a while to figure out (and verify!) that this is the average head radius (assuming an unrealistically spherical head) in millimeters. Now the documentation is much better, but it helped me to learn once more that one has to either

write clean code
- e.g., instead of having the factor 85 there, make it a variable with the name `realistic_head_radius_mm` (or something like it)
write a good documentation
- E.g., make short but instructive comments, or more exhaustive documentation in the function or module docstrings

probably a combination of both is best.

Eighth week of GSoC: Mixed tasks and progress

Stefan.Appelhoff@gmail.com (sappelhoff) — Sun, 21 Jul 2019 09:55:33 +0000

Two thirds of the GSoC program are already over - time is passing very quickly. This past week, we made some progress with the mne-study-template and making it usable with BIDS formatted data.

Alex has improved the flow substantially, with Mainak serving as the "Continuous Integration service", regularly running different datasets to the pipeline and reporting where they get stuck. My own tasks were very diverse this week:

MNE-BIDS maintenance

I fixed several bugs with MNE-BIDS that we found while working on the study template. For example:

Reviewing and user support

Furthermore, I was very happy to see many issues raised on MNE-BIDS. The issues showed that more and more people are picking up MNE-BIDS and using it in their data analysis pipelines. However, that also meant that in the last week, I did more user support and reviewing of pull requests than usual.

For example, a nice pull request that I reviewed was done by Marijn (who is also an MNE-Python contributor). He improved MNE-BIDS' find_matching_sidecar function by introducing a "race for the best candidate" of the matching sidecar file.

Work on mne-study-template

Finally, I also worked on the mne-study-template myself - however, my contributions were rather modest. I mostly cleaned up the configuration files, formatted testing data, and made workflows work where they got stuck.

See for example here.

Next week, I want to work more on the mne-study-template.

Seventh week of GSoC: Just a status report

Stefan.Appelhoff@gmail.com (sappelhoff) — Sun, 14 Jul 2019 08:13:55 +0000

1. What did you do this week?

Main work:

I improved MNE-BIDS's "read_raw_bids" function in PR #219 by allowing it to automatically set channel types in a "raw" object by parsing an accompanying BIDS channels.tsv file
I worked on the MNE-STUDY-TEMPLATE, making it work for the first step "loading and filtering" for a different dataset and modality than it was intended for
I started a PR (#221) to expose the MNE-BIDS "copyfile functions" to the command line interface

Other work:

User support in MNE-BIDS and MNE-Python over the issues
Bugfix in MNE-BIDS (PR #217)
Made dev docs accessible for MNE-BIDS via the CircleCI API (PR #216)
... and lots of other stuff. As usual, I keep my log on my GSoC repository

2. What is coming up next?

I will ...

finish the PR on improving the MNE-BIDS command line (including docs)
Go back to the MNE-STUDY-TEMPLATE and try to make it work for the EEG data beyond the filtering
Make a dedicated example to MNE-BIDS' read_raw_bids function
allow read_raw_bids to read the digitization files accompanying a raw data file

3. Did you get stuck anywhere?

As usual, there were many minor points where I got stuck. And as usual, I got lots of support from my mentoring team. This week, there was nothing serious however :-)

Some examples:

Trying to kill the warnings MNE-BIDS currently throws when running the tests
Fighting with Freesurfer and the MNE bindings to Freesurfer

Sixth week of GSoC: On taking breaks and abstaining from rewriting old code

Stefan.Appelhoff@gmail.com (sappelhoff) — Sun, 07 Jul 2019 17:03:29 +0000

This past week I finally finished the big Pull Request on coordinate systems and writing T1 MRI data for BIDS. Right after the PR was done, I felt like taking a break and not immediately start coding again. Usually, that works quite well in my life as a PhD student: There is a large diversity of non-coding tasks going from reading, over writing, to simply recording data (very practical work). With currently being a student in the Google Summer of Code, I perceive much less diversity of tasks: There are lots of features to be implemented ... and as soon as one feature gets done, the next one should be tackled.

How do other software developers take breaks (or when)?
Do they even feel like taking a break after finishing a certain feature?
Or is this an issue too individual to be generally answered?
... or could it be that my perception of the different coding tasks was a bit too coarse last week and that "implementing features" is more diverse than it sounds?

Anyhow, I overcame my short period of lower motivation and started to work again on the mne-study-template, just to face the next challenge: Rather than iteratively improve the codebase, I felt the urge to completely rewrite it from scratch.

Some background: I did not design or implement the codebase so far, so everything is rather new to me. I quickly realized that the study template is very biased towards specific types of data to be processed ... and also very biased towards a specific structure that the data should be set up in. With my job to make the mne-study-template more general and relying on a data standard rather than arbitrary data structures, a re-write seemed most efficient to me. Fortunately, I remembered this quote by Joel Spolsky from his blog entry Things you should never do, Part 1:

"Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand."

The takeaway of the post is, that re-writing an existing codebase from scratch is rarely a good idea.

So next week, I'll further dig into the study template and start with iterative improvements..

Fifth week of GSoC: Coordinate Systems and Transformations

Stefan.Appelhoff@gmail.com (sappelhoff) — Sun, 30 Jun 2019 17:18:25 +0000

1. What did you do this week?

This week's primary work related to work I started in my second week of GSoC. There I was starting to convert MNE-Python's "somato" dataset to the BIDS standard, so that I can use it as an easy test case for improving BIDS-MNE-pipelines.

That work was then halted, because we realized that some files could not yet be saved according to the BIDS standard, because the specification does not cover them (as of yet).

Thanks to an idea by Alex, this week was dedicated to implement code that can quickly recalculate all files, without having to save them --> thus, we achive full BIDS compatibility.

Let's have a concrete summary in bullet points:

When handling MEG data, we are often dealing with three different coordinate systems
- One system to specify the head of the study participant
- One system to specify the sensors of the MEG machine
- One system that specifies the MRI scan of the study participants head
For source-space analyses, we need to align these coordinate system in a process called coregistration
The coregistration is achieved through transformation matrices, which specify how points have to be rotated and translated to fit from one system into the other
In MNE-Python, these transformation matrices are called `trans` ... and currently, there is no fixed way in BIDS, how/where to save these as files
In BIDS however, we DO know how to save anatomical landmarks such as the Nasion, and left and right preauricular points
Thus, we simply save all of the points in their respective coordinate systems, and then call a function that calculates the `trans` by fitting the points to each other

Sounds more straight forward than it turned out to be, and I spent nearly the whole week wrapping my head around concepts, private functions, improving docs, and implementing the necessary code.

It's still not completely finished, by we are getting close.

2. What is coming up next?

Next week, I hope to finalize the work on coordinate systems and transformations. Then I will finally start to make a BIDS version of the mne-study template. Perhaps starting with the first steps, instead of tackling all steps (including source localization) at the same time.

I realized that currently the mne-study-template is quite MEG centric. I will see whether that will make me run into problems.

3. Did you get stuck anywhere?

I got stuck at several points while working out coregistration, as is documented in several posts I made:

Luckly, I received lots of helpful comments by Mainak, Eric, and Alex ... so I made some progress regardless of the challenges. :-)

Fourth week of GSoC: Second half of "short GSoC pause" (due to summer school), and getting back to work - Issues with the BIDS-validator

Stefan.Appelhoff@gmail.com (sappelhoff) — Mon, 24 Jun 2019 08:22:21 +0000

The past week I finished the summer school that I was running from the 11th of June until the 19th of June. It was a success given the reactions from all participants¹. However I was very happy when I could return to my GSoC project and coding starting last Thursday.

I started by adding a feature to MNE-BIDS: When reading a raw file into a python object, we want to automatically scan an accompanying meta data file (channels.tsv) to populate the python object with information about bad channels in the data. When implementing the feature, most of the problems I encountered were due to an interaction with the BIDS-validator, which I want to dedicate today's blog post to.

The BIDS-validator

I have written about BIDS before: It's a standard for organizing neuroimaging data. A standard can only be a standard when there is a set of testable rules to follow. The BIDS-validator is a software that automatically checks a dataset for its compliance with the BIDS set of testable rules. The current BIDS-validator is written in JavaScript, which offers a unique advantage: It can be run locally inside a browser (see here), that is: No files are uploaded. This way, users of BIDS can employ the BIDS-validator without having to download software. Yet, for users with some programming experience, the BIDS-validator can also be downloaded as a command line tool to run on nodejs.

Alas, the big advantage of having the BIDS-validator instantiated in Javascript also comes at a cost: The programming language itself. With BIDS being a standard for scientific data, most of the user base consists of researchers. Only a fraction of researchers in the field of neuroscience is well versed in Javascript, with the lingua francas of the field being Matlab and Python (and according to my experiences increasingly Python and less and less Matlab). This means, that open source contributions from the researchers to the BIDS-validator are limited and the BIDS-validator development relies on a small core of contributors and to some extend on contributions from a commercial company, funded through grants given to BIDS. The resulting problem is that the BIDS-validator often lags behind the development of the standard ... or that not all rules are tested to an appropriate extend.

Some rules of BIDS are implemented in the form of regular expressions (see here), and are thus"programming language agnostic". This is a great starting point for BIDS-validators implemented in other languages, and there is some limited Python support.

Thinking about this, I often find myself going down the road of writing a complete BIDS-validator in Python. The advantage would be obvious: Much easier development! And the expense that it wouldn't be as easily available from the Browser as the current Javascript implementation would be negligible for anyone who can install a python package. Yet, as soon as we have more than one validator, we need to ensure that they produce exactly the same results ... and that could lead to another set of problems very soon.

It seems there is no easy way out of this situation. For me, that means that while I develop features with Python during my GSoC, I will have to occasionally spend disproportionate amounts of time debugging and enhacing the BIDS-validator with its codebase in Javascript.

¹Although Eric from MNE-Python told me that "Success is measured by how many people you convinced to use and contribute to MNE-Python :)"

Third week of GSoC: Conference discussions and short GSoC pause due to summer school

Stefan.Appelhoff@gmail.com (sappelhoff) — Sun, 16 Jun 2019 07:33:22 +0000

1. What did you do this week?

The beginning of this week (including Saturday and Sunday of the previous week) I was in Rome at the 2019 annual meeting of the Organization for Human Brain Mapping.

This was an exciting event, were I met multiple colleagues working on the two things that connect in my GSoC: BIDS and MNE-Python. I had the chance to discuss both BIDS, and the mne-study-template:

Regarding BIDS, we discussed points like:

The current governance model
Community involvement
How to progress with important topics like derivative data ... both for MEEG and MRI modalities

For the mne-study-template, we discussed that this should become the main focus of my GSoC: Making the pipeline more robust and easy to use with all that we can draw on from BIDS.

2. What is coming up next?

BIDS conversion of the LIMO data in coorporation with Jose Alanis (@josealanis)
tackling an issue in mne-bids: https://github.com/mne-tools/mne-bids/issues/182
think about on where mne-bids can be imported in the mne-study-template to simplify the workflow and to make it more robust at the same time

3. Did you get stuck anywhere?

The third week of my GSoC went as planned, however I want to notice that most of the days I had to organize/lead a summer school at my institute. This has been part of my original project plan from the beginning (see week 3 in the schedule), so it did not come as a surprise to anyone. Still, I will be very happy to go back to coding once the summer school event is concluded!

Second week of GSoC: Description of two exemplary work projects

Stefan.Appelhoff@gmail.com (sappelhoff) — Sun, 09 Jun 2019 06:13:09 +0000

In today's blog post I will describe two example projects that I have been working on during the last week. finally I will describe how these two examples relate to my overall goal in this GSoC.

Conversion of MNE-somato-data

This week I spent some time converting a dataset to comply with the Brain Imaging Data Structure: The MNE-somato-data, which is used in several code examples and tutorials for the MNE-Python documentation.

The Brain Imaging Data Structure is an emerging standard on how to organize and structure neuroimaging data recordings such as MRI, EEG, MEG, or iEEG data. Such a standard is invaluable to improve the sharing of data, performing quality analysis, and building automated pipelines.

Converting existing datasets to this new standard allows us to reap all of these benefits and build on them in the future.

However, the conversion is often not very straight forward. In the particular case of the MNE-somato-data I was facing a severe lack of documentation. Thus, the conversion from an arbitrary data structure to the standard of BIDS was slower than expected, yet now the somato dataset has a much better documentation on top of being organized in a sensible standard.

Autoreject documentation

The autoreject package is Python software to "clean" electrophysiology data such as EEG and MEG. It uses a process of crossvalidation to automatically find thresholds that can be used to reject or retain parts of the data. In addition, there is an algorithm to repair data data that might be rejected otherwise (because of exceeding the crossvalidated threshold).

When using a software package such as autoreject, the documentation of the inner workings are almost as important as the functionality of the software itself: Especially when it comes to the analysis of scientific data by researchers, who are often not trained to go through sourcecode and understand the inner workings themselves.

The autoreject package has some documentation in the form of examples that show off the basic functionality. On top, there is a small FAQ section that addresses user needs beyond getting information about basic functionality.

This week, I added a section on the general understanding of the algorithm, not directly related to code. Providing this intuitive explanation up front can be used to approach the more mathematical explanations to be found in the associated scientific publication.

Throughout this process, I have tried to follow the guidelines on "good documentations" that are always split into 4 parts: "Tutorials", "How-to guides", "Explanation", and "Reference"

How does this related to my overall project?

My overall project goal is to enable or enhance automatic processing of neurophsyiology datasets organized using BIDS. The conversion of the MNE-somato-data to BIDS provides me with a testing case for analyses pipelines. And, as already evident from its name, the autoreject package is a prime candidate for automatic processing of neurophysiology data and it is a good idea to improve the documentation of the software that you want other people to use.

First week of GSoC: Going down several rabbit holes

Stefan.Appelhoff@gmail.com (sappelhoff) — Sun, 02 Jun 2019 14:36:13 +0000

1. What did you do this week?

This week was characterized by many different smaller tasks, such as:

improvements to documentation,
fixing of bugs (typo-bugs),
speeding up continuous integration through caching,
opening issues to discuss potential APIs for analysis pipelines,
... and some more

To track my progress in GSoC, I have made a repository: github.com/sappelhoff/gsoc2019 where I host a changelog file that contains each issue/pr/task that I have worked on, divided by weeks and days.

For my overall project, the most important work was probably opening an issue to discuss potential APIs for analysis pipelines. I suggested a JSON-file centered approach, and Mainak (my mentor) pointed me to several existing solutions. In our chat on Gitter we later agreed to target the mne-study-template and improving it, before making an attempt to program a new pipeline from scratch.

2. What is coming up next?

Conversion of MNE testing datasets to the BIDS standard to have a good set of data to test pipelines on
Applying code from MNE-BIDS to the mne-study-template to see where we can improve it
Finishing an addition to the documentation of the autoreject package: https://github.com/autoreject/autoreject/issues/144

Next week I will also travel to Rome for the OHBM conference, where I will meet Mainak and Alex who are mentoring me during this GSoC.

3. Did you get stuck anywhere?

I do not feel like I "got stuck" with anything in particular, but neither did I make a good "first step" with my project. As indicated in the title of this post, I always started to do something, and then got sidetracked by minor issues that I first wanted to fix. This ended up being a big time investment for each fix. It feels good to fix minor issues, but it should not distract me from the overall goal of the GSoC :-)

Google Summer of Code (GSoC) 2019: Analysis Pipelines and BIDS

Stefan.Appelhoff@gmail.com (sappelhoff) — Tue, 28 May 2019 19:58:18 +0000

Dear Python and GSoC Community,

this year I will take part in the Google Summer of Code (GSoC) to 
dedicate three months of coding towards improving neuro-data analysis 
with MNE-Python.

I am a PhD student in my second year, mostly working with EEG data in 
the domain of human decision making. In my free time I contribute to 
open source software and more recently, I have become a maintainer for 
the "Brain Imaging Data Structure" (BIDS), an emerging standard for 
organizing neuroimaging data.

In my GSoC project with MNE-Python, I will be drawing on "Brain Imaging 
Data Structure"  to build automated, standardized analysis pipelines. 
Stay tuned! :-)

If you want to get in touch, feel free to reach out via
Gitter or Github (@sappelhoff).


Cheers,

Stefan