[RomApp] Fix Bug in ECM

[Rbravo555]

📝 Description
This PR is intended to fix two problems in the ECM algorithm:

1. The extra constraint that until now was always enforced that the sum of the HROM weights was equal to the number of elements, sometimes ill-conditions the problem. We are now adding a flag, for the user to set this constraint to false if required. The default is still for it to be true, although we can discuss it further
2. There was a recently introduced bug consisting in, whenever the number of iterations was larger that some hard-coded large value (1000), the ECM tried to "enlarge" the candidate set. We intended this for the case of weakly enforcing the ECM to contain some initial candidate set, and then enlarge if convergence was impossible. For ill-conditioned problems like the ones arising from the prior point, many iterations occurred and when the ECM tried to enlarge the candidates, the so-called complement_set did not exist. The fix is as simple as enlarging only if the complement exists.

🆕 Changelog

• In ECM enlarge candidates with complement only if complement exists
• Add flag to control whether the "sum_of_elements" constraint should be enforce for the ECM. This affects:
  • RomManager
  • HromTrainingUtility

[RiccardoRossi]

just a question: not enforcing that constraint implies giving back with the capability of exactly integrating the areas, is that correct?

[Rbravo555]

just a question: not enforcing that constraint implies giving back with the capability of exactly integrating the areas, is that correct?

The intention of the constraint is to avoid the trivial solution of all weights equal to zero. A by-product of the contraint is that the sum of the weights equal the number of elements. If the contraint is not enforced, the sum of the weights can be whatever value the greedy algorithm comes up with, which can be very large or very small according to the specific problem. Imposing this condition should not have a negative effect besides requiring a single element extra, with respect to not imposing it. However, in practice we are observing that enforcing this constraint sometimes prevents the algorithm from converging. We are looking into the reasons why this is happening. In the meantime, this PR provides an easy fix by allowing the user to choose not to impose the constraint if convergence is difficult for the specific case.

[SADPR]

Can you please take a look why this is not passing the CI?
CI / ubuntu-intel-legacy (pull_request)

[SADPR]

Why is the tolerance here set to 0 by default?
I mean, do you think it will most likely need to use all elements/conditions to converge?

[SADPR]

Everything else LGTM.

[Rbravo555]

Could we approve this then?

[RiccardoRossi]

no objection on my side.

[SADPR]

LGTM