Investigate: Cartesian state vector + covariance triggers hypercube batch run

[carise]

Not sure if this is the intended behavior.

If Cartesian state vector + covariance are provided to the OpmParams (e.g. in single_run_demo notebook), it submits a hypercube batch run. However, if hypercube parameters are not specified, the job status will report as "COMPLETE" but the final state will be "FAILED".

Example input for the job (from single_run_demo):

# 6x1 state vector (position [km], velocity [km/s])
state_vec = [130347560.13690618,
             -74407287.6018632,
             -35247598.541470632,
             23.935241263310683,
             27.146279819258538,
             10.346605942591514]

# Lower triangular covariance matrix (21 elements in a list)
covariance = [3.331349476038534e-04, + \
              4.618927349220216e-04, 6.782421679971363e-04, + \
             -3.070007847730449e-04, -4.221234189514228e-04, 3.231931992380369e-04, + \
             -3.349365033922630e-07, -4.686084221046758e-07, 2.484949578400095e-07, 4.296022805587290e-10, + \
             -2.211832501084875e-07, -2.864186892102733e-07, 1.798098699846038e-07, 2.608899201686016e-10, 1.767514756338532e-10, + \
             -3.041346050686871e-07, -4.989496988610662e-07, 3.540310904497689e-07, 1.869263192954590e-10, 1.008862586240695e-10, 6.224444338635500e-10]

propagation_params = PropagationParams({
    'start_time': '2017-10-04T00:00:00Z',   # propagation start time in ISO format
    'end_time': '2017-10-11T00:00:00Z',     # propagation end time in ISO format

    'project_uuid': config['workspace'],

#     'step_size': 60 * 60,                   # step size (seconds)
#     'propagator_uuid': '00000000-0000-0000-0000-000000000002',  # force model
#     'description': 'some description'       # description of run
})

opm_params = OpmParams({
    'epoch': '2017-10-04T00:00:00Z',
    'state_vector': state_vec,
    'covariance': covariance,

#     'mass': 500.5,              # object mass
#     'solar_rad_area': 25.2,     # object solar radiation area (m^2)
#     'solar_rad_coeff': 1.2,     # object solar radiation coefficient
#     'drag_area': 33.3,          # object drag area (m^2)
#     'drag_coeff': 2.5,          # object drag coefficient

#     'covariance': covariance,   # object covariance
#     'perturbation': 3,          # sigma perturbation on state vector
#     'hypercube': 'FACES',       # hypercube propagation type
})

And screenshot of the output

I vaguely recall that plain batch runs don't bother with covariance and it's just hypercube/Monte Carlo where we used it, which is probably why the hypercube gets triggered. It's a bit confusing though, so we should do some validation to check that if covariance is specified, then some kind of perturbation should also be specified.

[HankG]

Interestingly the HyperCubeGenerator I'm working with right now checks that the type field called "HYPERCUBE" and that a sigma field called "INITIAL_PERTURBATION" are set to determine if it is an OPM containing hypercube information. The python code could check those conditions and return an error before submitting or the REST endpoint could check those and return an error type with that information (may be better so not duplicating checks on both sides perhaps).

I'm going to beef up the unit tests around HyperCubeGenerator to include the various permutations FYI.