Open SDI8 opened 1 year ago
You can use assertAlmostEqual
if you know the number of decimal places the numbers need to match to.
There is a lot we don't have control over in this situation. The error in the mass property is likely coming from OpenCASCADE kernel and not from CadQuery.
This is to be expected, numerical calculations are not exact and hardware/platform/compiler/compiler settings dependent.
I understand that the issue is to be expected across different hardware and architectures and that we don't have much control over OpenCASCADE at this stage. However, I believe that the compiler settings can play a big role in this, too. Especially different optimization settings. So let me rephrase my question: Do we even have sufficient control over the build process in order to alter the behavior, and possibly even align the results across the platforms?
I'm not sure what you mean TBH. OCP is built with gcc/msvc/clang on, respectively, linux, win, osx. We can change some flags, but do you know a set of them that will make the results bit for bit identical?
When comparing the surface area of solids between the win-64 and linux-64 version, small differences can be observed.
The following snippet is run on the same machine on both windows 11 and Ubuntu 22. It's run in a clean conda environment using
ocp-7.7.0.0
and Python 3.10.The difference might seem insignificant in this example, but I can tell from experience that this error can get greatly amplified on more complex geometries. We have seen differences in surface area in the
1e-2
range. This issue is particularly troublesome for us, as we have a suite of unit tests and snapshot tests that only evaluate successfully on one of the platforms (windows, in our case).This issue is not recent at all. In fact, our unit tests have never worked well for this reason.