Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision Both sides next revision
example:checkconfig [2018/10/21 15:05]
42.49.180.224 [How to control the behaviour of ft_checkconfig]
example:checkconfig [2017/08/17 11:21] (current)
127.0.0.1 external edit
Line 43: Line 43:
 ===== How to control the behaviour of ft_checkconfig ===== ===== How to control the behaviour of ft_checkconfig =====
 When you use a fieldtrip function, this automatically calls **[[:​reference:​ft_checkconfig]]** to check the cfg you supplied. If necessary, **[[:​reference:​ft_checkconfig]]** will give you feedback. How can you control this feedback? As explained in the help documentation:​ When you use a fieldtrip function, this automatically calls **[[:​reference:​ft_checkconfig]]** to check the cfg you supplied. If necessary, **[[:​reference:​ft_checkconfig]]** will give you feedback. How can you control this feedback? As explained in the help documentation:​
-&lt;code&gt;+<code>
 % The behaviour of checkconfig can be controlled by the following cfg options, % The behaviour of checkconfig can be controlled by the following cfg options,
 % which can be set as global fieldtrip defaults (see FT_DEFAULTS):​ % which can be set as global fieldtrip defaults (see FT_DEFAULTS):​
Line 49: Line 49:
 %   ​cfg.trackconfig = '​cleanup',​ '​report'​ or '​off'​ %   ​cfg.trackconfig = '​cleanup',​ '​report'​ or '​off'​
 %   ​cfg.checksize ​  = number in bytes, can be inf (set max size allowed for output cfg fields) %   ​cfg.checksize ​  = number in bytes, can be inf (set max size allowed for output cfg fields)
-&lt;/code&gt;+</code>
  
 When you use a fieldtrip function, this automatically calls ft_defaults. ft_defaults is a function that takes care of path setting, plus it sets defaults to be used throughout fieldtrip. It does this by creating a global variable called ft_defaults (i.e. a variable that is available to all functions, but not directly visible to the user. You can make it visible by typing '​global ft_default'​). The variable ft_default has the following fields and default settings that pertain to **[[:​reference:​ft_checkconfig]]**:​ When you use a fieldtrip function, this automatically calls ft_defaults. ft_defaults is a function that takes care of path setting, plus it sets defaults to be used throughout fieldtrip. It does this by creating a global variable called ft_defaults (i.e. a variable that is available to all functions, but not directly visible to the user. You can make it visible by typing '​global ft_default'​). The variable ft_default has the following fields and default settings that pertain to **[[:​reference:​ft_checkconfig]]**:​
-&lt;code&gt;+<code>
 ft_default.checkconfig = '​loose'; ​ ft_default.checkconfig = '​loose'; ​
 ft_default.trackconfig = '​off'; ​ ft_default.trackconfig = '​off'; ​
 ft_default.checksize ​  = 1e5; ft_default.checksize ​  = 1e5;
-&lt;/code&gt;+</code>
  
 These settings control the behaviour of **[[:​reference:​ft_checkconfig]]**. If you want to change these settings, either do it via the global variable (this way they will apply to all fieldtrip functions and automatically be added to the cfg), or do it directly via the cfg when you call a specific function. What are the available options? These settings control the behaviour of **[[:​reference:​ft_checkconfig]]**. If you want to change these settings, either do it via the global variable (this way they will apply to all fieldtrip functions and automatically be added to the cfg), or do it directly via the cfg when you call a specific function. What are the available options?
Line 64: Line 64:
  
 To give an example using **[[:​reference:​ft_freqdescriptives]]**,​ if your cfg contains the field '​jacknife'​ (which was used in a previous version of fieldtrip but has since been renamed to '​jackknife'​):​ To give an example using **[[:​reference:​ft_freqdescriptives]]**,​ if your cfg contains the field '​jacknife'​ (which was used in a previous version of fieldtrip but has since been renamed to '​jackknife'​):​
-&lt;code&gt;+<code>
 cfg=[]; cfg=[];
 cfg.jacknife='​no';​ cfg.jacknife='​no';​
 test = ft_freqdescriptives(cfg,​ freq) test = ft_freqdescriptives(cfg,​ freq)
-&lt;/code&gt;+</code>
 You will get the following feedback: You will get the following feedback:
-&lt;code&gt;+<code>
 Warning: use cfg.jackknife instead of cfg.jacknife Warning: use cfg.jackknife instead of cfg.jacknife
-&lt;/code&gt;+</code>
  
 In this case, you don't have to do anything: **[[:​reference:​ft_checkconfig]]** will rename the field for you, and **[[:​reference:​ft_freqdescriptives]]** can do its job. Of course the idea is, that you will use this feedback to improve your scripts! In this case, you don't have to do anything: **[[:​reference:​ft_checkconfig]]** will rename the field for you, and **[[:​reference:​ft_freqdescriptives]]** can do its job. Of course the idea is, that you will use this feedback to improve your scripts!
Line 85: Line 85:
   * **cfg.checksize:​ number in bytes, can be inf**   * **cfg.checksize:​ number in bytes, can be inf**
 This determines the maximum size allowed for output cfg fields (i.e. the data.cfg). Some fields in the output cfg can be very large, e.g. the cfg.grid field when you do sourceanalysis. To avoid that several MBs or even GBs of your disk space are taken up by the data.cfg, you can set a maximum and **[[:​reference:​ft_checkconfig]]** will empty all the cfg fields that are too big, before adding the cfg to the data. Crucial fields such as the cfg.trl and cfg.event will never be removed ((currently,​ the following fields are ignored: '​checksize',​ '​trl',​ '​trlold',​ '​event',​ '​artifact',​ '​artfctdef',​ '​previous'​)). The default is set to **100000** bytes, but you can change this to anything you want. If you do not want any fields to be removed, set checksize to **inf**. This determines the maximum size allowed for output cfg fields (i.e. the data.cfg). Some fields in the output cfg can be very large, e.g. the cfg.grid field when you do sourceanalysis. To avoid that several MBs or even GBs of your disk space are taken up by the data.cfg, you can set a maximum and **[[:​reference:​ft_checkconfig]]** will empty all the cfg fields that are too big, before adding the cfg to the data. Crucial fields such as the cfg.trl and cfg.event will never be removed ((currently,​ the following fields are ignored: '​checksize',​ '​trl',​ '​trlold',​ '​event',​ '​artifact',​ '​artfctdef',​ '​previous'​)). The default is set to **100000** bytes, but you can change this to anything you want. If you do not want any fields to be removed, set checksize to **inf**.
 +
 ===== How to use trackconfig to figure out which options were and were not used ===== ===== How to use trackconfig to figure out which options were and were not used =====
  
Line 211: Line 212:
 </​code>​ </​code>​
  
-This way **[[:​reference:​ft_checkconfig]]** will run recursively through the entire data.cfg, including all the previous fields, and empty the fields that are larger than the specified maximum. This can be used on all fieldtrip data.+This way **[[:​reference:​ft_checkconfig]]** will run recursively through the entire data.cfg, including all the previous fields, and empty the fields that are larger than the specified maximum. This can be used on all fieldtrip data.