Mklemme

member
  • Content Count

    21
  • Joined

  • Last visited

Community Reputation

9 Neutral

About Mklemme

  • Rank
    Flight Student - Groundwork

Recent Profile Visitors

920 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. 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.
  11. Hi, Since upgrading to v1.26, I also sometimes get this error message. In my case it seems related to whether the departure runway has a SID with defined end-points (ie not a vector SID). For example, tonight I was planning KEWR-EHAM; when selecting runway 22R for departure PFPX found a route ok using the PORTT3 SID to SBJ, etc. This SID is only available for runway 22L/R. However, when I switched the departure runway to 04L the route finder could not find a valid route. For runway 04L at KEWR, there are no SIDs that have fixed end-points, ie all SIDS off 04R are vector SIDs. Interestingly, even if I input a first fix (ie MERIT) into the Via box in the advanced route finder, PFPX could still not generate a route and gave me the error message. I am using NG 1605. Although I haven't tested at other airports, it may be that lack of a SID with defined end-points/transitions from the selected departure runway has something to do with this error. Hope this is helpful. Kind regards, Michael.
  12. Mklemme

    PFPX Profiles By FlyPrecisely

    Hi Mykyta, thanks, I hadn't spotted the other thread regarding this topic. It seems the developers are aware of the issue so will await their fix. Regards Michael.
  13. Mklemme

    PFPX Profiles By FlyPrecisely

    Hi Mykyta, Many thanks for the very detailed additional aircraft profiles for PFPX, especially the latest ones for the 747-400. However, I have a question: do your profiles adjust for non-ISA conditions? I just planned a flight from KSFO-EDDF using your 747-400 PW4056 profile with a M.84 cruise, but I noticed in the OFP printout that the TAS at FL390 remained constant at 482 knots although the temperature deviations at this cruise altitude ranged from ISA+15 to ISA-1 so there should have been some variation in TAS (typically 1k change per 1 degree deviation from ISA). Thanks again, Michael.