# Large MWorks datafiles **URL:** \ **Category:** Support\ **Created:** [July 21, 2014, 3:48pm UTC](https://mworks.discourse.group/t/large-mworks-datafiles/567 "2014-07-21T15:48:20Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [July 21, 2014, 3:48pm UTC](https://mworks.discourse.group/t/large-mworks-datafiles/567/1 "2014-07-21T15:48:20Z")
Hi Chris, I just tested my program (the two reflection timing task), and I’ve discovered that the file sizes are very large. A run of 1000 trials is about 600mb without any eye data. I checked out the event stream and it looks like every attribute of every stimulus is being recorded each time the position of the moving stimulus changes. Is it possible to reduce the amount of non-changing stimulus information that’s recorded? Thanks, Evan ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [July 22, 2014, 1:38pm UTC](https://mworks.discourse.group/t/large-mworks-datafiles/567/2 "2014-07-22T13:38:14Z")
Hi Evan, The only option you have for reducing the amount of stimulus announcement data is to disable individual stimulus announcements. To do this in recent nightlies, navigate to “MWServer → Preferences → Display” and uncheck “Announce stimuli individually via #announceStimulus events”. Alternatively, in your setup\_variables.xml, set the `announce_individual_stimuli` key of `#mainScreenInfo` to 0. Once this is done, stimuli will only be announced in `#stimDisplayUpdate` events. Cheers, Chris ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [July 22, 2014, 3:31pm UTC](https://mworks.discourse.group/t/large-mworks-datafiles/567/3 "2014-07-22T15:31:48Z")
Hi Chris, That will be fine. Thanks! - Evan ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [July 23, 2014, 8:42pm UTC](https://mworks.discourse.group/t/large-mworks-datafiles/567/4 "2014-07-23T20:42:44Z")
Hi Chris, Turning off accounce\_individual\_stimuli shrinks the data file by about half, which still isn’t really manageable. Testing the same program without the frame list stimuli further reduces the file size by about a factor of 15. Would it be feasible to program an option not to include information about display/stimulus updates driven by dynamic stimuli? - Evan ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [July 25, 2014, 6:18pm UTC](https://mworks.discourse.group/t/large-mworks-datafiles/567/5 "2014-07-25T18:18:10Z")
Hi Evan, > Would it be feasible to program an option not to include information about display/stimulus updates driven by dynamic stimuli? Yes, we could do that. I think the right approach would be to distinguish between explicit updates (i.e. those initiated via an “Update Stimulus Display” action) and implicit updates (e.g. those requested by a dynamic stimulus). We could then provide a per-experiment setting to omit the list of stimulus parameters in `#stimDisplayUpdate` events for implicit updates. Hence, for implicit updates, display update events would include only a timestamp. Implementing this would be pretty easy. However, the availability of such an option is going to make some people (e.g. Jim) nervous. Having the event file record _everything_ that happens in an experiment is an explicit design decision that dates back to the earliest days of MWorks. The reasoning is that the cost of running experiments is much, much greater than the cost of data storage, so it’s better to store data you may not need than to run the risk of discarding data you _do_ need (perhaps for some future, not-yet-thought-of analysis) and having to re-run your experiment. That said, I actually just chatted with Mehrdad about this, and he sounds comfortable with the approach I described. He made the argument that as long as you have the starting stimulus parameters and display update times, you can recreate the stimulus presentation after the fact. So if this approach sounds acceptable to you, I’ll add it to my to-do list. Cheers, Chris ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [July 25, 2014, 7:31pm UTC](https://mworks.discourse.group/t/large-mworks-datafiles/567/6 "2014-07-25T19:31:54Z")
I guess my response would be that the only thing I really care about is having manageable file sizes and at least being able to reconstruct the experiment as Mehrdad mentioned. How it’s implemented isn’t such a big deal, although I can think of a few different ways it could work. For instance, every #stimDisplayUpdate event contains a cell of _all_ the the stimuli displayed on that update, along with \*all \*their parameters, even if only one parameter in one stimulus changed. In my case, there are about 7-10 stimuli on the screen at a time, so if MWorks only logged the parameters of the changing stimulus, the size of the #stimulusDisplayUpdate data would be reduced by almost an order of magnitude, without losing any information. That being said, Mehrdad’s solution works for me. But it does omit parameter information, which as you mentioned conflicts with one of the core MWorks philosophies. - Evan ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [September 5, 2014, 8:45pm UTC](https://mworks.discourse.group/t/large-mworks-datafiles/567/7 "2014-09-05T20:45:42Z")
Hi Evan, > I think the right approach would be to distinguish between explicit updates (i.e. those initiated via an “Update Stimulus Display” action) and implicit updates (e.g. those requested by a dynamic stimulus). We could then provide a per-experiment setting to omit the list of stimulus parameters in #stimDisplayUpdate events for implicit updates. This solution is now implemented and will be available in the nightly build shortly. To disable stimulus parameter announcements for implicit display updates, your experiment must contain a `stimulus_display` device (which the editor includes by default in new experiments), and its `announce_stimuli_on_implicit_updates` parameter must be set to “NO”. When emitting `#stimDisplayUpdate` events for implicit updates, MWorks will omit the list of stimulus parameters and instead report a single integer, which represents the number of stimuli displayed during that update. Hopefully, this will keep your event files down to a reasonable size. If you have questions or run in to any issues, please let me know. Cheers, Chris ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [July 19, 2022, 10:58pm UTC](https://mworks.discourse.group/t/large-mworks-datafiles/567/8 "2022-07-19T22:58:16Z")