Accessing current hemorrhage severity for a compartment

I have a system where multiple different parts of my application may contribute to the severity of a hemorrhage in a single pulse compartment (e.g., at the application level, the patient may be hemorrhaging from the chest and abdomen, but in pulse these both map onto skin+muscle). Is there a way to access the current hemorrhage severity for a compartment? I’m planning to track it myself, but for unit testing that tracker it would be nice to get access to the severity directly from the pulse engine.

It looks like in the C++ interface the GetActionManager() method can give access to the current actions, which sounds like it would work. Unfortunately, I’m using the Java interface, and I don’t see how to access it from there.

Yep, you can get that information from the C++ interface pretty easily. I am currently investigating ways to get more of these type of details out of the C style interface (which serves Java, C#, python).

I also need to get out assessments, and conditions, actions, and also support dynamic data requests (so you can request the current flow of a hemorrhage)

I’m hoping to be able to have this working in the next few weeks.

1 Like

In the past I’ve used SWIG to automatically generate interfaces for other languages for C++ code. Might be something to look into.

FYI, this is working on the latest 3.x branch, and will be in the 3.2 release in the next few weeks!

You can get the compartment hemorrhage rate/volume by creating a data request, or getting the active actions from the engine.

I have NOT (but I can) add support to ‘add’ to the data requests.
So you could dynamically add a new data request for a new hemorrhage if you got that in your system
Which would update the length of the data array… and what not
Not done, but doable…

I tried getting the active actions and got this error:

java.lang.UnsatisfiedLinkError: 'java.lang.String com.kitware.pulse.engine.PulseEngine.nativePullActiveActions(long, int)'
	at com.kitware.pulse@3.1.0/com.kitware.pulse.engine.PulseEngine.nativePullActiveActions(Native Method)
	at com.kitware.pulse@3.1.0/com.kitware.pulse.engine.PulseEngine.getActiveActions(PulseEngine.java:380)

I’m building from commit 4519dc8e76e5c533b269fdf399ffd5fe94d7eb64 (head of the feature/serialization_testing branch, which appears to be ahead of the commits where these changes were made).

Are you running the HowTo_EngineUse.java and crashing here?

I am able to run this and get actions back with the latest (like as of right now)

So, I’m actually running a different bit of code now, and using the latest commit in the repo (cbb7016a), I’m running into a more fundamental problem.

boolean success = this.pulseEngine.serializeFromFile("path/to/patientState@0.json", new SEDataRequestManager());

This works fine in 3.1.0 (via Java interface), but in the latest it returns false and this error gets logged:

[ERROR] [2021-03-18 11:58:28,773] [main] [CppPulseEngine]  : [0(s)] Unable to load data requests string

I tried actually putting requests in the request manager, but I get the same error.

This is preventing me from getting to the part where I can actually test the pull actions stuff with the latest pulse code.

Did you regenerate the statefile with the new build?
I have been tweeking schema… could be related

That definitely seems to be part of it, because now that I’ve updated my application’s state files from the latest pulse, I get a different error message:

[WARN ] [2021-03-18 15:22:41,848] [main] [CppPulseEngine]  : [0(s)] Protobuf INVALID_ARGUMENT:(Configuration) AllowDynamicTimeStep: Cannot find field.

It turns out I was somehow not using the most recent binaries, even though I have a script to copy them over that runs automatically…but anyway, I’m able to load a patient now!

And getting the active actions works, too!

Great!

Also, so this is a kwirk of the Pulse build system

So, yes, some of the proto files have changed since your last build
We currently to not have an automated way for the build to detect that one or more proto files have changed since your last pull, and the bindings need to be regenerated at the start of our build.

You have to do this manually.
Open a command prompt in your install/bin and run the command run protoc

This will regenerate the binding files.
Then you do a full build (I build the INSTALL project)
And everything should be square with that new PulseJNI.dll

I actually ended up deleting my entire build directory and just starting over. That also seems to work :slight_smile:

haha, when in doubt
Blow up your build!

:exploding_head:

Did GetActionManager() ever get exposed to the Python interface? I’m trying to get a list of actions (hemorrhage, obstructed airway, etc.) and can’t figure out how to do it.

Thanks

It has not

What are you looking to do?
Load up a state and see what the current active actions are?

Yes, that’s exactly what I wanted to do. I’m doing some reinforcement learning and I originally thought I would need active actions… after a little more consideration, I think I can do without it.

That’s doable, to pass a list of the current actions to you.
It would not get any actions that were on then off to get to that state though
For example, you hemorrhage the patient for 10 min, then stop the hemorrhage, save out that state
You would not see the hemorrhage in that current actions list.

I have thought about having an option for an engine to cache off all actions and add that to the state
It could be lots of data (like recording all CPR compressions) but probably not in most cases…

If you pull our integration branch, there is new Log reader in python, that could be helpful, if you also keep the log used to make a state…

There is also the action data request, where you can get some data associated with an action

Generally, what we end up doing, is creating specific structures that book keep all that info during data generation. So we know what files had what patient and actions done to it when we start building a model

That log reader looks particularly useful. I’ll play with that and see where I get.

Thanks!