Closed zebengberg closed 1 month ago
I'll think about this more today.
We need some kind of solution for this. I think the proposed ISA approach will work for temperature since the AP is less sensitive to temperature. But the sensitivity to wind may be too high to assume true_airspeed is true_groundspeed (Can we check this?)
Its clear we need the gridded data for any kind of parcel tracking in the contrail models, but for the aircraft performance calculations, we only need meteorological data pointwise. Would it make sense to integrate with some kind of point-wise meteo api for the aircraft performance? I'm thinking of OpenMeteo or similar. We'd pass in points and request the data at those points for the forecast perscribed? Unfortunately a bit of a hack.
Check out this pull request on
See visual diffs & provide feedback on Jupyter Notebooks.
Powered by ReviewNB
I'll think about this more today.
We need some kind of solution for this. I think the proposed ISA approach will work for temperature since the AP is less sensitive to temperature. But the sensitivity to wind may be too high to assume true_airspeed is true_groundspeed (Can we check this?)
Its clear we need the gridded data for any kind of parcel tracking in the contrail models, but for the aircraft performance calculations, we only need meteorological data pointwise. Would it make sense to integrate with some kind of point-wise meteo api for the aircraft performance? I'm thinking of OpenMeteo or similar. We'd pass in points and request the data at those points for the forecast perscribed? Unfortunately a bit of a hack.
Good point. Internally, we often have met data going down to 500 hPa (=~ 18000 ft). So we'd be missing the first ~15 minutes of a flight trajectory after takeoff. Right now, running something like PSFlight
over the trajectory would ignore these first 15 minutes and estimate fuel burn as if the flight took off 18000 ft. So even if the model's fuel burn estimate at low-altitude is inaccurate on account of the true airspeed estimate, I think it would still better than ignoring these waypoints. I can try to quantify this.
My dream is have a met-interpolation REST API whose only responsibility is pointwise interpolation against gridded data. This would be fast (the user would only have to send coordinates, and only receive a handful of fields) and would save the user from downloading huge amounts of gridded met data when they only care about a few points.
This looks good to me! Filling u and v with zeros seems like the right decision. (I think the primary goal is to avoid having zero fuel burn below the bottom of the met data, and the error from setting u and v to zero should be small by comparison.) I left one comment about a possible improvement to temperature filling--up to you whether that seems worthwhile.
Edit: Marc seems less confident than I am that setting u = v = 0 is a reasonable solution... so maybe it is worth validating a bit more carefully.
I poked at this a bit more (nothing particularly rigorous). Below is a scatter plot of ~140000 waypoints in the climb phase from a fleet of ~6000 flights. I ran them all through PSFlight
with these two new flags enabled. The lowest-altitude met level in my weather data is around 22000ft. I used the red vertical line to show this in my plot. The fuel flow to the left of this line is computing using TAS = groundspeed and temperature = ISA. The fuel flow to the right is computing by interpolating against the met data.
The predictions don't go haywire to the left of the line, but you can see that the spread in the fuel flow distribution is larger compared with the met-interpolated points.
@thabbott I'm going to merge this branch, but we can hold off on making a release until we're a little more certain that this gives an improvement to our aircraft performance estimates.
Add experimental
interpolation_fill_low_alt_with_isa_temperature
model parameter. When set toTrue
, models withGeoVectorDataset
sources will fill points below the lowest altitude in themet["air_temperature]
data with the ISA temperature. This is useful for aircraft performance calculations when the met data does not extend to the surface. In this case, we can still estimate fuel flow and other performance metrics through the entire climb phase. By default, this parameter is set toFalse
.Tests
make test
)@thabbott
The main motivation for this PR is to compute aircraft performance estimates (most notably, fuel flow and aircraft mass) below the lowest-altitude met level. To do this, we need air temperature (which we approximate with ISA temperature). But we also need u and v wind to compute the true airspeed. How should we handle these unknown winds? One crude option is to assume no wind below the lowest-altitude met level (in other words, set true airspeed to true groundspeed).