1. What did you do this week?

As described in my previous post, I spent last week doing some smaller corrections on my Pull Requests. The biggest amount of work was dedicated to allowing fast and memory saving computation to the tfr_stockwell function, the last function where I haven't implemented this yet. Principally, most of this went similar to the other functions, i.e. I had to create an alternative function which computes stuff separately for lists of SourceEstimate objects, and is capable of handling input from generator objects. However, the tricky and time consuming part was again to make sure the data fields were completely equal.
Another step last week was to change the examples I created, from one example to three example that cover the diffferent TFR functions and SourceEstimate types which can be processed equally.
Finally I did some smaller commits, correcting some stuff that my reviewers mentioned could be made better.

2. What is coming up next?

Well, as my project is finished now, and all of the important functional stuff has been implemented, I will only spend my time working on review corrections, in order to get everything merged into master.
Concerning the extended plotting that I mentioned over the last blog posts, I will probably do a bigger independent PR, that can enhance plotting functionality and modularity.

3. Did you get stuck anywhere?

Yes. As I already mentioned I first had problems with making the data fields completely equivalent, when implementing a time/memory saving version of tfr_stockwell.
But probably even more annoying (because I didn't expect it) was trying to erase Errors when submitting the freshly made examples. I rewrote the exampels first to a MNE-testing dataset which contained real neurophysiological data. Then, when submitting it, noticed that my version of the testing data was outdated (the respective dataset has been revised for another MNE-Python GSoC project running this summer). So I had to adapt the respective file paths again, which would've been no problem at all, if one of the files that I needed for one of my examples (a trans.fif file) wouldn't have been removed from the dataset. So this resulted in trying various solutions to make things work again, until I finally decided to change the example and make it run on a different dataset, where all needed files were accessible.
So next time I'll be using testing data, I'll definitely will make sure to update my testing data folder first.

So this was the last regular report on my GSoC project, and I hope that you've found it an interesting thing to read. As you might have noticed from reading, I've definitely learned alot of things during the project (probably a consequence of doing a lot of mistakes during the project), but I'm glad that I could really notably enhance my coding skills during this summer.
From now (and after having all the stuff from the project entirely merged), I will still try to stay involved in MNE, so I hope that this won't be the last thing that you'll hear from me.

Finally I want to say thanks to everyone who participated in this Google Summer of Code project with me - from my mentors to all reviewers to the people from the Salzburg Brain Dynamics lab to finally you, the reader of my blog.
Thank's to everyone and have a good time - hopefully profiting from my works on MNE-Python this Google Summer of Code ;).

Cheers!

Dirk

Last week, I worked on several steps to finalize my project.
Some work was put into correcting and improving my pull requests, so they can be merged soon. I created an example file to demonstrate the useability of this project, and opened up a new pull request for it (next to another PR, that introduces the plotting support I implemented the previous week).
As mentioned in my last blog post, I also thought about an alternative solution, i.e. to create a genuine plotting function for SourceTFR. But as I already suspected, this will not work without a lot of additional work. I originally intended to introduce a new type of plot derived from MNE's "TimeViewer", where you can not only skim along the time axis through the plotting GUI, but also along the frequency (and maybe the epochs) axis. After trying out some stuff, my best intuition to reaching this goal would be to simplify the "TimeViewer" class, and make it some kind of a "AxisViewer" class. This class would allow a developer to decide which axis (or even multiple axes) should be manipulable through the GUI. Yet, this would be only a part of the work, as this does not include the actual plotting function used by SourceTFR, and also would only work for the plots made on surface type source level data (since volume type source level data employs an entirely different plotting GUI). In my opinion, this functionality should rather be added later, so I can now concentrate on the finishing touches of the rest of the project.
One such finishing touch is for example time and memory saving computation of tfr_stockwell, which is for now only available for tfr_morlet and tfr_multitaper. I already made attempts to tackle this problem, and currently try to make it pass the equivalence tests. But this will definitely be one of the things to do this week, as it will have big implications on the practical useability of the function.

Another thing I worked on last week (and will continue to work on this week) was the project page where I'll upload my final results next week. I decided to create a GitHub gist for this purpose, since it is simple and good looking at the same time. Most of the gist is already finished, only the links to the PRs and some direct examples will need to be added there. So I hope, everything will work out this week, and I'll be able to show you a nice conclusion on my Google Summer of Code project until next week.

So, for the last time (this summer?!): Stay tuned!

Last week, I finished the main functional goal of this GSoC project, by making tfr_functions compute all the things they should compute correctly. It even was possible to allow tfr_morlet and tfr_multitaper to process lists and generator objects subsequently, which is quite important in order to save memory. However, while doing so, I realized that this will basically scrap all the support I introduced for supporting kernelized data (the other memory saving trick I used, where memory is stored in two small arrays, which can be combined by taking the dot product). So this will be a point to work on again, however, this will probably more look like some dirty fix, as I really don't see any elegant solution to this at the moment.
Another thing I can finally start to work on now will be plotting. To be honest, I'm kind of excited to work on graphical/ user interface stuff, since I often experienced that the implementation of these things is quite fun (i.e. if they work, they work ;) ). But we'll see how that turns out. The other thing to do will be to write some nice tutorial, showing off the newly gained functionality (which I think will also be fun).
So, it's time to start the final sprint of the project, and I think I'm prepared for it. Stay tuned!

1. What did you do this week?

A lot of different stuff:

- Introduced some small tests to make sure the multitaper and stockwell functions do what they should to.
- Made tfr_stockwell catch up with tfr_morlet and tfr_multitaper.
- Pushed a smaller PR that gives the user an option to return SourceEstimates data as kernelized (i.e. memory saving).
- Made tfr_multitaper and tfr_morlet take lists and generators as input, a crucial further step that allows the Inter-Trial-Coherence to be calcualted (how good this works remains to be checked, however).

2. What is coming up next?

We'll need to see how good the IRT stuff works and finish all of it. When everythings done, the core stuff of this GSoC project will be finished. This will involve pushing a quite big chuck of code, reviewing and correcting it. Then I'll make sure the same stuff works for tfr_stockwell as well. Finally I might start this week with the implementation of the last functional aspect, which is plotting the data.

3. Did you get stuck anywhere?

Yes. When introducing lists into tfr functions, the perfect solution would have been to process each "epoch" or element of the list subsequently, in order to save data. After trying to implement this (and getting it to work for tfr_morlet), I found out that if this was to be done cleany and working for all functions, it would require a huge recstructuring of the tfr_functions, that might have grave consequences for other aspects, e.g. parallel computing of the functions. Therefore I had to start of with a bit of a poorer solution, where the data is simply concatenated together at the start of the function, and then treated very much like epochs data. This will increase memory usage. However, I hope that I can implement a memory saving solution at some later point.