Parameters not saved in Analysis classes

[PicoCentauri]

In all analysis classes the parameters start, stop, step and verbose are not saved if they are changed after the object was run once.

After looking into the code I found that for the start, stop and step parameters this is an issue due to the fix of the old deprecated syntax. For the verbose one just have to save this in the _verbose attribute of the object. All these things are easy to fix and I could provide a patch.

Code to reproduce the behavior

from MDAnalysis.analysis.lineardensity import LinearDensity
from MDAnalysis.tests.datafiles import PSF_TRICLINIC, DCD_TRICLINIC

u = mda.Universe(PSF_TRICLINIC, DCD_TRICLINIC)
ldens = LinearDensity(u.atoms, verbose=True)

ldens.run(start=0, stop=10)
print(ldens.start, ldens.stop)

ldens.run(start=0, stop=5, verbose=False)
print(ldens.start, ldens.stop)

Currently version of MDAnalysis

Python 3.6, mda 0.19.3, MacOS

[richardjgowers]

Yeah we used to save them on __init__ and use this during run(). We could save the last used values in run() I guess.

[PicoCentauri]

Yes. I would just add a simple test in _setup_frames. See PR #2207.

[orbeckst]

I don't think we should save them. That's a left over when we set them in init. When providing parameters to run I would expect that they only apply to this invocation.

[PicoCentauri]

On the one hand I could imagine that sometimes its useful to access this information i.e. at what frame the analysis started. On the other the user already put the information in so maybe its superfluous.

[zemanj]

@orbeckst

I don't think we should save them. That's a left over when we set them in init. When providing parameters to run I would expect that they only apply to this invocation.

I agree. Since the start/stop/step parameters are not passed to the initializer, they shouldn't be reused. The run() method should always work as documented, including its kwarg defaults. Permanently storing and reusing the parameters would invalidate the documented signature.

@PicoCentauri

On the other the user already put the information in so maybe its superfluous.

IMHO it is.

[PicoCentauri]

@zemanj I'm also fine with not storing them if this consistent with what is in the documentation. The total number of analysed frames is saved in any case. But this means to drop the old code completly, right?

[orbeckst]

Yes, any old code that stores this information should go away. The whole verbose thing is/was deprecated, I think. Not sure when it ought to get officially removed.

EDIT: 2020-02-05: verbose in constructor and run() conforms to the new API as required by #1463

[PicoCentauri]

I see. I quickly checked the usage of verbose and it seems that it is not used anymore by the modules. We could also kick this out...

[richardjgowers]

@PicoCentauri I think verbose is deprecated, it just needs finally removing (eventually). It's frustrating, but the idea is that old scripts (which use verbose) shouldn't break overnight because people have updated. I think we're planning on ripping out most of the tagged deprecations for the 1.0 release.

WRT start/stop/step, these parameters should be saved in the .results attribute, but it's not the base class' job to do this. Ie an individual implementation should be labelling frames when it's appropriate.

[orbeckst]

WRT start/stop/step, these parameters should be saved in the .results attribute

Under which circumstances is it useful to safe start/stop/step? I don't think that there's an expectation that run() knows how to reproduce the last run?

As long as the result contains e.g. the times or the frame numbers for a time series calculation, this should be fine. Or am I missing something?

[richardjgowers]

@orbeckst I run some analysis on frames 1-10, pickle the Analysis class object (containing the results), unpickle it a month later and don't know what frames it was ran on? Or more generally, it'd be nice if the object had full provenance of the results?

[orbeckst]

I don't like pickling analysis class objects as a form of data storage – that's just abuse of the pickle format. I wouldn't want to encourage this approach.

For timeseries it is eas(ier) to see what data you used. For anything that averages or does statistics this is harder and their I can see a valid reason for storing a metadata dict with, e.g., number of frames analyzed etc. because you would need to report this in a paper. But then this can be up to the individual class to do it.

Thinking about it, you summarized it succinctly

WRT start/stop/step, these parameters should be saved in the .results attribute, but it's not the base class' job to do this. Ie an individual implementation should be labelling frames when it's appropriate.

[richardjgowers]

Ok, then I think this issue is solved by recommending in the AnalysisBase docs that frame indices are stored for reproducibility.

[PicoCentauri]

Okay I’m fine with storing the information in the results attribute. Unfortunately, only changing the docs this will not resolve the issue I think. We still have to change the code in such a way that only the current parameters of the .run method are used. I also don’t see an „easy“ and clear way for an individual class to get acces to the information for saving start/stop/step in the results section if its not stored in object itself...