ledinot
commented
7 years ago Question 1 Yes, the tables of the first stage are tessellations of the flight domain (finite volume mesh), so the nodes have coordinates that are sorted in increasing order: the higher the three indexes of a vertex, the higher its corresponding (Speed, Altitude, Mass) values (ordering property true on each axis individually).
Question 2 For sure it is an algorithm design issue, is it a system level specification issue (i.e function concern)? They are two ways of playing the SYS<->SW game:
- option 1: YES it is. Argument: the system function specification is detailed, not pseudo-code like but not so far from that, so this limit case should have been addressed in the specification (I had it in mind indeed).
- option 2: NO it’s not. Argument: admittedly the specification is detailed, even formal everywhere needed, but it also tries to leave as open as possible all the implementation choices. This limit case induces a difficulty for uniform design of the algorithm, but the intent of what has to be done does not change: take all the relevant neighbors, even in the limit cases where they are fewer, and adapt appropriately to these cases.
The specification does not say either what happens if the state vector goes out of the mesh … (anticipated too :-)). Example: inappropriate data was loaded in the computer, for instance the max speed in the PDI is smaller than speed of the drone after an extreme blast of wind. This case was intentionally left unspecified.
Both are robustness issues, and may trigger the so called “derived requirements” case (ACCEPTABILITY OP).
So my answer to question 2 is “no answer” (option 2) :-). Up to you and to your assessment of what is at stake here. De : Anthony Leonardo Gracio [mailto:notifications@github.com] Envoyé : lundi 24 juillet 2017 17:07 À : AdaCore/RESSAC_Use_Case Cc : Subscribed Objet : [Message publicitaire : ] [AdaCore/RESSAC_Use_Case] F_MM: computation of nearest neighbours (#31)
In 6.6.4 (Mission Viability Logic), it's said that we should compute the nearest neighbours of the current mission profile in the appropriated tabulated function.
My hypothesis is that the table is in increasing order in its three dimensions: can you confirm this?
Another question: should we return the same number of neighbours every time, even when some of the indexes we have found are located in a boundary (e.g: when the mission profile's distance is lower than the first cell in the table)?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/AdaCore/RESSAC_Use_Case/issues/31, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVVweJwf2tnI0WjTAalwx1WYk_gsWXtCks5sRLMCgaJpZM4OhUZ4.
AnthonyLeonardoGracio
In 6.6.4 (Mission Viability Logic), it's said that we should compute the nearest neighbours of the current mission profile in the appropriated tabulated function.
My hypothesis is that the table is in increasing order in its three dimensions: can you confirm this?
Another question: should we return the same number of neighbours every time, even when some of the indexes we have found are located in a boundary (e.g: when the mission profile's distance is lower than the first cell in the table)?