How to treat residuals in Rainflow counting

[johannes-mueller]

As of now, pyLife's rainflow counting modules do not integrate the residuals into the final rainflow matrix. This can lead to confusion as for example in #21.

One idea is to introduce a method AbstractDetector.close_residuals() that adds load points to the collective that make sure that all the residuals are closed. It is debatable however, if that makes sense from a damage calculation point of view.

This thread is to discuss possible ways to deal with the residuals of a load collective. So please don't hesitate to share your thoughts.

[maierbn]

I want to suggest to add a flush parameter to the detector's process method to control if residuals are processed or not.

If flush=False, the last value of a load sequence is
cached for a subsequent call to process, because it may or may
not be a turning point of the sequence, which is only decided
when the next data point arrives. This is the current standard behavior.
The residual can then be retrieved by detector.residuals.

Setting flush=True forces processing of the last value.
No remainder residuals are left unprocessed and all loads
are reflected in the rainflow matrix.

When process is called again afterwards with new data,
two increasing or decreasing values in a row might have been
processed, as opposed to only turning points of the sequence.

The flush parameter is optional and set to False by default.

Examples:

        a) old behavior:
            process([1, 2])   # processes 1
            process([3, 1])   # processes 3
            -> processed sequence is [1,3], end ("1") is missing

        b)
            process([1, 2], flush=False)  # processes 1
            process([3, 1], flush=True)   # processes 3, 1
            -> processed sequence is [1,3,1], only turning points
        
        c)
            process([1, 2], flush=True)   # processes 1, 2
            process([3, 1], flush=True)   # processes 3, 1
            -> processed sequence is [1,2,3,1], "2" is not a turning point