feat: simulate and query multiple models

[gurdeep330]

For authors

Description

T2Bdemo3.mp4

This PR introduces the capability to simulate and query multiple models within T2B. Key updates include enhancements to the state key dic_simulated_data, which now stores the results of all simulations conducted by the user. The structure of dic_simulated_data has been updated to hold a list of dictionaries, each containing simulation data the following keys:

• name: A unique identifier assigned to the simulation by the LLM.
• source: Indicates whether the model was uploaded by the user or loaded from the BioModels database.
• data: The simulation results associated with the model.
• tool_call_id: A unique identifier automatically assigned to the tool simulate_tool when the simulation request was made.

With this update, the LLM can leverage the state key dic_simulated_data to retrieve results from previous simulations. This enables answering user queries about specific simulations and generates custom plots.

The demo provided illustrates these updates in action.

Fixes # (issue) NA

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests you conducted to verify your changes. These may involve creating new test scripts or updating existing ones.

• Added new test(s) in the tests folder
• Added new function(s) to an existing test(s) (e.g.: tests/testX.py)
• No new tests added (Please explain the rationale in this case)

Checklist

• My code follows the style guidelines mentioned in the Code/DevOps guides
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (e.g. MkDocs)
• My changes generate no new warnings
• I have added or updated tests (in the tests folder) that prove my fix is effective or that my feature works
• New and existing tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

For reviewers

Checklist pre-approval

• Is there enough documentation?
• If a new feature has been added, or a bug fixed, has a test been added to confirm good behavior?
• Does the test(s) successfully test edge/corner cases?
• Does the PR pass the tests? (if the repository has continuous integration)

Checklist post-approval

• Does this PR merge develop into main? If so, please make sure to add a prefix (feat/fix/chore) and/or a suffix BREAKING CHANGE (if it's a major release) to your commit message.
• Does this PR close an issue? If so, please make sure to descriptively close this issue when the PR is merged.

Checklist post-merge

• When you approve of the PR, merge and close it (Read this article to know about different merge methods on GitHub)
• Did this PR merge develop into main and is it suppose to run an automated release workflow (if applicable)? If so, please make sure to check under the "Actions" tab to see if the workflow has been initiated, and return later to verify that it has completed successfully.

[gurdeep330]

@dmccloskey
I will update the Jupyter notebooks once we have the parameter scanning and steady-state analysis and get annotations tools implemented next week. I have opened an issue for it #72 (comment)

[dmccloskey]

Nice implementation taking advantage of the shared state to record and recall simulation results. The implementation sets us up to move a key-value store to persist the results over different user sessions in the future.

[github-actions]

🎉 This PR is included in version 1.9.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀