The --tolerance option doesn't work as expected (or: documentation needs to be improved)

[horeah]

I am unable to use the --tolerance option in a meaningful way, as the mapping of the specified value to the actual shape of the tube is completely opaque (to my mind at least).

Here's a capture of a tube created with --tolerance=0.05:

Can you please explain a bit more how the --tolerance works? The short mention in the help is hardly informative enough...

[beutlich]

Can you also share the CSV files and the command you used to create the above plot.

Assigning @uschna for a discussion.

[horeah]

The command is:

Compare.exe --delimiter=, --tolerance=0.05 --nometareport --override --inline "testlet_simpleIO[32-bit DLL][modify][remote][dynamic][compute].csv" "testlet_simpleIO_base.csv"

The csv files can be found in the attached zip.
__REQInputOutput.zip

[uschna]

Lieber Thomas @beutlich,
ich weiß zwar, dass die Toleranz irgendwie mit dem Maximum aus der Intervalllänge und einer Mindestgröße multipliziert wird und dies die Toleranz in die jeweilige Richtung ist. Aber leider weiß ich nicht, wie ich hier im GitHub suchen kann oder das Programm ausführen kann. Oder soll ich mir die Projektmappe runterladen und dann im Visual Studio suchen?
Da ich zu Hause arbeite, kann ich auch nicht schnell eine Person fragen.
Vielen Dank im Voraus für Deine Antwort.
Viele Grüße,
Uwe

[uschna]

If you use --tolerance=0.1 instead the light-green and light-blue curve probably starts at -0.009 = -(0.09-0)*tolerance with the value 0.008 = (0.08-0)*tolerance resp. -0.008 = -(0.08-0)*tolerance and the breakpoints are probably at (0.001=0.01-(0.09-0)*tolerance, 0.008) resp. (0.019=0.01+(0.09-0)*tolerance,, -0.008). Unfortunately I cannot check this.

[andreas-junghanns]

Guys, are you working on this? We are kind of stuck trying to get this to work.
@beutlich: Are you expecting help from us? The dynamics are a little unclear to us, please advice!

[beutlich]

@beutlich: Are you expecting help from us?

Who is us here? @andreas-junghanns Are you connected with @horeah?

Guys, are you working on this?

I am not working on it. I cannot tell for @uschna . Maybe @TorstenBlochwitz can prioritize it somehow.

Please be also aware that there is no clarified maintenance situation for csv-compare (as I already told the MA board long time ago).

[andreas-junghanns]

Yes, Horea and I (Andreas) are colleagues and working on the same internal project.

[TorstenBlochwitz]

I just asked the team leader of @uschna if he can spend some time on the problem.

[uschna]

Dear @horeah, dear @andreas-junghanns
my comment #62 (comment) has been confirmed. Specifically:
The tolerance is a relative tolerance in the direction of the respective axis. The factor is usually
(largest value - smallest value)
in the direction of the respective axis.
Is this helpful?

[horeah]

This clears it up, thank you @uschna !
Do you think it would be possible to get an "absolute tolerance" option as well? This sounds like a useful concept in many practical cases, for modeling e.g. delays...

[andreas-junghanns]

Uwe: allow me to give a bit more detail to Horea´s suggestion. Relative tolerances in y-direction make a lot of sense because the magnitude of the signal values has an influence the allowed deviation from the target values.

However, in x-direction we believe that delays follow less a relative, but more an absolute tolerance pattern. Therefore, for x-direction, we would prefer to have a simple, absolute tolerance argument.

[uschna]

Dear @horeah, dear @andreas-junghanns,
in https://github.com/modelica-tools/csv-compare/blob/master/Modelica_ResultCompare/CurveCompare/TubeSize.cs there is also the variant absolute tolerance (relativity == Relativity.Absolute in Calculate). Surely it could also be built in that different tolerances are used in x- and y-direction. However, it would have to be clarified how this should be placed on the user interface.
This is an open code. So you are welcome to implement your suggestion locally or as a pull request.
And if there are no discontinuities at fixed points in time, but e.g. due to delays of value exceedings, the changes between different executions can increase over time. Then again, a relative tolerance depending on the length of time is useful.