Set flow to max rate?

I’m interested in modeling extreme injuries; e.g., a leg amputation. Based on several examples related to the combat multitrauma examples, I see hemorrhage rates on a leg ranging from 70-100 mL/min. I also see that if the rate is too high, pulse will get an error because the compartment will become empty.

Rather than trial and error to see what will work for how long, is it possible to ask for a “max” rate that will automatically select the largest value that doesn’t cause pulse to error? Or perhaps a different rate that isn’t technically the max, but is the max realistic rate. Maybe dynamically adjusting over time as needed?

We do have plans to put in a hemorrhage action that will take a severity rather than a flow.
This will be a resistance based implementation that will reduce the rate as part of the circuit calculation, so the drop in blood pressure will slow the rate down automagically.

As for an amputations, @rachel.clipp can address that better than me.


Yes, we plan to add an hemorrhage action that will accept a severity or potentially an initial hemorrhage rate. Then implement that rate as a resistance rather than a flow source. This would provide natural control for the hemorrhage rate over time as the rate would be dictated by the blood pressure. Hopefully, this is coming in the next release at the end of the summer.

As for amputation, we have discussed this as well. The best option would be to remove the circuit components associated with the amputed region (the leg), these paths would then be converted to paths leading to a ground. Again this would allow the flow to be dictated by the pressure. Amputation would most likely also have some systemic effects related to the shock that would need to be implemented.

Thanks for all of the feedback.


Those both sound like great features. Looking forward to it!

Hi @rachel.clipp, I’m just following up on the self-adjusting hemorrhage and amputation features you described in May. Is there an updated status on these?

Hi Bob,

Rachel is finishing up the hemorrhage resistance branch
So far implementation is near complete and preliminary testing is looking very good.
I expect her to hand off the implementation to me for general clean up, optimization, cross language support, test suite integration, etc.
I expect this to get merged into 3.x either late next week, or the first week of Nov. if all goes well.

There is not currently an active task to implement amputation methodology. As Rachel previously mentioned, it’s implementation is something that we could very well support in Pulse, but there is not any current funding for us to concentrate on this feature at this time.

I will let you know when the hemorrhage resistance is ready for testing if you have the time!


I’d be happy to test! Thanks!

Hey @bob.marinier,

The hemorrhage resistance branch is ready to be tested

We still have one more task to adjust the HR, but the interface is all complete and everything is running well (and still valid!)

Let me know what you think!

Ok, I’m trying it!

I ran into a strange issue when I first generated the solution with cmake gui – the generated projects failed to load. I had selected the download baselines option (everything else was left at defaults). So I unselected that option and tried again, and everything was fine. Then I turned the option on and tried yet again, and everything was still fine. Perhaps just a fluke? I’m using cmake 3.18.4 and VS 2019 16.7.4. I’m also on a new machine, so I have not previously built pulse on this machine (or even had cmake installed until now). You’ll ask what the errors were, but I didn’t note them because I didn’t expect them to be resolved so quickly…

BTW, creating a debug build was a bit confusing. By default only the Release configuation was created. I had to enable to the slave build option to get the Debug and RelWithDebInfo options.

One other thing about the build – is there any way to parallelize the unzipping of the baseline files? Or avoid doing it if it’s already been done? Every time I build it wants to do that, and it takes a while.

With the build working, and switching to severity instead of rate for the hemorrhages, it appears to be working! I’m not really sure how to best translate my previous rates to severities. Originally I had these insults (intended to simulate a gunshot wound to the chest):

Type: External
Compartment: Skin
Rate: 15 mL/min

Type: External
Compartment: Muscle
Rate: 35 mL/min

Type: External
Compartment: RightPulmonaryArteries
Rate: 1 mL/min

Type: External
Compartment: RightPulmonaryCapillaries
Rate: 1 mL/min

Type: External
Compartment: RightPulmonaryVeins
Rate: 1 mL/min

Gate: Open
Side: Right
Severity: 0.7

This ran for 951.3s before getting a compartment with a negative volume.

Leaving the TensionPneumothorax the same, I changed the hemorrhages like this:

Type: External
Compartment: Skin
Severity: 0.15

Type: External
Compartment: Muscle
Severity: 0.35

Type: External
Compartment: RightPulmonaryArteries
Severity: 0.01

Type: External
Compartment: RightPulmonaryCapillaries
Severity: 0.01

Type: External
Compartment: RightPulmonaryVeins
Severity: 0.01

This ran for 948.66s before getting a negative volume, which is similar. It may be that my severities are way off, but I was expecting to avoid the negative volume issue with the switch to severities. I’m guessing that even with the negative volume issue, that the simulation up to that point is more realistic since the flow rates dynamically adjust.

BTW, I also accidentally found that a severity > 1 works (I set one of them to 152). Not sure if that’s intended.

Finally, as part of this I also updated a couple java dependencies on my end:

guava: 29.0-jre -> 30.0-jre
java-ordered-properties: 1.0.3 -> 1.0.4

These appear to work fine, so I recommend updating to these versions since it’s easier to keep up with minor version changes as they come out than making a big update much later.

Morning Bob!

Check out this page about building with MSVC
A few key points:

A superbuild contains a outerbuild and an innerbuild.
The solution generated by cmake is the outerbuild.
This build will

  1. Pull and build Eigen and Protobuf
  2. Built the Pulse source code (only in release)
  3. Generate Data by running the Pulse engine. (This is why you can only build the outerbuild in release) this would take a long time in a Debug build
  4. Pull verification data if you chose this option.

This outer build can fail in the pull of verification if it happens to time out pulling one of the many zips. Pulse has already build and generated data, so this failure is not detrimental to the build. I need to update this pull mechanism to try again if it cannot connect to the data sever… So I think I can fix this.

The latest CMake version have been a little odd lately when dealing with MSVC.
I also sometimes have to click configure/generate again if there are issues with MSVC…
Yes these are hard to track down. You did the right thing!

Again, check out that wiki page.
You should only build the outerbuild once!
Then close it down and open the Innerbuild (and build debug)
The innerbuild will not pull/unzip the baselines.
To update baselines you should manually do it via the ‘run.bat’ tool (see the wiki root)
The Inner build is the solution used in step 2 of the outerbuild. Pulse only!

Superbuilds are weird to work with.
But once you get the hang of it… it kind of makes sense!

I am going to reproduce your scenario
I also thing that we should not break the circuit
I will start investigating this.

I will also see what’s up with > 1 severity. That should not work…

Thanks for testing the latest java jars.
I will update those as part of this hemorrhage release.

Thanks for the feedback
And I will keep you posted!

Yep, I get the crash as well… investigating…
Seems to be associated with the right pulmonary arteries/caps/veins…

As for the severity > 1
The API will automatically set the severity to 1 and output this warning:
11:59:55.008 [main] WARN CppPulseEngine - Attempting to set 0-1 Scalar to greater than 1, bounding to 1

Hey Bob,

The latest changes have been pushed to our hemorrhage_resistance branch

In investigating this issue we did notice an issue associated with creating ‘tiny’ resistances (associated with the 0.01 severity) especially at locations with ‘tiny’ flows (like the pulmonary arteries/capillaries/veins). Great edge case testing!

A few items to discuss with your scenario and its execution

As part of this new hemorrhage functionality, we have added the new event:
Cardiovascular Collapse
This event will precede the mathematical errors your scenario gets.
This is basically signaling that your patient is entering a non-recoverable state (close to death).

INFO] : [118.82(s)] [Event] 118.82(s),  Patient has Antidiuresis
[INFO] : [120(s)] Current Time is 120s, it took 11.716s to simulate the past 60s
[INFO] : [122.94(s)] [Event] 122.94(s),  Patient has Intracranial Hypotension
[INFO] : [180(s)] Current Time is 180s, it took 6.989s to simulate the past 60s
[INFO] : [187.4(s)] [Event] 187.4(s),  Patient is in Hypovolemic Shock
[INFO] : [240(s)] Current Time is 240s, it took 7.103s to simulate the past 60s
[INFO] : [297.44(s)] [Event] 297.44(s),  Patient has Bradypnea
[INFO] : [300(s)] Current Time is 300s, it took 6.756s to simulate the past 60s
[INFO] : [339.9(s)] [Event] 339.9(s),  Patient has low blood pressure and the vasculature has collapsed
[INFO] : [340.3(s)] [Event] 340.3(s),  Patient has Renal Hypoperfusion
[INFO] : [344.26(s)] [Event] 344.26(s),  Oxygen tension in the brain is dangerously low
FATAL:Cant transport with a negative volume included. Node = RightPulmonaryVeins. Volume = -0.39194 mL :grimacing:

Note that death is extremely contextual and hence programming a death check is difficult to do. It’s a combination of what actions have been performed along with what events have been thrown. For example, a cardiovascular collapse during a hemorrhage is not recoverable and could be considered death. But cardiovascular collapse also occurs during cardiac arrest, which is recoverable!

Long story short, if you are using hemorrhage, you should be listening to this event and gracefully put the pulse engine to pasture when it occurs . If you keep running past this event, you will get the math error you received.

We also added 2 new system properties on the cardiovascular system

TotalHemorrhageRate - The total rate of blood loss due to all active hemorrhages.
TotalHemorrhagedVolume - The total amount of blood lost due to all hemorrhages.

Monitoring these could also be helpful

Next up is your scenario.

I am not sure if the hemorrhages at the pulmonary arteries/capillaries/veins is accurate or not, but in any event, those are behaving much happier from a mathematical perspective… Your muscle and skin bleeds, though, are a very large bleed outs.

You are saying that 15% of the body’s blood flow to the skin and 30% of the body’s blood flow to the muscles is exiting the body. I think that is ok for the skin, but I don’t think the chest is 30% of your muscle…

This is how you can get a better idea of what you are doing with hemorrhage. Table 2 of the Cardiovascular Methodology Report gives us all the healthy flows of the various compartments:

Skin In Flow = 6.3mL/s
Muscle In Flow = 16.1mL/s
You probably want ~1 to 2 mL/s bleed out from each

Which is about 1.5 / 6.3 = severity of 0.15, and 1.5 / 16.1 = severity of 0.1

I don’t think you should bleed from the pulmonary vessels. If you do your patient will not last but a few minutes, even with 0.01. The pneumothorax is really influential and adding extra pulmonary trauma is pretty harsh…

Along with the 0.7 pneumothorax, severities of 0.1 to 0.15 for skin and 0.05 to 0.10 for muscle hemorrhages really create an injured patient and this scenario runs for about 10-15m before CV collapse, which I think is about what you want…

Again, plan for and expect the patient to die. Hopefully your users will intervein before death (borked math) occurs.

I am also updating the Explorer to support the new hemorrhage severity option and will put a windows that you could use to play with hemorrhage.
(I will probably put up a windows build this weekend)

Hope this clarifies using hemorrhage
Thanks for testing!
And let us know if you have any more questions!

Thanks for all the feedback! I have confirmed I am getting the same results you showed. For the injury model, my lack of medical knowledge is definitely showing, so thank you for the pointers!

I don’t think this is related, but I just wanted to make sure (I can post a separate question if not) – my understanding is that if someone loses a lot of blood, they will eventually get hypothermia. However, I have not been able to make this happen. If I remove the lung hemorrhages and reduce the skin and muscle to 0.1 severity, the patient gets a low-grade fever, and the temperature continues to rise (slowly) until the vasculature collapse at around 29 mins in. Do you have any insight into why I’m getting a temperature rise instead of fall?

I have not explicitly modeled the temperature effects. Let me take a look this week and I will get back to you. I might be able to fix it quickly…or not. :slight_smile:

That would be great! A customer representative has identified the “lethal triad” as an important thing to model, and hypothermia from hemorrhage is part of that. While we’re discussing it, does Pulse model acidosis or coagulopathy (the other parts of the lethal triad)? I think the hypothermia might be the most important for our use case, but it would help to know the status of these others, too.


We do not model coagulopathy. We model acidosis in a limited way with it occurring in the form of respiratory acidosis and metabolic acidosis. I believe our pH reacts correctly during hemorrhage. I will look at this further when I test the hypothermia during hemorrhage. I should have more info after the holiday.


Just following up on this – does it look like the temperature effects of hemorrhage will be easy to incorporate?

Privacy Notice