[Bug]: cannot analyse with hole-in-one kick data that is not from an ACD (i.e. when driven tunes = natural tunes)

[sashaj5454]

Bug Description

When running hole-in-one from the betabeat GUI, the input of having the same driven and natural tunes produces an error because of the check that the natural tunes and driven tunes are not too close to each other.

Steps to Reproduce

Run hole-in-one with the betabeat GUI where natural tunes = driven tunes.

Possible Fix Implementation

Perhaps have it have an exception for when natural tunes = driven tunes to allow for this type of analysis.

Operating System

No response

Python Version

No response

Package Version

No response

Relevant output

[JoschD]

I think this is probably a GUI issue.
The implementation in omc3 is such, that you either give two sets of tunes or one set of tunes.
The GUI always gives two sets of tunes, unless you specify "free kick" - which in turn activates some compenstation for the exponential decay (which you do not necessarily always want). So I guess the workaround was to give the same free and kicked tunes? I think you can set the tunes that you don't want in the GUI to 0.0 (if I remember correctly, @jgray-19 left 0.0 and None as "no tunes given". to be confirmed (or checked in the code).

[jgray-19]

I think this is probably a GUI issue.
The implementation in omc3 is such, that you either give two sets of tunes or one set of tunes.
The GUI always gives two sets of tunes, unless you specify "free kick" - which in turn activates some compenstation for the exponential decay (which you do not necessarily always want). So I guess the workaround was to give the same free and kicked tunes? I think you can set the tunes that you don't want in the GUI to 0.0 (if I remember correctly, @jgray-19 left 0.0 and None as "no tunes given". to be confirmed (or checked in the code).

So I had a look at it, it's because the gui gives tunes and natdeltas and if you give natdeltas of 0 then this causes the error I think.