Release 1.3.0

[rkm]

Changelog is here!

[thobson88]

I just tried a clean install (on OSX) and the script failed to create the virtual env due to the specific python version on this line.

Replacing python3.6 with python3 fixes the problem for me and should still work on Ubuntu.

[rkm]

Yes, that appears to be an oversight in the setup script - have fixed now.

[rkm]

@thobson88 I've also fixed the upper bound on the SEED endpoint and added a test for it

[thobson88]

I'm seeing a possible bug in the "set altitude" endpoint. I couldn't easily reproduce in a Bluebird test case so I'll just describe it here. The steps are:

1. Create an aircraft at FL250.

POST /api/v1/cre
{
  "acid": "TEST",
  "type": "B744",
  "lat": "0",
  "lon": "0",
  "hdg": "0",
  "alt": "FL250",
  "spd": "200"
} 

2. Check its position.

GET /api/v1/pos?acid=TEST

Response shows the altitude is 7620 metres (i.e. 25000 feet). Fine.

3. Request to ascend to FL450.

POST /api/v1/alt
{
  "acid": "TEST",
  "alt": "FL450"
}  

Returns 200 OK and "Command accepted"

4. Check its position again.

GET /api/v1/pos?acid=TEST

Response shows the altitude is less than 7620 metres and vs (vertical speed) is negative, i.e. descending.

This is one of my integration tests in rdodo, which used to pass, so I reckon this bug was introduced recently. @rkm Could you take a look please?

By the way, I see the same bug when working in feet as opposed to flight levels.

[rkm]

Good catch! This was caused by an incorrect type check that I added for the "cleared flight level" code. Fixed now, and has a test.

[radka-j]

Tested SIMMODE, STEP and GET method on the ALT endpoint and all work as expected :)

[thobson88]

I tested the LOADLOG endpoint:

• works fine when a valid value for the time parameter is submitted.
• when time is set too large (i.e. later than the time that episode finished) I get a 500 error code and the message: Could not step simulations: Error: Could not step. step_flag=False sim_t=1. It's possible to recover from this by repeating the call with a valid time.
• when a negative time is submitted it's correctly caught, but setting to 0 or 1 (usually) gives the same 500 error as above, but this time it's worse. BlueSky crashes (stack trace below) and needs a restart. Subsequent calls to LOADLOG give a 500 error with "Could not start scenario after upload".

Traceback (most recent call last):
  File "BlueSky.py", line 119, in <module>
    main()
  File "BlueSky.py", line 89, in main
    bs.sim.start()
  File "/Users/thobson/Documents/development/src/github/alan-turing-institute/bluesky/bluesky/network/node.py", line 48, in start
    self.run()
  File "/Users/thobson/Documents/development/src/github/alan-turing-institute/bluesky/bluesky/network/node.py", line 77, in run
    self.step()
  File "/Users/thobson/Documents/development/src/github/alan-turing-institute/bluesky/bluesky/simulation/qtgl/simulation.py", line 104, in step
    stack.process()
  File "/Users/thobson/Documents/development/src/github/alan-turing-institute/bluesky/bluesky/stack/stack.py", line 1407, in process
    results = function(*parser.arglist)  # * = unpack list to call arguments
  File "/Users/thobson/Documents/development/src/github/alan-turing-institute/bluesky/bluesky/simulation/qtgl/simulation.py", line 172, in setDtMultiplier
    self.sysdt = self.simdt / self.dtmult
ZeroDivisionError: float division by zero

• As already discussed, repeatedly calling LOADLOG with the same log file produces slightly different states. This appears to be unavoidable (in BlueSky at least) but it would be nice if we could quantify the effect. I'll put this in an issue as a documentation enhancement (for a later release).

[thobson88]

Looking at the metrics code, it looks like they're implemented independently for vertical and horizontal separation (possibly because of my incomplete initial comment at https://github.com/alan-turing-institute/nats/issues/73). As @radka-j pointed out, we need to combine the two, otherwise there's a penalty for, say, any two aircraft at the same altitude, regardless of how far apart they are horizontally.

I've updated the above ticket so we can discuss it there.

Also, to make testing easier, I'd suggest refactoring slightly to have a metric function that depends on the absolute horizontal & vertical distances, and then a wrapper function that takes the aircraft IDs.

[rkm]

This is on hold until #70 is completed

[rkm]

@thobson88

Also, to make testing easier, I'd suggest refactoring slightly to have a metric function that depends on the absolute horizontal & vertical distances, and then a wrapper function that takes the aircraft IDs.

That's a useful point - I'll update the tests accordingly

[thobson88]

@radka-j Minor point, but I noticed the aircraft_separation function in bluebird/metrics/bluebird/metrics.py could be simplified to just return max(horizontal_sep, vertical_sep), without the preceding if statements.

This would give the metric a nice generic form: given m_h and m_v functions, depending on horizontal & vertical (absolute) separation, the metric is:

m(d_h, d_v) = max{ m_h(d_h), m_v(d_v) }

[radka-j]

@thobson88 I literally just updated it to that a minute ago, well spotted :)

[radka-j]

I seem to have the same problem TH reported earlier with POST to the ALT endpoint.

I have an aircraft at FL250, request it goes to FL450 and the aircraft starts descending.

[rkm]

@radka-j I'll take a look at that and add an integration test to ensure it doesn't resurface later. Could you send me the logfile for that, if you can find it? Thanks.

[thobson88]

In experimenting with aircraft type vs cruise speed I think I found a bug in the way the POS endpoint reports ground speed. I doubt this was introduced in this version so I've opened a separate ticket: #71.