AddingAindBehaviorTaskLogicModel

[micahwoodard]

Pull Request instructions:

• Please follow the update protocol
• Answer the questions below in detail. Your responses will be emailed to experimenters.
• If the experimenters must do anything new, provide detailed step by step instructions on the wiki
• If computer maintainers need to manually update anything, provide detailed step by step instructions
• Use markdown syntax in order for your comments to be rendered reliably in the email: "1." instead of "1)", use four spaces for indents.
• If you use the keyword "skip email" in the title, it will skip the email updates
• Merges from "develop" into "production_testing" should use the keyword "production merge" in the title for reliable indexing of updates
• Merges from "production_testing" into "main" should use the keyword "update main"

Describe changes:

• Adding AindBehaviorTaskLogicModel into framework

What issues or discussions does this update address?

• resolves Implement AindBehaviorTaskLogicModel #800

Describe the expected change in behavior from the perspective of the experimenter

• None

Describe any manual update steps for task computers

• None

Was this update tested in 446/447?

• 446/7

[alexpiet]

This looks good to me!

[micahwoodard]

I'm going to change the imports to pull from the Aind.Behavior.DynamicForaging repo. Will request review then but should really only be the import that changes as well as the pyproject.toml

[XX-Yin]

Can we move this part to a separate python file? Foraging.py is already quite large. And this part is relatively independent. The idea is to make AindBehaviorTaskLogicModel relatively independent and modular.

[XX-Yin]

It seems that the current modification logic is like this:

1. Copy parameters to behavior_task_logic_model -> update these parameters if parameters are changed
2. Copy parameters to behavior_task_logic_model -> replacing existing parameters using behavior_task_logic_model (like replacing self.warmup.currentText() using self.behavior_task_logic_model.task_parameters.warmup)

What is the entire logic and purpose here in terms of step 1 and step 2? How is this related to the curriculum?

[micahwoodard]

I don't think this is ready to merge. I prematurely thought this is what it would look like but I think this will change as I figure out how the curriculum works with this

[micahwoodard]

What is the entire logic and purpose here in terms of step 1 and step 2? How is this related to the curriculum?

For number 1, the intent was so changes in gui would be reflected in the task logic. Number 2 makes it so we are not using the gui state as a reference of how the task was run but rather a defined schema.

For how this is related to curriculum, the stages in the curriculum require a task logic model. We can adopt some of Bruno's architecture hare and leverage it in the curriculum.

[XX-Yin]

Can we create a task logic model at the end of the session? Here the step 2 is circular. For curriculum, we only need a to set the parameters? Just like what we are doing now.

[micahwoodard]

This would be a great discussion to loop @alexpiet and @hanhou into. The task parameters (same ones we are putting in the task logic model) are part of the Stage class in the aind-behavior-curriculum. In my mind, when a mouse is loaded, the gui will query slims for the trainer state of this mouse. The trainer state will include the stage of this mouse, and therefore the task parameters for the session. We can use the stage task parameters to update the task logic model and this is what the gui will use to set up and run the session. If a mouse is loaded in, that will disable the task parameter widgets so mice are limited to the session outlined in slims. Integrating the task logic model and using it to run a session rather than the widgets will make it easier to use the trainer state from slims and also provides better documentation on how the session was run. That is the workflow and benefits as I see them. If we're not all on the same page, let me know and I can update my approach

[alexpiet]

Yes, thats right @micahwoodard. The task parameters will already be determined at the start of the session by the curriculum, so we should make the task model at the start of the session.

[hanhou]

This would be a great discussion to loop @alexpiet and @hanhou into. The task parameters (same ones we are putting in the task logic model) are part of the Stage class in the aind-behavior-curriculum. In my mind, when a mouse is loaded, the gui will query slims for the trainer state of this mouse. The trainer state will include the stage of this mouse, and therefore the task parameters for the session. We can use the stage task parameters to update the task logic model and this is what the gui will use to set up and run the session. If a mouse is loaded in, that will disable the task parameter widgets so mice are limited to the session outlined in slims. Integrating the task logic model and using it to run a session rather than the widgets will make it easier to use the trainer state from slims and also provides better documentation on how the session was run. That is the workflow and benefits as I see them. If we're not all on the same page, let me know and I can update my approach

Agreed.

[XX-Yin]

" We can use the stage task parameters to update the task logic model and this is what the gui will use to set up and run the session."

Why do we need to use the stage task parameters to update the task logic model and then update the GUI parameters instead of updating the GUI parameters directly?

[micahwoodard]

@hanhou @alexpiet Would the idea be to use only the task logic parameters instead of the TP_ parameters to run a session? So we're not updating the gui parameters, but we're only using the task logic parameters to run the session, increasing readability and reproducibility of code.

[micahwoodard]

Okay this is ready for rereview using external task logic repo, using pythonic naming conventions, and replacing widgets and TP parameters with task logic. I also changed the LineEdits to Spinboxes when applicable to simplify logic