From sketcher carbon copy tool to general discussion about cyclic dependency checking

[derMart]

@bambuko I changed the title to hopefully reflect the discussion better

[bambuko]

@derMart
thank you

[chrisb]

I suggest change the title and move to https://forum.freecadweb.org/viewforum.php?f=8

Done.

[adrianinsaval]

Second, usecase is quite easy: I do not want to duplicate sketches,

but this is what you would get with a bidirectional carbon copy (with some additional junk due to the duplicated geometry)

I want to duplicate / copy geometry. Lets say you have a sketch with some geometry (e.g nut hexagon) which you need multiple times in different sketches. I want to copy that geometry into several sketches (and surely don't want to care that certain unnecessary criteria are met to do such operation). [EDIT: It would be better if the copy operation does not create those constraint links, because as can be seen in the example above this possibly creates long dependency chains.] Carbon copy is the only way I know how this could be achieved atm. Whenever https://github.com/FreeCAD/FreeCAD/pull/5480 will be merged, I am happy to do it using the regular copy / paste functionality and don't care about carbon copy. But who knows how long this will take.

There are workarounds for what you want to do but directly using carbon copy is not it and it's not meant to be IMO, there is a case to be made about offering a variant that doesn't create expressions but not about removing the feature.
Hopefully we'll get regular copy/paste for the next version and that should satisfy your needs.

I do not know what "PD" means. Could you please explain and also why the example will be invalid in that regard? I am suspicious because all the operations I have posted in the examples showing the modified behaviour could be done also manually. And in that case I do not see why they should fail.

PD is short for Part Design, I was premature in my judgement, the specific case of two perfectly superimposed rectangles actually work in 0.20 however this type of setups can be problematic and it is not recommended to have superimposed geometry, see this simplistic example were a line is superimposed in one of the rectangle's edge, the pad can't be recomputed unless you remove the extra line because occ's facemaker can't handle it.

superimposedErrorEx.FCStd

(10.81 KiB) Downloaded 10 times

I am sorry, but this is the first time you mention this (...) But please, explain a little bit more in detail how it is done. Would be also happy for some documentation link. [EDIT: or even source code links where things are handled]

Sorry I either got confused with some other thread or wrote an answer about that and never actually submitted it

depErrorEx.FCStd

(5.9 KiB) Downloaded 10 times

see this classic example with a spreadsheet (this is a general issue, not of carbon copy or even sketcher), the height of the cube is set via spreadsheet but we can't use some other property of the cube in the same spreadsheet without triggering a cyclic dependency error, despite most of the other properties of the cube being actually independent of the height. So the dependency check only goes up to the object level, not individually for each property (and constraint is just another property of a sketch object).

Apart from this: The limitation that some copy operations will be prohibited due to the current cycle detection on sketch level should IMHO be stated in the wiki documentation for carbon copy. It is not straight forward that such a limitation exists if one just reads the documentation without knowing the internals of FreeCAD.

that's a fair point, are you open to adding that to the wiki? we can always use some help in documentation.

[adrianinsaval]

As for the complexity question, at first glance I do not think it will be more complex code wise,

famous last words I'll be happy if such a system is implemented, it could very well be that we just haven't had someone roll up their sleeves and do it yet but I wouldn't be surprised if it's more complex than it looks.

as the logic is similar if you try to detect dependencies on property level rather than on object level. It is just other parts of the graph which you are traversing. As for performance complexity, I also at first glance do not think it makes much of a difference, as to detect cycles on object / sketch level you anyway need to traverse over all underlying properties.

Feel free to propose if you have something in mind or even better some code. I can't really talk authoritatively about the details of the system but I would guess the first issue to overcome is that I don't think there is a standardized system in place to declare dependencies between properties so you would have to go through the entire code base and declare that dependency between every property that is actually dependent on another or find some way to detect it, and also have a way to detect/declare it for dynamically created properties. Then what about custom objects and addons? the system wouldn't be safe until we get everyone out there to use the system to declare dependencies between properties, I guess it could fallback to the current behavior when it doesn't have the info. I guess an alternative would be to make a system to have specialized for an object type per property dependency checker. This is my interpretation of how this works, I would love to be corrected on this if someone with more knowledge comes around and reads

Because there is now a proof which ensures that carbon copy will not create constraint cycles. As such, it does not need to check for cycles, simple as that.

It could easily become cyclic if I make one of the constraints a reference constraint, or if I manually added some other expressions, therefore we can't just assume there won't ever be dependency, it must be checked and as long as we don't have a per property dependency check we have to rely on the current one.

[derMart]

but this is what you would get with a bidirectional carbon copy (with some additional junk due to the duplicated geometry)

To not get any misunderstandings: The examples are just there to illustrate that no cyclic dependencies exists after carbon copy. Of course this is not a real world example.
Problem with duplication of a sketch is afterwards you have two sketches, not one single sketch with all the wanted geometry (part of which may be deleted afterwards). Basically you get it, what I need is regular copy paste of geometry.

There are workarounds for what you want to do but directly using carbon copy is not it and it's not meant to be IMO

Can you tell me those workarounds ?

there is a case to be made about offering a variant that doesn't create expressions but not about removing the feature.

Not sure if we talked past each other, but it sounds like that variant is exactly what I was proposing with the dialog to choose how to handle dependencies. But nevermind, in the long run regular copy paste is the better option here. So if this is there in the near future, one should wait until before looking at carbon copy again.

see this simplistic example were a line is superimposed in one of the rectangle's edge, the pad can't be recomputed unless you remove the extra line because occ's facemaker can't handle it.

I see, it is complaining about open wire's, so it does not know that the shape is closed. [ EDIT: For completeness, this seems to be a problem of detecting open shapes which overlay / superimpose itself as not being closed. I would guess it is not perse a problem of superimposed geometry. So as long as you only have independent closed shapes superimposed /overlayed, there won't be this error I guess (?) ]

see this classic example with a spreadsheet

Thanks, yes I think I now from a logical level fully understand how dependency checking works currently.

that's a fair point, are you open to adding that to the wiki? we can always use some help in documentation.

Yes, would be happy to help here. How is the wiki editing process? Do I just make an edit or how is moderation / review handled?
I would actually propose two changes. First I would like to be more verbose about how the constraint reference expressions to the originals are done and second I would explain in more detail the limitations. Is there maybe a page in the wiki which describes the dependency checking, which I can link to?

Feel free to propose if you have something in mind or even better some code. I can't really talk authoritatively about the details of the system but I would guess the first issue to overcome is that I don't think there is a standardized system in place to declare dependencies between properties.

I am afraid my time resources are limited here so I will focus on lower hanging fruits first (like the documentation of carbon copy or maybe the copy paste pull request). Some final thoughts on this from my side: I am not sure if you explicitly need a system to declare dependencies between properties because all the dependency information is already there. Example: if you have a constraint with an expression which mentions another constraint, you got your dependency information. The easiest way to correctly check for cycles is to just recompute everything. For every value you calculate, you anyway need to traverse over all its dependencies. While doing so you just store e.g. in a hash map all the id's of the properties you traversed and whenever you encounter a property which you already have traversed, you got a cycle. That is actually IMHO how often times such systems are implemented.
On the other hand I could image there is already alot of code which goes in that direction. For example the current top level system can't handle cycles inside one sketch, so there has to be some code which handles that already.

It could easily become cyclic if I make one of the constraints a reference constraint, or if I manually added some other expressions, therefore we can't just assume there won't ever be dependency, it must be checked and as long as we don't have a per property dependency check we have to rely on the current one.

Well again so that we do not talk past each other. The proof I presented makes statements about the carbon copy operation. The statement it does is, that the carbon copy operation, done on any valid acyclic FreeCad file in any way will never result in a cycle (of course, not by the definition of the current cycle checker, but by the definition of a real property cycle which might be problematic, or in other words it will always be possible to recalculate afterwards without infinite recursion). It does not make statements about any other operations which might be executed before a carbon copy or afterwards. So my point is not that dependency checking in general is not needed, but that it is unnecessary for carbon copy operations (given that freecad would only care about property cycles). I of course invite you to look at the proof. But be warned, I will defend it . If you have any *specific* questions though about the proof I am happy to answer or if there is something not understandable. If I made a mistake please also show me explicitly where. Again, the proof holds true for any reference constraints or any expressions, does not matter. If you want to question that, please come up with an explicit counter example. Really, everything is fine, no offense, but just stating there might be issues without presenting arguments, while I presented a mathematical proof which shows there are none, is nothing which I will accept

[abdullah]

I created an example in regular FreeCAD (not link branch).

It is generally possible to do carbon copy from sketch1 to sketch0 (where the number is the position in the body history). I think it is uncommon (and maybe misleading), but possible to use carbon copy this way.

It is possible to be prevented to do a carbon copy, when both sketches are on the XY plane (so none if the support of the other), if there is a cross-carbon copy.

It is possible to be prevented to do a carbon copy, when one sketch is the support of the other, and the copy is intended in the reverse.

I think the OP might be right in nothing that carbon copy, conceptually could work without this limitation. At the end, it is a matter of copying geometry and linking expressions. As long as all expressions exist, and the way it works "older" expressions are not modified and new are based on old, it should work.

The current behaviour is caused because the tool checks the dependencies inList relationship (this is how FreeCAD does it). As seen above, there are several combinations where the relation points towards a circular dependency. If object B depends on object A, it is not generally possible to base object A further on object B. If the further modification of object A based on object B is linearly independent of the dependency of object on object A, it should be possible to modify it. FreeCAD does not go to the depth of this additional check.

The next question is, can this behaviour be modified? Well, the fact that a solution exists, heavily points towards the fact that it may be possible to code it. One often undervalued question is, if, from a practical point of view, the tool should allow it. It is the general reflection that chrisb usually rightly does (though he may not agree in this instance ).

If sketch1 is supported on sketch, "conceptually" is depends on it. If this is not intended, then both sketches should be made depend on a common support, for example planeXY. If sketch1 is the result of sketch0 carbon copying sketch1 which further carbon copies sketch... well you will have overlapping or intersecting profiles and it is highly unlikely that this is the result sought. It rather points to a not-well-thought structure. It is difficult to think of a use case. Even if there was such a use case, is it really worth to generate such convoluted inter-dependencies, that will take several days (and possibly a length help forum topic) for a colleague inheriting the design to understand it? It is always possible to create one extra sketch or provide the right support information to convey the same idea. This way the idea will be much more easier to understand. Not all of us are Einstein... or for what matters his first wife.

From a different point of view, most users arriving to such situation most likely do not actually want to arrive there. They arrived there due to an oversight. The might have opened the wrong sketch. An oversight that would likely generate new problems difficult to find out, if it weren't for these mechanisms.

If there is a clear cut use case where this makes sense, I think it is worth discussing it. If not I agree it is a limitation, but the limitation might be a feature, rather than a bug.