Mklemme

member
  • Content count

    21
  • Joined

  • Last visited

Community Reputation

9 Neutral

About Mklemme

  • Rank
    Flight Student - Groundwork

Recent Profile Visitors

876 profile views
  1. Hi Bill, On the OFP where the takeoff and landing performance data is placed you see that FIELD is the limiting factor. This means that runway length or obstacle height for the given conditions is limiting the max allowable weight. So for takeoff, before the update and release the MTOW limit is the structural limit of the plane (ie 874,999 lb) whereas after the update and release the MTOW is reduced to 768,699 lb due to runway length available for the conditions, obstacle height, engine out requirements, etc. I can't explain the landing limit however as it is higher after update and release which shouldn't be the case, so maybe something has gone haywire in transposing the figures from TOPCAT to PFPX or there is an issue with the aircraft profile perhaps. Michael.
  2. On the topic of possible program 'enhancements', in terms of weather and flight planning, an additional feature I think would be really helpful is the ability to overlay radar returns/satellite images/sigmets/airmets etc on the PFPX planning map in order to adjust 'optimized' routes generated by PFPX to avoid severe wx areas (ie dense CB/TS buildups with tops >FL400). ATM I need to look for graphical deptiction of severe wx areas/advisories from external sources (ie Skyvector), whereas it would be nice if this could all be done interactively within PFPX and its flight planning map. Cheers, Michael.
  3. Mklemme

    Tracks not working

    Hi ganu88 Further to Stephen's reply, from my observations it seems that the PFPX algorithm has been set to ignore any organized track routing if that would give a flight plan distance c. 4% higher than the GC, in which case PFPX will ignore the track and give a GC routing. In your example above, the flight plan distance along Track E is around 9% more than the GC distance so is ignored by PFPX notwithstanding the more favorable wind situation. Anyway, let's hope the developers manage to address this issue sometime soon. BTW, it looks like NAX7147 is actually going via Track D tonight! Cheers Michael.
  4. Hi Gordon, The wind optimization feature in PFPX seems to be broken/disabled since v 1.28. Pls see below thread. Hopefully the developers are addressing the issue, but radio silence for some time now. Regards, Michael.
  5. Mklemme

    PFPX Profiles By FlyPrecisely

    This time with missing picture!
  6. Mklemme

    PFPX Profiles By FlyPrecisely

    Hello Mykyta and Duarte, I was also interested in the answer to this question regarding the higher fuel consumption vs. the PFPX estimate. I had a quick look at the detailed information Duarte provided for the flight and note the following which might help explain the variance. I plotted the fuel balance by waypoint for the actual flight and PFPX estimate (see chart below). The chart shows the fuel burn up to KOMUT is pretty close. Thereafter you can see actual fuel burn increases viz. PFPX. I noticed in the PFPX OFP that the mach speed is .78 at TABAX and KOMUT, but then it starts to decrease to .74 by TIMTO. If the actual flight was flown at constant .78 this could explain the increased fuel burn after KOMUT. It's could also be a conversion issue with how Cost Index 35 translates to TAS/M# in the Aerosoft FMC logic v. what's in the PFPX profile. The average fuel burn (ie kg/hr) for the cruise portion of the flight was around 25% higher than predicted by PFPX under similar weight and OAT conditions. Other than the speed issue noted above, it may be that the Aerosoft bus fuel burn is not modeled so accurately (ie as a function of weight, OAT, etc). I also noticed that the actual flight commenced descent well before the TOD point in PFPX (ie at TIMTO the actual flight was at FL252 whereas in PFPX it was still in cruise at FL380 at this point). Also the flight log shows a very strong wind of 101kts at TIMTO which is higher than the PFPX profile. A longer, slower descent would add to the fuel usage especially if there was more low level maneuvering than what PFPX assumes for the descent profile. Anyway, hope this is helpful in the analysis! Kind regards, Michael.
  7. Hi Christian, I have done some further testing with long-range flights and provide below a few observations that might help you track down the issue/resolution. 1. Flights involving defined tracks- ie NAT/PACOTS. If there are defined tracks in place between departure and destination, PFPX (using optimize route/minimum fuel track) will usually choose the track which is closest to the GC between departure and destination and not necessarily the most fuel efficient track. See below example for ANA7, KSFO-RJAA. PFPX (using Minimum Fuel Track) chose track F which is close to the GC (in yellow), resulting in an EET of 11:15, a wind component of -68kts and 82.7t fuel burn (left picture). The track actually used by ANA7 that day (as per Flightaware) was much further north (track C-right picture) giving a much lower wind component (-37kts) and shorter trip time/reduced fuel burn notwithstanding the much further ground distance of this routing. However, I've noticed that even with defined tracks, if the tracks have a longer ground distance than the GC (ie by say 3-4%) then PFPX auto routing will ignore the tracks and develop a random track close to the GC. 2. Flights not involving tracks. For routes without defined tracks (ie polar routings, North Atlantic above the OTS) PFPX always seems to generate a random routing more or less along the GC. See example below for UAL58 KSFO-EDDF. Left picture show PFPX derived track using optimize route, minimum fuel track, which is more or less along the GC. En-route time is 10:31, fuel burn 232klbs and wind component of zero (rare to see that!). Right picture shows the routing actually used by UAL58 this day, much further south picking up some tail wind, resulting in shorter flight time (10:15) and reduced fuel burn (228 klbs). In fact, I have planned this flight numerous times (>10) over the last month and PFPX invariably gives me the exact same routing every time (ie in the left picture below) no matter what the jet stream pattern for that day is. Hope the above is helpful and you are able to restore wind optimization within PFPX. Kind regards, Michael.
  8. Hi, Is it possibly also a Navdata issue? Strange that PFPX would generate the above routing via airways M771 and M772 as these are one-way, northbound only, at least as per the latest AIRAC cycle 1701, and thus shouldn't be chosen for a southbound flight. If you look at a few recent tracks of VHHH-WADD flights (ie on Flightaware) you will see they initially track more south-easterly out of VHHH to SABNO and then via A583, etc, in line with the routing in Stephen's email (#6) above. Cheers, Michael.
  9. Mklemme

    PFPX Profiles By FlyPrecisely

    Hi Mykyta, Thank you! Really appreciate your efforts in making these profiles. Cheers, Michael.
  10. Hi Joe, Glad to hear you got it working somewhat. It may be that once the track validity time has actually expired (in real time), PFPX no longer recognizes the track even if you set an earlier STD during the validity period. Let's see if the developers chime in. Cheers, Mike.
  11. Hi Joe, Check and make sure that the "Avoid Tracks" box isn't ticked in the advanced route planning menu. Next, what flight routing options are you selecting? PFPX may have determined a more 'optimal' route than the flex track BP12 would give based on winds, fuel burn, etc. You can always compare the OFP outcomes in terms of en-route time and fuel burn for the two routing options (ie BP12 v. the PFPX generated route above) to see which is the optimal/preferred. I have noticed on occasion that PFPX will not chose a defined track-routing (ie FLEX, NAT or PACOTS) if that would result in the total ground distance of the route being more than a certain percentage (usually around 4%) above the great circle distance between departure and destination, even if the track-routing would be more optimal. In other words if BP12 routing is most optimal but its ground distance is more than, say, 4% above the great circle distance (between YBBN-YPPH) then PFPX for some reason will not select it and will instead generate a routing which is within the 4% 'limit'. This can give spurious results in PFPX when the jet stream is far away from the great circle between airports by ignoring the most optimal routing (in terms of fuel burn) because it is too far removed from the GC. Hope I've explained this clearlyl. Cheers Mike.
  12. Hello, Was planning a flight from EGLL-KMIA today and noticed something odd with the W/B NAT tracks (see attached picture). 1. Three tracks are missing from the map; Tracks A, C and D are not displayed although they are included in today's NAT track message. The other tracks (except B ) are displayed correctly. 2. The entry point for track B, PIKIL, is not properly located on the map, shown as being well east of Europe (if you follow the green line it eventually ends up near Perth, Australia). This is probably a database error (just updated to Navigraph cycle 1611) wrt to PIKIL. Regards, Michael.
  13. Mklemme

    NATs don't work

    Hi Stephen, Thanks, but I don't understand the point about lack of 'suitable directs'. It seems PFPX is generating direct routings (without airways), for example between the various Lat/Lon waypoints in my example (ie CASPR-3570N-4160N-4650N-5240N, etc), so I don't see why it can't generate a direct routing (in the absence of airways) to the entry point for the most optimum NAT and then follow that track. Instead it has created a routing which cuts across all the NATs and which isn't even an optimal routing (I thought maybe I had ticked 'Ignore Tracks' in the route finder but this wasn't the case). If I understand the resolution in the link you posted, this requires first selecting a NAT and then manually routing between the beginning/end of that NAT and your origin/destination. This seems like a tedious solution, especially as there can be many tracks on a given day (last night there were 8 E/B ones) and to find the optimum one would require a trial and error process on each one to see which is best. I thought this was what PFPX was for! Again, this feature (auto route optimization) seemed to be working fine for me prior to changing to V1.28 so maybe something was changed in that version which is giving these results. I have also noticed on random track routings that PFPX will now more or less generate a route close to the great circle track (eg EDDF-KSFO) even if it is smack into a 100kt headwind rather than deviate from the GC to obtain a more (wind) optimised solution. Michael.
  14. Mklemme

    NATs don't work

    I have a similar problem, using v1.28. Planning a flight from KMIA-EGLL using the Optimized Route, Minimum Fuel Track option to determine a routing. The result is a crazy path which cuts across all the E/B NAT tracks- see screenshot! If I manually build a route via Track Y, I a get a better result (less time, less fuel) than the result given by PFPX so-called Optimized planner. Something with the route selection/optimization algorithm seems to have gone a bit haywire with this version of PFPX as I didn't have these issues with the prior version.
  15. Hello, I recently updated from v1.26 to v1.28 and noticed that route planning now doesn't seem to be wind optimized anymore. I was planning a flight KSFO-RJAA and chose Minimum Fuel (MFT) under Find Route, Advanced Route Planner. The result gave me a routing very close to the GC with a headwind of 84kts. I then tried Minimum Time and Minimum Distance options just for fun and got exactly the same routing, fuel burn and enroute time as for MFT. The attached screenshot shows the results for these three scenarios. In addition I also computed a flight using one of today's KSFO-RJAA routings from Flightaware. This gave me a much more southerly track avoiding the jetstream with flying time and fuel burn of 45 minutes/20,000lb less than under the PFPX ' optimized' plan (see last listing under results). Wind optimized routing seemed to be working well with v1.26, is there a new setting or option that I need to set to have this back in v1.28? Many thanks Kind regards, Michael.