Altitude and speed bounds throw errors on default behavior with cor_v2p1

[reliable-nranganathan]

Description

When running sample2track.m with a RADES correlated model (ex. cor_v2p1.txt), getters for altitude and speed bounds don't work properly. For altitude, getting min_speed and max_alt in lines 104-105 of sample2.track.m throws an exception because min/max alt bounds do not exist in cor_v2p1.txt at boundary index 2, the index of variable L. For speed, the default label (set in line 28) is 'v', which is not a valid label in the correlated model because there are only 'v_1','v_2'.

Reproducibility

[isGood, ~] = sample2track(parameters_filename, initial_output_filename, transition_output_filename, ... 'out_dir_parent', out_dir_parent) with valid inputs, and parameters_filename = 'cor_v2p1.txt'`, should reproduce both issues.

Expectation

I resolved this issue by simply adding altitude bounds back into cor_v2p1.txt consistent with the model report. For the speed bounds, I explicitly passed in 'label_initial_speed', 'v_1' into the function call, but I think this should be fixed in such a way that the function does not break on default functionality (i.e. either this should be a required argument or it should know to use 'v' or 'v_1' depending on the model).

Environment

Debian 10, MATLAB R2021a

[reliable-nranganathan]

In retrospect I didn't see that the correlated models have not been tested with sample2track before writing this - I'll avoid using it in this context until that changes.

[aweinert-MIT]

Potential resolution

sample2track currently looks for the indices for the variables in the conventional aircraft uncorrelated encounter models of G, A, L, v, v dot, h dot, and psi dot. This bug occurs because the RADES-based correlated model has other variables, such as the speeds of the first aircraft, v_1, and the other aircraft, v_2. Parsing these variables will not be sufficient to resolve the bug because the kinematic equations starting at the current line 182 assume one aircraft, not two; and initializes the aircraft at the (0,0) origin in a local Cartesian coordinate system. The correlated model initializes aircraft based on locations at CPA, thus both aircraft can not initialize at the origin.

Simulating the aircraft kinematics will likely be the bulk of the work to resolve this bug. Ideally, the resolution would leverage the run_dynamics_fast MEX function like the UncorEncounterModel class instead of native MATLAB inline equations.

Issue Reporting

sample2track was designed for the uncorrelated encounter model. The function should throw a warning when using the RADES-based correlated model that the correlated model wasn't tested for this model:

warning('sample2track:model', '%s has not been tested with these function, assigning default units\n', pfn{end});

So this bug is undesirable but also not totally surprising. The roadmap has a task to investigate prototyping a MATLAB class for the RADES-based correlated en route model. Completing that task should prevent issues like issue #45 in the future. Reporting this bug is good to help the roadmap task and we appreciate the report.

[reliable-nranganathan]

That make sense - I will continue using our old workflow for the correlated model until that point in the roadmap is reached. Feel free to mark as resolved, unless you think there is value in keeping it open.

[aweinert-MIT]

It is a known valid issue and I'm going to keep it open until we resolve it.