Internally, Pulse uses a 0.02s step size. I’m interested in increasing this to see if we can make pulse run faster. I realize this will degrade the accuracy, but it may be that there is a sweet spot for our purposes where the accuracy is good enough but pulse runs significantly faster.
While the SEScalarTime object that holds the step size is mutable, I don’t see a way to access it to change it, or to set a different default. Is there a way to do this without rebuilding? (I don’t mind rebuilding, but it’s nice not to have to.)
In that same place I also see that m_AllowDynamicTimeStep is set to Off. What does this flag do and is that something else I should explore to increase performance?
We had a previous project where we analyzed and identified several key updates we could do in Pulse to speed up the engine.
Increasing the time step was one of them.
I updated the engine to ensure all of our models calculate using the specified time step value
So you can set the time step you want in a configuration object, or scenario, and Pulse will execute each time step at that time interval. In our study, we found that, if you are ok with not getting high fidelity waveforms, you can run with a time step at most of 0.06s, anything above that gets pretty unreliable. I think 0.04s was pretty ok.
To enable the AllowDynamicTimeStep, you can find that flag in your state json file, or you can add it to that json in the configuration object, which would look similar to the json in the BasicStandard file linked above.
Then, what that does, is any time value you provide to this AdvanceModelTime method, that time is the time step it will use, so don’t ever advance with anything higher than 0.06s. Subsequent AdvanceModelTime calls will still use that time step. I currently don’t have a way for you to easily change that as you are running outside of C++. I think the best you could do is run 0.06s steps when the patient is stableish, then 0.02 when lots of trauma stuff is going on, then once somebody stabilizing/treats the patient, kick back up to 0.06 steps.
Again, there were several other improvments we could implement to quicken how long Pulse takes to calculate each time step besides changing the time step. But only the time step change is close to being usable, but that still needs some interface additions to really be easy to use.
Best you can do now is see if you can experiment with with some scenarios and their time step and how that affects the results.
This is super helpful! It looks like I can’t set the configuration object from Java, although the project that wants to do this is actually using Python (it’s different than the one I usually work on) – is it available there? But setting it in the scenario is easy, so that’s good enough for our purposes. The dynamic stuff sounds interesting – if we want to try that, we can rebuild the C++ to turn it on.
Engine configuration is currently only supported for engine initialization, not if you load a state. We haven’t exposed a way to do this dynamically yet.