Extreme axcelerations during engine start up.

[hvengel]

Might also have a look at line 303 where there is similar but slightly different code to calculate J.

Also had some more failures. This was typical:

/fdm/jsbsim/velocities/u-aero-fps = -1633029734

This time I observed /fdm/jsbsim/velocities/u-aero-fps for a few minutes before engaging the starter. it was close to 0 and was fluctuating between + and - values.

[jentron]

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.

Hi Dave,

I see a divide by zero check there:

Code: Select all

 if (RPS > 0.0) J = Vel / (Diameter * RPS); // Calculate J normally
  else           J = Vel / Diameter;


It even has your name on the commit. :D

Down at line 260 we have this:

Code: Select all

if (RPS != 0.0) J = Vel / (Diameter * RPS);

but we've already clipped the negative RPS values at that point.

Ron
// looking at http://jsbsim.cvs.sourceforge.net/viewv ... otate=1.48

[daveculp]

I was thinking it could get to -0, from the negative side before triggering the test for GT zero. This would also explain why it happens when hitting the starter in a tailwind. RPS goes from negative to positive, passing through -0 on the way. Not sure how -0 is handled. It may be compiler and architecture dependent.

[erik]

Wouldn't is be better to treat RPM < 1.0 as a special case, and treat it as stationary from that point?
Negative RPM is rather abstract, especially since Variable pitch prop can have pitch < 0 which should result in a negative thrust vector.

Erik

[hvengel]

RPS is RPM/60 so revolutions per second.

RPM can never be < 0.0 - from line 285

Code: Select all

if (RPM < 0.0) RPM = 0.0; // Engine won't turn backwards

So RPS < 0.0 should never happen.

Also my c++ foo, somewhat vaguely, says if a floating point number has a mantissa = 0 the sign bit does not matter since it is still 0. And I agree with Ron that there is a divide by zero check at line 211.

I think Ron was more concerned about an anomaly on how aero velocity is calculated which I think is calculated like this in the propeller code:

Code: Select all

FGColumnVector3 localAeroVel = Transform().Transposed() * in.AeroUVW;
double Vel = localAeroVel(eU);

But is Vel the same as or related to /fdm/jsbsim/velocities/u-aero-fps?

[jentron]

Actually, my concern is with propulsion/engine/prop-induced-velocity_fps which normally isn't used for anything, but is used in your aero section (and some I've written, too)

[erik]

Still RPM can be 0 possibly leading to device by zero in the calculations, or requiring a number of checks to prevent them (one even tests for RPS < 0 which you say can't happen), This could be simply avoided by testing for RPM< 1 once and treat it as if it were 0, or else run the current code (without the checks). At least that's just my 2 cents worth.

[hvengel]

Ron,

Yes I use propulsion/engine/prop-induced-velocity_fps to add prop wash affects for aero/thrust-qbar_psf and this in turn affects various control/stabilizer surfaces. Doing this makes the aircraft way more docile during the early phases of a take off and is probably a better fit to IRL behavior.

If this is the where the problem is coming from then this would explain why this is not showing up in a broader range of aircraft since most do not use it.

I can add a JSBSim function to clamp propulsion/engine/prop-induced-velocity_fps and output it to a custom property and use the clamped value instead. But first I will take a look at propulsion/engine/prop-induced-velocity_fps when there is a failure to see what it looks like.

Hal

[hvengel]

Ron,

Just had this happen while closely monitoring propulsion/engine/prop-induced-velocity_fps and I didn't see any anomalies with propulsion/engine/prop-induced-velocity_fps. In fact at the failure point it was 0.024307 and at no time did it go over 2.75 or below 0.

/fdm/jsbsim/velocities/u-aero-fps appears to be where the extreme numbers are coming from. It will have huge negative when the failure occurs. I tried to filter out the extreme negative values by doing:

Code: Select all

   <pure_gain name="u-aero-fps_clipped">
      <input>velocities/u-aero-fps</input>
      <gain>1.0</gain>
      <clipto>
        <min>-3500.0</min> <!--max 40 mile per hour tail wind -->
      </clipto>
      <output>velocities/u-aero-fps_clipped</output>
   </pure_gain>

But this only outputs 0.0. I must be doing something wrong but I don't see what it is.

[hvengel]

I think I have the issue fixed but I am not sure I have things totally correct.

My old code looks like this:

Code: Select all

   <function name="aero/thrust-qbar_psf">
     <description>Air_velocity_due_to_propwash</description>
     <product>
       <v> 0.5 </v>
       <p> atmosphere/rho-slugs_ft3 </p>
           <pow>
               <sum>
                  <p> velocities/u-aero-fps </p>   
                  <product>
                       <p> propulsion/engine/prop-induced-velocity_fps </p>
                       <v> 2.0 </v>
                  </product>
               </sum>
               <v> 2.0 </v>
       </pow>
     </product>
 </function>

It is using velocities/u-aero-fps along with propulsion/engine/prop-induced-velocity_fps to calculate the thrust-qbar_psf which is basically qbar_psf plus the prop wash induced qbar_psf. The problem is that velocities/u-aero-fps has major issues under certain conditions and can have huge negative values. I decided to eliminate velocities/u-aero-fps from the thrust-qbar_psf calculation and came up with this:

Code: Select all

   <function name="aero/thrust-qbar_psf">
      <description>Air_velocity_due_to_propwash</description>
      <sum>
       <product>
         <v> 0.5 </v>
         <p>atmosphere/rho-slugs_ft3</p>
              <pow>
                <product>
                  <p> propulsion/engine/prop-induced-velocity_fps </p>
                  <v> 2.0 </v>
                </product>
                <v> 2.0 </v>
            </pow>       
       </product>
        <p>aero/qbar-psf</p>
      </sum>     
  </function>


I am not sure that this is completely correct but the values it outputs at least seem plausible and I didn't feel any change in the way the P-51D handled.

If my memory is correct the original code was lifted from a thread on the developers email list but I don't remember who authored it. If possible could who ever wrote the original code for that thread please review this to make sure that I am not going totally off the farm.

[jentron]

Did you manage to nail down the conditions were u-aero-fps isn't valid?

Your formula looks ok to me. The full-on simguys might whine about adding pressures, and the helicopter guy in me would rather be using qbarUW-psf (qbar with the side component removed)

[hvengel]

u-aero-fps has issues when the is a slight wind and u-aero-fps is moving between + and - values. There is usually a slight tail wind when this is happening. It does not happen in stronger tail winds. I was able over the last few days to trigger the issue after the engine was running so it apparently had nothing to do with the starter per say.

So far the new version of aero/thrust-qbar_psf has not had any issues for me and I have had a report from a user who was having issues with this that the new version is working for him too. Since basically everyone other than a hand full of FDMs uses aero/qbar-psf in places where I am using aero/thrust-qbar_psf and this issue is not present for these other FDMs I suspect that there will no longer be an issue with this. But the problem is very intermittent so only time will tell.

[hvengel]

Well that didn't fix the issue since aero/qbar-psf also spikes when wind conditions are just right. IE. when u-aero-fps is moving between + and - values.

Not sure what to do about this.