cleanup, consistent formatting and wording

Author: robertoostenveld

development/meeting/20140402.md

@@ -21,4 +21,4 @@ tags: [meeting]
 - We discussed bug 2500.
 - We discussed bug 2516.
 - We briefly discussed how to deal with the e-mails that are left unanswered on the mailing list. All FT team members should reply occasionally (1 per week at least), to reflect that it's a team effort. Also we should give room to the outside-centre FT'ers to reply.
-- support for component data in source reconstruction functions: - dipolefitting and MNE should in principle be doable. - yet, the functions may become confused because of the mixed representation of the component data (in a freq/tlck structure). - identify which functions should support this, but currently don't do it well. - ensure that the data is unambiguous, i.e. only keep topo/topolabel and remove anything else.
+- support for component data in source reconstruction functions: - dipole fitting and MNE should in principle be doable. - yet, the functions may become confused because of the mixed representation of the component data (in a freq/tlck structure). - identify which functions should support this, but currently don't do it well. - ensure that the data is unambiguous, i.e. only keep topo/topolabel and remove anything else.

development/project/distributed.md

@@ -66,7 +66,7 @@ We may need to estimate the time and memory requirements of each process, potent
 
 Robert: an automatic estimation and updating of requirements for subsequent jobs was built into peercellfun, but turned out not to be very robust. In qsubcellfun I therefore forced the correct specification onto the user instead of attempting to have smart defaults.
 
-The benefit to different modules being run in parallel may vary. Memory/processor intensive scripts (fMRI normalisation) vs. hard disk intensive (DICOM to Nifti conversion) depending on the site specific architecture.
+The benefit to different modules being run in parallel may vary. Memory/processor intensive scripts (fMRI normalisation) vs. hard disk intensive (DICOM to NIFTI conversion) depending on the site specific architecture.
 
 Similarly, small jobs would benefit from stacking (running a series of jobs on a single distributed node). That is implemented in qsubcellfun.
 

development/project/testing_ft_vs_mne.md

@@ -187,7 +187,7 @@ It is not clear for me when you have to define the option grid.inside and grid.o
 
 ## Minimum-norm estimate in FieldTrip using simulated data
 
-Trying to understand the results above, we looked at the phantom data in detail. It turned out that the location of the phantom with respect to the sensor-array was quite eccentric. To get a better idea about whether the results are caused by a feature of the code, or by the strange alignment we simulate some phantom data, where the active dipole is in the centre of the helmet.
+Trying to understand the results above, we looked at the phantom data in detail. It turned out that the location of the phantom with respect to the sensor array was quite eccentric. To get a better idea about whether the results are caused by a feature of the code, or by the strange alignment we simulate some phantom data, where the active dipole is in the centre of the helmet.
 
     cd ~jansch/matlab/toolboxes/fs2fieldtrip/
     load grad;

development/realtime/scratchpad.md

@@ -114,7 +114,7 @@ and in a get request?
 The chunks seem a logical extension of the header structure, as such it seems
 more logical to extend the GET and PUT commands with a GET_CHUNK and PUT_CHUNK,
 where the respective packet would contain the chunk type and length. Predefined
-chunks (such as Siemens, Nifti and CTF res4) can remain as they are, but would
+chunks (such as Siemens, NIfTI and CTF res4) can remain as they are, but would
 not be sent along with each GET_HDR. This removes the requirement to switch
 from the polling to the blocking-read operation as implemented with WAIT_DAT.
 See also the light-header proposal.

faq/plotting/headmodel_localspheres.md

@@ -9,7 +9,7 @@ redirect_from:
 
 # How can I visualize a localspheres volume conductor model?
 
-Typically, one would use **[ft_plot_headmodel](/reference/plotting/ft_plot_headmodel)** for the visualization of a headmodel. This function will not allow you right away to visualize a localspheres headmodel in a meaningful way. The reason for this is that a meaningful interpretation of the localspheres headmodel is only possible in combination with a specification of the sensor-array that was used to construct the headmodel. Namely, in the specification of the headmodel, for each of the sensors a sphere has been specified that best describes the local surface of the boundary closest to that sensor. ft_plot_headmodel does not know anything about the sensors, and will not be able to plot an interpretable figure. The following snippet of code can be used to visualize the surface that is described by the localspheres headmodel. For this code to work it is assumed that you have the headmodel and corresponding sensor description (here named grad) in MATLAB working memory.
+Typically, one would use **[ft_plot_headmodel](/reference/plotting/ft_plot_headmodel)** for the visualization of a headmodel. This function will not allow you right away to visualize a localspheres headmodel in a meaningful way. The reason for this is that a meaningful interpretation of the localspheres headmodel is only possible in combination with a specification of the sensor array that was used to construct the headmodel. Namely, in the specification of the headmodel, for each of the sensors a sphere has been specified that best describes the local surface of the boundary closest to that sensor. ft_plot_headmodel does not know anything about the sensors, and will not be able to plot an interpretable figure. The following snippet of code can be used to visualize the surface that is described by the localspheres headmodel. For this code to work it is assumed that you have the headmodel and corresponding sensor description (here named grad) in MATLAB working memory.
 
     [a,b] = match_str(headmodel.label, grad.label);
 

faq/spectral/freqanalysis_foimismatchwavelet.md

@@ -10,16 +10,17 @@ redirect_from:
 
 # Why does my output.freq not match my cfg.foi when using 'wavelet' (formerly 'wltconvol') in ft_freqanalysis?
 
-Conceptually, a wavelet analysis is a time domain convolution of a signal with a set of wavelets, each of these being designed to capture some feature in the data. In neuroscience, we typically use Morlet-wavelets, which are designed to capture sine and cosine waves in the data. This is because a Morlet wavelet consists of a sine/cosine wave, tapered by a gaussian window. When doing a spectral decomposition, the goal typically is to assign the fluctuations in the signal to distinct frequency bands. Importantly, the (implicitly) required behavior of the spectral transformation is, that the power estimated at X Hz truly comes from signal fluctuations at X Hz., and not from signal fluctuations at Y Hz. (and Z Hz etc). This is the issue of spectral leakage, and a few signal processing tricks are needed to optimally control for this.
-In the context of wavelet analysis in FieldTrip and in order to minimize detrimental effects of (unpredictable spectral leakage), you need to keep 2 things in min
+Conceptually, a wavelet analysis is a time domain convolution of a signal with a set of wavelets, each of these being designed to capture some feature in the data. In neuroscience, we typically use Morlet-wavelets, which are designed to capture sine and cosine waves in the data. This is because a Morlet wavelet consists of a sine/cosine wave, tapered by a gaussian window. When doing a spectral decomposition, the goal typically is to assign the fluctuations in the signal to distinct frequency bands. Importantly, the (implicitly) required behavior of the spectral transformation is, that the power estimated at X Hz truly comes from signal fluctuations at X Hz, and not from signal fluctuations at Y Hz (and Z Hz, etc). This is the issue of spectral leakage, and a few signal processing tricks are needed to optimally control for this.
+
+In the context of wavelet analysis in FieldTrip and in order to minimize detrimental effects of (unpredictable spectral leakage), you need to keep 2 things in mind:
 
 - The length of the wavelet at frequency X should fit an integer number of cycles of the wavelet's frequency. If this is not the case, the wavelet becomes sensitive to other frequencies in the data as well, thus making the wavelet less specific to the wished-for frequency, and vulnerable to spectral leakage.
 
-- The total length of the data (your trials) should yield a frequency resolution that captures the frequencies of your spectral decomposition (your cfg.foi). This is because in its implementation FieldTrip uses the trick "convolution in the time domain is equivalent to multiplication in the frequency domain". In other words, rather than convolving the tome domain signal with the wavelets of different frequencies, the Fourier representation data is multiplied with the Fourier representation of the wavelets (and the inverse fourier transform is computed to get to the time domain representation again). If there is a mismatch between the frequencies specified in cfg.foi, and the inherent frequency resolution of the data (given by the length T, i.e. the frequency resolution is 1/T), some implicit spectral interpolation is done, which is particularly vulnerable to spectral leakage effects.
+- The total length of the data (your trials) should yield a frequency resolution that captures the frequencies of your spectral decomposition (your `cfg.foi`). This is because in its implementation FieldTrip uses the trick "convolution in the time domain is equivalent to multiplication in the frequency domain". In other words, rather than convolving the tome domain signal with the wavelets of different frequencies, the Fourier representation data is multiplied with the Fourier representation of the wavelets (and the inverse fourier transform is computed to get to the time domain representation again). If there is a mismatch between the frequencies specified in `cfg.foi`, and the inherent frequency resolution of the data (given by the length T, i.e. the frequency resolution is 1/T), some implicit spectral interpolation is done, which is particularly vulnerable to spectral leakage effects.
 
-So, to make a long story short: in order to protect the user against him/herself the new implementation in the specest-module checks for potential discrepancies, and corrects the cfg.foi, if needed. Therefore, if you wish for particular frequencies in your TFR, you need to think twic
+So to protect the user against him/herself, the new implementation in the specest-module checks for potential discrepancies, and corrects the `cfg.foi` if needed. Therefore, if you wish for particular frequencies in your TFR, you need to think twice:
 
-- Is cfg.width an integer number, resulting in an integer number of cycles for each requested frequency?
-- Is the length of my data such, that the frequency resolution 1/T can capture all cfg.foi? This means, in other words, that cfg.foi/T should be integer numbers.
+- Is `cfg.width` an integer number, resulting in an integer number of cycles for each requested frequency?
+- Is the length of my data such, that the frequency resolution 1/T can capture all `cfg.foi`? This means, in other words, that `cfg.foi` divided by T should be integer numbers.
 
-Hint: The length of the data can be influenced with the cfg.pad parameter.
+Hint: The length of the data can be influenced with the `cfg.pad` parameter.

tutorial.md

@@ -43,7 +43,7 @@ When adding or contributing to the tutorials please consider the [documentation
 - [Construct a headmodel for MEG source analysis](/tutorial/headmodel_meg)
 - [Construct a BEM headmodel for EEG source analysis](/tutorial/headmodel_eeg_bem)
 - [Construct a FEM headmodel for EEG source analysis](/tutorial/headmodel_eeg_fem)
-- [Construct a sourcemodel for MEG or EEG source analysis](/tutorial/sourcemodel)
+- [Creating a source model for MEG or EEG source analysis](/tutorial/sourcemodel)
 - [Localizing electrodes using a 3D-scanner](/tutorial/electrode)
 - [Localizing oscillatory sources in MEG data using a beamformer](/tutorial/beamformer)
 - [Beamforming oscillatory responses in combined MEG/EEG data](/workshop/natmeg2014/beamforming)

tutorial/connectivity/connectivity_sensor_source.md

@@ -168,7 +168,7 @@ We now recompute the virtual channel time series, but now only for the dipole di
 #### Exercise 8
 
 {% include markup/skyblue %}
-Rather than using a sourcemodel in the beamformer that consists of all three (x, y, z) directions, you can also have the beamformer compute the filter for only the optimal source orientation. This is implemented using the _cfg.lcmv.fixedori='yes'_ option.
+Rather than using a source model in the beamformer that consists of all three (x, y, z) directions, you can also have the beamformer compute the filter for only the optimal source orientation. This is implemented using the _cfg.lcmv.fixedori='yes'_ option.
 
 Recompute the spatial filter for the optimal source orientation and using that spatial filter (a 1x151 vector) recompute the time series.
 

tutorial/source/coregistration_opm.md

@@ -333,7 +333,7 @@ _Figure: Spatial topographies of the signals generated by the 3 HPI coils._
 
 For the fitting the magnetic dipole positions, we will use a grid search as an initial scan over the whole volume, followed by a iterative non-linear optimization. The grid search is motivated by the fact that a non-linear search of the whole parameter space (i.e., volume of space covered by the helmet) might result in convergence to a local minimum.
 
-The following creates a sourcemodel that consists of a regular grid of dipole positions that will be used for the initial grid search.
+The following creates a source model that consists of a regular grid of dipole positions that will be used for the initial grid search.
 
     %% create a regular grid of dipole positions bounded by the helmet
     fieldlinebeta2 = ft_read_sens('fieldlinebeta2.mat');  % from fieldtrip/template/grad

tutorial/source/epilepsy.md

@@ -20,7 +20,7 @@ This tutorial describes how to perform a source localization on epilepsy data us
 
 The tutorial covers data for 3 patients, all shared via our [download server](https://download.fieldtriptoolbox.org/tutorial/epilepsy/). The provided datasets have varying degrees of clinical complexity. The more complex cases are, of course, the ones most likely to be referred for MEG recordings prior to consideration for surgery.
 
-For one of the patients, case 3, we provide a detailed line-by-line breakdown of the MATLAB code required to analyze the data. We outline the steps in obtaining the beamformer outputs, from anatomical coregistration right through to plotting source images. We note an important extra step that is required in computing the beamformer for data collected on an Neuromag/Elekta/MEGIN system compared to a CTF system. We also describe how to output the source images into NiFTI format for viewing in other software such as [MRIcro](https://www.mccauslandcenter.sc.edu/crnl/tools), and how to output source timeseries as a file which can be examined clinically alongside the original data in [AnyWave](http://meg.univ-amu.fr/wiki/AnyWave) data viewing software.
+For one of the patients, case 3, we provide a detailed line-by-line breakdown of the MATLAB code required to analyze the data. We outline the steps in obtaining the beamformer outputs, from anatomical coregistration right through to plotting source images. We note an important extra step that is required in computing the beamformer for data collected on an Neuromag/Elekta/MEGIN system compared to a CTF system. We also describe how to output the source images into NIfTI format for viewing in other software such as [MRIcro](https://www.mccauslandcenter.sc.edu/crnl/tools), and how to output source timeseries as a file which can be examined clinically alongside the original data in [AnyWave](http://meg.univ-amu.fr/wiki/AnyWave) data viewing software.
 
 For patients 1 and 2, we simply provide a summary of the outputs and some other useful observations. These datasets can be analyzed by the reader in exactly the same way as case 3.