Basic integrator class has no protections for out-of-bounds indexing

[excaliburtb]

Trick::Integrator just loads how ever many states the user tries to input regardless of how many are allocated/available. This could be handled two ways.. allocate more as needed, or warn/error the user if exceeded.

[keithvetter]

The best would be if the user didn't have to count the states at all. It's error prone to have this in the input file:

num_step = 12
num_vars = 128

a.b.state = trick.alloc_type(num_vars, "double")
a.b.deriv = trick.alloc_type(num_step, "double")
a.b.state_ws = trick.alloc_type(num_step, "double")
a.b.stored_data = trick.alloc_type(8, "double")

for i in range(0, num_step):
    a.b.deriv[i] = trick.alloc_type(num_vars, "double")
    a.b.state_ws[i] = trick.alloc_type(num_vars, "double")
    

[excaliburtb]

agreed though I haven't had to allocate the individual params since trick 10. specific integrator type should have the num_step value and the user should provide the num_vars either via the getIntegrator call or if you can the constructor yourself.

[sharmeye]

Ok, so if you underload or overload the integrator states, how would y'all like it to be handled? What severity is this crime? Immediate termination, or gentle reminder to count correctly?

[excaliburtb]

i don't personally care too much about underloading just because it doesn't change the results. for overloading, i'd say a one-time non-fatal ERROR print should suffice. then it should just refuse to load any more states. that should be sufficient for letting the user know that something is wrong.

alternatively, we can re-size the underlying states arrays so that it does fit.