AugmentCmd should be clamped to [0.0..1.0] about jsbsim HOT 5 CLOSED

#1090

from jsbsim.

Sounds like a good check. When I wrote that bit I didn't think a user would expand the throttle command more than 2x, which results in the afterburner range using the last half of throttle movement. In practice however a user may expand the throttle command by any factor. Perhaps a clamp is needed on the expansion factor, or perhaps the expansion factor can be hard coded to 2?

from jsbsim.

On my side, I'd be reluctant to include this change following the drama of the mixture of piston engines (see issue #1037) and would rather update the docs in the same way than we did for PR #1048. Especially since I can't see any misuse of the current code that could go badly wrong (segfault, errors, un-physical behavior, etc.). But that's just my 2 cents.

from jsbsim.

Definitely not an issue on the level of a crash but the current implementation can result in thrusts being produced that are larger than what the turbine is configured to be able to provide in the current conditions which could be viewed as un-physical behavior?

To avoid conflict with potential future augmentation modes, rather than clamping the augmentation range for all modes, the clamping could be done at the point(s) where the thrust is calculated for 'augmentation method two' - this avoids a general limit on the expansion factor.

  double tdiff = (MaxThrust * MaxThrustLookup->GetValue()) - thrust;
- thrust += (tdiff * AugmentCmd);
+ thrust += (tdiff * std::min(AugmentCmd, 1.0));

Note: This change applies to two locations in Trim() and Run() respectively.

#1090 is updated to reflect this.

from jsbsim.

@cbirkhold since I was the only one to object and since @dpculp agreed with your proposal, the PR is now merged. And thanks for the update of your PR following my comment.

from jsbsim.