“Pressure-sensitive” valve are valves that automatically move themselves to control some system pressure. They self-actuate pneumatically – using the error in control pressure to move the valve. This creates a closed feedback loop between the valve position and pressures that can be unstable if not tuned properly. We have 3 types of these valves:

• GunnsFluidRegulatorValve:
  • Also called a “pressure reducing valve”
  • Given a high inlet pressure, supplies lower-pressure flow the downstream system
  • Regulates the pressure given to the downstream system within a configurable range of pressures.
• GunnsFluidReliefValve:
  • Similar to a regulator, except prevents over-pressurization at its inlet by opening up to dump flow overboard.
  • Maintains its inlet pressure within a configurable range.
  • Can also model a “back-pressure reducing valve”
• GunnsFluidCheckValve:
  • Valve that only allows one-way flow by opening for a forward pressure gradient and closing for a negative pressure gradient.
  • Similar to a relief valve.

When not tuned properly, these models tend to exhibit two undesirable signatures that are not necessarily realistic: “chatter” and “overshoot”. Both effects can also occur in the real world, but GUNNS tends to exaggerate them and they happen for different reasons.

Valve chatter is a high-frequency vibration and oscillation in valve position, with corresponding noise in the fluid pressure and flow. In the real-world, valve chatter happens because of physical things like the vibrational modes of the valve mechanism, which are not modeled in the GUNNS valve. In GUNNS, chatter happens because the valve model responds to the last pass of the discretized system state, creating a laggy feedback loop that is inherently unstable. This instability is exacerbated by longer execution time step, small line volumes to absorb the valve though-flow, and large flow rates.

The chatter frequency also differs between GUNNS and the real-world. In GUNNS, it is a factor of the model execution frequency, whereas in the real-world it is related to the vibrational modes of the hardware.

In the real-world, chatter is undesirable because it wears out the valve and the noisy pressure & flow can mess with exposed systems. In GUNNS, chatter is undesirable because it’s unrealistic and makes sections of the network noisy. Valve chatter in GUNNS is a false signature and is not predictive of real-world chatter. Therefore we usually try to tune it out altogether.

Overshoot happens in both GUNNS and the real-world when the valve can’t respond fast enough to a sudden change in pressure, and the line volume pressures drift outside the valve’s control range before it can re-establish control.

Here’s what chatter and overshoot look like in GUNNS:

Both chatter and overshoot are made worse by the following:

• High flow rate through the valve
• Low nearby volumes to absorb the flow
• Low model execution rate
• Valve travel speed. Lowering the speed worsens overshoot, but raising it risks chatter.

All of the above causes can be adjusted by model tuning and set-up. So to tune these valves, adhere to the following:

• A common mistake is giving the value too much conductivity. This makes flow rates too high — flow rates and pressures are too sensitive to small changes in valve position. Only give the valve enough conductivity to flow how much it needs to at a known pressure drop. Lowering the conductivity can help reduce chatter and overshoot.
• Increasing the volumes of the valve’s pressure port nodes is an easy way to reduce chatter and overshoot. Sometimes you may have to give unrealistically large volume — more than the real system has at that location. This may be an acceptable compromise for you.
• Increasing the execution rate is a very expensive option CPU-wise, but it can help reduce chatter and overshoot.
• Adjust the valve’s travel speed in the mRateLimit term, and search for a value avoids both chatter and overshoot.

Here is the same system as above, but re-tuned to avoid chatter and overshoot:

Previous Page / Next Page