Extreme axcelerations during engine start up.

[jentron]

My first thought, without looking through any code or configurations, is propeller induced velocity problems with slight tailwinds. Could you keep an eye on the environmental conditions, especially tailwinds?

[Bomber]

viewtopic.php?f=49&t=24266

The prop graphs are here..

If I recall correctly a plane spawns with the prop at the high angle and then adjusts to the low angle.

[hvengel]

bomber,

As far as I know there is nothing in my code that affects the prop when the aircraft is spawned but I suspect you are correct that by default it starts out in full course and then adjusts this to where ever the controls are set. In my setup I start the engine with the prop set to full fine so this is not affected by how the aircraft is spawned.

Ron,

Thanks for getting back to me. I just did a quick test with both a head wind and a tail wind (by starting FG using different ends of the same runway - wind speed around 15kts) and had no problems with either. Doesn't mean that this is not related to the issue since this problem is very intermittent. But the random/intermittent nature of the issue could be related to weather conditions which are constantly changing. I will keep an eye on environmental conditions when this starts happening but I have no idea when that will happen. I have gotten user reports of this issue in the past so it has been happening for some time (since at least FG 2.8 but perhaps earlier) but these reports have been very sporadic which confirms the intermittent nature of the problem.

Considering the extreme nature of the forces being generated, after all the aircraft is accelerated from 0 to mach 4 to 6 BACKWARDS in a fraction of a second when this is happening, would a tailwind cause those kinds of forces? Also this appears to be affecting the engine as well with some extremely high numbers being generated there (see the OP) and this is happening at a time when the engine is not "running". Also I notice that with a 15kts tailwind that the advance ratio is negative (around -2.7 when the starter is running but it jumps up to close to -6.0 when the starter is first engaged and then drops to around -0.25 when the engine is idling) but the prop tables only go to 0.0. Is there something going on with negative advance ratios and should the tables be extended below 0?

[jentron]

Ron,

Thanks for getting back to me.

Sorry to take so long with the replies

Considering the extreme nature of the forces being generated, after all the aircraft is accelerated from 0 to mach 4 to 6 BACKWARDS in a fraction of a second when this is happening, would a tailwind cause those kinds of forces?

It might be a bug related to the propeller induced velocity spiking under certain conditions. There are two main causes for un-physical blow-ups like this. One is division by zero or near zero causing a huge number to be generated, and the other is too slow of an integration rate on the physics model. The second is what causes the landing gear/structural blow-ups when you hit the ground too fast. The simple spring model gets stretched too far before its force is applied... oops off on a tangent.

The engine indications are largely RPM driven, and the RPM comes from the propeller model, which uses velocity (u-aero-fps, iirc) to calculate. So if the velocity spikes, so does the RPM and engine indications.

Ron

[Jabberwocky]

I had maybe a similar problem. Just at spawning my Lancaster took up enormous speed backwards. But for me it turned out it wasn't my Rolls Roye Merlin, it was gravitational power. JSB seemed to be initialized before FG even could tell where the ground was. So I kind of "fell" backwards instead of downwards. But it disappeared lately and I never really figured it out.

J.

[hvengel]

Jabberwocky,

That used to happen to me as well but it was fixed some time ago and I don't think it is related to this issue (rather I think this is related to the start up trim issues with tail draggers).

Ron,

I know about the landing gear issue and for me increasing the FDM rate helps that out a lot since the spring rate of the landing gear is adjusted more quickly. A landing that will cause a bad bounce at 120Hz will not bounce or only slightly bounce at 240Hz. So on faster hardware it makes a lot of sense to bump the FDM rate up. IRL automobiles with electronic control over suspension damping typically make damping adjustments at around 1000Hz so I think even 240Hz is still somewhat marginal. Enough OT.

Just had the issue of this thread pop up. There was a tail wind at the time. I have now turned on logging of u-aero-fps so if this happens again I will have that data. Also when looking for the /fdm/jsbsim/propulsion/engine data I do see that the data is way bad:

/fdm/jsbsim/propulsion/engine/propeller-rpm 4.536e +39
/fdm/jsbsim/propulsion/enginepower-hp 5.579e +39
/fdm/jsbsim/propulsion/engine/advance-ratio -1464622094

This is spite of the fact that the ignition was off and /fdm/jsbsim/propulsion/engine/set-running was false. I think the propeller-rpm data indicates that your theory about u-aero-fps may have merit. We will know more the next time it happens.

[Bomber]

Looking at these relationships, the BoostLossHP could be a factor.

[Johan G]

Quick questions: What are the stars? The place where things got awry? Is fttom a conversion from feet to meters?

[Bomber]

I initially had a single star outputting to the thruster...

Then fttom came along and I've no idea what it is, so I gave it a star so as someone would ask the question.

[Gijs]

First hit on Google gives:

Code: Select all

const double FGJSBBase::fttom = 0.3048;

So yes Johan, it seems to be exactly what it says it is

[jentron]

Looking at these relationships, the BoostLossHP could be a factor.

Based on...? c++ formulas can look rather messy, but BoostLossHP boils down the amount of boost supplied

Code: Select all

   double boost_factor = (( BoostMul[BoostSpeed] - 1 ) / RatedRPM[BoostSpeed] ) * RPM + 1;
...
   MAP = TMAP * boost_factor;
...
      double gamma = 1.414; // specific heat constants
      double Nstage = 1; // Nstage is the number of boost stages.
      BoostLossHP = ((Nstage * TMAP * v_dot_air * gamma) / (gamma - 1)) * (pow((MAP/TMAP),((gamma-1)/(Nstage * gamma))) - 1) * BoostLossFactor / 745.7 ; // 745.7 convert watt to hp


So we could simplify it: (thanks to Wolfram Alpha )

Code: Select all

      boost_factor = ( RPM / RatedRPM ) * BoostMul

      BoostLossHP = 0.00458021 * BoostLossFactor * TMAP *  v_dot_air *  (pow( boost_factor, 0.292786 )-1)


RatedRPM and BoostMul are constant arrays from the configuration, the array allows multi-speeds. So boost_factor is simply a product of RPM
BoostLossFactor is also a constant from the configuration.
The only variables are RPM (which comes from the thruster model), v_dot_air and TMAP.
v_dot_air and TMAP are both products of RPM, ambient air conditions and throttle position.
So we could say BoostLossHP is simply a product of RPM, ambient air conditions and throttle position. If those three are right, there is no magic to make it fail.

There are several important arrows missing from your chart.

You have HP -> Thruster but you missed Thruster -> RPM and RPM -> MeanPistonSpeed_fps <- [Stroke from XML]

[Bomber]

I didn't miss them off, they don't belong on this diagram....

They belong on the meanpistonspeed diagram, and will appear when I get to it.

Nice to hear from you tho.

[hvengel]

I have looked at BoostLossHP after these failures and it is always a small reasonable number (like 1.5 - don't currently set the BoostLossFactor).

Considering that the failure can happen even when the engine is in a state where it can not run (ignition off...) the root cause is probably not with the piston engine code. The anomalies in the propeller numbers indicate that Ron's theory about u-aero-fp is probably correct but we don't have any direct proof at this point so there is an element of (informed) speculation there.

/fdm/jsbsim/propulsion/engine/propeller-rpm = 4.536e +39 is exactly the kind of thing that Ron's theory would predict. The advance ratio numbers also support this since /fdm/jsbsim/propulsion/engine/advance-ratio = -1464622094 indicates a huge negative velocity spike. Normal numbers here should be between 6 and -6 for this prop/engine so this number is around 9 orders of magnitude outside of the normal range.

Unfortunately the intermittent nature of the issue makes finding the root cause very difficult. But I agree with Ron that a "division by zero or near zero causing a huge number to be generated" is probably one of the few plausible answers to what is causing this. I would expect the C++ run time engine to throw an exception if it was a true divide by zero so this is probably a divide by near zero that is missed by whatever sanity checks are in place in the code. But where is that happening and why?

[hvengel]

OK it happened again and I was able to get a look at /fdm/jsbsim/velocities/u-aero-fps and is was -1.06e -10 at the point where FG failed. This is a very small value.

One other thing I am noticing now that I am looking tailwind related stuff is that if the tailwind is not very slight then the problem does not happen. So it seems that the tail wind needs to be less than -1.5 FPS for this to occur.

[daveculp]

Looks like there is no divide-by-zero check before the calculation of J in line 211 of FGPropeller.cpp. (It allows divide by -0?). I'm on the road so can't get to it now.