OpenLIFU currently provides a pipeline form treatment planning through Solution generation, hardware execution, and Run recording. Would there be interest in defining a lightweight abstraction for research workflows where observations from a completed simulation or sanitation can inform generation of a subsequent solution?
An initial implementation could remain entirely simulation/offline-oriented and make no assumptions about the measurement modality or automatic hardware execution.
Conceptually:
Protocol -> Solution -> execution/simulation -> Observation -> FeedbackPolicy -> next Solution
Potential research uses could include focal correction, aberration correction, adaptive apodization, pressure/intensity targeting, or uncertainty-guided sonication planning.
One possible design would define an Observation representation plus a policy/callback interface that proposes modifications while leaving existing constraint checking, approval, and hardware execution pathways intact.
Before working on an implementation, I'd be interested in feedback on whether this abstraction belongs in openlifu-python, whether related functionality already exists/planned, and what boundary maintainers would prefer between planning, observations, and hardware control.
OpenLIFU currently provides a pipeline form treatment planning through
Solutiongeneration, hardware execution, andRunrecording. Would there be interest in defining a lightweight abstraction for research workflows where observations from a completed simulation or sanitation can inform generation of a subsequent solution?An initial implementation could remain entirely simulation/offline-oriented and make no assumptions about the measurement modality or automatic hardware execution.
Conceptually:
Protocol -> Solution -> execution/simulation -> Observation -> FeedbackPolicy -> next SolutionPotential research uses could include focal correction, aberration correction, adaptive apodization, pressure/intensity targeting, or uncertainty-guided sonication planning.
One possible design would define an Observation representation plus a policy/callback interface that proposes modifications while leaving existing constraint checking, approval, and hardware execution pathways intact.
Before working on an implementation, I'd be interested in feedback on whether this abstraction belongs in openlifu-python, whether related functionality already exists/planned, and what boundary maintainers would prefer between planning, observations, and hardware control.