Our continuous testing (CI) is currently failing quite heavily, primarily because the fuzzer encounters edge-case parameter configurations where no genuine bound states exist, causing the simulation to throw an error.
There are some tensions in our development. We purposely want to keep our parameter ranges wide open right now while we explore and determine what is pedagogically relevant. However, this inevitably leads the fuzzer into scenarios with zero possible bound states. Because the majority of our recent CI failures are just these expected failures to find bound states, we have fallen into the dangerous habit of ignoring CI alerts entirely. If a genuine, unrelated regression or bug is introduced, it will be completely buried and missed. While addressing #55 , I end up generating more CI failures instead of less, so CI seems more in the way than helpful.
We need to find a balanced compromise. For now, we should gracefully handle or temporarily suppress the BoundStateResult has no energies errors in CI. This will instantly clean up our test dashboard so we can catch other critical, unrelated failures that actually require immediate attention. Once we narrow down our "pedagogically relevant range," we do want to ensure that failing to find a bound state within that valid range triggers an error. We shouldn't mask a legitimate calculation failure when the parameters dictate a state should exist.
Our continuous testing (CI) is currently failing quite heavily, primarily because the fuzzer encounters edge-case parameter configurations where no genuine bound states exist, causing the simulation to throw an error.
There are some tensions in our development. We purposely want to keep our parameter ranges wide open right now while we explore and determine what is pedagogically relevant. However, this inevitably leads the fuzzer into scenarios with zero possible bound states. Because the majority of our recent CI failures are just these expected failures to find bound states, we have fallen into the dangerous habit of ignoring CI alerts entirely. If a genuine, unrelated regression or bug is introduced, it will be completely buried and missed. While addressing #55 , I end up generating more CI failures instead of less, so CI seems more in the way than helpful.
We need to find a balanced compromise. For now, we should gracefully handle or temporarily suppress the
BoundStateResult has no energieserrors in CI. This will instantly clean up our test dashboard so we can catch other critical, unrelated failures that actually require immediate attention. Once we narrow down our "pedagogically relevant range," we do want to ensure that failing to find a bound state within that valid range triggers an error. We shouldn't mask a legitimate calculation failure when the parameters dictate a state should exist.