Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API: simulation module #6119

Closed
makkostya opened this issue Apr 3, 2019 · 16 comments
Closed

API: simulation module #6119

makkostya opened this issue Apr 3, 2019 · 16 comments
Assignees

Comments

@makkostya
Copy link
Contributor

I create this issue to continue general discussion of a simulation module API, started in #5058.
We need to design the API which should:

  • easy way to define where the activity is happening (labels) (see Feature: Source labels simulation #5924)
  • what is the activity (waveform)
  • when it is happening (event info)
  • provide as an output a proper input for simulate_raw.

cc @sdeslauriers @ikojcic @ngayraud

@agramfort can you label this issue as "simulation" for codding sprint pls.

@larsoner
Copy link
Member

larsoner commented Apr 3, 2019

Closing as dup of conda/conda#8187

@larsoner larsoner closed this as completed Apr 3, 2019
@larsoner
Copy link
Member

larsoner commented Apr 3, 2019

Sorry wrong link, meant #5924

@larsoner
Copy link
Member

larsoner commented Apr 3, 2019

Ahh I thought #5924 was meant to cover all of these, but looking closer I guess not. Reopening

@larsoner larsoner reopened this Apr 3, 2019
@larsoner larsoner added the Core label Apr 3, 2019
@larsoner larsoner added Simulation and removed Core labels Apr 3, 2019
@makkostya
Copy link
Contributor Author

Here is an example of a possible simulation script:
https://gist.github.com/makkostya/4f783028bb1324dabb45388f91e2cb8f

Note: we suppose StcSimulator to be the subclass of SourceEstimate and thus it could be treated as an stc.

@ngayraud you created your own Simulator class? can you share the code pls to discuss.

@ngayraud
Copy link
Contributor

ngayraud commented Apr 9, 2019 via email

@ngayraud
Copy link
Contributor

ngayraud commented Apr 10, 2019

Ok I am somewhat up to date with everything. Here is the API I created a while ago, which answers to mostly 2 and 3.
https://gist.github.com/ngayraud/22f5d0360ba34e1873ae441b850253a1

The Simulation class saves the %basic" info on the experiment, such as, the forward model, the desired waveforms (for each dipole or for all dipoles).
The get_events creates an mne.event based on the events (stimulations) on each dipole
The simulate_raw_signal is similar to existing functions, with the difference that you can pass different stimulations for each dipole, thanks to the _get_propagation function which distributes the waveforms across time. Waveform lengths are given as time arrays, and another time array is given for the whole experiment.

@wmvanvliet
Copy link
Contributor

Just wanted to leave a note that the beamformer team also wants to run simulations during the code sprint. So we're interested in the API design too!

@larsoner
Copy link
Member

Great. First we need to decide on #6037, @agramfort is not convinced it's the best approach. Once that's done, we can work on the API of the SourceSimulator.

@wmvanvliet
Copy link
Contributor

wmvanvliet commented Apr 13, 2019

About the proposed SourceSimulator API, IMO it would be much simpler to not have to define all dipoles/sources at once with complicated lists/dics datastructures, but have something like:

sim = SourceSimulator(fwd)
sim.add_signal(name='signal1', location=..., waveform=...)
sim.add_signal(name='signal2', location=..., waveform=...)
sim.add_signal(name='signal3', location=..., waveform=...)

@larsoner
Copy link
Member

Sounds good to me, except that it should take src not fwd in the constructor. Mapping source( time course)s to sensors is the domain of simulate_raw and should probably stay that way

@larsoner
Copy link
Member

@ngayraud et al. here is the example of a naive API I wrote to do this sort of thing:

https://gist.github.com/larsoner/8566361d3e011c9ce34c1d321f0f4ef1

Feel free to reuse the code (not the simulator) to test out the eventual API/implementation. The result will hopefully produce images like this:

Screen Shot 2019-03-18 at 22 39 05

Screen Shot 2019-03-18 at 22 39 10

@megazero1316
Copy link

hello i have a question, can the simulation API be used to simulated motor imagery EEG signal (or ERD/ERS pattern ) ?

@ngayraud
Copy link
Contributor

ngayraud commented Apr 24, 2019 via email

@ngayraud
Copy link
Contributor

Now that we have #6243 merged into master, what else do we need to implement to close this issue? From what I remember, we discussed about providing template waveforms. I can provide templates for the following evoked responses: P300, N200, combination of P300+N200, and N400. For all these waveforms, two parameters can be tuned to set the amplitude and jitter of the peak. Before I do a PR, let me know if (1) you think it's a good idea and (2) if they should be on a separate .py file, maybe named waveforms.py
Users can then create their own waveforms adding as much variability as they wand, and these can be passed to the SourceSimulator using the add_data function. An example should also be implemented - I can add one in the same PR.

@agramfort
Copy link
Member

agramfort commented Apr 29, 2019 via email

@mmagnuski mmagnuski changed the title API: simulation modul API: simulation module Apr 29, 2019
@larsoner
Copy link
Member

Narrative in #6261, closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants