Interactive Scenarios Question

BioGears newbie here. What is the best way to create interactive (i.e., human-in-the-loop) scenarios using the BioGears SDK? I have looked at the how-to programs that are bundled with the SDK, which seem to be good examples of creating scenarios completely within source code. I have also looked at some of the example XML scenarios, and I see that there is an ExecuteScenario method in the PhysiologyEngine class. Suppose, though, that we wanted to have a pre-programmed XML scenario that the user could then interact with? For example, the XML file would indicate that a hemorrhage occurred with certain properties at a certain time, and then the user would perform some actions to stop the hemorrhage. Any help is appreciated. Thanks!

Best Answers

  • abrayabray Entry Level
    Answer ✓
    A scenario is a static execution of the engine, which means it will execute all the actions provided in the scenario and then the engine will stop.
    If you want any kind of interaction with the engine, you will need to control the execution of the engine so that you can pass in any kind of user interaction to the engine via the ProcessAction call.

    To set up a dynamic engine, you just instantiate an engine object, initialize it with the patient file you want.
    In your case you would then create a Hemorrhage action for the engine to process.
    Then you have to keep advancing time, while waiting for any user input.

    We don't have any way (as of now) to Initialize an engine instance with an XML file, that you could then get control of and manually advance time and feed it actions with, but it would not be too difficult to create that type of engine harness.

    I think the key thing to understand is that you need to control the advancement of time for the engine. It would be best if you controlled it from the instantiation of the engine and through out it's lifetime.

    Note that when you call InitializeEngine, it can take several minutes for the engine to come to a steady state and be ready for actions (including advance time), so you may want to create a function that creates, initializes the engine, and processes your standard hemorrhage action. Then wait to advance time until you are ready to present the hemorrhage to the end user, then advance time until either the patient dies or the user accomplishes the goal

    Let me know if that helps or you have any other questions
  • abrayabray Entry Level
    Answer ✓
    I agree with your approach and it does seem that BioGears is running pretty slowly on your hardware.
    The 3.0 release is running at about half real time on most of the machines I have run it on (which I admit is not that many). I have an I5 surface pro (1.9GHz) that I have run BioGears on and it takes about 5.7s of real time to simulate 10s, so a little over half real time. It could be your hardware, it could be your API usage (but that sounds right, or you could be doing something that I just need to optimize)

    In any case, what kind of hardware are you running on?

    A good benchmark to run would be the BioGearsScenarioDriver.exe found in the toolkit download.
    (At least then, we are running the same code and we can evaluate against your hardware.)
    If you could open a command prompt in the toolkit directory and run:
    BioGearsScenarioDriver.exe ./Scenarios/Basic/Basic1.xml
    It will output some timing metrics.
    (Note this is a C++ executable, no Java code associated)


  • Thanks for your feedback - I think that's what we expected.

    I have a follow-up question regarding advancement of time for the engine. In our application, suppose we wish to run the simulation at 30Hz. Our thought was to perform any processing that we need to perform during each frame, and then advance the engine by 33 milliseconds. However, advancing the engine by this amount seems to take longer than we expected. In our testing, it takes about 27-30 ms to advance the engine by 33 ms, which doesn't leave us much time to perform whatever additional processing that we need to perform during each frame.

    Is this what you would expect to see? Is our hardware just not sufficient enough to do what we are trying to do? Or maybe we just don't have a good handle on how the advancement of the engine time is supposed to work? Really what we're looking to do is to figure out a way to keep the engine time in sync with the "real world" time, since this will be a human-in-the-loop system. Any help is appreciated. Thanks!
Sign In or Register to comment.