Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)

Post here for help on using FreeCAD's graphical user interface (GUI).
Forum rules
and Helpful information
IMPORTANT: Please click here and read this first, before asking for help

Also, be nice to others! Read the FreeCAD code of conduct!
TheMarkster
Veteran
Posts: 5505
Joined: Thu Apr 05, 2018 1:53 am

Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)

Post by TheMarkster »

I would not call them false positives. This implies the check is finding issues that do not exist. I would prefer to say defects are found which might not necessarily make the model unusable.
User avatar
adrianinsaval
Veteran
Posts: 5534
Joined: Thu Apr 05, 2018 5:15 pm

Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)

Post by adrianinsaval »

I'm just repeating what the OCC guy says, I trust he knows more about how OCC works than most of us, BOP check is not meant for users to validate a shape because it gives false positives so you might be forever seeking to pass a check that is not relevant to your case. Maybe come back to it if it actually gives you trouble in an operation but as it is now it should not be considered a bug (certainly not on FreeCAD's side).
User avatar
adrianinsaval
Veteran
Posts: 5534
Joined: Thu Apr 05, 2018 5:15 pm

Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)

Post by adrianinsaval »

TheMarkster wrote: Wed Nov 24, 2021 5:00 pm I would not call them false positives. This implies the check is finding issues that do not exist. I would prefer to say defects are found which might not necessarily make the model unusable.
I guess you might be right, in practice the conclusion is the same: don't use BOP check to try to judge your model just because.
drmacro
Veteran
Posts: 8806
Joined: Sun Mar 02, 2014 4:35 pm

Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)

Post by drmacro »

The issue I see with "BOP can give false positives" is that there is nothing quantitative ion the statement.

Are there 10% false positives? Are there 50% false positives?

My experience indicates the false positives aren't nearly 50%.

So, my, admittedly belt and suspenders, approach is to combine with looking at dependency graph and the tree, etc. for indications of what might be the cause and fixing it. Of course, with a STEP of other file formats this may be easier said than done or not be possible at all.
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
MRx
Posts: 319
Joined: Wed Jul 08, 2020 5:59 am
Location: Tainan / Taiwan

Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)

Post by MRx »

I had at least 2 objects where I have experienced issues in such an intersected area. Certainly it doesn't mean that it was caused by the intersection itself but I'd still like to avoid it (maybe it's a reason).
User avatar
adrianinsaval
Veteran
Posts: 5534
Joined: Thu Apr 05, 2018 5:15 pm

Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)

Post by adrianinsaval »

drmacro wrote: Wed Nov 24, 2021 5:39 pm The issue I see with "BOP can give false positives" is that there is nothing quantitative ion the statement.

Are there 10% false positives? Are there 50% false positives?

My experience indicates the false positives aren't nearly 50%.
...you may want to run BOP checker in cases if you see that Boolean operation fails and you do not understand why. In such situation, BOP checker may give some hints like "this shape interferes this shape"...
...It would be safe to say that those checkers are not designed for users of OpenCascade as they may produce lots of false-positive errors. You have to be a developer of BOPs to get some useful info out of those checkers...
...Applying those severe checkers to all inputs in any conditions will give you a frustrating output that half of your models are "crappy" while they are not...
my interpretation is, stay away from it unless you're actually experiencing problems with BOP, it's probably impossible to quantify how often the results should be ignored but it's safe to say that you shouldn't lose sleep over it if your model fails the check but you haven't had any trouble with it.
MRx
Posts: 319
Joined: Wed Jul 08, 2020 5:59 am
Location: Tainan / Taiwan

Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)

Post by MRx »

Since I got into the tolerance settings and to finally answer my original question by myself:

After refining an object which intersects holes there will be a BOPAlgo_InvalidCurveOnSurface issue.

It has been advised to create a chamfer / fillet on the edge to get rid of this problem, however the chamfer / fillet is only a temporary fix until the next refinement, and doing another chamfer / fillet on the existing one is not really practical.


Refining seems to re-create the edge which is intersected, to get rid of the error you can simply update the tolerance value for the intersecting edge.
Select the edge and run:
Gui.Selection.getSelectionEx()[0].SubObjects[0].fixTolerance(0.001)

on the python console.

When originally creating an intersecting hole there is no such problem in the Geometry checker.
So I have compared the original tolerances:

>>> Gui.Selection.getSelectionEx()[0].SubObjects[0].Tolerance
1.6280357646833993e-07 <<-- new tolerance after refining
>>> 2.0608753678009897e-07
2.0608753678009897e-07 <<-- original tolerance before refining

Applying the original tolerance will make the issue go away too of course.

The Check Geometry feature is very important for monitoring the integrity of an object, don't ignore it and in case I'd rather suggest to post in the forum and ask about it. (I ignored it to a certain degree in the past and it lead to a disaster...)
User avatar
adrianinsaval
Veteran
Posts: 5534
Joined: Thu Apr 05, 2018 5:15 pm

Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)

Post by adrianinsaval »

Ok are the tolerance issues present in the PD generated geometry, in the simple copies, in the refined copies or in all? From what I've been seeing Part Design sets the tolerance to Precision::Confusion() (equal to 1.e-7) in most if not all operations https://github.com/FreeCAD/FreeCAD/sear ... tTolerance
Are you saying that this tolerance is insufficient for most operations and we should lower it? Or is the way that tolerance is set there incorrect?

Edit: reading better you say the issue is with refined geometry, are you refining with the Part Design property or using the Part workbench operation?

Edit 2: is this correctly written?
>>> Gui.Selection.getSelectionEx()[0].SubObjects[0].Tolerance
1.6280357646833993e-07 <<-- new tolerance after refining
>>> 2.0608753678009897e-07
2.0608753678009897e-07 <<-- original tolerance before refining
that would mean setting a higher tolerance is fixing your problem, I'm not sure how that can be...
Last edited by adrianinsaval on Tue Jan 18, 2022 7:46 pm, edited 1 time in total.
MRx
Posts: 319
Joined: Wed Jul 08, 2020 5:59 am
Location: Tainan / Taiwan

Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)

Post by MRx »

For this particular issue -- only after the refinement the set tolerance is wrong.
It does not matter where you refine it, you will also get that problem when you downgrade and upgrade the object in the draft workbench.
I did not trace in detail where it comes from (other than the "refine" operation selected via Gui)

Original object before refinement (I just copied and pasted it in no particular order before):
>>> Gui.Selection.getSelectionEx()[0].SubObjects[0].Tolerance
2.0608753678009897e-07 <<-- original tolerance before refining
Object after refinement:
>>> Gui.Selection.getSelectionEx()[0].SubObjects[0].Tolerance
1.6280357646833993e-07 <<-- new tolerance after refining

The original object, generated in PartDesign does not have tolerance issues, in fact the tolerance values differ from before and after refinement on the intersecting circle. After the refinement the tolerance number is like half of the original number before.

Tolerance issues are only on my radar for one day now, I need to keep watching what's going on with it in freecad.
User avatar
adrianinsaval
Veteran
Posts: 5534
Joined: Thu Apr 05, 2018 5:15 pm

Re: Intersecting Holes (BOPAlgo_InvalidCurveOnSurface)

Post by adrianinsaval »

Ok I have now checked your file (thanks for being sooo helpful and re-uploading and providing links to help us out :roll: :roll: )
The BOP check raises issues when refine=true but doesn't when refine=false, checks out with your story
checking tolerance of problematic edge... it was 2.09e-7 with refine=false and 1.48e-7 with refine=true, setting the tolerance for that edge to 2.09e-7 (higher than it was after refine) leads to a clean BOP check.
Now your story doesn't check out, how come a higher tolerance would fix it? You also mentioned somewhere setting the tolerance to 0.001 this is several orders of magnitude higher than any tolerance I managed to come across... your story seems more wild now.
My guess is that refining is setting a more strict tolerance that let's BOP check detect stuff it didn't detect with the original higher tolerance, naturally setting the tolerance as high as 0.001 would give even more wrong results...
Would be nice if someone more knowledgeable could study this.
I don't see how your "fix" is actually fixing stuff... can you provide a better more useful example of an issue resolved by setting a lower tolerance?

Edit: I was wrong changing the tolerance to 2.09e-7 did not lead to a clean BOP check, although it did give different results, turns out the first time I was just running the check on the single edge since I hadn't reselected the body :oops: I suspect the same happened to OP here so it might have happened before too.
Situation is still the same, we have no useful example or explanation of a situation were the issue presents itself and is solved by setting a lower tolerance and OP refuses to provide one...
Post Reply