I’m using the Java JNI bridge for Pulse and I would like to have some clarification about Data Requests in general.
It seems to me that there are 2 ways to create a Pulse Engine instance:
- By providing a Patient, Conditions and Data Requests
- By providing a previously serialized instance and the Data Requests
The part that I don’t fully understand is why do we have to pass the Data Requests when creating an instance from a previously serialized engine. The serialized data already has the Data Requests in it. My thought was that we could use a different set of Data Requests when deserializing an engine, but that doesn’t appear to be the case. When deserializing an engine, Pulse seems to expect the same Data Requests (or maybe a subset of them) that were used in the serialized version.
In my scenario, we are creating a Pulse Engine instance for a patient, serializing it and then creating multiple Pule Engine instances based on it. This way we don’t have to wait for Pulse to be stabilized each time we want to run a simulation. The problem here is that because a single serialized engine instance can be used in multiple simulations (with different data requirements), and because the Data Requests cannot be changed when deserializing an engine, I’m kind of forced to create the initial version of the engine with ALL the supported Data Requests enabled. Is there any penalty in doing this?
So, summarizing, my questions are:
1.- Why do we have to provide a list of Data Requests when deserializing a Pulse Engine instance if it seems that you have to use the same Data Requests that were used when the Pulse Engine was serialized in the first place?
2.- When deserializing a Pulse Engine, can I provide a subset of the Data Requests used by the Pulse Engine that was serialized?
3.- Does the number of Data Requests affects the performance of the engine in any way? It is the same to have an engine with 1 Data Requests or with 50?
Can you specify what build of Pulse you are using?
This was not intended.
The state file does contain the data requests
If you provide new data requests, those should be overwritten with what you provide
If that is not the case, I need to have that fixed
I am unsure what you are asking. Would you like to save the state with a different set of data requests, so they are used the next time you load the state? If I fix the error to properly replace data requests with the ones provided on the serialize from file/string method, would you still need this?
I am sure there is a penalty, but I believe it would be very little. Pulse calculates EVERYTHING it can, every time step. And the data requests have pointers to the scalar objects they are assigned to. SO the extra time would be in the iteration to pull the already calculated value from the pointer and put it into an array and pass that array back over to java. Maybe that would include math to convert the value to the unit you requested it in.
I will look more into question 1.
But I suggest you take a look at the latest 3.x branch.
We have greatly refactored the Java interface to match our Python and C# interface, which dramatically changes how you will pull data in Java
This problem may already be fixed on that branch as well.
FYI, I am not sure how I missed this post
I just got an email about it today.
I am not sure what happened
Sorry this has taken so long to get a response
Thank you for your clarifications. I’m currently working on a kind of outdated build of Pulse I guess. The version I’m using is based on this commit: 42cf1b8880eda6ef0c8ec6a18e752e0de9483fe9 (2020-04-22). In the tests I did, I was not able to provide a different set of Data Requests (completely new set or a sub-set of the original set) when deserializing a state. If I tried to do that I got an error from the engine telling me that the Data Request was unknown.
In my ideal world, I should be able to create an Engine instance without any Data Request, serialize it, and then deserialize it multiple times using different Data Requests each time.
I’ll try to update my code to use a newer version of Pulse, but I think the changes you introduced for the multiplexed ventilator will brake part of my code.