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:

Privacy Notice