p51d-jsbsim on Start, severe compressability, screen red

[lipad]

I have been flying the p51d-jsbsim and has been challenge trying to takeoff with just mouse and keyboard. But recently as I press Start to start the engine, the screen turns flashing red, with a siren of a sound and the message "severe compressabilty - structural failure possible".

On reset, the cockpit reappers but with red flashing. It needs two or more resets, before the flashing would dissapear. I follow the start sequence again and on start - "severe compressability" again.

I may be able to start and fly if I change airport but not always.

What to do to avoid the "severe compressabilty"? What is being compressed?

[sim]

Press "v" on your keyboard so you can observe plane from "helicopter" or "chase" external view before starting engine.
See if that gives a clue as to what is happening. Also are you sure the P51 version is compatible with ver 2.12.0.
You could try downloading this earlier P51d to see if it exhibits the same behaviour.

https://db.tt/PhyMaSG8

[hvengel]

The behavior has been there since at least FG 2.8.

What I am seeing is that the aircraft under goes an extreme but very momentary acceleration when the starter is engaged. I have seen acceleration to speeds well in excess of MACH 2 within milli seconds of engaging the starter. On one occasion I observed the aircraft shooting backwards like it had been shot out of a canon. Since the only forces created by the FDM in that direction are drag I don't understand what is going on. The direction of the force/acceleration varies and I have seen forward, backward, lateral and vertical directions. Looking at the various forces in the property tree I have been unable to find the force spike that is causing this issue and I suspect that the force is of such short duration that detecting it will require some fairly low level hooks into the property tree or FDM to record what is happening. I have created several threads about this and so far no one seems to have any idea what is going on.

I suspect that it is happening to other JSBSim aircraft as well since this acceleration is not noticeable by the pilot and most aircraft do not have code that detects and reports this when it happens. In the case of the JSBSim P-51D there is code that detects things like compressibility (IE. speeds over MACH 0.76) and alerts the pilot of the dangerous flight condition and if the forces are high enough (over MACH 0.85) will trigger an airframe failure. Clearly MACH 2 is way past that point.

All recently released (last 5 years) JSBSim P-51D's are 2.12 compatible.

The starter and related code in the JSBSim P-51D is very ordinary and it does not create any FDM specific forces (IE. it is a normal starter).

I have found that if I disable the limits/damage code so that the P-51D is more like most JSBSIm aircraft that the issue becomes undetectable. But this is clearly masking the underlying issue and I would much rather figure out what is generating the unusual force(s) and fix the real problem rather then just hide it.

For those that don't know, like the OP, compressibility is what happens when the airflow over the wings/aircraft is accelerated above MACH 1 by the shape of the aircraft. This is something that happens in transonic flight conditions, It was shortly before WWII that compressibility was discovered. For the P-51 series the only way you would normally (IE. outside of the starter issue) see compressibility is to do a high altitude (above 30,000 ft) full power very steep dive. For the P-51 the onset of compressibility is at about MACH 0.76 and the airframe will be destroyed by the generated forces at around MACH 0.85.

[hvengel]

I should add that if ANYONE has ANY ideas about how to isolate the source of the force(s) involved in this that I am all ears.

[lipad]

By the way, I'm using FG 3.0 and the latest version of P51d (20140111).

Thank you hvengel for the explanation. Much appreciated. This "severe compressability" at start seems hard to replicate. I'm flying the p51d again, same airport (KSFO) and no red screen this time. It seems there is a certain condition that triggers it. Would it be air pressure (density pressure )?

hvengel mentions that sometimes the aircraft shoots backward. Indeed, I observed this once. But it was more of the plane moving slowly backward as the p51d 's engine started and the propeller rotated. It was a disconcerting experience as it was the complete opposite of what you would expect . You think, What is happening!? What did I do? What do I do now? Panic. Brake, brake! (I don't remember the brakes working.)

Perhaps the pitch of the propeler was reversed and started pushing the plane backward.

[hvengel]

By the way, I'm using FG 3.0 and the latest version of P51d (20140111).

Thank you hvengel for the explanation. Much appreciated. This "severe compressability" at start seems hard to replicate. I'm flying the p51d again, same airport (KSFO) and no red screen this time. It seems there is a certain condition that triggers it. Would it be air pressure (density pressure )?

hvengel mentions that sometimes the aircraft shoots backward. Indeed, I observed this once. But it was more of the plane moving slowly backward as the p51d 's engine started and the propeller rotated. It was a disconcerting experience as it was the complete opposite of what you would expect . You think, What is happening!? What did I do? What do I do now? Panic. Brake, brake! (I don't remember the brakes working.)

Perhaps the pitch of the propeler was reversed and started pushing the plane backward.

No it is not possible to reverse the propellers pitch since the pitch range of the prop is 23 through 58 degrees you can't really even feather the prop. In addition proper start up procedure calls for the prop to be full fine (23 degrees) during start up and I see this happen starting the aircraft with pitch set to full fine.

There is nothing in the FDM as coded that can create a force in the direction of the tail other than drag forces which should be (close to) zero during start up but will increase after start up due to the slipstream from the engine/prop but at that point the engine/prop is also producing some level of forward thrust that is greater than the drag created by the slipstream.

You are right about this being hard to reproduce and it seems to come and go at random. I think you are right that there is a set of conditions that needs to be just right for this to happen but what those are is a mystery to me. I don't think it is as simple as one specific property (like air pressure or air density) having values in a certain range. For some time now I had hoped that this would be looked into by someone who knows more about JSBSim internals so that the underlying problem can get fixed or at least identified but this has not yet happened.

One of the things that is fairly unique about the JSBSim P-51D is that it is likely the only JSBSim piston driven aircraft in FG that implements transonic affects (drag due to MACH, compressibility tuck and compressibility porpoise) in the FDM. But there may be other piston aircraft that have compressibility code that I don't know about. There are a number of jets that do this but even with jets, where transonic flight is common, only a sub set of JSBSim FDMs take transonic flight into consideration. Since this happens when the starter is engaged on piston engined aircraft I think that this is related to the piston engine code in some way but I don't know how. But I have to admit that this is pure speculation on my part and I would be happy to be proven wrong.

I am thinking about having the compressibility code disabled when the starter is engaged as a possible fix (this would only add a few lines of XML to the FDM). Another option would be to disable the compressibility code when WOW or perhaps some combination to prevent the compressibility code from detecting the condition during start up. Again this only masks the real problem and does nothing to fix the underlying issue which is probably happening silently in other aircraft since code (like the compressibility code in the P-51D) that would detect this is rare.

One thing that does occur to me is that the Drag due to Mach code:

Code: Select all

 <!-- from NACA P-51X and P-51B test data -->
<function name="aero/coefficient/CDmach">
<description>Drag_due_to_mach</description>
<product>
<property>aero/qbar-psf</property>
<property>metrics/Sw-sqft</property>
<table>
<independentVar>velocities/mach</independentVar>
<tableData>
0.00 0.00000
0.62 0.00000
0.64 0.00100
0.66 0.00200
0.68 0.00500
0.70 0.01250
0.72 0.02000
0.74 0.03000
0.76 0.04300
0.78 0.06000
0.80 0.08000
0.82 0.10000
0.84 0.12500 <!-- guesses to extend the table -->
0.86 0.15500
0.88 0.20000
0.90 0.26000
0.92 0.35000
1.00 0.60000
</tableData>
</table>
</product>
</function>

Does generate force toward the tail of the aircraft in the form of drag. Could this produce some sort of feedback loop that makes things worse? When an aircraft is gong backwards is velocities/mach a negative number? I had assumed that it was but perhaps this assumption is wrong. In any case the aircraft would have to reach at least mach 0.64 for this to be an issue so this does not explain where the initial acceleration force is coming from. This is a baffling issue and this is at least the third thread about it here on the forums and so far no one has had any helpful information about what the root cause is.

[Thorsten]

What I am seeing is that the aircraft under goes an extreme but very momentary acceleration when the starter is engaged.

It sounds a bit like a time interval duration (I'm tempted to say a frame, but the FDM doesn't operate in frames, I don't know the proper designation though...) is miscalculated - if the code thinks for some reason that dt ~ 0, then any small real acceleration, or in fact any numerical jitter will blow up to an infinite spike.

Basically JSBSim shouldn't do that and it smells like a bug - does Jon know about this?

[hvengel]

I agree that it is probably a single FDM iteration where something is miscalculated. I also agree that the force spike would have to be close to infinite to cause the kind of acceleration that we are seeing (0 to mach -2 in a few milliseconds).

I am currently running my FDM at 120 Hz so that would have a duration of about 8 milliseconds per FDM iteration which seems to correspond to what I am seeing. I am also seeing something similar right before the aircraft appears when FG is starting where it acts like it is dropped into the runway from a considerable height and experiences some substantial forces - sometimes enough to cause an airframe failure. This issue gets worse as the FDM frequency is increased and will happen consistently at higher FDM frequencies like 480Hz where airframe failures from this become common. Like the compressibility/starter issue this is detected and reported by the aircraft specific over G code and if that code was not there the pilot would not know something was amiss. So this may be happening to many/most JSBSim aircraft without pilots and aircraft authors being aware of the issue.

Both of these issues have been reported numerous times by myself and others on the forum but I have not opened tickets for either issue. I do think they are related because both involve large but very short duration force spike and both may have the same root cause. Also your delta-t idea is a plausible thing to be looked at.

And I agree there is likely a long standing bug in the JSBSim code that is responsible for this behavior. But it is likely something that looks very innocuous when looking at the code so it might be very difficult to isolate and also possibility difficult to fix but until the problem is located we will not know how difficult it is to fix.

[Thorsten]

Well, since you know how to reproduce it reliably (FDM to high frequency, press starter on P-51D), someone who works with the JSBSim code can probably track this down fairly easily by adding a few monitoring lines. The tough bugs are only the ones which occur occasionally every hour or so.

[daveculp]

I've never seen this happen with any of my piston powered models. My guess is that one of your monitoring/reporting systems is causing the problem.

[hvengel]

Double post sorry.

[hvengel]

I think the reason this does not show up on other piston engine aircraft is that almost none of them have code that will detect compressibility and report it to the pilot. I did some grepping in the git Aircraft directory looking for terms related to this in xml and nas files to see how many aircraft might have code related to this. I tried a number of search terms but the only significant ones were "compressibility" (only shows in the P-51D and the XB70) and "transonic" (which shows up in a number of jets but no prop jobs). I was unable to find another piston/prop aircraft that has any code related to transonic flight other than a few that had drag-due-to-mach functions and some with more or less generic JSBSim functions related to control effectiveness due to mach.

In addition, I am not sure how the monitoring/reporting code could generate such huge momentary forces although the compressibility code can cause the pitch moment to change (this is how the porpoise is implemented) but if this part of the code is disabled (IE. only monitoring and reporting but nothing that affects the flight modeling by commenting out the two compressibility functions in the FDM - see code below)) I still see the messages about compressibility which indicates that somehow the airframe is being accelerated to above mach 0.76 nearly instantaneously when the aircraft has no initial velocity. What needs to be determined is where are the forces that cause this acceleration are coming from.

Here is the code Involved in this functionality. I would really like some more eyes on this in case there is an issue here that I have missed. If this code is ok or only has issues that are not responsible for the large forces that this thread is about then this points to some underlying issue in JSBSim.

The following code is in the pitch section of the FDM:

Code: Select all

                       
<function name="aero/coefficient/Cm-mach-porpoise">
       <description>Pitch_moment_due_mach_porpoise</description>
       <product>
              <property>aero/qbar-psf</property>
              <property>metrics/Sw-sqft</property>
              <property>metrics/cbarw-ft</property>
              <property>/fdm/jsbsim/systems/compressibility/sine_wave</property>
              <property>/fdm/jsbsim/systems/compressibility/strength</property>
              <value>0.1</value>
     </product>
 </function>

<function name="aero/coefficient/Cm-mach-tuck">
      <description>Pitch_moment_due_mach</description>
      <product>
      <property>aero/qbar-psf</property>
      <property>metrics/Sw-sqft</property>
      <property>metrics/cbarw-ft</property>
      <table>  <!-- control reversal -->
           <independentVar>velocities/mach</independentVar>
                 <tableData>
                        0.0000        0.0
                        0.746         0.0
                        0.775         -0.05
                        1.0000        -0.2
                 </tableData>
    </table>
    </product>
</function>

The following code is the compressibility


The porpoise code in the FDM depends on the following code:

Code: Select all

 
<system name="compressibility">

  <channel name="Compressibility">

    <switch name="compressibility enabled">
        <default value="0"/>
             <test logic="AND" value="1">
                 velocities/mach gt 0.775
                 <!-- the following three lines were just added to git to try to help this issue -->
                 /gear/gear/wow lt 0.1
                 /position/altitude-agl-ft gt 100
                 /position/altitude-ft gt 5000
        </test>
        <output>/fdm/jsbsim/systems/compressibility/enabled</output>
    </switch>

    <fsc_function name = "/fdm/jsbsim/systems/compressibility/hertz">
      <function>
        <product>
        <property>/fdm/jsbsim/systems/compressibility/enabled</property>
        <table>
          <independentVar lookup="row">velocities/mach</independentVar>
          <tableData>
             0         0.0
             0.76      0.0
             0.78      0.2
             0.9       1.0
          </tableData>
        </table>
        </product>
      </function>
      <output>/fdm/jsbsim/systems/compressibility/hertz</output>
   </fsc_function>

   <fsc_function name = "/fdm/jsbsim/systems/compressibility/strength">
      <function>
         <product>
            <property>/fdm/jsbsim/systems/compressibility/enabled</property>
            <table>
              <independentVar lookup="row">velocities/mach</independentVar>
              <tableData>
                 0           0.0
                 0.76        0.0
                 0.78        0.1
                 0.9         4.0
              </tableData>
            </table>
         </product>
      </function>
      <output>/fdm/jsbsim/systems/compressibility/strength</output>
   </fsc_function>

   <fcs_function name="Sine Wave Generator">
     <function>
       <sin>
         <product>
           <property>/fdm/jsbsim/systems/compressibility/hertz</property>
           <property>sim-time-sec</property>
           <value>6.283185307</value>
         </product>
       </sin>
     </function>
     <output>/fdm/jsbsim/systems/compressibility/sine_wave</output>
   </fcs_function>

  </channel>


</system>


Here is the crash detect code:

Code: Select all

<system name="crash-detect">

 <!-- <property value="0">systems/crash-detect/crashed</property>-->

  <channel name="Over-G">

     <fcs_function name="wing-load">
       <function>
          <product>
             <property>accelerations/Nz</property>
             <property>inertia/weight-lbs</property>
          </product>
       </function>
       <output>systems/crash-detect/wing-load</output>
     </fcs_function>

     <!--
          Detect wing loads that exceed limits.
          Operational limits are +64,000 lbs and
          -32,000lbs.  IE. +8 or -4 Gs at 8,000 lbs
          gross weight  This allows for a 40% engineering
          margin of safety before actual structural
          failure.   At higher gross weights the wing
          structure will fail at lower G loadings.
          -->
     <switch name="over-g-failure">
          <test value="1">
                systems/crash-detect/wing-load gt 89600
          </test>
          <test value="1">
                systems/crash-detect/wing-load lt -34800
          </test>
          <output>systems/crash-detect/crashed</output>
          <output> systems/crash-detect/over-g-failure </output>
     </switch>

     <switch name="over-g">
          <test value="1">
                systems/crash-detect/wing-load gt 64000
          </test>
          <test value="1">
                systems/crash-detect/wing-load lt -32000
          </test>
          <output> systems/crash-detect/over-g </output>
     </switch>

  </channel>

  <channel name="crashed">

     <!-- end the sim if the aircraft is crashed -->
     <switch name="systems/crash-detect/FG">
        <test value="1">
           systems/crash-detect/crashed == 1
        </test>
        <output>/sim/freeze/clock</output>
        <output>/sim/freeze/main</output>
        <output>/controls/engines/engine[0]/cutoff</output>
        <output>/sim/crashed</output>
     </switch>
 
  </channel>

  <channel name="impact-ground">

     <switch name="impact">
          <test logic="AND" value="1">
                position/h-agl-ft lt 1.0
                simulation/sim-time-sec gt 1.0
          </test>
          <output>systems/crash-detect/crashed</output>
          <output> systems/crash-detect/impact </output>
     </switch>

  </channel>

</system>>

And finally limits.nas which is where the messages to the pilot are output:

Code: Select all

#
# Nasal script to print errors to the screen when aircraft exceed design limits:
#  - extending flaps above maximum flap extension speed(s)
#  - extending gear above maximum gear extension speed
#  - exceeding Vna
#  - exceeding structural G limits
#  - compressibility onset

var checkFlaps = func(n) {

var flapsetting = n.getValue();
    if (flapsetting == 0)
        return;


    var airspeed = getprop("velocities/airspeed-kt");

    if ((flapsetting < 0.35 and airspeed > 347.6) or
        (flapsetting > 0.35 and flapsetting < 0.55 and airspeed > 239) or
        (flapsetting > 0.55 and flapsetting < 0.75 and airspeed > 195.5) or
        (flapsetting > 0.75 and flapsetting < 0.95 and airspeed > 156.4) or
        (flapsetting > 0.95 and airspeed > 143.4)) {
            screen.log.write("Flaps extended above maximum flap extension speed!");
        }
    # cause structural damage when safe speed is exceeded by 10%
    if ((flapsetting < 0.35 and airspeed > 381.7) or
        (flapsetting > 0.35 and flapsetting < 0.55 and airspeed > 263) or
        (flapsetting > 0.55 and flapsetting < 0.75 and airspeed > 214.5) or
        (flapsetting > 0.75 and flapsetting < 0.95 and airspeed > 172) or
        (flapsetting > 0.95 and airspeed > 157.7)) {
            screen.log.write("Flaps damaged!");
            setprop("/sim/failute-manager/controls/flight/flaps/serviceable", 0);
        }
}


var checkGear = func(n) {

    if (!n.getValue())
        return;

    if (getprop("velocities/airspeed-kt") > 147.7) {
        screen.log.write("Gear extended above maximum extension speed!");
    }
}


# ====== Structural failure load limit exceeded =======
# This only prints a message actual failure is handled
# by Systems/crash-detect.xml

var checkG = func (n) {

    if (getprop("/sim/freeze/replay-state"))
       return;

    var overG = n.getValue();

    if (overG > 0){
        if (getprop("/fdm/jsbsim/accelerations/Nz") > 0) {
            msg = "Airframe structural positive load limit exceeded!";
        }
        else {
            msg = "Airframe structural negative load limit exceeded!";
        }
        screen.log.write(msg);
    }
}

var checkCompressibility = func (n) {

    if (getprop("/sim/freeze/replay-state"))
       return;

    var compressibilityStength = n.getValue();

    if (compressibilityStength > 0.0) {
        if (compressibilityStength <= 0.15) {
           msg = "Initial on set of compressibility.";
        }
        else {
            if (compressabilityStength <= 0.4) {
                msg = "Moderate compressibility.";
            }
            else {
               if (compressabilityStength > 0.4 ) {
                  msg = "Severe compressibility - structural failure possible.";
               }
            }
        }
        screen.log.write(msg);
    }
}

# Set the listeners
setlistener("fdm/jsbsim/systems/compressibility/strength", checkCompressibility);
setlistener("controls/flight/flaps", checkFlaps);
setlistener("controls/gear/gear-down", checkGear);
setlistener("fdm/jsbsim/systems/crash-detect/over-g", checkG);

# ====== VNE exceeded =======

var VnePlusTime = 0;

var checkVNE = func {

     if (getprop("/sim/freeze/replay-state"))
       return;

     if (getprop("instrumentation/airspeed-indicator/indicated-airspeed") != nil and
         getprop("instrumentation/airspeed-indicator/indicated-airspeed") > 439) {
         screen.log.write("Airspeed exceeds Vne!");
     }
     else {
        VnePlusTime = 0;
     }
    if (getprop("instrumentation/airspeed-indicator/indicated-airspeed") != nil and
        getprop("instrumentation/airspeed-indicator/indicated-airspeed") > 483) {
        # elevator fails after 2 seconds above VNE + 10%
        if (VnePlusTime == 4) {
            screen.log.write("Elevator Failure");
            setprop("/sim/failure-manager/controls/flight/elevator/serviceable", 0);
        }
        # rudder fails after 3 seconds above VNE + 10%
        if (VnePlusTime == 6) {
            screen.log.write("Rudder Failure");
            setprop("/sim/failure-manager/controls/flight/rudder/serviceable", 0);
        }
        # ailerons fails after 4 seconds above VNE + 10%
        if (VnePlusTime == 8) {
            screen.log.write("Aileron Failure");
            setprop("/sim/failure-manager/controls/flight/aileron/serviceable", 0);
        }
        # complete structural failure after 5 seconds above VNE + 10%
        if (VnePlusTime >= 10) {
           screen.log.write("Structural Failure");
            setprop("/fdm/jsbsim/systems/crash-detect/crashed", 1);
        }
        VnePlusTime = VnePlusTime + 1;
    }
    else {
        VnePlusTime = 0
    }
    settimer(checkVNE, 0.5);
}

checkVNE();

[daveculp]

Sorry, I haven't been able to run the p-51d-jsbsim without freezing the sim, requiring an xkill. I won't be able to test it. The model called p-51d starts fine though (but some parts, like the propeller, are missing visually).

- Dave

[hvengel]

Well, since you know how to reproduce it reliably (FDM to high frequency, press starter on P-51D), someone who works with the JSBSim code can probably track this down fairly easily by adding a few monitoring lines. The tough bugs are only the ones which occur occasionally every hour or so.

No the FDM frequency does not affect the starter issue as far as I can tell. The FDM frequency affects the issue that happens just before the aircraft appears when FlightGear is starting up. This one happens consistently for me and the over G warning is what is displayed when this happens. For this one increasing the FDM frequency results in the behavior getting worse and at higher frequencies I start seeing airframe failures in addition to the over G warning messages. I think the startup and starter issues are related because they both involve a very large momentary force. In the case of the startup issue the force appears to be vertical and in the case of the starter issue the force appears to be a backward force (most of the time).

[hvengel]

Sorry, I haven't been able to run the p-51d-jsbsim without freezing the sim, requiring an xkill. I won't be able to test it. The model called p-51d starts fine though (but some parts, like the propeller, are missing visually).

- Dave

The other model is the YASim version. This is old, obsolete and unmaintained and will be removed before FG 3.2 is released.

This is the first report of the sim freezing when attempting to run the JSBSim P-51D. I have been running on a Windows box for a little less than a year so I have not tested recent changes on *nix. But there have only been minor FDM changes during that time since most of the work has been on the computing gunsight and some 3D modeling work. It is possible that while doing that work that I introduced a change that is causing problems on *nix machines. File naming type stuff comes to mind and when making my changes I pay close attention to this. But if it was a file name issue then FG generally handles this with some grace and reports the issue on the console. So it is unlikely to be a file naming issue. Do you have any idea what might be causing this? Did you see any messages on the console that may provide some ideas?

Also are you using current git or the version that is on the FG 3.0 aircraft download page? I made some changes to the compressibility code to try to make it more robust and these changes were pushed to git earlier today. One of the issues here is that it is possible that the compressibility code was not being correctly initialized at start up and it may have been doing some unexpected things. The changes I put in will make sure that things are correctly initialized when the sim starts now on matter what. I also added logic that will prevent the compressibility code from doing anything until the aircraft is off the ground. Due to the intermittent nature of the issue I don't know if these changes will help or not (>95% of the time I don't see this issue). Time will tell.

I would encourage the OP and others to get the most recent git version and test it out. If anyone wants to try the most recent version but does not want to have to do a git clone let me know and I will zip of a copy and put it someplace were it can be downloaded.