Add explicit warnings for zero-identity comparison runs

[widdowquinn]

Summary:

Several issues have been raised (#93 #72 #73 etc.) where the main issue is that a comparison has given a zero identity, and errors have been thrown downstream. Throwing a specific error might be one way to alert users that the problem is in the dataset, not the analysis code.

[baileythegreen]

Where is the best place for such an error to be thrown so that it is helpful for the user? Looking at the Issues you cite, both anim.py and graphics.py seem like possibilities.

[widdowquinn]

I might think of doing it when parsing the input file. We have options here, I think. Do we, for instance:

• log a WARNING and continue, treating the input as zero identity and substituting in dummy values
• log an ERROR, raise an exception and halt, forcing the user to attend to or remove one or other input file
• log an INFO message and continue, treating the input as zero identity and substituting in dummy values

If we're not halting, then we could warn on file parsing and/or when comparisons are complete, so that the individual comparison is flagged and the total influence on the comparisons is noted (e.g. "6/n comparisons had zero identity values, please check that the input for [list of files] is what you expect)

I think it might be helpful to report the associated comparison commands so that the user can investigate more easily.

Maybe we need a new log table in the database to associate messages like this with the originating run?

[baileythegreen]

I think adding logs to the database is a really good idea; it is a good way of keeping them associated with a particular run without needing to keep a bunch of log files (if one chooses not to).

My only concern would be with the choice of what to store; storing everything for a run may be a lot and there may be a point at which it is too much to be very useful. (Like how I feel about the pytest logging output.)

[widdowquinn]

It will be a case of trying things out to see if they're proportionate, I think.

We certainly need the versions of tools, the command-line used, date and time - all the things you'd want for reproducibility/reporting in a publication.

For other logs a natural choice would be: anything that could be an error and might have affected the outputs/results, which I think would include the "zero identity" case above.

I'm running out after that. I expect more candidates will present themselves.