Some airports like LSGK and EGLC have a fairly short TORA compared to the ASDA.
I’ve noticed the V2 point calculated by Simbrief’s calculator seems to generally (and probably coincidentally) place V2 in the vicinity of the “stop distance” point (usually right before or right after), and often rather “far” from Vr.
As a result, takeoff is often TORA-limited at these airports despite the higher available ASDA.
I wanted to be sure the V2 placement is accurate/realistic and Simbrief is not artificially limiting the takeoff performance by placing V2 too far?
Unfortunately I don’t have a known-good software to compare it too so not sure how to proceed, but I wanted to bring this up in case someone else can shed some more light on this.
It shouldn’t be artificially limiting the performance at all. There are some limitations when it comes to the graphical depiction, but the actual calculation (speeds and performance limitations) should correctly consider the different ASDA/TORA distances.
The runway diagram and distance markers in the graphical depiction are based on the TORA, but note in your example how the Stop Distance marker is placed almost at the runway end, yet lists a margin of 324 meters. This is because of the longer ASDA, which isn’t depicted on the diagram.
When it comes to the placement of V2, note that this distance is based on an engine failure at V1 and a subsequent rotation and climb to 35 feet in the air. So for the portion between V1 and V2, you have less thrust (1 engine failed), are accelerating less quickly, and at the same time need to rotate and climb to 35 feet. So it’s normal for the gap between V1 and V2 to be quite a bit larger.
It’s also normal for the accelerate-stop and accelerate-go distances to match up most of the time. In most cases this is the optimal calculation result, normally referred to as a Balanced Field Takeoff.
With all that said, in SimBrief the distance markers are mainly determined after the raw V-speeds and performance limits are calculated for the given conditions. They should be close to reality, but are still estimates at the end of the day. They don’t affect the validity of the raw speeds and weight limits however.
Oh, I think I figured out what I think might actually be limiting takeoff performance (as I understand it, unnecessarily) on Simbrief at airports where the TORA is significantly shorter than the runway length.
It seems I incorrectly focused on ASDA where it’s TODA that’s not being fully/correctly accounted for.
Take-Off Run Available (TORA)
TORA is the total length of runway available for an aircraft to accelerate from brake release to liftoff and half the horizontal distance to climb to 35 ft.
At first glance, it looks like Simbrief’s calculation might attempt to ensure that, in case of engine failure at V1, the aircraft reaches 35 feet AGL by the end of the TORA (so the whole distance between the Vr and V2 points) when it only needs to ensure said elevation is reached by the end of the TODA instead (with only half the distance between the Vr and V2 points required to fit within the TORA itself).
Using as an example takeoff from EGLC with current weather, but switching to a dry runway for simplicity.
RJ1H taking off with bleeds off, optimal flaps (resulting in flaps 30), anti-ice auto (resulting in A/I off). Simbrief’s indicated maximum weight for takeoff given the conditions is 39,736 kg.
In the following graphics, I’ve hand-placed the very approximate halfway point between the distance where Vr is reached and the distance where V2/35AGL is reached.
Starting at 39,700 kg, V2/35AGL is reached just within TORA, but the equidistant “halfway” point from Vr occurs somewhat significantly earlier:
There, V2/35AGL is reached before the end of the TODA and the equidistant “halfway” point appears to be reached before the end of the TORA as well. Plus it seems like a flaps 18 takeoff is possible as well (the increased V-speeds and stop distance reflecting the optimum flaps having selected 18 in this case).
Hi Tim, yes you’re correct, currently the TODA is not considered. The tool tries to reach V2/35’ by the end of the TORA.
While obviously not perfect, the logic here is that because SimBrief can’t account for obstacles (no obstacle database available), limiting ourselves to the TORA is more conservative. And when comparing with real-world tools (which do account for obstacles), using the TORA-only approach tended to give results that were the closest match.
This kind of makes sense when you think about it:
Airports with a large split between TORA and TODA seem to be more likely to have obstacles along the takeoff path (perhaps they don’t bother to pave the clearway portion because of these obstacles).
At these airports, real world tools initially take credit for the TODA, but often end up limiting their TOW due to obstacles instead.
SimBrief arrives at a similar MTOW result by not taking credit for the TODA, which seems to (more or less) match the obstacle penalty that real-world tools give.
At airports where TORA equals TODA, this tends to be associated with less obstacles in the takeoff path, so SimBrief ends up matching real world tools in both cases.
Obviously this approach is based on some pretty big assumptions, and there are surely airports without obstacles that have a long clearway for example. But I still think this is the best compromise since we (at least currently) don’t have any obstacle data.
And for what it’s worth, I strongly suspect EGLC would be very obstacle limited. I don’t have access to real world tools for this unfortunately, but I’d be shocked if they let you use the entire TODA without becoming obstacle limited instead.
Most US operators don’t consider clearway… for us and where and what we fly, it is not really necessary. We do run off of some very short runways (KSNA is one),
