What "Configurations" belong in StimulusEpoch

[bruno-f-cruz]

Currently, StimulusEpoch accepts the following types:

    configurations: DiscriminatedList[SpeakerConfig | LightEmittingDiodeConfig | LaserConfig | MousePlatformConfig] = (
        Field(default=[], title="Device configurations")
    )

I am a bit confused as to why some of these are elevated above other seemingly similar configurations (e.g. ScreenConfig, TreadmillConfig, OlfactometerConfig, ManipulatorConfig, ....)

This makes it somewhat confusing to know what to add to the schema since there are clearly additional active devices in the experiment, but their configuration cannot be added since the union is discriminated.

[dbirman]

Yes, stimulus information in general in the metadata needs improvement. I think convening a group to meet once or twice to discuss how we want to deal with this would be good. In the meantime, if we want any StimulusEpoch.configurations it's a non-breaking change to create new ones and add them in. We're doing this with OlfactometerConfig which will get added in the 2.1 release. You can also continue doing what we did in 1.0 and put stimulus information as parameters in the StimulusEpoch.code.

If there's stimulus device metadata that is changing across epochs and meets our bar for inclusion (either "this metadata is needed to properly interpret the data asset for analysis" or "this metadata is needed to make the asset searchable") we should create appropriate configurations and add them to the union..

[bruno-f-cruz]

Ok so maybe practical examples are more useful. Most of the tasks that I develop operate on top of an asynchronous structure where sensors and actuators can occupy a wide variety of states at any given point in time. The way that I look at it, the "configuration" is not metadata but instead data. For instance, for the treadmill, at any given point in time (well any "site" in our vr-foraging task) the friction can change. Sometimes it may even change in stochastic ways (if the value is drawn from a distribution). As a result, what we do is log the value as data that can be analyzed later.

However, in our task, this is EXACTLY the same for sound, contrast changes, odor delivery, etc... So if everything is the same, why are some "worthy" of being elevated in the data schemas while others are not? Should I simply not define the speaker at all and rely on data to extract relevant stimulus information? Or, alternatively, should we model each site as a different epoch and end up with 1000s epochs in our metadata?

[saskiad]

things that are being controlled programatically should be represented in the parameters of the software.
Things that have settings that are being set (e.g. laser wavelength and power) should be in a config.

[saskiad]

should we model each site as a different epoch and end up with 1000s epochs in our metadata?

Absolutely not. Trials are not metadata - they are data.

[bruno-f-cruz]

Thanks! This distinction helps a lot! - and it makes our life easier, since most (if not all) configurations are being set programatically and not manually, and the parameters are already being pushed as parameters of the code.

Out of curiosity, why is this approach different when it comes to Calibration? As I mentioned in #1535, in our case, the line between calibration and configuration is very often blurred from the point of view of the control software. Since calibration is something that doesn't get entered manually, and the Code ALWAYS knows about it to instantiate an experiment, why should we duplicate it as a Calibration instead of giving it the same treatment as you are suggesting for a <...>Config?

For a practical example, water calibration MUST always exist in our code configuration; there is no way an experiment will run without it being defined in the Code parameters.

[saskiad]

If every system worked that way, we'd maybe handle configurations differently.