SWA OFP format issues

Hi @SimBrief! First off I would like to say, thank you for fixing the flap issue on the SWA formatted dispatch releases!

That being said, I noticed a a few different issues with the SWA format OFP (dispatch release).

Issue #1. ATOG (Allowed Takeoff Gross Weight) is not being calculated correctly on the SWA formatted dispatch release (OFP).

I posted a picture depicting the issue at hand since its a bit complicating of a topic.

The ATOG calculated at the top of the picture is incorrect. It says 143.4 and LMT code is T (takeoff). What this SHOULD mean is that based off of how the dispatcher planned this release, the absolute heaviest you can legally and safely takeoff is 143.4 (except that is incorrect. Keep reading to find out why). In this case, the ATOG SHOULD be the exact same as the green highlighted weight on the bottom of the screenshot (Since the ATOG is limited by T (takeoff).

Think of ALL 3 of those weights at the bottom of the screenshot as TAKEOFF weights (TAKEOFF limited takeoff weight, LANDING limited takeoff weight, and ENROUTE limited takeoff weight/“Driftdown”).

Hypothetically speaking, just as an example, if the ENROUTE limited takeoff weight was the lowest number of the 3 weights highlighted in the screenshot, then the ATOG would be the same as the ENROUTE limited takeoff weight, in this case 150.6, and would have an LM code of E. (LM code of T = ATOG is Limited by Takeoff, LM code of L = ATOG is Limited by Landing, and LM code of E = ATOG is Limited by Enroute).

So the LANDING limited takeoff weight should not be 129.2. Rather, in this case it should be 150.7 (150.7 because 129.2 + 21.5 = 150.7). If the LANDING limited takeoff weight was actually 129.2, the flight would get canceled because that would mean the max allowed landing weight would be 107.7 (129.2 - 21.5 = 107.7).
NOTE: I keep mentioning 21.5 because, on this release, the ENROUTE BURN is calculated as 0215 (21.5 or 21,500lbs).

So in the screenshot provided, the TAKEOFF limited takeoff weight is 139.8 (limited by climb - C, in this case), the LANDING limited takeoff weight is 150.7 (limited by structure - S, in this case), and the ENROUTE limited takeoff weight is 150.6. Out of those 3 weights, 139.8 is the most restrictive and THEREFORE the ATOG is 139.8 (limited by Takeoff - T).

So the calculated ATOG at the top of the screenshot (143.4) is incorrect and exceeds the real ATOG of 139.8 by 3,600lbs! thats a very big deal!

Is there anyway we can get this resolved?


Issue #2. the TLR implementation is a fantastic new feature! However, it seems that simbrief only attaches FULL TLRs to the release… IRL the pilots wont get a full TLR unless ACARS is INOP or the aircraft is at a gate that doesnt have an ACARS signal. Is there any chance we could also have a LIMITED TLR option (ive attached a screenshot of that the limited TLR looks like). Notice how little amount of data is on the Limited TLR compared to the Full TLR.

NOTE: This is a screenshot of a TEST Limited TLR and was NOT used for a real world flight. However, the format is still correct per real world.


Issue #3. I can’t seem to manipulate the takeoff and landing performance on the dispatch release (OFP) at all… I should be able to manually change the wind (defaults to CALM), temperature (defaults to current from METAR), altimeter setting (QNH) (defaults to current from METAR), runway condition code (defaults to 6-DRY for takeoff and defaults to 5-GOOD for landing), bleeds config (defaults to OFF), anti ice config (defaults to OFF), enroute ice (defaults to NO; enroute ice = for landing only), and flap setting (note: OPTIMUM defaults to flap setting that provides the highest ATOG for the flight (contingent upon runway length, of course) - for both takeoff and landing). Is there any chance this could get implemented so that we can properly plan our flights just like we do in the real world?


Keep up the great work and thanks for all that you do for us!

6 Likes

These would be great improvements to see!

1 Like

I would love to see those improvements made! Thank you Navigraph :slight_smile:

1 Like

I would like to see this change as it would help with realism as well as laying out information easier.

1 Like

I would also be really happy to see this change!

1 Like

Hi,

  • Issue # 1 → ATOG should be fixed now as per your guidelines.
  • Issue # 2 → The 737-600 and 737-700 should default to flaps 1 now if the runway permits.
  • Issue # 3 → An abbreviated TLR is not currently possible, maybe sometime in the future.
  • Issue # 4 → The ability to customize the default TLR parameters (winds, bleeds, runway condition, etc) is also not currently possible. No timeframe on when this might be added unfortunately.

Best regards,

1 Like

@SimBrief thank you very much for the speedy fix sir! I really appreciate your help!

One quick thing I just noticed when testing just now… the ATOG is not limiting the planned TOW, on the dispatch release (OFP), like it should be doing (i.e. when flight is weight restricted).

Attached is a screenshot of my dispatch release (OFP) showing ATOG has been exceeded by my planned takeoff weight. The system should automatically reduce the planned takeoff weight to never exceed the ATOG.

In this case, the TOW should be limited to 152900.

The system always prioritizes fuel over payload. So the system will first reduce PYLD until the TOW matches the ATOG. If that wasn’t enough, and the payload is reduced all the way to 0lbs (hypothetically speaking), then the next thing the system will do is start to reduce fuel in an attemp to get planned TOW down to ATOG.

If planned fuel drops below minimum required takeoff fuel, then the system will spit out an error and say unable to calculate due planned fuel being less than minimum required fuel for the flight.

In the example in the screenshot, the ATOG is exceeded by the Planned Takeoff Weight by 8,800lbs! Thats quite a bit!

Is this something we could get fixed possibly?


Thanks again for everything, Derek!

Hi, this is intentional. Years ago it was decided to not limit the ETOW in case of runway performance limitations. In other words, if landing or departing from a very short runway, SimBrief will not automatically reduce your TOW or LW. You’ll need to do this manually for now.

In your example, the max landing WT was limited due to field length (LMT = F). SimBrief will only reduce the planned TOW (and offload any excess payload/fuel) to respect the structural landing weight (LMT = S).

Best regards,

@SimBrief Interesting. Just curious what the reason was that you decided to do that for SimBrief. Because IRL the system will reduce the payload so that TOW doesnt exceed ATOG (no matter what the ATOG limitation is). IRL, it is illegal to send a release where the TOW exceeds ATOG , so I thought that would be a beneficial feature for SimBrief and its users.

@SimBrief Also, just curious, is this something that you think potentially could be added in the future for Simbrief? Or is this a “hard set-in-stone” kind of thing that Simbrief will never receive an update to include this type of realistic functionality that we have requested in this thread?

Once again, thank you for all that you do for the community. It is truly and immensely appreciated amongst all of us!

Hi, just for clarity. The TOW is already limited for max landing weight (in the case where ATOG = max structural landing weight + enroute burn). However TOW is not limited where ATOG is performance limited (either due to a short landing runway or short departure runway).

Until we can provide some finer control over the takeoff and landing conditions used in the ATOG calculation (which is a looooong way off), the decision to restrict the payload in such situations will be left to the dispatcher to do manually.

There are some tools on the Flight Options page to help make this easier. The takeoff and landing calculation widgets are already available by clicking the icon above the selected runways, and in the next update we’ll be adding a Briefing Preview feature which lets you view the full OFP before generating:

Best regards,

2 Likes

Hi @SimBrief. Thank you very much for the quick and detailed response! The briefing preview is great idea! Thank you very much for including this!!

Just curious, is there a proposed timeline on when the next update to simbrief is projected to go live?

As well, is this the same simbrief update that will be including the ability to change the First Officer’s name? (I saw there was a post about that request on the forums recently).

Lastly, will we be able to eventually toggle and manually change/adjust takeoff and landing performance data (such as bleeds config, flaps, anti-ice, etc…) on the dispatch release or will this remain an automatic feature only with Simbrief, going forward?

In a few days probably.

Yes.

This is probably a long way out, likely not this year at least.

Best regards,

1 Like

In order to do any of that you need to add specific child weights. One thing i love is adult pax is the avg adult pax + carry on avg weights. However child weight help is huge way with them being significantly less. If i planned a flight for a 175 pax and 24 of them are children i have to put 151 pax and then manually adjust the payload to take the child weights. This needs to be implimented as its been very looked over too.

@swaluver480 We actually dont plan child weights (also known as “half weights”, in the airline world) in dispatch normally speaking (unless we actually need to - which is pretty much never).

We do this to simplify the process and as well to plan more restrictive so that we reduce the chances of taking a delay due to being over weight when the crew runs their takeoff PWB.

If we are actually running into a weight restriction issue on the release, the crew can run their PWB on their end before boarding to see if we are actually going to be weight restricted (remember we always plan adults and one standard bag per adult, on the dispatch side.) Once the crew knows their actual payload or actual ZFW, they can call dispatch or ACARS us that info and we can give them an amended release with the new weights.

IRL, our dispatch planning software is incapable of planning kids on a flight unless we manually change the payload or ZFW to account for kids or less bags. However, we cant get that info without the PIC running the numbers for us and then giving us that information.

So simbrief is actually correct as is currently in that regard.

1 Like

Nah pilots dont adjust pwb at swa… Ops agents do then sends it through opsuite to aerodata then it goes to PWB (aerodata). I know a lot of ops agents and dispatchers at swa they both plan on child weights. Actually 95% of the time for HNL flights they rely on those weights planning to not oversell.

@swaluver480 Understood, I apologize, I should have been more clear I was not talking about SWA specifically… I meant more so in general.

The thing is, SABRE, SWIFT, Flight Keys… it doesnt matter which software the dispatcher is using to plan, they are unable to see, nor select, kids to plan. That has to be done with an adjusted ZFW or adjust payload from either the station or the PIC.

At my company (regional) the crew has to run PWB all on their own (including weight and balance). we dont have ops agents like SWA does.

So from an SWA perspective, the dispatcher would plan normally and then if the flight was running into weight issues, the ops agent would call the dispatcher and let them know of it and give the dispatcher updated kid weights and bag counts and then the dispatcher would have to manually adjust the payload (based off of the standard weights in the company’s weight and balance manual).

From there, the dispatcher would revise the release with updated performance calculations based off of the new adjusted zero fuel weight.

So, again, the way simbrief currently has the system designed is correct. You are not able to tell the system you have set amount of kids or set amount of bags. That is where the dispatcher has to do the math and MANUALLY adjust the payload/ZFW to get the correct number.

Does that make sense?

The process is a bit cumbersome but its actually realistic lol.

1 Like