Accurate TSFC - Thrust Specific Fuel Consumption

[agodemar]

Suppose I have maps of Thrust and Specific Fuel Consumptions, as functions of Mach number, altitude, and engine ratings.
Is it possible to model that?

[seanmcleod]

Can't you get your thrust and specific fuel consumption data into the turbine engine model? In which case the mass would decrease correctly as the turbine ran?

[seanmcleod]

So taking a look at the CFM56 as an example, is the issue that the turbine model only allows you to specify a single value for TSFC and you need it to vary based on Mach and altitude?

While the thrust can be specified based on Mach and altitude.

jsbsim/engine/CFM56.xml

Lines 14 to 59 in d1ca6eb

	<turbine_engine name="CFM56">
	<milthrust> 20000.0 </milthrust>
	<bypassratio> 5.9 </bypassratio>
	<tsfc> 0.657 </tsfc>
	<bleed> 0.04 </bleed>
	<idlen1> 30.0 </idlen1>
	<idlen2> 60.0 </idlen2>
	<maxn1> 100.0 </maxn1>
	<maxn2> 100.0 </maxn2>
	<augmented> 0 </augmented>
	<injected> 0 </injected>
	<function name="IdleThrust">
	<table>
	<independentVar lookup="row">velocities/mach</independentVar>
	<independentVar lookup="column">atmosphere/density-altitude</independentVar>
	<tableData>
	-10000 0 10000 20000 30000 40000 50000 60000
	0.0 0.0420 0.0436 0.0528 0.0694 0.0899 0.1183 0.1467 0.0
	0.2 0.0500 0.0501 0.0335 0.0544 0.0797 0.1049 0.1342 0.0
	0.4 0.0040 0.0047 0.0020 0.0272 0.0595 0.0891 0.1203 0.0
	0.6 0.0 0.0 0.0 0.0 0.0276 0.0718 0.1073 0.0
	0.8 0.0 0.0 0.0 0.0 0.0174 0.0468 0.0900 0.0
	1.0 0.0 0.0 0.0 0.0 0.0 0.0422 0.0700 0.0
	</tableData>
	</table>
	</function>
	<function name="MilThrust">
	<table>
	<independentVar lookup="row">velocities/mach</independentVar>
	<independentVar lookup="column">atmosphere/density-altitude</independentVar>
	<tableData>
	-10000 0 10000 20000 30000 40000 50000 60000
	0.0 1.2600 1.0000 0.7400 0.5340 0.3720 0.2410 0.1490 0.0
	0.2 1.1710 0.9340 0.6970 0.5060 0.3550 0.2310 0.1430 0.0
	0.4 1.1500 0.9210 0.6920 0.5060 0.3570 0.2330 0.1450 0.0
	0.6 1.1810 0.9510 0.7210 0.5320 0.3780 0.2480 0.1540 0.0
	0.8 1.2580 1.0200 0.7820 0.5820 0.4170 0.2750 0.1700 0.0
	1.0 1.3690 1.1200 0.8710 0.6510 0.4750 0.3150 0.1950 0.0
	1.2 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0
	</tableData>
	</table>
	</function>
	</turbine_engine>

[agodemar]

I have a much more complicated model. It's a turboprop engine (aircraft similar to ATR42) and I have the thrust. No propeller data. No rpm.
There are several thrust & tsfc lookup tables, one for each engine 'rating'. Then I have a engine rating selector logic.

[agodemar]

So taking a look at the CFM56 as an example, is the issue that the turbine model only allows you to specify a single value for TSFC and you need it to vary based on Mach and altitude?

I could define a custom property that gives tsfc as a function of engine_rating, Mach, altitude ?

[seanmcleod]

So currently the turbine source code assumes a single value for TFSC (and ATFSC - augmented thrust).

jsbsim/src/models/propulsion/FGTurbine.cpp

Lines 455 to 458 in d1ca6eb

	if (el->FindElement("tsfc"))
	TSFC = el->FindElementValueAsNumber("tsfc");
	if (el->FindElement("atsfc"))
	ATSFC = el->FindElementValueAsNumber("atsfc");

So my thinking was the user could optionally provide a function for TFSC instead of a single value, much along the lines of the function that is currently supplied for IdleThrust, MilThrust etc. In your case in addition to Mach and altitude as independent variables you could also include engine rating etc.

[agodemar]

You mean that this is not implemented yet? If I supply such a function for tsfc, will it work?

[seanmcleod]

Correct, there is currently no support in the source code for TSFC to be read from a function, it only supports TSFC being supplied as a single float number.

jsbsim/src/models/propulsion/FGTurbine.cpp

Lines 455 to 458 in d1ca6eb

	if (el->FindElement("tsfc"))
	TSFC = el->FindElementValueAsNumber("tsfc");
	if (el->FindElement("atsfc"))
	ATSFC = el->FindElementValueAsNumber("atsfc");

But it wouldn't be a big deal to add support for an optional function. I'll prototype something today.

[seanmcleod]

@agodemar I've just prototyped and done some basic testing of adding support for TSFC to be optionally specified as a function in the engine model file.

Take a look at - seanmcleod@f2c23a9

For testing I added a TSFC function to the CFM56 engine model and tested it with the 737 cruise script.

  <function name="TSFC">
    <table>
      <independentVar lookup="row">velocities/mach</independentVar>
      <independentVar lookup="column">atmosphere/density-altitude</independentVar>
      <tableData>
             -10000     0     10000   20000   30000   40000   50000   60000
        0.0  0.2        0.3   0.4     0.5     0.6     0.7     0.8     0.9
        0.2  0.3        0.4   0.5     0.6     0.7     0.8     0.9     1.0
        0.4  0.4        0.5   0.6     0.7     0.8     0.9     1.0     1.1
        0.6  0.5        0.6   0.7     0.8     0.9     1.0     1.1     1.2
        0.8  0.6        0.7   0.8     0.9     1.0     1.1     1.2     1.3
        1.0  0.7        0.8   0.9     1.0     1.1     1.2     1.3     1.4
      </tableData>
    </table>
  </function>

The TSFC element can be left in the engine model file, it will simply be overridden/ignored if there is also a TSFC function.

For your case where you have different data for each engine 'rating' then you would simply create a 3D table using breakpoints which map to your engine_rating property.

[seanmcleod]

Currently JSBSim only supports a single static value for TSFC for an engine.

<turbine_engine name="CFM56">
  <tsfc>            0.657 </tsfc>

However it looks like the TSFC value can vary during flight by quite a lot, so providing the ability to specify a function to calculate TSFC during flight would allow users who want to model TSFC more accurately the ability to do so, e.g. as in - seanmcleod@f2c23a9

Some references to the amount of variation in TSFC during flight.

Characteristics of the Specific Fuel Consumption for Jet Engines

Why is the ratio of TSFC at altitude vs. sea level different for hi-bypass vs. lo-bypass turbofan engines?

[agodemar]

@seanmcleod Thank you for working on this. Yes TSFC do vary with flight conditions, Mach number and altitude, and with enging setting a.k.a. "engine rating". This feature that you implemented in your fork enables those users who have these maps of thrust and TSFC to get much more realistic simulations. Especially for turboprops and turbofans.

Do we go for a pull request?

[seanmcleod]

I'm happy to submit a pull request.

I've pushed another commit which exposes read-only properties for TSFC and ATSFC so you can easily confirm what value is being used.

Repeating Notify (Event 2) executed at time: 100.004333
    propulsion/engine[0]/n2 = 97.211420
    propulsion/engine[1]/n2 = 97.211420
    propulsion/engine[0]/thrust-lbs = 6996.344735
    propulsion/engine[1]/thrust-lbs = 6996.344735
    velocities/vc-kts = 283.100665
    propulsion/engine[0]/tsfc = 0.976481
    propulsion/engine[1]/tsfc = 0.976481

One thing I noticed in the source code is the calculation of a correctedTSFC value.

jsbsim/src/models/propulsion/FGTurbine.cpp

Lines 238 to 239 in d1ca6eb

	correctedTSFC = TSFC * sqrt(T/389.7) * (0.84 + (1-N2norm)*(1-N2norm));
	FuelFlow_pph = Seek(&FuelFlow_pph, thrust * correctedTSFC, 1000.0, 10000.0);

Part of it appears to be a temperature compensation? Not sure about the reasoning behind the 0.84 constant and N2norm values.

[agodemar]

Looks like that 0.84 part of a correlation accounting for a non-dimensionalized rpm

[bcoconni]

Looks like that 0.84 part of a correlation accounting for a non-dimensionalized rpm

Looks actually like the hardcoded ratio of SFC@idle to SFC@100%N2: 1.84

[seanmcleod]

@agodemar you had mentioned originally:

modify at runtime the total mass. Conceptually this would be done by decreasing the mas by an amount which is: the current TSFC times the current thrust times by delta_time.

Are you happy that the 'correction' being applied to the supplied TSFC is correct and will give the correct/expected results in terms of the amount of fuel mass burnt per delta-T?

[agodemar]

@seanmcleod I am happy that my original question brought to light the necessity to have a variable TSFC, which would be nice to have in the main version of JSBSim.
At the same time it would be good to have a variable mass as well. For instance, a tank that would leak fuel. Or a tank that would be filled during a refueling manoeuvre. This mass variation in time should be taken into account at each time step when aircraft mass & balance are recalculated.

[seanmcleod]

Doing a quick search on 'corrected TSFC` in the repo I came across this issue with commentary by @bcoconni and @Mike402.

Turbine fuel consumption

Note the mention regarding a number of 'magic' numbers, and wondering where the temperature value of 389.7 comes from in terms of the formula for calculating the corrected TSFC value.

[bcoconni]

Note the mention regarding a number of 'magic' numbers, and wondering where the temperature value of 389.7 comes from in terms of the formula for calculating the corrected TSFC value.

Yeah, I mean the FGTurbine model is better than nothing but it is not much more worth than that. It contains lots of magic numbers and even some plain wrong assumptions: SFC curves with respect to TLA (Thrust Lever Angle) or N2 are bucket shaped :

While FGTurbine assumes a monotonically decreasing function with N2

jsbsim/src/models/propulsion/FGTurbine.cpp

Lines 238 to 239 in d1ca6eb

	correctedTSFC = TSFC * sqrt(T/389.7) * (0.84 + (1-N2norm)*(1-N2norm));
	FuelFlow_pph = Seek(&FuelFlow_pph, thrust * correctedTSFC, 1000.0, 10000.0);

The thing is that an engine SFC is terrible while idling: it is operating far from its design point so its efficiency is low. Not mentioning that you are dividing a finite value (fuel flow) by an almost zero value (thrust).

Edit: the function from FGTurbine is monotonically decreasing not increasing. My mistake.

[seanmcleod]

In terms of corrected TSFC, it looks to me like the JSBSim correction to TFSC is based on the Husk Plot section of https://en.wikipedia.org/wiki/Jet_engine_performance?

[agodemar]

It looks so

[bcoconni]

SFC is a function of the square root of the ambient temperature as is documented in literature (Jack D. Mattingly, Elements of Gas Turbine Propulsion. McGraw-Hill International Editions, 1996. ISBN : 0-07-114521-4).

[agodemar]

Yes, I see. And when you have TSFC maps you are beyond preliminary analysis.

[bcoconni]

Yes, I see. And when you have TSFC maps you are beyond preliminary analysis.

Not saying otherwise. I was just reacting to @seanmcleod statement. My point is that this relationship has not been invented by JSBSim contributors, it is widely accepted by the aerospace community.

[seanmcleod]

My one concern, when I was implementing the TSFC function option, was whether the user would supply a TSFC function/map that implemented things like temperature correction/denormalisation within it, but then the current code would go ahead and apply it again via the correction TSFC code we have.

[bcoconni]

I guess we should avoid second guessing the user input when a TSFC function is submitted and just use it upfront ? Said in other word, the temperature correction should be dropped when the TSFC is supplied as a function.

[seanmcleod]

Yep, that's why I asked at the time, partly whether it's 'correct' but also partly whether it should be applied at all:

Are you happy that the 'correction' being applied to the supplied TSFC is correct and will give the correct/expected results

[seanmcleod]

@bcoconni mentioned the following in - #196 (comment)

jsbsim/src/models/propulsion/FGTurbine.cpp

Lines 238 to 239 in d1ca6eb

	correctedTSFC = TSFC * sqrt(T/389.7) * (0.84 + (1-N2norm)*(1-N2norm));
	FuelFlow_pph = Seek(&FuelFlow_pph, thrust * correctedTSFC, 1000.0, 10000.0);

In addition I don't know where the number 389.7 is coming from. I thought it was the ISA temperature in Rankine but it is not (ISA temperature is 15°C i.e. 288K i.e. 518.4R).

And the recent reference:

And from https://en.wikipedia.org/wiki/Jet_engine_performance

So yes, when we are applying a correction I wonder if T0 really should be 518.4 rather than 389.7.

[bcoconni]

The problem is that if we fix that value, it will break the fuel consumption of all the existing aircraft models by a factor of sqrt(518.4/389.7) i.e. 1,153.

[seanmcleod]

I guess we should avoid second guessing the user input when a TSFC function is submitted and just use it upfront ? Said in other word, the temperature correction should be dropped when the TSFC is supplied as a function.

I think that's a good idea.

If their TSFC data is temperature normalised then they could apply the temperature correction/denormalisation as part of their TSFC function.

[bcoconni]

The other point is whether the relationship between correctedTSFC and N2 is kept when the TSFC is supplied as a function ?

[seanmcleod]

If the TSFC function/table makes use of thrust, e.g. the x-axis in the bucket shaped graph example you posted earlier, or the Husk plot then would there need to be a relationship between correctedTSFC and N2?

[bcoconni]

I guess not.

[seanmcleod]

@agodemar can you post a snippet of some of the TSFC data table/graph etc. that you're using that triggered this discussion?

Is it a Husk plot, or does it look similiar to the graph that @bcoconni posted earlier showing the bucket shape? Or something else?

[seanmcleod]

Talking of using the current thrust as an input to a TSFC function how do you go about ensuring that the thrust value is for the current engine in a multi-engine setup in the engine model file?

For example let's say I wanted to replace atmosphere/density-altitude with the property describing the thrust of the current engine?

  <function name="TSFC">
    <table>
      <independentVar lookup="row">velocities/mach</independentVar>
      <independentVar lookup="column">atmosphere/density-altitude</independentVar>
      <tableData>
             -10000     0     10000   20000   30000   40000   50000   60000
        0.0  0.2        0.3   0.4     0.5     0.6     0.7     0.8     0.9
        0.2  0.3        0.4   0.5     0.6     0.7     0.8     0.9     1.0
        0.4  0.4        0.5   0.6     0.7     0.8     0.9     1.0     1.1
        0.6  0.5        0.6   0.7     0.8     0.9     1.0     1.1     1.2
        0.8  0.6        0.7   0.8     0.9     1.0     1.1     1.2     1.3
        1.0  0.7        0.8   0.9     1.0     1.1     1.2     1.3     1.4
      </tableData>
    </table>
  </function>

[bcoconni]

You can use the sharp/hash # character to replace the engine number

<independentVar lookup="column">propulsion/engine[#]/thrust-lbs</independentVar>

Not sure this is a feature we have much communicated about 😄

[agodemar]

This is an example of nondimensional thrust:

[seanmcleod]

@bcoconni you seem to have posted the same graph twice. Edit -- actually I mean @agodemar.

I presume the delta-T = 10K at the top of the graph refers to ISA standard day + 10K?

[bcoconni]

@bcoconni you seem to have posted the same graph twice.

I am innocent 😄 I guess you mean @agodemar ?

[agodemar]

Yes, ISA standard day + 10K

[agodemar]

This is an example of TSFC:

[seanmcleod]

@agodemar the pull request was merged last night. I've just submitted another pull request which bypasses the TSFC correction if the user supplies a TSFC function. The assumption is we don't know what corrections/denormalisations may or may not be required, so the user needs to provide them in the TSFC function if need be.

Based on the source code implementation we went with it does mean the example I posted earlier won't work as is.

So previously I suggested you would add your TSFC function along these lines in the turbine engine model file.

  <function name="TSFC">
    <table>
      <independentVar lookup="row">velocities/mach</independentVar>
      <independentVar lookup="column">atmosphere/density-altitude</independentVar>
      <tableData>
             -10000     0     10000   20000   30000   40000   50000   60000
        0.0  0.2        0.3   0.4     0.5     0.6     0.7     0.8     0.9
        0.2  0.3        0.4   0.5     0.6     0.7     0.8     0.9     1.0
        0.4  0.4        0.5   0.6     0.7     0.8     0.9     1.0     1.1
        0.6  0.5        0.6   0.7     0.8     0.9     1.0     1.1     1.2
        0.8  0.6        0.7   0.8     0.9     1.0     1.1     1.2     1.3
        1.0  0.7        0.8   0.9     1.0     1.1     1.2     1.3     1.4
      </tableData>
    </table>
  </function>

Now with the latest commit you would replace the current <tsfc> number </tsfc> element with something along these lines:

  <tsfc>
    <table>
      <independentVar lookup="row">velocities/mach</independentVar>
      <independentVar lookup="column">propulsion/engine[#]/thrust-lbs</independentVar>
      <tableData>
        -10000     0     10000   20000   30000   40000   50000   60000
        0.0  0.2        0.3   0.4     0.5     0.6     0.7     0.8     0.9
        0.2  0.3        0.4   0.5     0.6     0.7     0.8     0.9     1.0
        0.4  0.4        0.5   0.6     0.7     0.8     0.9     1.0     1.1
        0.6  0.5        0.6   0.7     0.8     0.9     1.0     1.1     1.2
        0.8  0.6        0.7   0.8     0.9     1.0     1.1     1.2     1.3
        1.0  0.7        0.8   0.9     1.0     1.1     1.2     1.3     1.4
      </tableData>
    </table>
  </tsfc>    

I've replaced atmosphere/density-altitude with propulsion/engine[#]/thrust-lbs just to demonstrate how you would go about making use of the current engine's thrust for example.

@bcoconni although I like the FGParameter implementation we went with, I'm just wondering whether this will be a bit more cryptic for users who hear (without seeing full proper documentation, assuming they would read it) that they can supply a TSFC function, take a look at an existing engine model and create a TSFC function in the style of IdleThrust, MilThrust etc.

  <function name="MilThrust">
   <table>
    <independentVar lookup="row">velocities/mach</independentVar>
    <independentVar lookup="column">atmosphere/density-altitude</independentVar>
    <tableData>
          -10000       0   10000   20000   30000   40000   50000   60000
     0.0   1.2600  1.0000  0.7400  0.5340  0.3720  0.2410  0.1490  0.0
     0.2   1.1710  0.9340  0.6970  0.5060  0.3550  0.2310  0.1430  0.0
     0.4   1.1500  0.9210  0.6920  0.5060  0.3570  0.2330  0.1450  0.0
     0.6   1.1810  0.9510  0.7210  0.5320  0.3780  0.2480  0.1540  0.0
     0.8   1.2580  1.0200  0.7820  0.5820  0.4170  0.2750  0.1700  0.0
     1.0   1.3690  1.1200  0.8710  0.6510  0.4750  0.3150  0.1950  0.0
     1.2   0.0000  0.0000  0.0000  0.0000  0.0000  0.0000  0.0000  0.0
    </tableData>
   </table>
  </function>

[bcoconni]

@bcoconni although I like the FGParameter implementation we went with, I'm just wondering whether this will be a bit more cryptic for users who hear (without seeing full proper documentation, assuming they would read it) that they can supply a TSFC function, take a look at an existing engine model and create a TSFC function in the style of IdleThrust, MilThrust etc.

Yes but the thing is that the tag <tsfc> was already existing and we can't remove it for backward compatibility reasons.

So in my opinion it would be weird that the TSFC could be specified with <tsfc> if it's a number and with <function name="TSFC"> if it's a function. With the current implementation, whether the TSFC is expressed as a number or as a function it is specified under the tag <tsfc>.

[seanmcleod]

Well there is some sort of similar precedent 😉

In terms of a milthrust element and separate function.

<turbine_engine name="CFM56">
  <milthrust> 20000.0 </milthrust>
  <bypassratio>     5.9 </bypassratio>
  <tsfc>            0.657 </tsfc>
  <bleed>           0.04 </bleed>

  <function name="MilThrust">
   <table>
    <independentVar lookup="row">velocities/mach</independentVar>
    <independentVar lookup="column">atmosphere/density-altitude</independentVar>
    <tableData>
          -10000       0   10000   20000   30000   40000   50000   60000
     0.0   1.2600  1.0000  0.7400  0.5340  0.3720  0.2410  0.1490  0.0
     0.2   1.1710  0.9340  0.6970  0.5060  0.3550  0.2310  0.1430  0.0
     0.4   1.1500  0.9210  0.6920  0.5060  0.3570  0.2330  0.1450  0.0
     0.6   1.1810  0.9510  0.7210  0.5320  0.3780  0.2480  0.1540  0.0
     0.8   1.2580  1.0200  0.7820  0.5820  0.4170  0.2750  0.1700  0.0
     1.0   1.3690  1.1200  0.8710  0.6510  0.4750  0.3150  0.1950  0.0
     1.2   0.0000  0.0000  0.0000  0.0000  0.0000  0.0000  0.0000  0.0
    </tableData>
   </table>
  </function>

[bcoconni]

Not quite so. Since the number specified in <milthrust> is multiplied by the table MilThrust.

jsbsim/src/models/propulsion/FGTurbine.cpp

Lines 432 to 433 in a00129a

	if (el->FindElement("milthrust"))
	MilThrust = el->FindElementValueAsNumberConvertTo("milthrust","LBS");

jsbsim/src/models/propulsion/FGTurbine.cpp

Line 483 in a00129a

MilThrustLookup = GetPreFunction(property_prefix+"/MilThrust");

jsbsim/src/models/propulsion/FGTurbine.cpp

Line 201 in a00129a

milthrust = (MilThrust - idlethrust) * MilThrustLookup->GetValue();

I guess this design has been chosen to allow modifying the dry thrust without having to modify the MilThrust table. I guess this is mainly due to the fact that most users have no clue about how to generate a new table MilThrust. So the exact same table is copied over from one model to another.

For TSFC, the situation is different: either you know what you're doing and you use a table/function or you don't and you use a number that you've gathered from data collected over the internet.

[seanmcleod]

Yep, that's why I mentioned 'some sort of similar..', in terms of a user taking a look at an example engine model file and seeing an element and a function with the same name, in this case internally they're multiplied.

In my original implementation rather than a multiplication if both were specified the function overrode the element, potentially confusing, or either one could be specified. In the current implementation if both a tsfc number element and a function element are present the one that appears first takes precedent.

[bcoconni]

I guess this is the kind of limits you bump against when you have to deal with legacy 😃

[seanmcleod]

@agodemar the commit to only perform the temperature and thrust correction/denormalisation when using the single tsfc value in the <tsfc> element and not when the user provides a function for tsfc has just been merged in.

[agodemar]

@seanmcleod Just as a recap: Now users can use a single value in <tsfc> element as usual, or they can provide a function in <tsfc>. In the latter case the interpolated values at runtime are used with no further scaling/corrections.

[seanmcleod]

Correct, although to be pedantic there may not be any interpolation going on depending on the nature of the user supplied function, i.e. there is no requirement for there to be a table with interpolation, the function may simply be a formula using some input properties without any table lookups.

[agodemar]

Of course

[seanmcleod]

Oh, @agodemar one more thing, as @bcoconni pointed out there is one more case where there is some code/logic currently that will override what you may want to achieve with a TSFC function, and that's the idle fuel flow case.

Regarding the fuel consumption at idle, my point is the same than for the temperature correction: the user who specifies TSFC with a table will most likely provide data that cover idling as well. In that case, that user doesn't want FGTurbine to take over the TSFC tables with the code:

jsbsim/src/models/propulsion/FGTurbine.cpp

Line 525 in a00129a

IdleFF = pow(MilThrust, 0.2) * 107.0; // just an estimate

jsbsim/src/models/propulsion/FGTurbine.cpp

Line 225 in a00129a

if (FuelFlow_pph < IdleFF) FuelFlow_pph = IdleFF;

So my idea is that these 2 lines of code will end up in the class FGSimplifiedTSFC as well. The point being that this correction will only be applied when <tsfc> is specified with a number.

[agodemar]

Not sure when all this gets into the released binaries

[bcoconni]

Bleeding edge binaries are available in our Rolling Release.
Automatically compiled, tested and deployed each time a commit is pushed.

[bcoconni]

Freshly baked from GitHub Actions 🍞 🧑‍🍳 😄

[seanmcleod]

Been wondering how much C02 we generate for each commit...

[bcoconni]

In an constant effort of reducing JSBSim carbon footprint, I have just added a feature to skip the CI workflow when it is not relevant (docs modifications, update of README.md, ...). For that, you just need to add [skip ci] at the beginning of the commit message.

(See the commit message of commit 56c4e62 for an example)