AllenNeuralDynamics / AllenNeuralDynamics/Aind.Physiology.Fip

Consider splitting "task" from "rig" configurations

Ouverte
#47 1 commentaire 0 réactions 1 personne assignée Réclamée par @bruno-f-cruz Voir sur GitHub
Langage dominant
C#
Étoiles
0
Forks
0
Merge moyen
15 j 20 h
PR mergées (30 j)
1

Description

For the current preview version, we decided to merge all specifications at the level of the rig configuration schema:

https://github.com/AllenNeuralDynamics/Aind.Physiology.Fip/blob/e1765c8d54348ad16adfeb3065f326dbf142f231/src/aind_physiology_fip/rig.py#L125

However, a few edge cases suggest the domain is not being properly understood/modelled. A few pain points come to mind:
1. We may want to decouple AVAILABLE region-of-interest definition from which rois are currently being used. This could be achieved by keeping the ROI definition as it is (fully backward compatible) while, additionally, allowing the specification of which rois are enabled (see https://github.com/AllenNeuralDynamics/Aind.Physiology.Fip/issues/40#issuecomment-3598944952 for additional details). This would allow a rig configuration to exist, and be shared across multiple subjects, experiments and experimenters, while still allowing individuals to store a "planned" task/measurement (identical to what currently happens with the task logic for the behavior component of the experiment).
2. Laser power. As it stands, both laser calibration and power specification is specified in the rig schema (https://github.com/AllenNeuralDynamics/Aind.Physiology.Fip/blob/e1765c8d54348ad16adfeb3065f326dbf142f231/src/aind_physiology_fip/rig.py#L109-L110). There are cases where one would ideally keep the calibration static and want to use different powers for different experiments (e.g. somatic vs axon imaging) or different animals (e.g: to accommodate slightly different levels of expression of the indicator). One way to go about this is to move the "power" to the task as well, while keeping the calibration in the rig schema. One could make this backward compatible by using the current "power" as a fallback (currently defaults to 0 to be safe) if the task does not specify any other power.

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.