You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several Omnsicape users are running into issues with AssertionErrors:
AssertionError:norm(G * v .- curr) /norm(curr) <1.0e-6
I'm wondering if we can either increase the error tolerance here, make it relative instead of absolute, or add an option to allow failure of this check. My understanding is that the tolerance of 1e-6 was chosen somewhat arbitrarily? When running 100s or 1000s of moving windows, there is more likely to be an edge case where this check fails. If I could tell Circuitscape to allow this check to fail and instead log a warning about potential innacuracies (and maybe their magnitude relative to current density predictions?) around that one moving window, I think that would alleviate a big headache for many Omniscape users. Alternatively, if we can make this tolerance larger, or allow it to be relative, we may end up seeing this issue pop up a lot less, while still enforcing some degree of accuracy in the solutions.
Okay great. I can look into this this weekend. Any tips on how to adjust the tolerance based on the matrix norm? Happy to just put in a PR if this is straightforward enough.
Several Omnsicape users are running into issues with AssertionErrors:
I'm wondering if we can either increase the error tolerance here, make it relative instead of absolute, or add an option to allow failure of this check. My understanding is that the tolerance of 1e-6 was chosen somewhat arbitrarily? When running 100s or 1000s of moving windows, there is more likely to be an edge case where this check fails. If I could tell Circuitscape to allow this check to fail and instead log a warning about potential innacuracies (and maybe their magnitude relative to current density predictions?) around that one moving window, I think that would alleviate a big headache for many Omniscape users. Alternatively, if we can make this tolerance larger, or allow it to be relative, we may end up seeing this issue pop up a lot less, while still enforcing some degree of accuracy in the solutions.
cc @ranjanan @ViralBShah
The text was updated successfully, but these errors were encountered: