Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

AugmentCmd should be clamped to [0.0..1.0] #1089

Closed
1 of 3 tasks
cbirkhold opened this issue May 18, 2024 · 5 comments
Closed
1 of 3 tasks

AugmentCmd should be clamped to [0.0..1.0] #1089

cbirkhold opened this issue May 18, 2024 · 5 comments
Labels

Comments

@cbirkhold
Copy link
Contributor

I'm submitting a ...

  • bug report
  • feature request
  • support request => Please do not submit support request here, see note at the top of this template.

Describe the issue
AugmentCmd should be clamped to [0.0..1.0] as is documented modulated afterburner command (0.0 to 1.0) and based on how it is applied:

double tdiff = (MaxThrust * MaxThrustLookup->GetValue()) - thrust;
thrust += (tdiff * AugmentCmd);

What is the current behavior?
AugmentCmd may assume values > 1.0 if the provided ThrottlePos is sufficiently large => thrust may exceed limits.

What is the expected behavior?
AugmentCmd should be clamped to [0.0..1.0]

What is the motivation / use case for changing the behavior?
Consistency with documented behavior.

@cbirkhold
Copy link
Contributor Author

#1090

@dpculp
Copy link
Collaborator

dpculp commented May 18, 2024

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?

@bcoconni
Copy link
Member

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.

@cbirkhold
Copy link
Contributor Author

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.

@bcoconni
Copy link
Member

@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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants