{ "id": 6055, "title": "Simulator Issues and Bug Reports", "url": "/competitions/flight2-main/discussion/6055", "author_name": "", "post_date": "2013-10-19T02:43:34.063Z", "votes": null, "comment_count": 115, "views": 56858, "content": "

Please use this thread to report any bugs or issues you find with the Simulator in a constructive manner. We've corrected many of the issues you've found previously, but as we've now added more features new bugs may need to be addressed.

\n

Thanks for participating in Flight Quest!

", "messages": [ { "id": "32428", "postDate": "10/19/2013 02:43:34", "content": "

Please use this thread to report any bugs or issues you find with the Simulator in a constructive manner. We've corrected many of the issues you've found previously, but as we've now added more features new bugs may need to be addressed.

\n

Thanks for participating in Flight Quest!

", "rawMarkdown": "", "votes": null }, { "id": "32430", "postDate": "10/19/2013 04:33:41", "content": "

When will the previous topics of the forum be available?

", "rawMarkdown": "", "votes": null }, { "id": "32437", "postDate": "10/19/2013 13:25:00", "content": "

Flight Quest 2 - Milestone forums can be found here. I will create a link to this on the main page as well.

", "rawMarkdown": "", "votes": null }, { "id": "32449", "postDate": "10/20/2013 00:53:11", "content": "

I'm afraid my download of 'FQ2DataRelease2_AggregateTrain' (.zip version) stopped at 99% with 1 second remaining).  Would it possible to break this file up into smaller pieces please.

\n

Thanks in anticipation.

\n

A second try was successful.

\n

 

", "rawMarkdown": "", "votes": null }, { "id": "32458", "postDate": "10/20/2013 09:42:25", "content": "

We're still waiting for pointers on how arrival files (actualLandings, actualTakeoffs and groundConditions) are built, as promised. Plus, with the new simulator, I think it would be nice to have pointer also on which files you used to generate turbulence files and which thresholds are in effect when you choose what to add to those files...

\n

Thank you.

\n

Edit: I've seen now that turbulence files are already available.

", "rawMarkdown": "", "votes": null }, { "id": "32462", "postDate": "10/20/2013 14:26:55", "content": "

So, are we going to get weather files? Partial weather files? (They aren't in "FQ2 partial Simulator Data".)

\n

Incidentally, I notice that some useful routines have been moved into 'Serialization.fs' so that they can be called from the dll. That will help me make my code cleaner. I appreciate it.

", "rawMarkdown": "", "votes": null }, { "id": "32478", "postDate": "10/21/2013 08:13:54", "content": "

Hello, admins.

\n

I've found an issue with the restricted zones handling in the simulator, details below.

\n

I've run the simulator on the test flights (without weather, i.e. zero wind), and after analyzing the generated flight logs, I've found cases when a flight enters a restricted zone, but does not get aborted (continues normally). The specific flight ID I found is 308736069, it has InRestrictedZones=1, but continues flying.

\n

By looking at the simulator code, in Flight.fs line 158 I can see:

\n

else if reachedWaypoint then
Some(Complete)
else if needToAbort parameters updatedState updatedSteps reachedWaypoint then
Some(Failed)

\n

It looks like you should change the order of the state checks. Right now, if the flight reaches a waypoint, the fact that it's in a restricted zone is ignored.

\n

Please look into this.

", "rawMarkdown": "", "votes": null }, { "id": "32491", "postDate": "10/21/2013 18:57:21", "content": "

Hi Charango,

\n

Yep, these state checks should be moved around.  I've updated our evaluation simulator and re-scored the leaderboard.  We won't release an update to all competitors for another day or two as more bugs may arise or performance improvements may be made. 

\n

Thanks

", "rawMarkdown": "", "votes": null }, { "id": "32496", "postDate": "10/21/2013 22:45:40", "content": "It would be nice if the simulator had an option to ignore the weather, groundconditions, takeoffs, and landings. These files are not included in the Simulator Data, and until we figure out how to generate them we can't run the simulator, right?\n\nBTW, it would be mighty nice if there was a script to generate these missing files from the Aggregate information at the cut-off time, perhaps using some trivial rules like the weather doesn't change and the planes travel in a straight line to their destination at current speed with no wind or restricted zones etc. Otherwise it is very hard for a beginner to start on this competition. The point is for us to do AI and not file conversion, right?", "rawMarkdown": "", "votes": null }, { "id": "32499", "postDate": "10/21/2013 23:48:49", "content": "

Even if you are willing to do file conversion, you will find it challenging to extract anything from the current content of

\n

http://soostrc.comet.ucar.edu/data/grib/rap/

\n

According to the forum, it's been some 12 hours since I pointed out that the RAP files are all gone, and I am getting a little concerned. Helpful suggestion to the effect that I don't know the difference between files and folders notwithstanding, they really are gone. I know they used to be there, so presumably there are some teams who do have the data needed to create leaderboard submissions, and plenty who do not.

\n

Kaggle must reasonably have the weather files needed to score those submissions, and presumably the RAP files used to create them. May I suggest posting at least one of those file sets?

", "rawMarkdown": "", "votes": null }, { "id": "32500", "postDate": "10/21/2013 23:52:29", "content": "

Hi TecS,

\n

Not sure what you're talking about ... I just looked and the files are there and they are 30 M as stated on the webpage.

", "rawMarkdown": "", "votes": null }, { "id": "32501", "postDate": "10/22/2013 00:07:39", "content": "TecS,\n\nYes, I can also download the GRIB files from the website you pointed, but not that I'm any wiser for it. These files are even more complicated than the provided Aggregate files :-(", "rawMarkdown": "", "votes": null }, { "id": "32502", "postDate": "10/22/2013 00:10:53", "content": "

This is what that folder looks like to me...

\n

Earlier it occurred to me that maybe my IP was blocked for some reason, so I had a look through a proxy; no difference.

\n

Now I wonder if maybe they are blocking IPs from outside North America (I'm on the other side of the pond).

", "rawMarkdown": "", "votes": null }, { "id": "32503", "postDate": "10/22/2013 00:13:07", "content": "Did you try clicking on the link that says "hybrid" ? :-)", "rawMarkdown": "", "votes": null }, { "id": "32504", "postDate": "10/22/2013 00:16:19", "content": "

:P

\n

I downloaded a few of those files yesterday to have a look, while I was deciding whether it would be worth parsing them on my own, so yes, I clicked that link. Whatever happened, happened overnight.

\n

Edit:

\n

...and now (5 minutes later?) I'm even more puzzled, because I see files again. o.O

\n

I swear I'm not on anything stronger than tap water. No idea what's going on, but I'm grabbing those files as long as it lasts.

", "rawMarkdown": "", "votes": null }, { "id": "32505", "postDate": "10/22/2013 01:18:10", "content": "

Except... http://soostrc.comet.ucar.edu/data/grib/rap/20130920/

\n

Do you see that one? I don't now, which is particularly ironic since I have a few files from it since last night.

\n

And problematic if it stays gone, because it is one of the dates in the test set.

\n

 

", "rawMarkdown": "", "votes": null }, { "id": "32507", "postDate": "10/22/2013 01:37:13", "content": "

We've released a complete set of simulation data for Sep 10th, the day previous to the test days. Soon we'll also release the partial weather data (one snapshot of wind pre-cutoff for each day) as we did for the milestone prize. 

\n

More info about how takeoff, landing, and ground condition files are created can be found here.  As you can see, we're just doing simple queries of the flight data.

\n

 

\n

 

\n

 

", "rawMarkdown": "", "votes": null }, { "id": "32510", "postDate": "10/22/2013 03:28:06", "content": "Hi Nick,\n\nThanks for providing the data for Sep 10. Could you also please explain how the Weather files were constructed? If not the script then at least the set of files that were used as input.", "rawMarkdown": "", "votes": null }, { "id": "32515", "postDate": "10/22/2013 06:27:21", "content": "

I've tried to use the simulator in my code and I see terrible performance compared to the old version. Is anyone else experiencing the same problem, or am I doing something wrong?

", "rawMarkdown": "", "votes": null }, { "id": "32516", "postDate": "10/22/2013 06:41:09", "content": "

Tecs,

\n

partially agree:

\n

1) I am in Norway and can download the grib2-files.

\n

2) But the one fron 20.09.20013 is not there if you look at the index: (http://soostrc.comet.ucar.edu/data/grib/rap/) it just jumps over (=there is one for the 19th and another entry for the 21st).

\n

3) It also shows me empty folders like your png, but when I click on hybrid everything is there.

", "rawMarkdown": "", "votes": null }, { "id": "32523", "postDate": "10/22/2013 12:52:34", "content": "Well, the link for the Sep 20th GRIB files now works. I did notice that this link was not working earlier. Anyway, before I download 100s of GBs of data, it would be helpful if a kaggle admin could confirm that these files were indeed used for constructing the simulator's weather files :-)\n\n
\n\nI noticed that some of these files contain weather forecasts valid for the next 6-8 hours. So, it seems like all we have to do is get the forecast as of the cuttoff time on the test dates and plug it into the Simulator. I still don't understand though why this data was not included in the first place.", "rawMarkdown": "", "votes": null }, { "id": "32528", "postDate": "10/22/2013 13:46:21", "content": "

Nimar, see here: https://www.gequest.com/c/flight2-milestone/forums/t/5714/relation-between-grib-files-and-simulator-weather-files

\n

 

\n

There you find all the info how the files were obtained and how to read them.

", "rawMarkdown": "", "votes": null }, { "id": "32533", "postDate": "10/22/2013 15:24:18", "content": "

September 20 works for me too now.

\n

I have a hypothesis: it's more than one server. Maybe they are doing round-robin DNS
to balance the load, or they pointed the subdomain to a new machine after I started
looking.

\n

They use a very long Time To Live of 172800 seconds (48 hours), so if a server
you're looking at starts misbehaving, you're stuck on it for up to that long, or until
you refresh your DNS cache. Others who go there for the first time in at least 48 hours
get a fresh DNS record, and then they think you're nuts. :P

", "rawMarkdown": "", "votes": null }, { "id": "32535", "postDate": "10/22/2013 15:50:03", "content": "Hi TecS,\n

\nNo one is judging anyone :-) You can access the data, that is great! Now, let's focus on the real question that is which of these files are we supposed to use for this contest?\n

\nConsider the files for Sep 20. The cutoff time is 15:14. So I assume we can use the file 13092015.rap.t15z.awp130bgrbf00.grib2 . But there are other files at the same time with different "cycle" values going from 0 to 18 -- the last being 13092015.rap.t15z.awp130bgrbf18.grib2. Now, I'm not sure what "cycle" means (is it the length of the forecast?). Do we need to concatenate all the files or just pick one of them?\n

\nI'd appreciate anyone shedding light on these files. Of course, I would appreciate most of all, if Kaggle simply gave us the correctly formatted weather files :-) Why ask all the competitors to do so much busy work?", "rawMarkdown": "", "votes": null }, { "id": "32538", "postDate": "10/22/2013 16:26:52", "content": "

Based on the explanation on the data page I think the last two digits (00 to 18) are forecast time offset. So the 00th file is current conditions, 01 is conditions forecast one hour in the future and so on.

", "rawMarkdown": "", "votes": null }, { "id": "32540", "postDate": "10/22/2013 17:21:26", "content": "

[quote=Nimar;32535]

\n

So I assume we can use the file 13092015.rap.t15z.awp130bgrbf00.grib2 . But there are other files at the same time with different "cycle" values going from 0 to 18 -- the last being 13092015.rap.t15z.awp130bgrbf18.grib2. Now, I'm not sure what "cycle" means (is it the length of the forecast?). Do we need to concatenate all the files or just pick one of them?
[/quote]

\n

So far I have found out the following:

\n

- 0 to 18 is the forecast hours offset, i.e. in your example, t15z...00 means the wind forecast for 15:00, t15z...01 is the forecast for 16:00, etc up to 18 hours ahead;

\n

- if the cutoff time is 15:00, you can use t15z* files; but if the cutoff time is 15:59, you're not allowed to use t16z* files, as this is prohibited by the competition rules (is the data from the future);

", "rawMarkdown": "", "votes": null }, { "id": "32545", "postDate": "10/22/2013 20:22:12", "content": "

[quote=Gabriele Seppi;32515]

\n

I've tried to use the simulator in my code and I see terrible performance compared to the old version. Is anyone else experiencing the same problem, or am I doing something wrong?

\n

[/quote]

\n

I see the time step value has been changed from 0.1 hr to 0.01 hr. That is bound to slow things down.

", "rawMarkdown": "", "votes": null }, { "id": "32547", "postDate": "10/22/2013 20:42:17", "content": "

[quote=Anil Thomas;32545]

\n

[quote=Gabriele Seppi;32515]

\n

I've tried to use the simulator in my code and I see terrible performance compared to the old version. Is anyone else experiencing the same problem, or am I doing something wrong?

\n

[/quote]

\n

I see the time step value has been changed from 0.1 hr to 0.01 hr. That is bound to slow things down.

\n

[/quote]

\n

TimeStep was 0.01 in the previous version too! I'm guessing Gabriele meant the final cost. If I'm right, probably he's not landing ~100 planes because of the restricted zones!

", "rawMarkdown": "", "votes": null }, { "id": "32548", "postDate": "10/22/2013 21:09:05", "content": "

[quote=Alessandro Mariani;32547]

\n

TimeStep was 0.01 in the previous version too!

\n

[/quote]

\n

So it was! My bad.

", "rawMarkdown": "", "votes": null }, { "id": "32550", "postDate": "10/22/2013 23:21:09", "content": "

The first hour of wind data for each day has been uploaded and can be found on the data page.

\n

The performance of the simulator has been degraded by detecting collisions with restricted/turbulent airspace. In our upcoming update, we'll be including some optimizations to decrease simulation time.

", "rawMarkdown": "", "votes": null }, { "id": "32552", "postDate": "10/23/2013 00:13:26", "content": "Thanks Nick!\n

\nDo you mean the first hour of wind data for that day OR one hour of wind data forecast from the cutoff time?\n

\nFrom what I can make out in the code, the simulator will default to nowind if there is no wind data for a given time. So these files can only be used to get the simulator running, but they won't result in any reasonable cost estimates because the simulator will assume that there is no wind at all after the 1 hour, right?", "rawMarkdown": "", "votes": null }, { "id": "32554", "postDate": "10/23/2013 00:27:41", "content": "

The wind snapshot that is taken before to the cut-off time.  The simulator will retrieve whatever wind data is closest in time for that day.  Until you predict future wind data, the simulator will use these snapshots all day.

", "rawMarkdown": "", "votes": null }, { "id": "32566", "postDate": "10/23/2013 05:17:12", "content": "

[quote=charango;32540]

\n

[quote=Nimar;32535]

\n

So I assume we can use the file 13092015.rap.t15z.awp130bgrbf00.grib2 . But there are other files at the same time with different "cycle" values going from 0 to 18 -- the last being 13092015.rap.t15z.awp130bgrbf18.grib2. Now, I'm not sure what "cycle" means (is it the length of the forecast?). Do we need to concatenate all the files or just pick one of them?
[/quote]

\n

So far I have found out the following:

\n

- 0 to 18 is the forecast hours offset, i.e. in your example, t15z...00 means the wind forecast for 15:00, t15z...01 is the forecast for 16:00, etc up to 18 hours ahead;

\n

- if the cutoff time is 15:00, you can use t15z* files; but if the cutoff time is 15:59, you're not allowed to use t16z* files, as this is prohibited by the competition rules (is the data from the future);

\n

[/quote]

\n

Hi

\n

Can I query that logic? For instance if the cutoff time is 15:14, then I would think that you could NOT use the t15z* files, since how do we know that those files (predicting/reporting wind at 15:00) didn't include information from the time period from 15:00 to 16:00 ?

\n

Surely only the t16z* files could be safely assumed to include no real-time data from the 15:00 to 15:14 time period? (or do I misunderstand the data?)

\n

Thanks Dave

", "rawMarkdown": "", "votes": null }, { "id": "32573", "postDate": "10/23/2013 07:09:57", "content": "

A completely other thing:

\n

could you upload a change log? Or since that might be too big, a list to which .fs files have been changed (wrt milestone-simulator)? So we would not have to invest again a lot of time to figure out the details of the simlator, but can do a directed analysis.

", "rawMarkdown": "", "votes": null }, { "id": "32580", "postDate": "10/23/2013 12:39:26", "content": "

[quote=Sandro Scodeller (Sigma);32573]

\n

could you upload a change log? Or since that might be too big, a list to which .fs files have been changed (wrt milestone-simulator)? So we would not have to invest again a lot of time to figure out the details of the simlator, but can do a directed analysis.

\n

[/quote]

\n

I've put the F# into a local git repo, it's really helpful.

\n

Here are the stats (changes between "flight2-milestone" and "flight2-main"):

\n

Aircraft.fs | 28 ++---
Airspace.fs | 36 +++++++
Arrival.fs | 5 +-
CollisionDetection.fs | 85 +++++++++++++++
CostModel.fs | 135 ++++++++++++++++--------
CostParameters.fs | 3 +
Flight.fs | 61 +++++++----
FlightEntry.fs | 3 +
FlightQuest.fsproj | 4 +-
FlightTypes.fs | 17 +--
InstructionParser.fs | 2 +-
LambertConverter.fs | 11 +-
Messages.fs | 2 +
Movement.fs | 14 +--
Serialization.fs | 928 ++++++++++++++++++++++++++---------------------------
SimulationTypes.fs | 14 +++
Simulator.fs | 303 ++++++++++++++++++++++++++---------------------------
Spatial.fs | 55 +++++++++-
Tuple2.fs | 10 +-
Tuple3.fs | 10 +-
WeightModel.fs | 6 +-
Zone.fs | 10 ++
22 files changed, 1059 insertions(+), 683 deletions(-)

", "rawMarkdown": "", "votes": null }, { "id": "32602", "postDate": "10/23/2013 20:16:55", "content": "

maybe i misunderstand something, but is there any reason my you dont provide takeoff, landing, and ground condition files, and only give instruction how to build them ?

\n

i think, it will be easy fo us if you can provide them , no ?

", "rawMarkdown": "", "votes": null }, { "id": "32620", "postDate": "10/24/2013 06:09:38", "content": "

Actual takeoffs/landings and ground conditions is something that you're not supposed to know at cutoff, since it includes data from the future.

\n

The link provided by the admins (http://github.com/benhamner/GEFlightQuest/blob/master/PythonModule/geflight/postgres_ingest/schema.sql#L377) provides some insight into how those files were created from a complete dataset.

", "rawMarkdown": "", "votes": null }, { "id": "32647", "postDate": "10/24/2013 23:21:28", "content": "

We've uploaded an update to the flight simulator.  

\n

Version 2.0.1
- Fixed order of instruction status checking
- Performance improvement to collision detection

\n

 

\n

Note: if you're re-compiling the source code, we highly recommend you compile in Release mode.  The compiler optimizations are quite noticeable. 

", "rawMarkdown": "", "votes": null }, { "id": "32679", "postDate": "10/25/2013 14:41:53", "content": "

Hi Nick,

\n

I tried running the simulator application after making the changes as per the README file but after entering the submission file name, the simulator stops working. The error message gives a path to the program.fs file located on your desktop. Can you please tell me where the problem lies?

", "rawMarkdown": "", "votes": null }, { "id": "32718", "postDate": "10/26/2013 15:05:27", "content": "

I'm trying to generate the groundConditions files for the test data from the metar_reports.csv file as instructed in an earlier post. But the immediate problem I face is that the metar_reports.csv file is not complete.

\n

<br><br>

\n

For example: airport KPSP has its first entry in test2_metar_reports.csv at 2013-09-12 09:53. So, how am I supposed to generate the entry for 2013-09-11 18:24:00 ?

\n

 

\n

 

\n

X

", "rawMarkdown": "", "votes": null }, { "id": "32816", "postDate": "10/29/2013 07:26:12", "content": "

Hi Nick,

\n

I tried running the simulator application after making the changes as per the README file but after entering the submission file name, the simulator stops working. The error message gives a path to the program.fs file located on your desktop. Can you please tell me where the problem lies? I have already tried rebooting the system after installing visual studio F#. I am getting exactly the same error line as pavan kumar is getting.

\n

kindly do reply ASAP

\n

 

\n

 

\n

 

\n

 

", "rawMarkdown": "", "votes": null }, { "id": "32819", "postDate": "10/29/2013 07:36:45", "content": "

Looking at the error message, it says the simulator is failing on line 181, which is where the flight logs are saved.  You and Pavan probably don't have the 'Logs' directory created.  You could also remove the need for that directory by editing the config file.

", "rawMarkdown": "", "votes": null }, { "id": "32820", "postDate": "10/29/2013 09:24:27", "content": "

Hi,

\n

I need some clarification regarding data provided in Partial Simulator Data . I have problem understanding data provided under Scheduled gate departure and similar time variables. how do I interpret the negative sign and decimal values.

Thanks in advance.

\n

 

", "rawMarkdown": "", "votes": null }, { "id": "32879", "postDate": "10/30/2013 07:07:18", "content": "

hi - I've noticed that in the partial weather data files provided for the test set, and the full weather in 'Sept10-SimulatorFiles', the altitude layers goes up to 40880.21.

\n

[18115.849805621583,...,40880.212387122636]

\n

Planes flying at 41,000ft won't have any benefit/drawbacks from the wind... am I right? At least so looks like from the logs!

", "rawMarkdown": "", "votes": null }, { "id": "32882", "postDate": "10/30/2013 09:15:31", "content": "

[quote=Alessandro Mariani;32879]

\n

hi - I've noticed that in the partial weather data files provided for the test set, and the full weather in 'Sept10-SimulatorFiles', the altitude layers goes up to 40880.21.

\n

[18115.849805621583,...,40880.212387122636]

\n

Planes flying at 41,000ft won't have any benefit/drawbacks from the wind... am I right? At least so looks like from the logs!

\n

[/quote]

\n

 

\n

Doesn't it depend from your code? I mean I always take wind-data from the closest wind-height available...

", "rawMarkdown": "", "votes": null }, { "id": "32888", "postDate": "10/30/2013 13:53:47", "content": "

Ankush wrote

\n

Hi,

\n

I need some clarification regarding data provided in Partial Simulator Data . I have problem understanding data provided under Scheduled gate departure and similar time variables. how do I interpret the negative sign and decimal values.

\n

Thanks in advance.

\n

 

\n

I have the same doubt.

", "rawMarkdown": "", "votes": null }, { "id": "32919", "postDate": "10/31/2013 06:22:51", "content": "

Hi,

\n

I need some clarification regarding data provided in Partial Simulator Data . I have problem understanding data provided under Scheduled gate departure and similar time variables. how do I interpret the negative sign and decimal values and also how do one interpret  delay_cost_proportion_30m  and delay_cost_proportion_2h in the same file.

\n

waiting for the reply ASAP.

\n

Thanks in advance

\n

 

\n

X

", "rawMarkdown": "", "votes": null }, { "id": "32959", "postDate": "10/31/2013 17:50:32", "content": "

Float time variables are offsets from the cutoff time for the day (found in the TestFlights.csv file).

\n

 

\n

The DelayCostProportion parameters are used in the perPassengerRelativeDelayCost function within CostModel.fs.  I recommend you graph that function's output over an array of incrementing delay time to get an idea of the curve.

", "rawMarkdown": "", "votes": null }, { "id": "33167", "postDate": "11/04/2013 11:28:14", "content": "

There seems to be a finite delay cost even when time delayed is zero(costmodel.fs, perpassengerrelativedelaycost lines:48-56) due to the constant term time offset. Can you give me some clarification on this?  

\n

Also in descent.fs

\n

let calculateTime (model:DescentModel) (altitude:float<Feet>) =
let aTime = (float altitude)**model.TimePower
let time = model.TimeIntercept + model.TimeAltitude*aTime
let maxDescent = System.Math.Abs(float(altitude / model.MaximumRateOfDescent))
let result = max maxDescent time
result * 1.0<Hours>

\n

am I right to assume that the altitude used here is the altitude to descend(altitude difference between current and next position) and not the actual altitude(altitude of current position - this case will bias the results by ignoring the elevation of airports)?

\n

 

", "rawMarkdown": "", "votes": null }, { "id": "33423", "postDate": "11/08/2013 13:52:15", "content": "

This might not be a bug, but is quite strange anyway.

\n

The simulation-time is not linear in number of days simulated:

\n

if I simulate only Day1 it takes around 47.941237 seconds to simulate

\n

if I simulate all 14 Days it takes 9356.984812 seconds=~2.59 hours,while I would expect it to be around 14*48=672 seconds=~11.2 min

\n

This, since it seems to me that the code simulates day per day, so there should be a linear time Increase.

", "rawMarkdown": "", "votes": null }, { "id": "33429", "postDate": "11/08/2013 14:45:11", "content": "

@Sandro: I've obsorved the same, even though it takes me only a couple of minutes to run the simulator for all 14 days (on a five year old notebook). I'm not pretty sure, but I think it has something to do with how many flights are there on a day flying close to restricted areas. Most of the simulator time (> 90%)  is "lost" in the function checking wether the airplane access a restricted area. To make the computation faster, this detection is only done, if the airplane is close (there is a threshold of 570 "something", maybe miles) to at least one restricted area. And exactly here you have a high variance between the days.

", "rawMarkdown": "", "votes": null }, { "id": "33523", "postDate": "11/10/2013 22:15:03", "content": "

It seems simulator can fly through restricted areas.... :-)

\n

Parameters:
Folder: Sept10-SimulatorFiles
Configuration: {"TimeStep":0.01,"MaxSteps":1000,"MaxInstructions":200,"WaypointRadius":1.0,"MinimumAltitude":2000.0,"LandingMode":2,"RecordFlightLog":true}
Flight: 308567975
Restriced Area: Twenty Nine Palms
FlightId,Ordinal,Latitude,Longitude,Altitude,AirSpeed:
308567975,1,33.942,-118.408,1000,500
(StartPoint = {(-880.438361, 641.350407, 38000)}, FinishPoint = {(-1174.85113965191, 640.813583752209, 125)})

\n

One corner of area is too sharp....

\n

Or I am wrong?

", "rawMarkdown": "", "votes": null }, { "id": "33529", "postDate": "11/10/2013 23:00:04", "content": "

I've tried and it lands .. so you're not wrong! probably as that vertex is soo sharp, and the plane can cross the area pretty quickly, the interpolation of the simulator is not quick enough to catch that (using 0.01 as TimeStep).

\n

To let it crash it, you need to set TimeStep to 0.0001 in your configuration file... beside that, I don't really think there are many cases like this!

\n

 

", "rawMarkdown": "", "votes": null }, { "id": "33532", "postDate": "11/11/2013 00:18:52", "content": "

I'm not sure this kind of thing is that rare. If your algorithm happens to exploit this behavior, it's possible to cut right through the middle of some of the thinner restricted airspace zones.

\n

Here's a flight that does it:

\n

310039922,1,34.97441755760357,-114.64500555487143,39000.0,490.0

\n

310039922,2,34.93409855397412,-114.75539098107771,38000.0,490.0

\n

310039922,3,34.71280234193989,-115.39569522750435,2000.0,514.5

\n

310039922,4,34.29542586809027,-116.81651190318607,2000.0,490.0

\n

310039922,5,34.28802281433884,-116.84514731267217,38000.0,490.0

\n

310039922,6,34.207960928876524,-117.16504597631933,2000.0,524.79

\n

310039922,7,34.04467210342863,-117.88785326245329,38000.0,490.0

\n

310039922,8,33.94199999999999,-118.40799999999993,17000.0,490.0

\n

 

\n

And here's a visualization of where the plane flies over the restricted airspace. Each dot on the line is one step of the simulator.

\n

\n

 

\n

It does seem that making the time step smaller fixes this problem for the most part. But it'd be good to get an official ruling on this.

\n

 

\n

(ETA: This flightLog entry was generated using the 1hr weather file for the date in question.)

", "rawMarkdown": "", "votes": null }, { "id": "33552", "postDate": "11/11/2013 09:44:16", "content": "

@johnsonav: I observed the same effect in my experiments. But I don't think you can exploit this behaviour to reduce the calculated flight costs. The main problem is, that you run in numerical instabilities. My code also calculated such route, and its a valide flight route on one computer, but when I go to another computing architecture, the route is invalid as it enteres the restricted zone. Even when I keep my code running on the same computer, but have small changes in the input date (e.g. weather files), it's just random, whether the flight reached the destination or not. Even if you have 10 flights, where you try to make use of this effect (and I don't think it will significantly reduce the flight cost), and one flight is rejected by the simulator, the overall cost will be higher than with flight routs correctly avoiding the restricted zones.

", "rawMarkdown": "", "votes": null }, { "id": "33560", "postDate": "11/11/2013 14:33:25", "content": "

My experience is similar to that of the 2 posters above. I can safely send flights through the center of the exclusion zone at 29 Palms, and cutting corners of the other zones. However, a change in the weather tends to crash them. I see this feature as more hazard than opportunity, but fair game either way.

", "rawMarkdown": "", "votes": null }, { "id": "33627", "postDate": "11/12/2013 14:36:02", "content": "

We found the same problem a few days ago, but wanted to be 100% sure we weren't missing something before posting (actually, I came to the forum today to post this very problem! :D)

\n

Anyway, I think that a solution can be easily implemented in the simulator by the admins. It requires 2 changes:

\n

1) the aircraft is considered as a point (not too big a problem: consider that at the moment the cylinder that represents the aircraft is so small compared to movement/restricted zones that the simulator won't lose much)

\n

2) every step performs a simple line-polygon intersection check which, coupled with the fact that the aircraft is considered as a point, could even bring some performance improvements

\n

 

\n

What do you think?

", "rawMarkdown": "", "votes": null }, { "id": "33632", "postDate": "11/12/2013 15:17:07", "content": "

There is even a simpler solution, that would speed up the simulator by a factor. You just need to check, whether there is at least one intersection of the route's instructions (which are also just 2D line segments) and the polygon lines of the restricted zones. But where it does not work are the turbulenze zones, as you want to know how long the airplane flighs through them.

", "rawMarkdown": "", "votes": null }, { "id": "33644", "postDate": "11/12/2013 22:51:00", "content": "

Indeed, flights are capable of traveling through thin restricted zones due to the length of the time step.  We considered shortening the step before releasing the updated simulator; however, the return effect wouldn't be worth the increased workload on the simulator.  It's only three or four zones small enough to be susceptible to side-to-side crossing and cutting corners would occur at practically any step size.  The simulator code and settings will not be changed. 

\n

There exists several options to improve the performance of the simulator, but we feel the current speed is satisfactory for your use and our evaluation servers.  You're welcome to make those changes to your simulator instance. DerDasMachenMuss makes a good suggestion of only checking the line segments of your flight instructions, at the cost of ignoring turbulent zone intersection times.  

", "rawMarkdown": "", "votes": null }, { "id": "33664", "postDate": "11/13/2013 07:15:49", "content": "

Unfortunately performing a segment-polygon intersection check over instruction points is not safe enough, because the actual vertical profile could be different from the instructed one and at the same time the aircraft, although small, is not a point.

\n

Regardless of performance, anyway, what's the point of having restricted zones if they can be intersected without consequences under particular conditions? Yes, we're talking about three, max four zones, but over less than 30 total at any given time (restricted + turbulent): that's more than 10%. And we're not considering corners... Cutting through corners (or entire zones) can yield quite an interesting advantage over a full length deviation, and I guess this is not the purpose of the competition, especially after the addition of such areas.

\n

Just my opinion though =)

", "rawMarkdown": "", "votes": null }, { "id": "33684", "postDate": "11/13/2013 18:16:55", "content": "

I completely agree with Gabriele Seppi, and in fact I was going to propose the same solution to the problem of undetected intersected restricted zones.

\n

It can be an importante factor in the evaluated mean cost, and the proposed line-polygon intersection check in each step seems a simple solution.

\n

I understand nobody likes simulator code changes, but it seems clearly better to consider the airplane a moving point (segment) during each step, that a tiny cylinder with quantum tunneling powers.

", "rawMarkdown": "", "votes": null }, { "id": "34818", "postDate": "11/17/2013 09:47:31", "content": "

Hi admins,

\n

I'm taking a look at the arrival model of the simulator, and there are a few things I found suspicious.

\n

1. visibility terms in landing model and taxi model

\n

visibility coefficients are given in the Landing.csv and Taxi.csv data files, but they are not used in the predictLanding and predictTaxi functions in Arrival.fs. Are they intentionally omitted?

\n

2. utilScheduledRunwayArrival/untilScheduledGateArrival in landing model

\n

Landing model data(Landing.csv) has the coefficent named time_at_cutoff_to_scheduled_gate_arrival_hours and time_at_cutoff_to_scheduled_runway_arrival_hours. From the namesI assume they are meant to be the coefficents for (scheduled gate/runway arrival time - cutoff time), but in predictLanding function, these coefficients are multiplied with (scheduled gate/runway arrival time - the starting time of descent for landing). Which is correct (the field name or the code)?

\n

3. untilScheduledGateArrival in taxi model

\n

Similarly, taxi model data(Taxi.csv) has the coefficient actual_runway_arrival_to_scheduled_gate_arrival_hours but it is multiplied by (scheduled gate arrival - the starting time of descent for landing). Again, which is correct one?

\n

 

\n

Aside from the arrival model, I have another issue with the simulator. In the simulator, the wind speed above 40880 feet or below 18115 feet are calculated as zero.This can be exploited for avoiding headwind, and I think the more realistic behavior for the weather modeling would be using wind vector from the nearest grid point.

", "rawMarkdown": "", "votes": null }, { "id": "34934", "postDate": "11/19/2013 21:07:02", "content": "

I realise it's pretty late in the game for this, but is there any documentation on what the simulator is supposed to do, other than the actual code?  There have been a lot of good questions raised, but I can barely get through the F# well enough to figure out how it works, much less decide if the code is "correct" (obviously it's my own fault for not committing more time, but still).

\n

My most recent question: if you ascend or descend over (or under, I guess) a restricted area, then whether or not you intersect it depends on the rate of ascent or descent, and I can SEE the math, obfuscated tho it is, in the F# code, but I have nothing tangible to compare it to, so I can't tell if there's a bug or not.  Does that make sense?  Should descent be a straight line?  Should it (a graph of altitude over time during descent) be steeper at the start and level off (convex), or should it start more slowly (concave or s-shaped)?  Concave would cause crashes, of course.  Should turns happen on a dime or cut the corner of the waypoint on the acute side?

\n

For example, there's an <altitude>^1.2 calculation in the ascent code a few times. Can someone explain why that is?  Is this due to a lower drag that comes with higher altitude?  And I see a lot of constants, but I can't tell if they're "right"... FuelAltitudeSqrt is not the Square Root of FuelAltitude (negatives notwithstanding).  Should it be?  What do these mean in the world of physics equations?

\n

As a last example, was the eccentricity that allowed the winning milestone strategy not considered a bug in the ascent cost logic?  From the forum posts it sounds like the ascent costs weren't changed (only the 5-change penalty added).  With some sort of descriptive model to compare against it would be easier to tell and recommend improvements.

\n

Anyway, let me know if I'm missing something... I have a hundred other questions, but it's too late to go into that level of detail, I think, and almost certainly too late to fix simulator bugs, but I finally had to break down and ask.  Thanks for reading!

", "rawMarkdown": "", "votes": null }, { "id": "34951", "postDate": "11/20/2013 03:16:21", "content": "

Hi,

\n

I've been trying to get RunSimulation.exe to compile. At first it couldn't find the files groundConditions_*, actualTakeoffs_* and actualLandings_*. If I'm interpreting correctly, those files aren't needed for the FQ2 Partial Simulator Data? Anyways, I removed the references to those files in RunSimulation.exe.config. But now I am getting an error:

\n

 

\n

System.UnauthorizedAccessException: Access to the path my_path_to_the_data is denied.

\n

 

\n

I am running the executable as an administrator and the folder has no special permissions required. Plus, the program has already read a bunch of data from the folder (Airports.csv for example).  Has anyone encountered this error? I am running on Windows 8.1.

\n

 

\n

Thanks!

\n

 

", "rawMarkdown": "", "votes": null }, { "id": "34999", "postDate": "11/21/2013 13:59:10", "content": "

I am concerned about the issue of a flight flying unperturbed through a restrictedZone.

\n

After looking at the code, it seems to me that one can safely pass any restrictedZone that is small enough to be crossed in less than 0.6 minutes (one can take a safe margin to account for possible headwind) by putting a waypoint just before crossing it.

\n

By doing it, he is assured that the next step at which the simulator will check the possible intersection would take place after 0.6 minute. So as long as one chooses a good enough margin, he would be safe to cross it (I have not tested this).

\n

If it is indeed the case, any one who would not use this strategy would be penalized, since it is certain that cutting through corners of small enough restricted zones would save on fuel and time, with practically no risk of crash.

\n

I think there should be an official ruling (and enforcement) on whether or not this is allowed. I agree with Gabriele and Jose that adding a check to disallow this would be best for the purpose of this competition.

\n

One possible option that would not require any change in the simulator would be to postprocess the flight logs to check that this condition has not occured during the flight.

", "rawMarkdown": "", "votes": null }, { "id": "35076", "postDate": "11/23/2013 02:16:56", "content": "

We've updated the simulator and have re-scored the leaderboard. 

\n

Version 2.1
- Changed collision detection mechanism to prevent skipping over zones
- Added Visibility to Landing/Taxi GLMs
- Wind data is now relevant above 40.8k and below 18k feet

", "rawMarkdown": "", "votes": null }, { "id": "35079", "postDate": "11/23/2013 08:19:26", "content": "

Hi!

Thank you for updating the simulator.

"Wind data is now relevant above 40.8k and below 18k feet". Will we get a new weather file snapshot in the cutoff time, to see the difference? 

Thank you in advance,
Christian

", "rawMarkdown": "", "votes": null }, { "id": "35083", "postDate": "11/23/2013 10:59:19", "content": "

The leaderboard seems to like those changes. Is it still using the same flights as before? If so, I guess the improved scores are due to the aircraft now being a dimensionless dot which can get closer to restricted zones with impunity, so there are fewer collisions. Oh well, win some, lose some.

", "rawMarkdown": "", "votes": null }, { "id": "35089", "postDate": "11/23/2013 14:36:15", "content": "

The new collision detection still has potential for "skipping". As stated at line 29 of Airspace.fs, using only destination altitude allows for clipping of upper and lower corners. Furthermore, flights which at cutoff are inside a zone (near the boundary), can easily escape it without being penalized.

\n

Glad to see that segment-polygon intersection has been implemented, though :)

", "rawMarkdown": "", "votes": null }, { "id": "35094", "postDate": "11/23/2013 15:37:06", "content": "

... or perhaps the improvement is because flights at 41,000 can also benefit from the wind

\n

Thanks to the organizers for the new simulator.

", "rawMarkdown": "", "votes": null }, { "id": "35105", "postDate": "11/23/2013 23:07:47", "content": "

[quote=Gabriele Seppi;35089]

\n

The new collision detection still has potential for "skipping". As stated at line 29 of Airspace.fs, using only destination altitude allows for clipping of upper and lower corners. Furthermore, flights which at cutoff are inside a zone (near the boundary), can easily escape it without being penalized.

\n

[/quote]

\n

You're welcome to try making gains from clipping on the z-axis.  Furthermore, no flights start off within a zone. 

\n

[quote=Christian Kiss-Tóth;35079] 

\n

Will we get a new weather file snapshot in the cutoff time, to see the difference?

\n

[/quote]

\n

Sorry for being vague; there is no new wind data.  For altitudes outside the range of 18k-40.8k ft, the min or max altitude level is used.  

\n

[quote=Arieli;35094]

\n

... or perhaps the improvement is because flights at 41,000 can also benefit from the wind

\n

Thanks to the organizers for the new simulator.

\n

[/quote]

\n

You're welcome :)

", "rawMarkdown": "", "votes": null }, { "id": "35106", "postDate": "11/23/2013 23:09:46", "content": "

I just noticed on MSDN that System.Math.Round() can be unpredictable in rounding certain values (see http://msdn.microsoft.com/en-us/library/wyk4d9cy(v=vs.110).aspx for an example). Considering that flight level selection during instruction correction is an important step in the evaluation of a flight, wouldn't it better to replace System.Math.Round() with System.Math.Ceiling() (o System.Math.Floor()) for consistency? I'm talking about line 25 of InstructionCorrector.fs: why do westbound flight receive rounding with System.Math.Round() while eastbound flight with System.Math.Ceiling()?

", "rawMarkdown": "", "votes": null }, { "id": "35107", "postDate": "11/24/2013 00:00:40", "content": "

[quote=ℕick ∈ Sardo;35105]

\n

[quote=Gabriele Seppi;35089]

\n

The new collision detection still has potential for "skipping". As stated at line 29 of Airspace.fs, using only destination altitude allows for clipping of upper and lower corners. Furthermore, flights which at cutoff are inside a zone (near the boundary), can easily escape it without being penalized.

\n

[/quote]

\n

You're welcome to try making gains from clipping on the z-axis.  Furthermore, no flights start off within a zone. 

\n

[/quote]

\n

I'm not saying we can make gains, but that, not knowing future winds, we could find ourselves in a situation where the aircraft hits a zone even if we didn't want to, simply because of a stronger tailwind or headwind.

\n

Regarding flights starting off within a zone, I may be wrong, but I've come across a few which, at cutoff, are inside a turbulence zone (a couple examples: 309252255, 309256963). I haven't checked them all, of course, so I don't know it this is the case, but if a flight at cutoff is inside a zone, yet close enough to the lower or upper boundary, it can escape easily.

\n

I don't think it's going to matter anyway, I was just trying to be open and notify of possible - yet remote - pitfalls :)

", "rawMarkdown": "", "votes": null }, { "id": "35108", "postDate": "11/24/2013 00:23:57", "content": "

[quote=Gabriele Seppi;35107]

\n

I'm not saying we can make gains, but that, not knowing future winds, we could find ourselves in a situation where the aircraft hits a zone even if we didn't want to, simply because of a stronger tailwind or headwind.

\n

[/quote]

\n

Sounds like real life.  :-)

\n

[quote=Gabriele Seppi;35107]

\n

Regarding flights starting off within a zone, I may be wrong, but I've come across a few which, at cutoff, are inside a turbulence zone (a couple examples: 309252255, 309256963).

\n

[/quote]

\n

Ah, I thought you were referring to restricted zones.  

", "rawMarkdown": "", "votes": null }, { "id": "35134", "postDate": "11/24/2013 20:09:32", "content": "

Hi

\n

Thanks to the organizers for the update.I just want to mention to everybody I had some initial problems with the updated simulator because violations of restricted (turbulent) zones with repeated vertices are not detected (because of the resulting (Nan, Nan) in calculating the unit normal vector of this zero-length polygon side).

\n

The last version of "FQ2 Partial Simulator Data with 1hr weather" has the corrected "restrictedZones.csv" without vertices repetitions but the "Sept10-SimulatorFiles" still have the "Twenty Nine Palms" restricted zone with repeated vertices.

\n

 

", "rawMarkdown": "", "votes": null }, { "id": "35135", "postDate": "11/24/2013 21:35:18", "content": "

[quote=José A. R. Fonollosa;35134]

\n

The last version of "FQ2 Partial Simulator Data with 1hr weather" has the corrected "restrictedZones.csv" without vertices repetitions but the "Sept10-SimulatorFiles" still have the "Twenty Nine Palms" restricted zone with repeated vertices.

\n

[/quote]

\n

Replaced the restrictedZones.csv in the Sept. 10 files.  

", "rawMarkdown": "", "votes": null }, { "id": "35186", "postDate": "11/25/2013 12:48:58", "content": "

Hi,

\n

sometimes the simulator doesn't reach the destination because of arrivalRadius (1mile in Configuration.json) simulator parameter.

\n

Let me explain my self. Suppose the last waypoint is within 1 mile from the airport arrival frontier, i.e. waypoint between [64.1732, 65.1732]. stepToWaypoint function returns that destination is reached when you are at most at arrivalRadius from the last waypoint. Sometimes it happens that the last position is larger than 65.1732 (destination reached is set) but the aircraft won't land because it is out of airport radius.

\n

Can we know the simulator parameters in the online simulator?

\n

BR

", "rawMarkdown": "", "votes": null }, { "id": "35973", "postDate": "12/08/2013 22:03:38", "content": "

Most expensive flight, ever!

\n

With this itinerary:

\n

308663997,1,34.9709,-103.1294,37000,406.5456
308663997,2,32.8996,-97.0574,17000,319.4624
308663997,3,32.897,-97.038,17000,319.3332

\n

I get, 10^33 in fuel expenses ?!

\n

...

\n

308663997,33.3034728137757,-98.1717180290048,-160.875486538811,502.229931179563,1.500,319.46,316.36,17000.00,6689.14,False,False,125895.56,Flying
308663997,32.897,-97.038,-103.747366772221,476.470353064938,3208235363634990000000000000000000.000,0.00,0.00,607.00,6365645862639280000000000000000000000.00,False,False,114668.00,Crashed

\n

 

", "rawMarkdown": "", "votes": null }, { "id": "36012", "postDate": "12/10/2013 00:42:50", "content": "

It seems a bit odd that groundConditions for times outside those in the file are set to 0, 0, 0, T=45, rather than assigned to the nearest value, similar to the issue/change made for weather layers.

\n

This means, if a cutoff is early in the hour, and the next report isn't until cutoff + value close to 1hr, all flights landing in < 1hr will ignore ground conditions and set to the constant values? Why not just use the closest report (as done for values within the timeaxis, and now similarly done for z outside wind layers)? Seems like an odd boundary condition to introduce, and fairly unrealistic.

", "rawMarkdown": "", "votes": null }, { "id": "36376", "postDate": "12/19/2013 19:53:14", "content": "

[quote=Arieli;35973]

\n

Most expensive flight, ever!

\n

With this itinerary:

\n

308663997,1,34.9709,-103.1294,37000,406.5456
308663997,2,32.8996,-97.0574,17000,319.4624
308663997,3,32.897,-97.038,17000,319.3332

\n

[/quote]

\n

Arieli, is this reproducible for you (or anyone else)?  My flight log came out normal with this itinerary.

", "rawMarkdown": "", "votes": null }, { "id": "36622", "postDate": "12/24/2013 09:29:37", "content": "

Hi Admins,

\n

 

\n

Maybe I missed something or doing something wrong but it seems to me that

\n

training3_flighthistory.csv is possibly corrupt.

\n

In contrast with training2_flighthistory.csv column 24 (scheduled_aircraft_type) is filled
with datetime info and not with stuff like M80 etc.

\n

 

\n

Could somebody look into this please?

\n

Thanks in advance.

\n

 

", "rawMarkdown": "", "votes": null }, { "id": "36623", "postDate": "12/24/2013 10:26:54", "content": "

Confirmed. It looks a lot like it's equivalent to scheduled runway arrival for certain flights, but for others it's not...

", "rawMarkdown": "", "votes": null }, { "id": "36630", "postDate": "12/24/2013 14:32:24", "content": "

Just to clarify, it's only part of the file, not the whole thing? What fraction of the file is affected? Could you cut and paste a sample row where it's wrong, with line number? We'll try to get to it as soon as we can, but with the holidays it might be a while. 

", "rawMarkdown": "", "votes": null }, { "id": "36635", "postDate": "12/24/2013 18:48:28", "content": "

Hi joycenv,

\n

Thanks for the quick reaction. Column 24 has a wrong value for all the 620.569 rows of the file. I don't know if the other columns are OK, I don't see any obvious flaws.

\n

My guess is that either the program extracting the data has been changed between extracting training2_flighthistory.csv and training3_flighthistory.csv or the format of the source has been changed.

\n

If so, this could possibly also be an explanation for the discrepancies between training2_flighthistory.csv and actualLandings_20130910_1803.csv reported by Alessandro, Anil and myself in the thread http://www.gequest.com/c/flight2-main/forums/t/6239/which-files-are-going-to-be-provided

", "rawMarkdown": "", "votes": null }, { "id": "36728", "postDate": "12/27/2013 20:18:08", "content": "

Maybe there is yet another issue with training3_flighthistory.csv.

\n

It looks like there are big gaps where there are no flights with an actual_runway_departure.

\n

For instance there seems to be no flight with an

\n

actual_runway_departure > 2013-11-20 8:38 and actual_runway_departure < 2013-11-21 4:51

\n

Can somebody confirm this please?

\n

Thanks in advance!

", "rawMarkdown": "", "votes": null }, { "id": "36734", "postDate": "12/27/2013 21:11:39", "content": "

"More info about how takeoff, landing, and ground condition files are created can be found here. As you can see, we're just doing simple queries of the flight data."

\n

could you expand upon this?  I'm just "upgrading" to the most recent dataset.  I run the simulator and it bails trying to open files for files "groundConditions_{DAY_TIME}.csv" which are not found.  According to: https://www.gequest.com/wiki/FlightQuest2 I should just be able to build them and I'm pointed to a large python script.  "https://github.com/benhamner/GEFlightQuest/blob/master/PythonModule/geflight/postgres_ingest/schema.sql#L405"  (or I guess it's an sql script). What exactly am I supposed to do with this?  A higher level page includes invocation of a python script.  Please expand upon this.

\n

Another very odd thing is that the simulator doesn't even seem to use this data.

\n

Obviously I'm missing something ridiculously obvious here.  Anyone know what it might be?

\n

Robert Ramey

\n

 

", "rawMarkdown": "", "votes": null }, { "id": "36822", "postDate": "12/30/2013 14:03:19", "content": "

Hi Admins and fellow competitors,

\n

 

\n

The Flight Simulator seems to crash depending on contents of actualLandings_....csv.

\n

I varied the contents of the actualLandings- and the actualTakeoffs-file according to the contents of the training1- and training2-flighthistory file and found that the Flight Simulator crashes on a number of occasions.

\n

I looked for an example easy to reproduce and found the following one:

\n

step1: start out with 10 sept simulation files (version2)

\n

step2: remove from actualLandings_20130910_1803.csv all landings in the first 5 hours ( so the first line after the header is: KMCO,6.001758,1)

\n

step3: start runsimulation

\n

It crashes before you can enter the routes. (on my machine anyway)

\n

Can someone reproduce this?

\n

 

\n

I attached the STDERR of the command

\n

 

\n

 

", "rawMarkdown": "", "votes": null }, { "id": "36825", "postDate": "12/30/2013 16:03:01", "content": "

Does the actualLanding (and takeoff) file contains at least one records for all the 63 airports? If does not, this is you problem!

", "rawMarkdown": "", "votes": null }, { "id": "36870", "postDate": "12/31/2013 11:59:33", "content": "

Thanks, I will keep that in mind.

", "rawMarkdown": "", "votes": null }, { "id": "36924", "postDate": "01/02/2014 19:46:09", "content": "

[quote=Jules;36622]

\n

Hi Admins,

\n

 

\n

Maybe I missed something or doing something wrong but it seems to me that

\n

training3_flighthistory.csv is possibly corrupt.

\n

In contrast with training2_flighthistory.csv column 24 (scheduled_aircraft_type) is filled
with datetime info and not with stuff like M80 etc.

\n

 

\n

Could somebody look into this please?

\n

Thanks in advance.

\n

 

\n

[/quote]

\n

A corrected version of training3_flighthistory (has _rev1 in the name) has been posted to the Data page. Sorry for the error. Thank you very much for your patience while we prepared the new file.

", "rawMarkdown": "", "votes": null }, { "id": "36989", "postDate": "01/04/2014 10:07:31", "content": "

Hello, admins.

\n

Currently, it looks like, if any flight path in the submission has more than 200 waypoints, the whole submission is aborted with zero score. Maybe it'll be better to penalize this flight path with NonArrivalPenalty (100,000) instead of failing the whole submission?

\n

Right now it doesn't seem fair (to me) to kick the participant out of the competition, instead of adjusting the score, for a single error.

", "rawMarkdown": "", "votes": null }, { "id": "37004", "postDate": "01/05/2014 09:27:44", "content": "

Hi Charango,  This rule was mentioned in Basic Structure of Flight Quest2/Getting Started/Paragraph 5 where it says

\n

"One constraint worth mentioning here is the maximum allowed number of instructions for each flight is 200 instructions"

\n

Good Luck

", "rawMarkdown": "", "votes": null }, { "id": "37006", "postDate": "01/05/2014 09:52:25", "content": "

To be honest, I see no point in setting this constraint in the first place... What's the purpose of limiting the number of instructions?

", "rawMarkdown": "", "votes": null }, { "id": "37007", "postDate": "01/05/2014 10:00:30", "content": "

"This is the captain speaking. To your left, you can now enjoy the unusual sight of my co-pilot sitting on the port wing. We will be flying in a holding pattern until he agrees to climb back in here and resume punching 500 updated waypoints into the flight computer. Refreshments to be rolled out soon."

", "rawMarkdown": "", "votes": null }, { "id": "37010", "postDate": "01/05/2014 12:17:06", "content": "

I have implemented this rule in my model, I have no problem with it.

\n

It was just very surprising that the simulator fails the whole submission, if you don't meet it (you get zero score). In contrast, if you will crash a few planes (by running out of fuel), the punishment is less severe - your score will be a bit worse.

", "rawMarkdown": "", "votes": null }, { "id": "37011", "postDate": "01/05/2014 13:04:11", "content": "

I have implemented it too, no problem here. I was just wondering what the purpose of limiting the number of instructions is...

", "rawMarkdown": "", "votes": null }, { "id": "37057", "postDate": "01/06/2014 21:09:02", "content": "

Subtlety failing flights would cause even more surprise (and anger) once participants figured it out after submitting a few times.  Without a doubt, preemptive failing the whole submission is the right way to go for such a simple, universal rule.

\n

 

\n

This constraint exists for several reasons: first, flight routes should be in the domain of a human pilot, not a navigational computer.  Second, this prevents any malicious user from bogging down our servers with routes containing millions of instructions.

", "rawMarkdown": "", "votes": null }, { "id": "37062", "postDate": "01/06/2014 22:54:05", "content": "

I'm not saying of setting no upper bound, but since the simulator is currently upper bounded on 1000 steps, why not allow up to 1000 instructions for example?

\n

Secondly, I understand routes should be in the domain of a human pilot, but we're talking about commercial jets here. If pilots are given 200 waypoints they're never going to "hand fly" them anyway, that's just impossible. Assume a 3000nm route with 200 waypoints: that's 15nm between any 2 waypoints on average. No human being is capable of sustaining such stress for so long a time.
Adding the route into the FMC will show it up onto the ND and the pilot will be able to hand fly the aircraft following pitch and roll instructions on the PDF, but we're already falling into the realm of navigational computer here. So, should we reduce the number of instructions? Yes, but the FMC will compute a nice interpolation for pilots, a thing that our simulator is not going to do.
Furthermore, I thought we were trying to improve information shown to the pilots in order to allow them make fuel saving decisions. How should they get them? A navigational computer is already installed on all modern aircrafts, why not use it?

\n

All I'm saying is that, since no interpolation is available, long routes could benefit from more than 200 instructions. I see no point in imposing this limit, except of course not clogging Kaggle servers (which, as a system administrator, I know can be hard to handle ;)

", "rawMarkdown": "", "votes": null }, { "id": "37063", "postDate": "01/06/2014 22:56:51", "content": "

The instruction and step limits stay as they are.

", "rawMarkdown": "", "votes": null }, { "id": "37152", "postDate": "01/09/2014 06:33:17", "content": "

[quote=ℕick ∈ Sardo;37057]

\n

This constraint exists for several reasons: first, flight routes should be in the domain of a human pilot, not a navigational computer.

\n

[/quote]

\n

Isn't 200 already out of the domain of a human pilot? I would have liked to see an upper bound of 20. Not to be nice to the pilot, but because that's the maximum number of waypoints in my solution :-)

\n

Clearly, I am leaving something on the table. On the plus side, it only takes a couple of hours to generate a complete solution.

", "rawMarkdown": "", "votes": null }, { "id": "37230", "postDate": "01/10/2014 14:56:44", "content": "

That is interesting information. In the spirit of reciprocity: my paths contain 8 to 12 waypoints (fewer if you ignore those that don't matter), and I use the first hour's weather plus the examples they gave us for "actualLandings_xxx" etc.. Ignoring weather prediction saved me a considerable amount of time and aggravation, but it's looking like a gamble that didn't pay off.

", "rawMarkdown": "", "votes": null }, { "id": "37493", "postDate": "01/17/2014 08:41:29", "content": "

I was running out of things to try, so I decided to revisit this. Following the pointers from id, I added some code (highlighted below) to FuelModel.fs.

\n

 

\n

let ascentFuelBurn = max rawAscentFuelBurn cruiseFuelBurn

\n

if ascentFuelBurn = cruiseFuelBurn then 

\n

    printfn "weight %A altitude %A airspeed %A" weight altitude airSpeed

\n

(ascentFuelBurn, ascentRate)

\n

 

\n

And sure enough, running the simulator spews out messages like the ones below:

\n

weight 129295.9445 altitude 10033.14302 airspeed 522.3755016

\n

weight 131833.9212 altitude 13577.58477 airspeed 515.15

\n

weight 130342.3101 altitude 11607.57011 airspeed 519.2323575

\n

weight 130199.4593 altitude 13479.28208 airspeed 515.4957218

\n

weight 130251.1845 altitude 12287.62375 airspeed 517.8747166

\n

What does this mean? For certain combinations of weight, altitude and air speed, the aircraft can climb to higher altitudes as if gravity didn't exist. This is of course, very wrong!

\n

Our optimizers must be benefiting from this flaw, albeit unknowingly. I think a solution that systematically exploits this will do better. Maybe something to try before the buzzer goes off...

", "rawMarkdown": "", "votes": null }, { "id": "37496", "postDate": "01/17/2014 09:37:28", "content": "

Interesting, did you consider that the code run in parallel so maybe this is not the same flight or there is no time order ? (also the weight looks going on the off)

", "rawMarkdown": "", "votes": null }, { "id": "37498", "postDate": "01/17/2014 09:50:40", "content": "

Anil, airspeed is not an input in the ascent model. Fuel consumed seems to depend on altitude and weight.  I took it that the ascent model describes the typical aircraft in ascent and, for a given weight, the fuel consumed depends on altitude reached.  It would be possible with some algebra (and possibly some differentiation) to determine the airspeed at a particular altitude but this is not in the ascent model.  Have I missed something?

", "rawMarkdown": "", "votes": null }, { "id": "37501", "postDate": "01/17/2014 10:05:36", "content": "

[quote=sparrow ;37496]

\n

Interesting, did you consider that the code run in parallel so maybe this is not the same flight or there is no time order ? (also the weight looks going on the off)

\n

[/quote]

\n

They are all different flights.

", "rawMarkdown": "", "votes": null }, { "id": "37502", "postDate": "01/17/2014 10:22:19", "content": "

[quote=JC36;37498]

\n

Anil, airspeed is not an input in the ascent model.

\n

[/quote]

\n

Correct. However airspeed is an input to the cruise model. The way the code is written, the amount of fuel consumed during ascent also depends on the cruise model. In any case, my point is that at just the right combinations of weight, altitude and airspeed, the ascent burn rate becomes equal to the cruise burn rate (within the alternate reality of the simulator).

", "rawMarkdown": "", "votes": null }, { "id": "37504", "postDate": "01/17/2014 11:19:09", "content": "

Thanks Anil.  I'm afraid I have missed the subtleties of line 37 in the FuelModel.  id speculated on the reality of the ascent/descent/ascent etc path.  I have been told that in certain motor competitions to get the maximum distance for a given amount of fuel the optimum is to flatten the accelerator to get to a high speed and then to coast and then to repeat this.  The efficiency of the internal combustion engine (work done per unit of fuel) is greatest under high load.  I don't know much about the efficiency of a jet engine but it is conceivable it has this sort of characteristic.  Not sure the passengers would think much of it!

\n

 

", "rawMarkdown": "", "votes": null }, { "id": "37508", "postDate": "01/17/2014 13:14:11", "content": "

[quote=Anil Thomas;37493]

\n

I was running out of things to try, so I decided to revisit this. Following the pointers from id, I added some code (highlighted below) to FuelModel.fs.

\n

 

\n

let ascentFuelBurn = max rawAscentFuelBurn cruiseFuelBurn

\n

if ascentFuelBurn = cruiseFuelBurn then 

\n

    printfn "weight %A altitude %A airspeed %A" weight altitude airSpeed

\n

(ascentFuelBurn, ascentRate)

\n

 

\n

And sure enough, running the simulator spews out messages like the ones below:

\n

weight 129295.9445 altitude 10033.14302 airspeed 522.3755016

\n

weight 131833.9212 altitude 13577.58477 airspeed 515.15

\n

weight 130342.3101 altitude 11607.57011 airspeed 519.2323575

\n

weight 130199.4593 altitude 13479.28208 airspeed 515.4957218

\n

weight 130251.1845 altitude 12287.62375 airspeed 517.8747166

\n

What does this mean? For certain combinations of weight, altitude and air speed, the aircraft can climb to higher altitudes as if gravity didn't exist. This is of course, very wrong!

\n

Our optimizers must be benefiting from this flaw, albeit unknowingly. I think a solution that systematically exploits this will do better. Maybe something to try before the buzzer goes off...

\n

[/quote]

\n

Hmm... I'm a bit lost about it.

\n

Do you have other flights with the same issue at higher altitude? all these flights are flying below 15,000ft and the lower the altitude, the higher is the fuel required to cruise. As higher than what would be required to climb further, given what you get printed.. am I wrong?

\n

I would expect this behavior to change as soon as cruising at higher altitude, then will be cheaper than climb further... or did I completely miss the point?

", "rawMarkdown": "", "votes": null }, { "id": "37550", "postDate": "01/18/2014 01:13:16", "content": "

To all those interested in the peculiarities of the fuel consumption for the GE model of a typical commercial aircraft, please see the attached graph.  Fuel consumption (lbs/hr) is plotted on the y-axis and altitude (ft) on the x-axis.  Series 1, 2 and 3 are for cruising at 300, 400 and 500 knots respectively.  Series 4 is for the aircraft ascending.  The aircraft weight is 130,000 lbs.  All points on the ascent curve are for an aircraft weighing this amount.

\n

The calculation ignores line 37 in FuelModel.fs
"let ascentFuelBurn = max rawAscentFuelBurn cruiseFuelBurn"

\n

It appears that the model has a peculiarity in that, at low altitudes ( 10,000 to 12,000 ft)  the ascent fuel burn rate is less than the cruise fuel burn rate for an aircraft cruising at 500 knots.  There are probably intersection points for lower altitudes and lower speeds also.

", "rawMarkdown": "", "votes": null }, { "id": "37662", "postDate": "01/21/2014 04:52:02", "content": "

A bug was brought to our attention recently by charango which occurs when the difference between the wind direction and the plane's direction is equal to a multiple of Π.  Given these circumstances, the plane's ground velocity could be double its airspeed.  We've updated our evaluation simulator and re-scored the latest leaderboard. Fortunately, this bug occurs extremely rarely.  Not a single submission showed a difference in its public or private score after applying the fix.

\n

We've released the updated simulator as v2.1.1 for your use on the final leaderboard.  The only code change is on line 28 of Movement.fs.

\n

Thank you Charango for finding this!

\n

 

", "rawMarkdown": "", "votes": null }, { "id": "37673", "postDate": "01/21/2014 15:40:15", "content": "

If no submission showed a difference, why bother to upload a new simulator? I mean, I guess we are not allowed to update our models to include this correction... Who assures us that this bug will not show up in the final leaderboard?

\n

P.S.
Don't you think that a modification after the final deadline deserves an email notification, at least?

", "rawMarkdown": "", "votes": null }, { "id": "37677", "postDate": "01/21/2014 16:55:03", "content": "

I hadn't noticed this feature and it looks difficult to exploit, but if someone has managed to, I think it would be grossly unfair to change the simulator now. And isn't it in violation of the rules anyway? The fourth paragraph under section 9 says that Kaggle reserves the rights to modify the simulator code up to one week before the deadline for submitting models. It seems pretty clear-cut.

", "rawMarkdown": "", "votes": null }, { "id": "37689", "postDate": "01/21/2014 19:04:55", "content": "

It seems that calculateGroundVelocity still has issues.

\n

Please check this: calculateGroundVelocity 100.0 PI (-1.0,-1.0e-15)

", "rawMarkdown": "", "votes": null }, { "id": "37696", "postDate": "01/21/2014 23:32:24", "content": "

This was not a modeling change; it was the closing of a loophole.  Winning by exploiting this loophole would have been counter to the spirit of the competition.  In the end this bug fix made no changes to anyone's flights -- in over 30 M flights that were re-scored, no changes in score were observed.

\n

It has been our practice to address simulator bugs as they appear.  No one looking at this competition would think this bug should be part of the Simulator.

\n

The final eval leaderboard will be scored using Simulator v.2.1.1.

\n

 

\n

[quote=id;37689]

\n

It seems that calculateGroundVelocity still has issues.

\n

Please check this: calculateGroundVelocity 100.0 PI (-1.0,-1.0e-15)

\n

[/quote]

\n

Id, the simulator does not support wind vectors with coordinates approaching zero at that level of precision.  If you take a look at the provided simulator weather files, the x,y coordinates are described to the hundredths place max.

", "rawMarkdown": "", "votes": null }, { "id": "37714", "postDate": "01/22/2014 06:31:46", "content": "

It's just an example that not all bugs were corrected. Once you've decided to fix bugs, it's worth fixing them all.

", "rawMarkdown": "", "votes": null }, { "id": "37715", "postDate": "01/22/2014 07:56:22", "content": "

[quote=ℕick ∈ Sardo;37696]

\n

This was not a modeling change; it was the closing of a loophole.  Winning by exploiting this loophole would have been counter to the spirit of the competition.  In the end this bug fix made no changes to anyone's flights -- in over 30 M flights that were re-scored, no changes in score were observed.

\n

It has been our practice to address simulator bugs as they appear.  No one looking at this competition would think this bug should be part of the Simulator.

\n

The final eval leaderboard will be scored using Simulator v.2.1.1.

\n

[/quote]

\n

We re-wrote the simulator in C++ for performance improvements and easier function modification and reuse. Since no one can say for sure that this "loophole" cannot be exploited in the final leaderboard dataset, we may inadvertently exploit it while computing those routes. Since we are not allowed to modify our models, not even to "close a loophole", modifying the official simulator is (not "would have been") counter the spirit of the competition.

", "rawMarkdown": "", "votes": null } ], "comments": [ { "id": 32430, "author_name": "", "author_url": "", "post_date": "10/19/2013 04:33:41", "content": "

When will the previous topics of the forum be available?

", "votes": null, "replies": [] }, { "id": 32437, "author_name": "joycenv", "author_url": "", "post_date": "10/19/2013 13:25:00", "content": "

Flight Quest 2 - Milestone forums can be found here. I will create a link to this on the main page as well.

", "votes": null, "replies": [] }, { "id": 32449, "author_name": "jc3626439", "author_url": "", "post_date": "10/20/2013 00:53:11", "content": "

I'm afraid my download of 'FQ2DataRelease2_AggregateTrain' (.zip version) stopped at 99% with 1 second remaining).  Would it possible to break this file up into smaller pieces please.

\n

Thanks in anticipation.

\n

A second try was successful.

\n

 

", "votes": null, "replies": [] }, { "id": 32458, "author_name": "gabrieleseppi", "author_url": "", "post_date": "10/20/2013 09:42:25", "content": "

We're still waiting for pointers on how arrival files (actualLandings, actualTakeoffs and groundConditions) are built, as promised. Plus, with the new simulator, I think it would be nice to have pointer also on which files you used to generate turbulence files and which thresholds are in effect when you choose what to add to those files...

\n

Thank you.

\n

Edit: I've seen now that turbulence files are already available.

", "votes": null, "replies": [] }, { "id": 32462, "author_name": "glazed", "author_url": "", "post_date": "10/20/2013 14:26:55", "content": "

So, are we going to get weather files? Partial weather files? (They aren't in "FQ2 partial Simulator Data".)

\n

Incidentally, I notice that some useful routines have been moved into 'Serialization.fs' so that they can be called from the dll. That will help me make my code cleaner. I appreciate it.

", "votes": null, "replies": [] }, { "id": 32478, "author_name": "sergeykozub", "author_url": "", "post_date": "10/21/2013 08:13:54", "content": "

Hello, admins.

\n

I've found an issue with the restricted zones handling in the simulator, details below.

\n

I've run the simulator on the test flights (without weather, i.e. zero wind), and after analyzing the generated flight logs, I've found cases when a flight enters a restricted zone, but does not get aborted (continues normally). The specific flight ID I found is 308736069, it has InRestrictedZones=1, but continues flying.

\n

By looking at the simulator code, in Flight.fs line 158 I can see:

\n

else if reachedWaypoint then
Some(Complete)
else if needToAbort parameters updatedState updatedSteps reachedWaypoint then
Some(Failed)

\n

It looks like you should change the order of the state checks. Right now, if the flight reaches a waypoint, the fact that it's in a restricted zone is ignored.

\n

Please look into this.

", "votes": null, "replies": [] }, { "id": 32491, "author_name": "nicksardo", "author_url": "", "post_date": "10/21/2013 18:57:21", "content": "

Hi Charango,

\n

Yep, these state checks should be moved around.  I've updated our evaluation simulator and re-scored the leaderboard.  We won't release an update to all competitors for another day or two as more bugs may arise or performance improvements may be made. 

\n

Thanks

", "votes": null, "replies": [] }, { "id": 32496, "author_name": "nimararora", "author_url": "", "post_date": "10/21/2013 22:45:40", "content": "It would be nice if the simulator had an option to ignore the weather, groundconditions, takeoffs, and landings. These files are not included in the Simulator Data, and until we figure out how to generate them we can't run the simulator, right?\n\nBTW, it would be mighty nice if there was a script to generate these missing files from the Aggregate information at the cut-off time, perhaps using some trivial rules like the weather doesn't change and the planes travel in a straight line to their destination at current speed with no wind or restricted zones etc. Otherwise it is very hard for a beginner to start on this competition. The point is for us to do AI and not file conversion, right?", "votes": null, "replies": [] }, { "id": 32499, "author_name": "hyperborean", "author_url": "", "post_date": "10/21/2013 23:48:49", "content": "

Even if you are willing to do file conversion, you will find it challenging to extract anything from the current content of

\n

http://soostrc.comet.ucar.edu/data/grib/rap/

\n

According to the forum, it's been some 12 hours since I pointed out that the RAP files are all gone, and I am getting a little concerned. Helpful suggestion to the effect that I don't know the difference between files and folders notwithstanding, they really are gone. I know they used to be there, so presumably there are some teams who do have the data needed to create leaderboard submissions, and plenty who do not.

\n

Kaggle must reasonably have the weather files needed to score those submissions, and presumably the RAP files used to create them. May I suggest posting at least one of those file sets?

", "votes": null, "replies": [] }, { "id": 32500, "author_name": "joycenv", "author_url": "", "post_date": "10/21/2013 23:52:29", "content": "

Hi TecS,

\n

Not sure what you're talking about ... I just looked and the files are there and they are 30 M as stated on the webpage.

", "votes": null, "replies": [] }, { "id": 32501, "author_name": "nimararora", "author_url": "", "post_date": "10/22/2013 00:07:39", "content": "TecS,\n\nYes, I can also download the GRIB files from the website you pointed, but not that I'm any wiser for it. These files are even more complicated than the provided Aggregate files :-(", "votes": null, "replies": [] }, { "id": 32502, "author_name": "hyperborean", "author_url": "", "post_date": "10/22/2013 00:10:53", "content": "

This is what that folder looks like to me...

\n

Earlier it occurred to me that maybe my IP was blocked for some reason, so I had a look through a proxy; no difference.

\n

Now I wonder if maybe they are blocking IPs from outside North America (I'm on the other side of the pond).

", "votes": null, "replies": [] }, { "id": 32503, "author_name": "nimararora", "author_url": "", "post_date": "10/22/2013 00:13:07", "content": "Did you try clicking on the link that says "hybrid" ? :-)", "votes": null, "replies": [] }, { "id": 32504, "author_name": "hyperborean", "author_url": "", "post_date": "10/22/2013 00:16:19", "content": "

:P

\n

I downloaded a few of those files yesterday to have a look, while I was deciding whether it would be worth parsing them on my own, so yes, I clicked that link. Whatever happened, happened overnight.

\n

Edit:

\n

...and now (5 minutes later?) I'm even more puzzled, because I see files again. o.O

\n

I swear I'm not on anything stronger than tap water. No idea what's going on, but I'm grabbing those files as long as it lasts.

", "votes": null, "replies": [] }, { "id": 32505, "author_name": "hyperborean", "author_url": "", "post_date": "10/22/2013 01:18:10", "content": "

Except... http://soostrc.comet.ucar.edu/data/grib/rap/20130920/

\n

Do you see that one? I don't now, which is particularly ironic since I have a few files from it since last night.

\n

And problematic if it stays gone, because it is one of the dates in the test set.

\n

 

", "votes": null, "replies": [] }, { "id": 32507, "author_name": "nicksardo", "author_url": "", "post_date": "10/22/2013 01:37:13", "content": "

We've released a complete set of simulation data for Sep 10th, the day previous to the test days. Soon we'll also release the partial weather data (one snapshot of wind pre-cutoff for each day) as we did for the milestone prize. 

\n

More info about how takeoff, landing, and ground condition files are created can be found here.  As you can see, we're just doing simple queries of the flight data.

\n

 

\n

 

\n

 

", "votes": null, "replies": [] }, { "id": 32510, "author_name": "nimararora", "author_url": "", "post_date": "10/22/2013 03:28:06", "content": "Hi Nick,\n\nThanks for providing the data for Sep 10. Could you also please explain how the Weather files were constructed? If not the script then at least the set of files that were used as input.", "votes": null, "replies": [] }, { "id": 32515, "author_name": "gabrieleseppi", "author_url": "", "post_date": "10/22/2013 06:27:21", "content": "

I've tried to use the simulator in my code and I see terrible performance compared to the old version. Is anyone else experiencing the same problem, or am I doing something wrong?

", "votes": null, "replies": [] }, { "id": 32516, "author_name": "sandros", "author_url": "", "post_date": "10/22/2013 06:41:09", "content": "

Tecs,

\n

partially agree:

\n

1) I am in Norway and can download the grib2-files.

\n

2) But the one fron 20.09.20013 is not there if you look at the index: (http://soostrc.comet.ucar.edu/data/grib/rap/) it just jumps over (=there is one for the 19th and another entry for the 21st).

\n

3) It also shows me empty folders like your png, but when I click on hybrid everything is there.

", "votes": null, "replies": [] }, { "id": 32523, "author_name": "nimararora", "author_url": "", "post_date": "10/22/2013 12:52:34", "content": "Well, the link for the Sep 20th GRIB files now works. I did notice that this link was not working earlier. Anyway, before I download 100s of GBs of data, it would be helpful if a kaggle admin could confirm that these files were indeed used for constructing the simulator's weather files :-)\n\n
\n\nI noticed that some of these files contain weather forecasts valid for the next 6-8 hours. So, it seems like all we have to do is get the forecast as of the cuttoff time on the test dates and plug it into the Simulator. I still don't understand though why this data was not included in the first place.", "votes": null, "replies": [] }, { "id": 32528, "author_name": "sandros", "author_url": "", "post_date": "10/22/2013 13:46:21", "content": "

Nimar, see here: https://www.gequest.com/c/flight2-milestone/forums/t/5714/relation-between-grib-files-and-simulator-weather-files

\n

 

\n

There you find all the info how the files were obtained and how to read them.

", "votes": null, "replies": [] }, { "id": 32533, "author_name": "hyperborean", "author_url": "", "post_date": "10/22/2013 15:24:18", "content": "

September 20 works for me too now.

\n

I have a hypothesis: it's more than one server. Maybe they are doing round-robin DNS
to balance the load, or they pointed the subdomain to a new machine after I started
looking.

\n

They use a very long Time To Live of 172800 seconds (48 hours), so if a server
you're looking at starts misbehaving, you're stuck on it for up to that long, or until
you refresh your DNS cache. Others who go there for the first time in at least 48 hours
get a fresh DNS record, and then they think you're nuts. :P

", "votes": null, "replies": [] }, { "id": 32535, "author_name": "nimararora", "author_url": "", "post_date": "10/22/2013 15:50:03", "content": "Hi TecS,\n

\nNo one is judging anyone :-) You can access the data, that is great! Now, let's focus on the real question that is which of these files are we supposed to use for this contest?\n

\nConsider the files for Sep 20. The cutoff time is 15:14. So I assume we can use the file 13092015.rap.t15z.awp130bgrbf00.grib2 . But there are other files at the same time with different "cycle" values going from 0 to 18 -- the last being 13092015.rap.t15z.awp130bgrbf18.grib2. Now, I'm not sure what "cycle" means (is it the length of the forecast?). Do we need to concatenate all the files or just pick one of them?\n

\nI'd appreciate anyone shedding light on these files. Of course, I would appreciate most of all, if Kaggle simply gave us the correctly formatted weather files :-) Why ask all the competitors to do so much busy work?", "votes": null, "replies": [] }, { "id": 32538, "author_name": "hyperborean", "author_url": "", "post_date": "10/22/2013 16:26:52", "content": "

Based on the explanation on the data page I think the last two digits (00 to 18) are forecast time offset. So the 00th file is current conditions, 01 is conditions forecast one hour in the future and so on.

", "votes": null, "replies": [] }, { "id": 32540, "author_name": "sergeykozub", "author_url": "", "post_date": "10/22/2013 17:21:26", "content": "

[quote=Nimar;32535]

\n

So I assume we can use the file 13092015.rap.t15z.awp130bgrbf00.grib2 . But there are other files at the same time with different "cycle" values going from 0 to 18 -- the last being 13092015.rap.t15z.awp130bgrbf18.grib2. Now, I'm not sure what "cycle" means (is it the length of the forecast?). Do we need to concatenate all the files or just pick one of them?
[/quote]

\n

So far I have found out the following:

\n

- 0 to 18 is the forecast hours offset, i.e. in your example, t15z...00 means the wind forecast for 15:00, t15z...01 is the forecast for 16:00, etc up to 18 hours ahead;

\n

- if the cutoff time is 15:00, you can use t15z* files; but if the cutoff time is 15:59, you're not allowed to use t16z* files, as this is prohibited by the competition rules (is the data from the future);

", "votes": null, "replies": [] }, { "id": 32545, "author_name": "anlthms", "author_url": "", "post_date": "10/22/2013 20:22:12", "content": "

[quote=Gabriele Seppi;32515]

\n

I've tried to use the simulator in my code and I see terrible performance compared to the old version. Is anyone else experiencing the same problem, or am I doing something wrong?

\n

[/quote]

\n

I see the time step value has been changed from 0.1 hr to 0.01 hr. That is bound to slow things down.

", "votes": null, "replies": [] }, { "id": 32547, "author_name": "alzmcr", "author_url": "", "post_date": "10/22/2013 20:42:17", "content": "

[quote=Anil Thomas;32545]

\n

[quote=Gabriele Seppi;32515]

\n

I've tried to use the simulator in my code and I see terrible performance compared to the old version. Is anyone else experiencing the same problem, or am I doing something wrong?

\n

[/quote]

\n

I see the time step value has been changed from 0.1 hr to 0.01 hr. That is bound to slow things down.

\n

[/quote]

\n

TimeStep was 0.01 in the previous version too! I'm guessing Gabriele meant the final cost. If I'm right, probably he's not landing ~100 planes because of the restricted zones!

", "votes": null, "replies": [] }, { "id": 32548, "author_name": "anlthms", "author_url": "", "post_date": "10/22/2013 21:09:05", "content": "

[quote=Alessandro Mariani;32547]

\n

TimeStep was 0.01 in the previous version too!

\n

[/quote]

\n

So it was! My bad.

", "votes": null, "replies": [] }, { "id": 32550, "author_name": "nicksardo", "author_url": "", "post_date": "10/22/2013 23:21:09", "content": "

The first hour of wind data for each day has been uploaded and can be found on the data page.

\n

The performance of the simulator has been degraded by detecting collisions with restricted/turbulent airspace. In our upcoming update, we'll be including some optimizations to decrease simulation time.

", "votes": null, "replies": [] }, { "id": 32552, "author_name": "nimararora", "author_url": "", "post_date": "10/23/2013 00:13:26", "content": "Thanks Nick!\n

\nDo you mean the first hour of wind data for that day OR one hour of wind data forecast from the cutoff time?\n

\nFrom what I can make out in the code, the simulator will default to nowind if there is no wind data for a given time. So these files can only be used to get the simulator running, but they won't result in any reasonable cost estimates because the simulator will assume that there is no wind at all after the 1 hour, right?", "votes": null, "replies": [] }, { "id": 32554, "author_name": "nicksardo", "author_url": "", "post_date": "10/23/2013 00:27:41", "content": "

The wind snapshot that is taken before to the cut-off time.  The simulator will retrieve whatever wind data is closest in time for that day.  Until you predict future wind data, the simulator will use these snapshots all day.

", "votes": null, "replies": [] }, { "id": 32566, "author_name": "dave40", "author_url": "", "post_date": "10/23/2013 05:17:12", "content": "

[quote=charango;32540]

\n

[quote=Nimar;32535]

\n

So I assume we can use the file 13092015.rap.t15z.awp130bgrbf00.grib2 . But there are other files at the same time with different "cycle" values going from 0 to 18 -- the last being 13092015.rap.t15z.awp130bgrbf18.grib2. Now, I'm not sure what "cycle" means (is it the length of the forecast?). Do we need to concatenate all the files or just pick one of them?
[/quote]

\n

So far I have found out the following:

\n

- 0 to 18 is the forecast hours offset, i.e. in your example, t15z...00 means the wind forecast for 15:00, t15z...01 is the forecast for 16:00, etc up to 18 hours ahead;

\n

- if the cutoff time is 15:00, you can use t15z* files; but if the cutoff time is 15:59, you're not allowed to use t16z* files, as this is prohibited by the competition rules (is the data from the future);

\n

[/quote]

\n

Hi

\n

Can I query that logic? For instance if the cutoff time is 15:14, then I would think that you could NOT use the t15z* files, since how do we know that those files (predicting/reporting wind at 15:00) didn't include information from the time period from 15:00 to 16:00 ?

\n

Surely only the t16z* files could be safely assumed to include no real-time data from the 15:00 to 15:14 time period? (or do I misunderstand the data?)

\n

Thanks Dave

", "votes": null, "replies": [] }, { "id": 32573, "author_name": "sandros", "author_url": "", "post_date": "10/23/2013 07:09:57", "content": "

A completely other thing:

\n

could you upload a change log? Or since that might be too big, a list to which .fs files have been changed (wrt milestone-simulator)? So we would not have to invest again a lot of time to figure out the details of the simlator, but can do a directed analysis.

", "votes": null, "replies": [] }, { "id": 32580, "author_name": "sergeykozub", "author_url": "", "post_date": "10/23/2013 12:39:26", "content": "

[quote=Sandro Scodeller (Sigma);32573]

\n

could you upload a change log? Or since that might be too big, a list to which .fs files have been changed (wrt milestone-simulator)? So we would not have to invest again a lot of time to figure out the details of the simlator, but can do a directed analysis.

\n

[/quote]

\n

I've put the F# into a local git repo, it's really helpful.

\n

Here are the stats (changes between "flight2-milestone" and "flight2-main"):

\n

Aircraft.fs | 28 ++---
Airspace.fs | 36 +++++++
Arrival.fs | 5 +-
CollisionDetection.fs | 85 +++++++++++++++
CostModel.fs | 135 ++++++++++++++++--------
CostParameters.fs | 3 +
Flight.fs | 61 +++++++----
FlightEntry.fs | 3 +
FlightQuest.fsproj | 4 +-
FlightTypes.fs | 17 +--
InstructionParser.fs | 2 +-
LambertConverter.fs | 11 +-
Messages.fs | 2 +
Movement.fs | 14 +--
Serialization.fs | 928 ++++++++++++++++++++++++++---------------------------
SimulationTypes.fs | 14 +++
Simulator.fs | 303 ++++++++++++++++++++++++++---------------------------
Spatial.fs | 55 +++++++++-
Tuple2.fs | 10 +-
Tuple3.fs | 10 +-
WeightModel.fs | 6 +-
Zone.fs | 10 ++
22 files changed, 1059 insertions(+), 683 deletions(-)

", "votes": null, "replies": [] }, { "id": 32602, "author_name": "drorrr", "author_url": "", "post_date": "10/23/2013 20:16:55", "content": "

maybe i misunderstand something, but is there any reason my you dont provide takeoff, landing, and ground condition files, and only give instruction how to build them ?

\n

i think, it will be easy fo us if you can provide them , no ?

", "votes": null, "replies": [] }, { "id": 32620, "author_name": "gabrieleseppi", "author_url": "", "post_date": "10/24/2013 06:09:38", "content": "

Actual takeoffs/landings and ground conditions is something that you're not supposed to know at cutoff, since it includes data from the future.

\n

The link provided by the admins (http://github.com/benhamner/GEFlightQuest/blob/master/PythonModule/geflight/postgres_ingest/schema.sql#L377) provides some insight into how those files were created from a complete dataset.

", "votes": null, "replies": [] }, { "id": 32647, "author_name": "nicksardo", "author_url": "", "post_date": "10/24/2013 23:21:28", "content": "

We've uploaded an update to the flight simulator.  

\n

Version 2.0.1
- Fixed order of instruction status checking
- Performance improvement to collision detection

\n

 

\n

Note: if you're re-compiling the source code, we highly recommend you compile in Release mode.  The compiler optimizations are quite noticeable. 

", "votes": null, "replies": [] }, { "id": 32679, "author_name": "windsofchange", "author_url": "", "post_date": "10/25/2013 14:41:53", "content": "

Hi Nick,

\n

I tried running the simulator application after making the changes as per the README file but after entering the submission file name, the simulator stops working. The error message gives a path to the program.fs file located on your desktop. Can you please tell me where the problem lies?

", "votes": null, "replies": [] }, { "id": 32718, "author_name": "nimararora", "author_url": "", "post_date": "10/26/2013 15:05:27", "content": "

I'm trying to generate the groundConditions files for the test data from the metar_reports.csv file as instructed in an earlier post. But the immediate problem I face is that the metar_reports.csv file is not complete.

\n

<br><br>

\n

For example: airport KPSP has its first entry in test2_metar_reports.csv at 2013-09-12 09:53. So, how am I supposed to generate the entry for 2013-09-11 18:24:00 ?

\n

 

\n

 

\n

X

", "votes": null, "replies": [] }, { "id": 32816, "author_name": "ankushporwal1", "author_url": "", "post_date": "10/29/2013 07:26:12", "content": "

Hi Nick,

\n

I tried running the simulator application after making the changes as per the README file but after entering the submission file name, the simulator stops working. The error message gives a path to the program.fs file located on your desktop. Can you please tell me where the problem lies? I have already tried rebooting the system after installing visual studio F#. I am getting exactly the same error line as pavan kumar is getting.

\n

kindly do reply ASAP

\n

 

\n

 

\n

 

\n

 

", "votes": null, "replies": [] }, { "id": 32819, "author_name": "nicksardo", "author_url": "", "post_date": "10/29/2013 07:36:45", "content": "

Looking at the error message, it says the simulator is failing on line 181, which is where the flight logs are saved.  You and Pavan probably don't have the 'Logs' directory created.  You could also remove the need for that directory by editing the config file.

", "votes": null, "replies": [] }, { "id": 32820, "author_name": "ankushporwal1", "author_url": "", "post_date": "10/29/2013 09:24:27", "content": "

Hi,

\n

I need some clarification regarding data provided in Partial Simulator Data . I have problem understanding data provided under Scheduled gate departure and similar time variables. how do I interpret the negative sign and decimal values.

Thanks in advance.

\n

 

", "votes": null, "replies": [] }, { "id": 32879, "author_name": "alzmcr", "author_url": "", "post_date": "10/30/2013 07:07:18", "content": "

hi - I've noticed that in the partial weather data files provided for the test set, and the full weather in 'Sept10-SimulatorFiles', the altitude layers goes up to 40880.21.

\n

[18115.849805621583,...,40880.212387122636]

\n

Planes flying at 41,000ft won't have any benefit/drawbacks from the wind... am I right? At least so looks like from the logs!

", "votes": null, "replies": [] }, { "id": 32882, "author_name": "sandros", "author_url": "", "post_date": "10/30/2013 09:15:31", "content": "

[quote=Alessandro Mariani;32879]

\n

hi - I've noticed that in the partial weather data files provided for the test set, and the full weather in 'Sept10-SimulatorFiles', the altitude layers goes up to 40880.21.

\n

[18115.849805621583,...,40880.212387122636]

\n

Planes flying at 41,000ft won't have any benefit/drawbacks from the wind... am I right? At least so looks like from the logs!

\n

[/quote]

\n

 

\n

Doesn't it depend from your code? I mean I always take wind-data from the closest wind-height available...

", "votes": null, "replies": [] }, { "id": 32888, "author_name": "jigyashukeshri", "author_url": "", "post_date": "10/30/2013 13:53:47", "content": "

Ankush wrote

\n

Hi,

\n

I need some clarification regarding data provided in Partial Simulator Data . I have problem understanding data provided under Scheduled gate departure and similar time variables. how do I interpret the negative sign and decimal values.

\n

Thanks in advance.

\n

 

\n

I have the same doubt.

", "votes": null, "replies": [] }, { "id": 32919, "author_name": "ankushporwal1", "author_url": "", "post_date": "10/31/2013 06:22:51", "content": "

Hi,

\n

I need some clarification regarding data provided in Partial Simulator Data . I have problem understanding data provided under Scheduled gate departure and similar time variables. how do I interpret the negative sign and decimal values and also how do one interpret  delay_cost_proportion_30m  and delay_cost_proportion_2h in the same file.

\n

waiting for the reply ASAP.

\n

Thanks in advance

\n

 

\n

X

", "votes": null, "replies": [] }, { "id": 32959, "author_name": "nicksardo", "author_url": "", "post_date": "10/31/2013 17:50:32", "content": "

Float time variables are offsets from the cutoff time for the day (found in the TestFlights.csv file).

\n

 

\n

The DelayCostProportion parameters are used in the perPassengerRelativeDelayCost function within CostModel.fs.  I recommend you graph that function's output over an array of incrementing delay time to get an idea of the curve.

", "votes": null, "replies": [] }, { "id": 33167, "author_name": "windsofchange", "author_url": "", "post_date": "11/04/2013 11:28:14", "content": "

There seems to be a finite delay cost even when time delayed is zero(costmodel.fs, perpassengerrelativedelaycost lines:48-56) due to the constant term time offset. Can you give me some clarification on this?  

\n

Also in descent.fs

\n

let calculateTime (model:DescentModel) (altitude:float<Feet>) =
let aTime = (float altitude)**model.TimePower
let time = model.TimeIntercept + model.TimeAltitude*aTime
let maxDescent = System.Math.Abs(float(altitude / model.MaximumRateOfDescent))
let result = max maxDescent time
result * 1.0<Hours>

\n

am I right to assume that the altitude used here is the altitude to descend(altitude difference between current and next position) and not the actual altitude(altitude of current position - this case will bias the results by ignoring the elevation of airports)?

\n

 

", "votes": null, "replies": [] }, { "id": 33423, "author_name": "sandros", "author_url": "", "post_date": "11/08/2013 13:52:15", "content": "

This might not be a bug, but is quite strange anyway.

\n

The simulation-time is not linear in number of days simulated:

\n

if I simulate only Day1 it takes around 47.941237 seconds to simulate

\n

if I simulate all 14 Days it takes 9356.984812 seconds=~2.59 hours,while I would expect it to be around 14*48=672 seconds=~11.2 min

\n

This, since it seems to me that the code simulates day per day, so there should be a linear time Increase.

", "votes": null, "replies": [] }, { "id": 33429, "author_name": "derdasmachenmuss", "author_url": "", "post_date": "11/08/2013 14:45:11", "content": "

@Sandro: I've obsorved the same, even though it takes me only a couple of minutes to run the simulator for all 14 days (on a five year old notebook). I'm not pretty sure, but I think it has something to do with how many flights are there on a day flying close to restricted areas. Most of the simulator time (> 90%)  is "lost" in the function checking wether the airplane access a restricted area. To make the computation faster, this detection is only done, if the airplane is close (there is a threshold of 570 "something", maybe miles) to at least one restricted area. And exactly here you have a high variance between the days.

", "votes": null, "replies": [] }, { "id": 33523, "author_name": "ruai00", "author_url": "", "post_date": "11/10/2013 22:15:03", "content": "

It seems simulator can fly through restricted areas.... :-)

\n

Parameters:
Folder: Sept10-SimulatorFiles
Configuration: {"TimeStep":0.01,"MaxSteps":1000,"MaxInstructions":200,"WaypointRadius":1.0,"MinimumAltitude":2000.0,"LandingMode":2,"RecordFlightLog":true}
Flight: 308567975
Restriced Area: Twenty Nine Palms
FlightId,Ordinal,Latitude,Longitude,Altitude,AirSpeed:
308567975,1,33.942,-118.408,1000,500
(StartPoint = {(-880.438361, 641.350407, 38000)}, FinishPoint = {(-1174.85113965191, 640.813583752209, 125)})

\n

One corner of area is too sharp....

\n

Or I am wrong?

", "votes": null, "replies": [] }, { "id": 33529, "author_name": "alzmcr", "author_url": "", "post_date": "11/10/2013 23:00:04", "content": "

I've tried and it lands .. so you're not wrong! probably as that vertex is soo sharp, and the plane can cross the area pretty quickly, the interpolation of the simulator is not quick enough to catch that (using 0.01 as TimeStep).

\n

To let it crash it, you need to set TimeStep to 0.0001 in your configuration file... beside that, I don't really think there are many cases like this!

\n

 

", "votes": null, "replies": [] }, { "id": 33532, "author_name": "johnsonav", "author_url": "", "post_date": "11/11/2013 00:18:52", "content": "

I'm not sure this kind of thing is that rare. If your algorithm happens to exploit this behavior, it's possible to cut right through the middle of some of the thinner restricted airspace zones.

\n

Here's a flight that does it:

\n

310039922,1,34.97441755760357,-114.64500555487143,39000.0,490.0

\n

310039922,2,34.93409855397412,-114.75539098107771,38000.0,490.0

\n

310039922,3,34.71280234193989,-115.39569522750435,2000.0,514.5

\n

310039922,4,34.29542586809027,-116.81651190318607,2000.0,490.0

\n

310039922,5,34.28802281433884,-116.84514731267217,38000.0,490.0

\n

310039922,6,34.207960928876524,-117.16504597631933,2000.0,524.79

\n

310039922,7,34.04467210342863,-117.88785326245329,38000.0,490.0

\n

310039922,8,33.94199999999999,-118.40799999999993,17000.0,490.0

\n

 

\n

And here's a visualization of where the plane flies over the restricted airspace. Each dot on the line is one step of the simulator.

\n

\n

 

\n

It does seem that making the time step smaller fixes this problem for the most part. But it'd be good to get an official ruling on this.

\n

 

\n

(ETA: This flightLog entry was generated using the 1hr weather file for the date in question.)

", "votes": null, "replies": [] }, { "id": 33552, "author_name": "derdasmachenmuss", "author_url": "", "post_date": "11/11/2013 09:44:16", "content": "

@johnsonav: I observed the same effect in my experiments. But I don't think you can exploit this behaviour to reduce the calculated flight costs. The main problem is, that you run in numerical instabilities. My code also calculated such route, and its a valide flight route on one computer, but when I go to another computing architecture, the route is invalid as it enteres the restricted zone. Even when I keep my code running on the same computer, but have small changes in the input date (e.g. weather files), it's just random, whether the flight reached the destination or not. Even if you have 10 flights, where you try to make use of this effect (and I don't think it will significantly reduce the flight cost), and one flight is rejected by the simulator, the overall cost will be higher than with flight routs correctly avoiding the restricted zones.

", "votes": null, "replies": [] }, { "id": 33560, "author_name": "glazed", "author_url": "", "post_date": "11/11/2013 14:33:25", "content": "

My experience is similar to that of the 2 posters above. I can safely send flights through the center of the exclusion zone at 29 Palms, and cutting corners of the other zones. However, a change in the weather tends to crash them. I see this feature as more hazard than opportunity, but fair game either way.

", "votes": null, "replies": [] }, { "id": 33627, "author_name": "gabrieleseppi", "author_url": "", "post_date": "11/12/2013 14:36:02", "content": "

We found the same problem a few days ago, but wanted to be 100% sure we weren't missing something before posting (actually, I came to the forum today to post this very problem! :D)

\n

Anyway, I think that a solution can be easily implemented in the simulator by the admins. It requires 2 changes:

\n

1) the aircraft is considered as a point (not too big a problem: consider that at the moment the cylinder that represents the aircraft is so small compared to movement/restricted zones that the simulator won't lose much)

\n

2) every step performs a simple line-polygon intersection check which, coupled with the fact that the aircraft is considered as a point, could even bring some performance improvements

\n

 

\n

What do you think?

", "votes": null, "replies": [] }, { "id": 33632, "author_name": "derdasmachenmuss", "author_url": "", "post_date": "11/12/2013 15:17:07", "content": "

There is even a simpler solution, that would speed up the simulator by a factor. You just need to check, whether there is at least one intersection of the route's instructions (which are also just 2D line segments) and the polygon lines of the restricted zones. But where it does not work are the turbulenze zones, as you want to know how long the airplane flighs through them.

", "votes": null, "replies": [] }, { "id": 33644, "author_name": "nicksardo", "author_url": "", "post_date": "11/12/2013 22:51:00", "content": "

Indeed, flights are capable of traveling through thin restricted zones due to the length of the time step.  We considered shortening the step before releasing the updated simulator; however, the return effect wouldn't be worth the increased workload on the simulator.  It's only three or four zones small enough to be susceptible to side-to-side crossing and cutting corners would occur at practically any step size.  The simulator code and settings will not be changed. 

\n

There exists several options to improve the performance of the simulator, but we feel the current speed is satisfactory for your use and our evaluation servers.  You're welcome to make those changes to your simulator instance. DerDasMachenMuss makes a good suggestion of only checking the line segments of your flight instructions, at the cost of ignoring turbulent zone intersection times.  

", "votes": null, "replies": [] }, { "id": 33664, "author_name": "gabrieleseppi", "author_url": "", "post_date": "11/13/2013 07:15:49", "content": "

Unfortunately performing a segment-polygon intersection check over instruction points is not safe enough, because the actual vertical profile could be different from the instructed one and at the same time the aircraft, although small, is not a point.

\n

Regardless of performance, anyway, what's the point of having restricted zones if they can be intersected without consequences under particular conditions? Yes, we're talking about three, max four zones, but over less than 30 total at any given time (restricted + turbulent): that's more than 10%. And we're not considering corners... Cutting through corners (or entire zones) can yield quite an interesting advantage over a full length deviation, and I guess this is not the purpose of the competition, especially after the addition of such areas.

\n

Just my opinion though =)

", "votes": null, "replies": [] }, { "id": 33684, "author_name": "jarfo1", "author_url": "", "post_date": "11/13/2013 18:16:55", "content": "

I completely agree with Gabriele Seppi, and in fact I was going to propose the same solution to the problem of undetected intersected restricted zones.

\n

It can be an importante factor in the evaluated mean cost, and the proposed line-polygon intersection check in each step seems a simple solution.

\n

I understand nobody likes simulator code changes, but it seems clearly better to consider the airplane a moving point (segment) during each step, that a tiny cylinder with quantum tunneling powers.

", "votes": null, "replies": [] }, { "id": 34818, "author_name": "tyi2000", "author_url": "", "post_date": "11/17/2013 09:47:31", "content": "

Hi admins,

\n

I'm taking a look at the arrival model of the simulator, and there are a few things I found suspicious.

\n

1. visibility terms in landing model and taxi model

\n

visibility coefficients are given in the Landing.csv and Taxi.csv data files, but they are not used in the predictLanding and predictTaxi functions in Arrival.fs. Are they intentionally omitted?

\n

2. utilScheduledRunwayArrival/untilScheduledGateArrival in landing model

\n

Landing model data(Landing.csv) has the coefficent named time_at_cutoff_to_scheduled_gate_arrival_hours and time_at_cutoff_to_scheduled_runway_arrival_hours. From the namesI assume they are meant to be the coefficents for (scheduled gate/runway arrival time - cutoff time), but in predictLanding function, these coefficients are multiplied with (scheduled gate/runway arrival time - the starting time of descent for landing). Which is correct (the field name or the code)?

\n

3. untilScheduledGateArrival in taxi model

\n

Similarly, taxi model data(Taxi.csv) has the coefficient actual_runway_arrival_to_scheduled_gate_arrival_hours but it is multiplied by (scheduled gate arrival - the starting time of descent for landing). Again, which is correct one?

\n

 

\n

Aside from the arrival model, I have another issue with the simulator. In the simulator, the wind speed above 40880 feet or below 18115 feet are calculated as zero.This can be exploited for avoiding headwind, and I think the more realistic behavior for the weather modeling would be using wind vector from the nearest grid point.

", "votes": null, "replies": [] }, { "id": 34934, "author_name": "chipmonkey", "author_url": "", "post_date": "11/19/2013 21:07:02", "content": "

I realise it's pretty late in the game for this, but is there any documentation on what the simulator is supposed to do, other than the actual code?  There have been a lot of good questions raised, but I can barely get through the F# well enough to figure out how it works, much less decide if the code is "correct" (obviously it's my own fault for not committing more time, but still).

\n

My most recent question: if you ascend or descend over (or under, I guess) a restricted area, then whether or not you intersect it depends on the rate of ascent or descent, and I can SEE the math, obfuscated tho it is, in the F# code, but I have nothing tangible to compare it to, so I can't tell if there's a bug or not.  Does that make sense?  Should descent be a straight line?  Should it (a graph of altitude over time during descent) be steeper at the start and level off (convex), or should it start more slowly (concave or s-shaped)?  Concave would cause crashes, of course.  Should turns happen on a dime or cut the corner of the waypoint on the acute side?

\n

For example, there's an <altitude>^1.2 calculation in the ascent code a few times. Can someone explain why that is?  Is this due to a lower drag that comes with higher altitude?  And I see a lot of constants, but I can't tell if they're "right"... FuelAltitudeSqrt is not the Square Root of FuelAltitude (negatives notwithstanding).  Should it be?  What do these mean in the world of physics equations?

\n

As a last example, was the eccentricity that allowed the winning milestone strategy not considered a bug in the ascent cost logic?  From the forum posts it sounds like the ascent costs weren't changed (only the 5-change penalty added).  With some sort of descriptive model to compare against it would be easier to tell and recommend improvements.

\n

Anyway, let me know if I'm missing something... I have a hundred other questions, but it's too late to go into that level of detail, I think, and almost certainly too late to fix simulator bugs, but I finally had to break down and ask.  Thanks for reading!

", "votes": null, "replies": [] }, { "id": 34951, "author_name": "spirals0", "author_url": "", "post_date": "11/20/2013 03:16:21", "content": "

Hi,

\n

I've been trying to get RunSimulation.exe to compile. At first it couldn't find the files groundConditions_*, actualTakeoffs_* and actualLandings_*. If I'm interpreting correctly, those files aren't needed for the FQ2 Partial Simulator Data? Anyways, I removed the references to those files in RunSimulation.exe.config. But now I am getting an error:

\n

 

\n

System.UnauthorizedAccessException: Access to the path my_path_to_the_data is denied.

\n

 

\n

I am running the executable as an administrator and the folder has no special permissions required. Plus, the program has already read a bunch of data from the folder (Airports.csv for example).  Has anyone encountered this error? I am running on Windows 8.1.

\n

 

\n

Thanks!

\n

 

", "votes": null, "replies": [] }, { "id": 34999, "author_name": "arieli", "author_url": "", "post_date": "11/21/2013 13:59:10", "content": "

I am concerned about the issue of a flight flying unperturbed through a restrictedZone.

\n

After looking at the code, it seems to me that one can safely pass any restrictedZone that is small enough to be crossed in less than 0.6 minutes (one can take a safe margin to account for possible headwind) by putting a waypoint just before crossing it.

\n

By doing it, he is assured that the next step at which the simulator will check the possible intersection would take place after 0.6 minute. So as long as one chooses a good enough margin, he would be safe to cross it (I have not tested this).

\n

If it is indeed the case, any one who would not use this strategy would be penalized, since it is certain that cutting through corners of small enough restricted zones would save on fuel and time, with practically no risk of crash.

\n

I think there should be an official ruling (and enforcement) on whether or not this is allowed. I agree with Gabriele and Jose that adding a check to disallow this would be best for the purpose of this competition.

\n

One possible option that would not require any change in the simulator would be to postprocess the flight logs to check that this condition has not occured during the flight.

", "votes": null, "replies": [] }, { "id": 35076, "author_name": "nicksardo", "author_url": "", "post_date": "11/23/2013 02:16:56", "content": "

We've updated the simulator and have re-scored the leaderboard. 

\n

Version 2.1
- Changed collision detection mechanism to prevent skipping over zones
- Added Visibility to Landing/Taxi GLMs
- Wind data is now relevant above 40.8k and below 18k feet

", "votes": null, "replies": [] }, { "id": 35079, "author_name": "ktchris", "author_url": "", "post_date": "11/23/2013 08:19:26", "content": "

Hi!

Thank you for updating the simulator.

"Wind data is now relevant above 40.8k and below 18k feet". Will we get a new weather file snapshot in the cutoff time, to see the difference? 

Thank you in advance,
Christian

", "votes": null, "replies": [] }, { "id": 35083, "author_name": "hyperborean", "author_url": "", "post_date": "11/23/2013 10:59:19", "content": "

The leaderboard seems to like those changes. Is it still using the same flights as before? If so, I guess the improved scores are due to the aircraft now being a dimensionless dot which can get closer to restricted zones with impunity, so there are fewer collisions. Oh well, win some, lose some.

", "votes": null, "replies": [] }, { "id": 35089, "author_name": "gabrieleseppi", "author_url": "", "post_date": "11/23/2013 14:36:15", "content": "

The new collision detection still has potential for "skipping". As stated at line 29 of Airspace.fs, using only destination altitude allows for clipping of upper and lower corners. Furthermore, flights which at cutoff are inside a zone (near the boundary), can easily escape it without being penalized.

\n

Glad to see that segment-polygon intersection has been implemented, though :)

", "votes": null, "replies": [] }, { "id": 35094, "author_name": "arieli", "author_url": "", "post_date": "11/23/2013 15:37:06", "content": "

... or perhaps the improvement is because flights at 41,000 can also benefit from the wind

\n

Thanks to the organizers for the new simulator.

", "votes": null, "replies": [] }, { "id": 35105, "author_name": "nicksardo", "author_url": "", "post_date": "11/23/2013 23:07:47", "content": "

[quote=Gabriele Seppi;35089]

\n

The new collision detection still has potential for "skipping". As stated at line 29 of Airspace.fs, using only destination altitude allows for clipping of upper and lower corners. Furthermore, flights which at cutoff are inside a zone (near the boundary), can easily escape it without being penalized.

\n

[/quote]

\n

You're welcome to try making gains from clipping on the z-axis.  Furthermore, no flights start off within a zone. 

\n

[quote=Christian Kiss-Tóth;35079] 

\n

Will we get a new weather file snapshot in the cutoff time, to see the difference?

\n

[/quote]

\n

Sorry for being vague; there is no new wind data.  For altitudes outside the range of 18k-40.8k ft, the min or max altitude level is used.  

\n

[quote=Arieli;35094]

\n

... or perhaps the improvement is because flights at 41,000 can also benefit from the wind

\n

Thanks to the organizers for the new simulator.

\n

[/quote]

\n

You're welcome :)

", "votes": null, "replies": [] }, { "id": 35106, "author_name": "gabrieleseppi", "author_url": "", "post_date": "11/23/2013 23:09:46", "content": "

I just noticed on MSDN that System.Math.Round() can be unpredictable in rounding certain values (see http://msdn.microsoft.com/en-us/library/wyk4d9cy(v=vs.110).aspx for an example). Considering that flight level selection during instruction correction is an important step in the evaluation of a flight, wouldn't it better to replace System.Math.Round() with System.Math.Ceiling() (o System.Math.Floor()) for consistency? I'm talking about line 25 of InstructionCorrector.fs: why do westbound flight receive rounding with System.Math.Round() while eastbound flight with System.Math.Ceiling()?

", "votes": null, "replies": [] }, { "id": 35107, "author_name": "gabrieleseppi", "author_url": "", "post_date": "11/24/2013 00:00:40", "content": "

[quote=ℕick ∈ Sardo;35105]

\n

[quote=Gabriele Seppi;35089]

\n

The new collision detection still has potential for "skipping". As stated at line 29 of Airspace.fs, using only destination altitude allows for clipping of upper and lower corners. Furthermore, flights which at cutoff are inside a zone (near the boundary), can easily escape it without being penalized.

\n

[/quote]

\n

You're welcome to try making gains from clipping on the z-axis.  Furthermore, no flights start off within a zone. 

\n

[/quote]

\n

I'm not saying we can make gains, but that, not knowing future winds, we could find ourselves in a situation where the aircraft hits a zone even if we didn't want to, simply because of a stronger tailwind or headwind.

\n

Regarding flights starting off within a zone, I may be wrong, but I've come across a few which, at cutoff, are inside a turbulence zone (a couple examples: 309252255, 309256963). I haven't checked them all, of course, so I don't know it this is the case, but if a flight at cutoff is inside a zone, yet close enough to the lower or upper boundary, it can escape easily.

\n

I don't think it's going to matter anyway, I was just trying to be open and notify of possible - yet remote - pitfalls :)

", "votes": null, "replies": [] }, { "id": 35108, "author_name": "nicksardo", "author_url": "", "post_date": "11/24/2013 00:23:57", "content": "

[quote=Gabriele Seppi;35107]

\n

I'm not saying we can make gains, but that, not knowing future winds, we could find ourselves in a situation where the aircraft hits a zone even if we didn't want to, simply because of a stronger tailwind or headwind.

\n

[/quote]

\n

Sounds like real life.  :-)

\n

[quote=Gabriele Seppi;35107]

\n

Regarding flights starting off within a zone, I may be wrong, but I've come across a few which, at cutoff, are inside a turbulence zone (a couple examples: 309252255, 309256963).

\n

[/quote]

\n

Ah, I thought you were referring to restricted zones.  

", "votes": null, "replies": [] }, { "id": 35134, "author_name": "jarfo1", "author_url": "", "post_date": "11/24/2013 20:09:32", "content": "

Hi

\n

Thanks to the organizers for the update.I just want to mention to everybody I had some initial problems with the updated simulator because violations of restricted (turbulent) zones with repeated vertices are not detected (because of the resulting (Nan, Nan) in calculating the unit normal vector of this zero-length polygon side).

\n

The last version of "FQ2 Partial Simulator Data with 1hr weather" has the corrected "restrictedZones.csv" without vertices repetitions but the "Sept10-SimulatorFiles" still have the "Twenty Nine Palms" restricted zone with repeated vertices.

\n

 

", "votes": null, "replies": [] }, { "id": 35135, "author_name": "nicksardo", "author_url": "", "post_date": "11/24/2013 21:35:18", "content": "

[quote=José A. R. Fonollosa;35134]

\n

The last version of "FQ2 Partial Simulator Data with 1hr weather" has the corrected "restrictedZones.csv" without vertices repetitions but the "Sept10-SimulatorFiles" still have the "Twenty Nine Palms" restricted zone with repeated vertices.

\n

[/quote]

\n

Replaced the restrictedZones.csv in the Sept. 10 files.  

", "votes": null, "replies": [] }, { "id": 35186, "author_name": "smiler", "author_url": "", "post_date": "11/25/2013 12:48:58", "content": "

Hi,

\n

sometimes the simulator doesn't reach the destination because of arrivalRadius (1mile in Configuration.json) simulator parameter.

\n

Let me explain my self. Suppose the last waypoint is within 1 mile from the airport arrival frontier, i.e. waypoint between [64.1732, 65.1732]. stepToWaypoint function returns that destination is reached when you are at most at arrivalRadius from the last waypoint. Sometimes it happens that the last position is larger than 65.1732 (destination reached is set) but the aircraft won't land because it is out of airport radius.

\n

Can we know the simulator parameters in the online simulator?

\n

BR

", "votes": null, "replies": [] }, { "id": 35973, "author_name": "arieli", "author_url": "", "post_date": "12/08/2013 22:03:38", "content": "

Most expensive flight, ever!

\n

With this itinerary:

\n

308663997,1,34.9709,-103.1294,37000,406.5456
308663997,2,32.8996,-97.0574,17000,319.4624
308663997,3,32.897,-97.038,17000,319.3332

\n

I get, 10^33 in fuel expenses ?!

\n

...

\n

308663997,33.3034728137757,-98.1717180290048,-160.875486538811,502.229931179563,1.500,319.46,316.36,17000.00,6689.14,False,False,125895.56,Flying
308663997,32.897,-97.038,-103.747366772221,476.470353064938,3208235363634990000000000000000000.000,0.00,0.00,607.00,6365645862639280000000000000000000000.00,False,False,114668.00,Crashed

\n

 

", "votes": null, "replies": [] }, { "id": 36012, "author_name": "briank2", "author_url": "", "post_date": "12/10/2013 00:42:50", "content": "

It seems a bit odd that groundConditions for times outside those in the file are set to 0, 0, 0, T=45, rather than assigned to the nearest value, similar to the issue/change made for weather layers.

\n

This means, if a cutoff is early in the hour, and the next report isn't until cutoff + value close to 1hr, all flights landing in < 1hr will ignore ground conditions and set to the constant values? Why not just use the closest report (as done for values within the timeaxis, and now similarly done for z outside wind layers)? Seems like an odd boundary condition to introduce, and fairly unrealistic.

", "votes": null, "replies": [] }, { "id": 36376, "author_name": "nicksardo", "author_url": "", "post_date": "12/19/2013 19:53:14", "content": "

[quote=Arieli;35973]

\n

Most expensive flight, ever!

\n

With this itinerary:

\n

308663997,1,34.9709,-103.1294,37000,406.5456
308663997,2,32.8996,-97.0574,17000,319.4624
308663997,3,32.897,-97.038,17000,319.3332

\n

[/quote]

\n

Arieli, is this reproducible for you (or anyone else)?  My flight log came out normal with this itinerary.

", "votes": null, "replies": [] }, { "id": 36622, "author_name": "julesvanligtenberg", "author_url": "", "post_date": "12/24/2013 09:29:37", "content": "

Hi Admins,

\n

 

\n

Maybe I missed something or doing something wrong but it seems to me that

\n

training3_flighthistory.csv is possibly corrupt.

\n

In contrast with training2_flighthistory.csv column 24 (scheduled_aircraft_type) is filled
with datetime info and not with stuff like M80 etc.

\n

 

\n

Could somebody look into this please?

\n

Thanks in advance.

\n

 

", "votes": null, "replies": [] }, { "id": 36623, "author_name": "gabrieleseppi", "author_url": "", "post_date": "12/24/2013 10:26:54", "content": "

Confirmed. It looks a lot like it's equivalent to scheduled runway arrival for certain flights, but for others it's not...

", "votes": null, "replies": [] }, { "id": 36630, "author_name": "joycenv", "author_url": "", "post_date": "12/24/2013 14:32:24", "content": "

Just to clarify, it's only part of the file, not the whole thing? What fraction of the file is affected? Could you cut and paste a sample row where it's wrong, with line number? We'll try to get to it as soon as we can, but with the holidays it might be a while. 

", "votes": null, "replies": [] }, { "id": 36635, "author_name": "julesvanligtenberg", "author_url": "", "post_date": "12/24/2013 18:48:28", "content": "

Hi joycenv,

\n

Thanks for the quick reaction. Column 24 has a wrong value for all the 620.569 rows of the file. I don't know if the other columns are OK, I don't see any obvious flaws.

\n

My guess is that either the program extracting the data has been changed between extracting training2_flighthistory.csv and training3_flighthistory.csv or the format of the source has been changed.

\n

If so, this could possibly also be an explanation for the discrepancies between training2_flighthistory.csv and actualLandings_20130910_1803.csv reported by Alessandro, Anil and myself in the thread http://www.gequest.com/c/flight2-main/forums/t/6239/which-files-are-going-to-be-provided

", "votes": null, "replies": [] }, { "id": 36728, "author_name": "julesvanligtenberg", "author_url": "", "post_date": "12/27/2013 20:18:08", "content": "

Maybe there is yet another issue with training3_flighthistory.csv.

\n

It looks like there are big gaps where there are no flights with an actual_runway_departure.

\n

For instance there seems to be no flight with an

\n

actual_runway_departure > 2013-11-20 8:38 and actual_runway_departure < 2013-11-21 4:51

\n

Can somebody confirm this please?

\n

Thanks in advance!

", "votes": null, "replies": [] }, { "id": 36734, "author_name": "robertramey", "author_url": "", "post_date": "12/27/2013 21:11:39", "content": "

"More info about how takeoff, landing, and ground condition files are created can be found here. As you can see, we're just doing simple queries of the flight data."

\n

could you expand upon this?  I'm just "upgrading" to the most recent dataset.  I run the simulator and it bails trying to open files for files "groundConditions_{DAY_TIME}.csv" which are not found.  According to: https://www.gequest.com/wiki/FlightQuest2 I should just be able to build them and I'm pointed to a large python script.  "https://github.com/benhamner/GEFlightQuest/blob/master/PythonModule/geflight/postgres_ingest/schema.sql#L405"  (or I guess it's an sql script). What exactly am I supposed to do with this?  A higher level page includes invocation of a python script.  Please expand upon this.

\n

Another very odd thing is that the simulator doesn't even seem to use this data.

\n

Obviously I'm missing something ridiculously obvious here.  Anyone know what it might be?

\n

Robert Ramey

\n

 

", "votes": null, "replies": [] }, { "id": 36822, "author_name": "julesvanligtenberg", "author_url": "", "post_date": "12/30/2013 14:03:19", "content": "

Hi Admins and fellow competitors,

\n

 

\n

The Flight Simulator seems to crash depending on contents of actualLandings_....csv.

\n

I varied the contents of the actualLandings- and the actualTakeoffs-file according to the contents of the training1- and training2-flighthistory file and found that the Flight Simulator crashes on a number of occasions.

\n

I looked for an example easy to reproduce and found the following one:

\n

step1: start out with 10 sept simulation files (version2)

\n

step2: remove from actualLandings_20130910_1803.csv all landings in the first 5 hours ( so the first line after the header is: KMCO,6.001758,1)

\n

step3: start runsimulation

\n

It crashes before you can enter the routes. (on my machine anyway)

\n

Can someone reproduce this?

\n

 

\n

I attached the STDERR of the command

\n

 

\n

 

", "votes": null, "replies": [] }, { "id": 36825, "author_name": "alzmcr", "author_url": "", "post_date": "12/30/2013 16:03:01", "content": "

Does the actualLanding (and takeoff) file contains at least one records for all the 63 airports? If does not, this is you problem!

", "votes": null, "replies": [] }, { "id": 36870, "author_name": "julesvanligtenberg", "author_url": "", "post_date": "12/31/2013 11:59:33", "content": "

Thanks, I will keep that in mind.

", "votes": null, "replies": [] }, { "id": 36924, "author_name": "joycenv", "author_url": "", "post_date": "01/02/2014 19:46:09", "content": "

[quote=Jules;36622]

\n

Hi Admins,

\n

 

\n

Maybe I missed something or doing something wrong but it seems to me that

\n

training3_flighthistory.csv is possibly corrupt.

\n

In contrast with training2_flighthistory.csv column 24 (scheduled_aircraft_type) is filled
with datetime info and not with stuff like M80 etc.

\n

 

\n

Could somebody look into this please?

\n

Thanks in advance.

\n

 

\n

[/quote]

\n

A corrected version of training3_flighthistory (has _rev1 in the name) has been posted to the Data page. Sorry for the error. Thank you very much for your patience while we prepared the new file.

", "votes": null, "replies": [] }, { "id": 36989, "author_name": "sergeykozub", "author_url": "", "post_date": "01/04/2014 10:07:31", "content": "

Hello, admins.

\n

Currently, it looks like, if any flight path in the submission has more than 200 waypoints, the whole submission is aborted with zero score. Maybe it'll be better to penalize this flight path with NonArrivalPenalty (100,000) instead of failing the whole submission?

\n

Right now it doesn't seem fair (to me) to kick the participant out of the competition, instead of adjusting the score, for a single error.

", "votes": null, "replies": [] }, { "id": 37004, "author_name": "jc3626439", "author_url": "", "post_date": "01/05/2014 09:27:44", "content": "

Hi Charango,  This rule was mentioned in Basic Structure of Flight Quest2/Getting Started/Paragraph 5 where it says

\n

"One constraint worth mentioning here is the maximum allowed number of instructions for each flight is 200 instructions"

\n

Good Luck

", "votes": null, "replies": [] }, { "id": 37006, "author_name": "gabrieleseppi", "author_url": "", "post_date": "01/05/2014 09:52:25", "content": "

To be honest, I see no point in setting this constraint in the first place... What's the purpose of limiting the number of instructions?

", "votes": null, "replies": [] }, { "id": 37007, "author_name": "hyperborean", "author_url": "", "post_date": "01/05/2014 10:00:30", "content": "

"This is the captain speaking. To your left, you can now enjoy the unusual sight of my co-pilot sitting on the port wing. We will be flying in a holding pattern until he agrees to climb back in here and resume punching 500 updated waypoints into the flight computer. Refreshments to be rolled out soon."

", "votes": null, "replies": [] }, { "id": 37010, "author_name": "sergeykozub", "author_url": "", "post_date": "01/05/2014 12:17:06", "content": "

I have implemented this rule in my model, I have no problem with it.

\n

It was just very surprising that the simulator fails the whole submission, if you don't meet it (you get zero score). In contrast, if you will crash a few planes (by running out of fuel), the punishment is less severe - your score will be a bit worse.

", "votes": null, "replies": [] }, { "id": 37011, "author_name": "gabrieleseppi", "author_url": "", "post_date": "01/05/2014 13:04:11", "content": "

I have implemented it too, no problem here. I was just wondering what the purpose of limiting the number of instructions is...

", "votes": null, "replies": [] }, { "id": 37057, "author_name": "nicksardo", "author_url": "", "post_date": "01/06/2014 21:09:02", "content": "

Subtlety failing flights would cause even more surprise (and anger) once participants figured it out after submitting a few times.  Without a doubt, preemptive failing the whole submission is the right way to go for such a simple, universal rule.

\n

 

\n

This constraint exists for several reasons: first, flight routes should be in the domain of a human pilot, not a navigational computer.  Second, this prevents any malicious user from bogging down our servers with routes containing millions of instructions.

", "votes": null, "replies": [] }, { "id": 37062, "author_name": "gabrieleseppi", "author_url": "", "post_date": "01/06/2014 22:54:05", "content": "

I'm not saying of setting no upper bound, but since the simulator is currently upper bounded on 1000 steps, why not allow up to 1000 instructions for example?

\n

Secondly, I understand routes should be in the domain of a human pilot, but we're talking about commercial jets here. If pilots are given 200 waypoints they're never going to "hand fly" them anyway, that's just impossible. Assume a 3000nm route with 200 waypoints: that's 15nm between any 2 waypoints on average. No human being is capable of sustaining such stress for so long a time.
Adding the route into the FMC will show it up onto the ND and the pilot will be able to hand fly the aircraft following pitch and roll instructions on the PDF, but we're already falling into the realm of navigational computer here. So, should we reduce the number of instructions? Yes, but the FMC will compute a nice interpolation for pilots, a thing that our simulator is not going to do.
Furthermore, I thought we were trying to improve information shown to the pilots in order to allow them make fuel saving decisions. How should they get them? A navigational computer is already installed on all modern aircrafts, why not use it?

\n

All I'm saying is that, since no interpolation is available, long routes could benefit from more than 200 instructions. I see no point in imposing this limit, except of course not clogging Kaggle servers (which, as a system administrator, I know can be hard to handle ;)

", "votes": null, "replies": [] }, { "id": 37063, "author_name": "nicksardo", "author_url": "", "post_date": "01/06/2014 22:56:51", "content": "

The instruction and step limits stay as they are.

", "votes": null, "replies": [] }, { "id": 37152, "author_name": "anlthms", "author_url": "", "post_date": "01/09/2014 06:33:17", "content": "

[quote=ℕick ∈ Sardo;37057]

\n

This constraint exists for several reasons: first, flight routes should be in the domain of a human pilot, not a navigational computer.

\n

[/quote]

\n

Isn't 200 already out of the domain of a human pilot? I would have liked to see an upper bound of 20. Not to be nice to the pilot, but because that's the maximum number of waypoints in my solution :-)

\n

Clearly, I am leaving something on the table. On the plus side, it only takes a couple of hours to generate a complete solution.

", "votes": null, "replies": [] }, { "id": 37230, "author_name": "glazed", "author_url": "", "post_date": "01/10/2014 14:56:44", "content": "

That is interesting information. In the spirit of reciprocity: my paths contain 8 to 12 waypoints (fewer if you ignore those that don't matter), and I use the first hour's weather plus the examples they gave us for "actualLandings_xxx" etc.. Ignoring weather prediction saved me a considerable amount of time and aggravation, but it's looking like a gamble that didn't pay off.

", "votes": null, "replies": [] }, { "id": 37493, "author_name": "anlthms", "author_url": "", "post_date": "01/17/2014 08:41:29", "content": "

I was running out of things to try, so I decided to revisit this. Following the pointers from id, I added some code (highlighted below) to FuelModel.fs.

\n

 

\n

let ascentFuelBurn = max rawAscentFuelBurn cruiseFuelBurn

\n

if ascentFuelBurn = cruiseFuelBurn then 

\n

    printfn "weight %A altitude %A airspeed %A" weight altitude airSpeed

\n

(ascentFuelBurn, ascentRate)

\n

 

\n

And sure enough, running the simulator spews out messages like the ones below:

\n

weight 129295.9445 altitude 10033.14302 airspeed 522.3755016

\n

weight 131833.9212 altitude 13577.58477 airspeed 515.15

\n

weight 130342.3101 altitude 11607.57011 airspeed 519.2323575

\n

weight 130199.4593 altitude 13479.28208 airspeed 515.4957218

\n

weight 130251.1845 altitude 12287.62375 airspeed 517.8747166

\n

What does this mean? For certain combinations of weight, altitude and air speed, the aircraft can climb to higher altitudes as if gravity didn't exist. This is of course, very wrong!

\n

Our optimizers must be benefiting from this flaw, albeit unknowingly. I think a solution that systematically exploits this will do better. Maybe something to try before the buzzer goes off...

", "votes": null, "replies": [] }, { "id": 37496, "author_name": "drorrr", "author_url": "", "post_date": "01/17/2014 09:37:28", "content": "

Interesting, did you consider that the code run in parallel so maybe this is not the same flight or there is no time order ? (also the weight looks going on the off)

", "votes": null, "replies": [] }, { "id": 37498, "author_name": "jc3626439", "author_url": "", "post_date": "01/17/2014 09:50:40", "content": "

Anil, airspeed is not an input in the ascent model. Fuel consumed seems to depend on altitude and weight.  I took it that the ascent model describes the typical aircraft in ascent and, for a given weight, the fuel consumed depends on altitude reached.  It would be possible with some algebra (and possibly some differentiation) to determine the airspeed at a particular altitude but this is not in the ascent model.  Have I missed something?

", "votes": null, "replies": [] }, { "id": 37501, "author_name": "anlthms", "author_url": "", "post_date": "01/17/2014 10:05:36", "content": "

[quote=sparrow ;37496]

\n

Interesting, did you consider that the code run in parallel so maybe this is not the same flight or there is no time order ? (also the weight looks going on the off)

\n

[/quote]

\n

They are all different flights.

", "votes": null, "replies": [] }, { "id": 37502, "author_name": "anlthms", "author_url": "", "post_date": "01/17/2014 10:22:19", "content": "

[quote=JC36;37498]

\n

Anil, airspeed is not an input in the ascent model.

\n

[/quote]

\n

Correct. However airspeed is an input to the cruise model. The way the code is written, the amount of fuel consumed during ascent also depends on the cruise model. In any case, my point is that at just the right combinations of weight, altitude and airspeed, the ascent burn rate becomes equal to the cruise burn rate (within the alternate reality of the simulator).

", "votes": null, "replies": [] }, { "id": 37504, "author_name": "jc3626439", "author_url": "", "post_date": "01/17/2014 11:19:09", "content": "

Thanks Anil.  I'm afraid I have missed the subtleties of line 37 in the FuelModel.  id speculated on the reality of the ascent/descent/ascent etc path.  I have been told that in certain motor competitions to get the maximum distance for a given amount of fuel the optimum is to flatten the accelerator to get to a high speed and then to coast and then to repeat this.  The efficiency of the internal combustion engine (work done per unit of fuel) is greatest under high load.  I don't know much about the efficiency of a jet engine but it is conceivable it has this sort of characteristic.  Not sure the passengers would think much of it!

\n

 

", "votes": null, "replies": [] }, { "id": 37508, "author_name": "alzmcr", "author_url": "", "post_date": "01/17/2014 13:14:11", "content": "

[quote=Anil Thomas;37493]

\n

I was running out of things to try, so I decided to revisit this. Following the pointers from id, I added some code (highlighted below) to FuelModel.fs.

\n

 

\n

let ascentFuelBurn = max rawAscentFuelBurn cruiseFuelBurn

\n

if ascentFuelBurn = cruiseFuelBurn then 

\n

    printfn "weight %A altitude %A airspeed %A" weight altitude airSpeed

\n

(ascentFuelBurn, ascentRate)

\n

 

\n

And sure enough, running the simulator spews out messages like the ones below:

\n

weight 129295.9445 altitude 10033.14302 airspeed 522.3755016

\n

weight 131833.9212 altitude 13577.58477 airspeed 515.15

\n

weight 130342.3101 altitude 11607.57011 airspeed 519.2323575

\n

weight 130199.4593 altitude 13479.28208 airspeed 515.4957218

\n

weight 130251.1845 altitude 12287.62375 airspeed 517.8747166

\n

What does this mean? For certain combinations of weight, altitude and air speed, the aircraft can climb to higher altitudes as if gravity didn't exist. This is of course, very wrong!

\n

Our optimizers must be benefiting from this flaw, albeit unknowingly. I think a solution that systematically exploits this will do better. Maybe something to try before the buzzer goes off...

\n

[/quote]

\n

Hmm... I'm a bit lost about it.

\n

Do you have other flights with the same issue at higher altitude? all these flights are flying below 15,000ft and the lower the altitude, the higher is the fuel required to cruise. As higher than what would be required to climb further, given what you get printed.. am I wrong?

\n

I would expect this behavior to change as soon as cruising at higher altitude, then will be cheaper than climb further... or did I completely miss the point?

", "votes": null, "replies": [] }, { "id": 37550, "author_name": "jc3626439", "author_url": "", "post_date": "01/18/2014 01:13:16", "content": "

To all those interested in the peculiarities of the fuel consumption for the GE model of a typical commercial aircraft, please see the attached graph.  Fuel consumption (lbs/hr) is plotted on the y-axis and altitude (ft) on the x-axis.  Series 1, 2 and 3 are for cruising at 300, 400 and 500 knots respectively.  Series 4 is for the aircraft ascending.  The aircraft weight is 130,000 lbs.  All points on the ascent curve are for an aircraft weighing this amount.

\n

The calculation ignores line 37 in FuelModel.fs
"let ascentFuelBurn = max rawAscentFuelBurn cruiseFuelBurn"

\n

It appears that the model has a peculiarity in that, at low altitudes ( 10,000 to 12,000 ft)  the ascent fuel burn rate is less than the cruise fuel burn rate for an aircraft cruising at 500 knots.  There are probably intersection points for lower altitudes and lower speeds also.

", "votes": null, "replies": [] }, { "id": 37662, "author_name": "nicksardo", "author_url": "", "post_date": "01/21/2014 04:52:02", "content": "

A bug was brought to our attention recently by charango which occurs when the difference between the wind direction and the plane's direction is equal to a multiple of Π.  Given these circumstances, the plane's ground velocity could be double its airspeed.  We've updated our evaluation simulator and re-scored the latest leaderboard. Fortunately, this bug occurs extremely rarely.  Not a single submission showed a difference in its public or private score after applying the fix.

\n

We've released the updated simulator as v2.1.1 for your use on the final leaderboard.  The only code change is on line 28 of Movement.fs.

\n

Thank you Charango for finding this!

\n

 

", "votes": null, "replies": [] }, { "id": 37673, "author_name": "gabrieleseppi", "author_url": "", "post_date": "01/21/2014 15:40:15", "content": "

If no submission showed a difference, why bother to upload a new simulator? I mean, I guess we are not allowed to update our models to include this correction... Who assures us that this bug will not show up in the final leaderboard?

\n

P.S.
Don't you think that a modification after the final deadline deserves an email notification, at least?

", "votes": null, "replies": [] }, { "id": 37677, "author_name": "glazed", "author_url": "", "post_date": "01/21/2014 16:55:03", "content": "

I hadn't noticed this feature and it looks difficult to exploit, but if someone has managed to, I think it would be grossly unfair to change the simulator now. And isn't it in violation of the rules anyway? The fourth paragraph under section 9 says that Kaggle reserves the rights to modify the simulator code up to one week before the deadline for submitting models. It seems pretty clear-cut.

", "votes": null, "replies": [] }, { "id": 37689, "author_name": "id118392", "author_url": "", "post_date": "01/21/2014 19:04:55", "content": "

It seems that calculateGroundVelocity still has issues.

\n

Please check this: calculateGroundVelocity 100.0 PI (-1.0,-1.0e-15)

", "votes": null, "replies": [] }, { "id": 37696, "author_name": "nicksardo", "author_url": "", "post_date": "01/21/2014 23:32:24", "content": "

This was not a modeling change; it was the closing of a loophole.  Winning by exploiting this loophole would have been counter to the spirit of the competition.  In the end this bug fix made no changes to anyone's flights -- in over 30 M flights that were re-scored, no changes in score were observed.

\n

It has been our practice to address simulator bugs as they appear.  No one looking at this competition would think this bug should be part of the Simulator.

\n

The final eval leaderboard will be scored using Simulator v.2.1.1.

\n

 

\n

[quote=id;37689]

\n

It seems that calculateGroundVelocity still has issues.

\n

Please check this: calculateGroundVelocity 100.0 PI (-1.0,-1.0e-15)

\n

[/quote]

\n

Id, the simulator does not support wind vectors with coordinates approaching zero at that level of precision.  If you take a look at the provided simulator weather files, the x,y coordinates are described to the hundredths place max.

", "votes": null, "replies": [] }, { "id": 37714, "author_name": "id118392", "author_url": "", "post_date": "01/22/2014 06:31:46", "content": "

It's just an example that not all bugs were corrected. Once you've decided to fix bugs, it's worth fixing them all.

", "votes": null, "replies": [] }, { "id": 37715, "author_name": "gabrieleseppi", "author_url": "", "post_date": "01/22/2014 07:56:22", "content": "

[quote=ℕick ∈ Sardo;37696]

\n

This was not a modeling change; it was the closing of a loophole.  Winning by exploiting this loophole would have been counter to the spirit of the competition.  In the end this bug fix made no changes to anyone's flights -- in over 30 M flights that were re-scored, no changes in score were observed.

\n

It has been our practice to address simulator bugs as they appear.  No one looking at this competition would think this bug should be part of the Simulator.

\n

The final eval leaderboard will be scored using Simulator v.2.1.1.

\n

[/quote]

\n

We re-wrote the simulator in C++ for performance improvements and easier function modification and reuse. Since no one can say for sure that this "loophole" cannot be exploited in the final leaderboard dataset, we may inadvertently exploit it while computing those routes. Since we are not allowed to modify our models, not even to "close a loophole", modifying the official simulator is (not "would have been") counter the spirit of the competition.

", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "32428": "", "32430": "", "32437": "", "32449": "", "32458": "", "32462": "", "32478": "", "32491": "", "32496": "", "32499": "", "32500": "", "32501": "", "32502": "", "32503": "", "32504": "", "32505": "", "32507": "", "32510": "", "32515": "", "32516": "", "32523": "", "32528": "", "32533": "", "32535": "", "32538": "", "32540": "", "32545": "", "32547": "", "32548": "", "32550": "", "32552": "", "32554": "", "32566": "", "32573": "", "32580": "", "32602": "", "32620": "", "32647": "", "32679": "", "32718": "", "32816": "", "32819": "", "32820": "", "32879": "", "32882": "", "32888": "", "32919": "", "32959": "", "33167": "", "33423": "", "33429": "", "33523": "", "33529": "", "33532": "", "33552": "", "33560": "", "33627": "", "33632": "", "33644": "", "33664": "", "33684": "", "34818": "", "34934": "", "34951": "", "34999": "", "35076": "", "35079": "", "35083": "", "35089": "", "35094": "", "35105": "", "35106": "", "35107": "", "35108": "", "35134": "", "35135": "", "35186": "", "35973": "", "36012": "", "36376": "", "36622": "", "36623": "", "36630": "", "36635": "", "36728": "", "36734": "", "36822": "", "36825": "", "36870": "", "36924": "", "36989": "", "37004": "", "37006": "", "37007": "", "37010": "", "37011": "", "37057": "", "37062": "", "37063": "", "37152": "", "37230": "", "37493": "", "37496": "", "37498": "", "37501": "", "37502": "", "37504": "", "37508": "", "37550": "", "37662": "", "37673": "", "37677": "", "37689": "", "37696": "", "37714": "", "37715": "" }, "source": "meta" }