when you say header you mean the first line of the csv file?  if you leave that out it interprets the first line of your file as the header, and so the first leg of your first flight disappears... possibly leading to a crashed flight.  

I haven't been able to replicate this using the provided simulator. I did a complete shuffling of my routes, and got identical results (twice).

That's exactly what I thought in the first place, but according to the submission page this should not be a problem and, indeed, it doesn't happen with all the files I produce.

To be honest, that's the kind of behavior I see most of the time, but not always. That's why I'm worried, I can't find a plausible reason for this behavior.

when i run the simulator locally on the one day (July 4th) files and do vs. do not put in the header line in the submitted flight legs .csv file (onedaysamplesubmission), the simulator seems to clearly skip the first line of my submission file when i don't include the header and i (in that case) lost a flight.

when i made the fix and submitted to the leaderboard with header i fixed a couple of other things too, i got a better score but i can't be sure the leaderboard has the same issue.

it would make sense, though, relative to your other issues - if you left out the header and ran flights with order shuffled such that the first line was different each run, it would drop a different flight leg each time and possibly lead to somewhat different scores.

on the submission instructions it seems to indicate a header with column names is needed - did you see elsewhere that it isn't?

Maybe I'm making confusion with flight quest 1, I don't know.

Anyway, I'll try to always add the header just to be sure everything is in order. Thank you for your help =)

Ragingphilip correctly states that the first waypoint of your first flight will be skipped, thereby affecting your cost.

Rounding error while summing the costs is plausible; the final score could change depending on the order of the flight costs (... the flights themselves).  Unless we see an extremely tight race near the end of the competition, this is not worth looking at any further.

The leaderboard score is the weighted average of the daily scores.  

Waiting for the new data release I am going through the simulator-code atm, (which I should have done earlier, since I see plenty of useless stuff I coded like different cruising speeds and heights depending on which airplane type it is).

Anyway, in Movement.fs are you sure that the angles in:

let calculateGroundVelocity are right?

More in detail, I think there is an error in defining g, assuming that Groundspeed in the next line is computed via the sine-formula. From just drawing the triangle:

1)the angle oppsed to airspeed is (PI - aDirection) and sin(PI - aDirection)==sin(aDirection).

2)the angle opposed to the grounddirection is gMine= aDirection-w.

So the sine formula gives

GroundSpeed/sin(aDirection-w)=airspeed/sin(PI-aDirection)

Rearranging and using sin(PI-th)=sin(th) twice:

Groundspeed=airSpeed* sin (PI-aDirection + w)/sin(aDirection)

So if my triangle is not wrong, then g in the code should be:

g = System.Math.PI - aDirection + w    and not:

g = System.Math.PI - aDirection - w

The unit test cases that this function passes are as follows:

module SpatialTests

open FlightQuest.Units
open FlightQuest.Movement

open Testing
open NUnit.Framework
open FsUnit

[]
type SpatialTests() =
    let Precision = 0.0001

    []
    member test.``Calculated Ground Speed``() =
        let checkCalculatedSpeed (airspeed, windX:float, windY:float, groundDirection:float, expededGroundSpeed:float) =
            let gSpeed = calculateGroundVelocity (airspeed*1.0) groundDirection (windX * 1.0, windY * 1.0)
            gSpeed |> should (equalWithin 1.0) expededGroundSpeed

        let entries =
            [(500.0,0.0,300.0,0.0,400.0);
            (500.0,100.0,0.0,0.0,600.0);
            (500.0,0.0,0.0,0.0,500.0);
            (500.00,300.0,0.0,1.570796327,400.0);
            (0.0,0.0,0.0,0.0,0.0);
            (400.0,-100.0,0.0,0.0,300.0);
            (230.0,100.0,0.0,-0.6681002,300.0);
            (255.3256439,87.75825619,47.94255386,-0.093823323,332.0);
            (455.0,-85.33,-135.32,0.0,349.0816684);
            (433.0,0.0,0.0,1.3321,433.0);
            ]
        List.iter checkCalculatedSpeed entries

The change you proposed causes the (230.0, 100.0, 0.0, -0.6681002, 300.0) test to fail (and possibly subsequent ones as well). If you still believe there's an error in the math, could you make a case for the failing unit test(s) being erroneous as well and possibly propose new unit tests?

Ok, I found where I was wrong: I assumed that the directions are wrt to the north while actually the atan2 function in spatial.fs:

let calculateRadians (v:Vector) =     System.Math.Atan2(float(snd v), float(fst v))

returns the angle from the x-axis.

E.g.: (u,v)=(100,0) corresponds to a windir=0, while I assumed it would be +90deg

Re-drawing my triangle with this in mind, I completely agree with the formula (and your test anyway showed it to be right:-)).

Sorry, for this misunderstanding.