Turning off `store_state` in mesolve

Describe the issue In mesolve, all the intermediate result for each t in the tlist will be saved. If the given tlist is very long, this can be a bottleneck for time and memory. In the Option class, there is an option store_states, but it does not work as I expected. Setting it to False does not turn this off.

https://github.com/qutip/qutip/blob/7a73b136cb74f832cf19f15e93c7268244674bdb/qutip/mesolve.py#L461-L463

According to the code above, there is no way to completely turn this off. One has to either save expectation values or save the intermediate states.

To Reproduce

from qutip import *
import numpy as np

options = Options()
options.store_states = False
print(options.store_states)
result = mesolve(sigmax(), basis(2,0), np.linspace(0,1,10), options=options)
print(options.store_states)

gives

False
True

@Ericgig @jakelishman

[Ericgig]

When no options and no e_ops are given, the solver should store the states, otherwise nothing is done. Since the default value si store_states=False, the solver don’t know that the value was explicitly given or the default. We should have store_states=None as the default. This allow us to respect an explicit False while keeping the expected behaviour when no options are given. I will make this change in the v5 solver (And make sure no Options are modified).

tlist was never meant to control time dependence, it represent the time at which the solver look at the state (+ first and last times). I added array support as coefficient as a shortcut to Cubic_Spline and I used the already existing tlist, but this is clearly a limitation and in v5 they will be controlled independently.

[jakelishman]

Ok, cool. I don’t think there’s any situation we should be mutating the Options class we’re passed in though - I’d consider that a bug no matter what, since that leaks like your print statement shows. We can just duplicate it on entry, then modify that.

To me it’s not clear that passing several items in tlist should override an explicit store_states=False - as long as we allow you to pass an array as time-dependence, there is a sensible reason to pass more items in tlist than you need results for. Sure, you may also be able to use Cubic_Spline, but if we punish you for using arrays by swapping your options, why do we provide them? I think we should only warn and change the settings if nothing is going to be stored - store_final_state should be enough to suppress it and not store the intermediate states, even if that implies the user might not be doing the fastest possible thing. I don’t necessarily think we should try to promote ideal usage through runtime warnings if that’s more verbose to type - that’s what documentation is for, and some people will do stuff because it’s faster to type, since they work interactively.