How to reference objects ? PropertyLink and DAG constraints

[Cyril]

I have 3 objects referencing each other :

object A:
- PropertyLink -> object C

object B:
- PropertyLink -> object C

object C:
- PropertyLinkList -> object A, object B

They are in a document structure like this :

Parent 1
- Parent 2
- - Parent 3
- - -Object A
- - Parent 4
- - - Object B

Group 1
- Object C

Apparently FreeCAD don't like this at all. Elements stay touched after recompute and I get the exception :

Code: Select all

<Exception> Document.cpp(2847): The graph must be a DAG.

Issues are clearly visible on dependency graph.

So I have few questions :

• Is there a way to make a mutual reference between objects without issues ?
• If Object A and Object B have a reference to Object C but not the opposite to respect DAG constraints. Is there a way to reach Object A and Object B from Object C ?

[vocx]

[*]Is there a way to make a mutual reference between objects without issues ?

I find this a bit strange to imagine. Maybe you should provide a concrete example. My first instinct, as I'm sure many others also feel, is that circular dependencies are inherently wrong.

[chrisb]

I can imagine situations where such dependencies can well be solved, e.g. two sketches A and B, where the placement of A depends on the placement of B while a dimension in B depends on a dimension of A. But this is rather academic, and does not help at all to build clear models.

In this case I would create a third master sketch on which both A and B depend. A spreadsheet can be used in the same way.

[Cyril]

I find this a bit strange to imagine. Maybe you should provide a concrete example. My first instinct, as I'm sure many others also feel, is that circular dependencies are inherently wrong.

I have tons of examples. Using the word dependencies assume that A and B affect C and C affect A and B which is not necessarily the case. The more simple example is a Group, you can loop thought all group elements but you can also reach the parent of an element. How can I make such relationships ?

1. Case 1 : The one which brings me here. I have a boundary which have been generated based on a wall. A boundary is a room limit used in my case for energy modeling. If you have a room on each side of the wall you have at least 2 boundaries related to the wall but you can have many. I need to know from my boundary on which wall it was based (to get thermal mass, heat transfer coefficient etc…) but I also need from my wall to the list of every boundary based on this wall for example to find which boundary and room is on the opposite side of the wall.
   If this case Object A and B are boundaries, Object C is a wall. Parent 3 is a space/room, Parent 4 is a space/room.
2. Case 2 : I have a ventilation system with some air terminals connected by a duct
   AirTerminal 1 ---- Duct ---- Fitting ---- Duct ---- | Fitting connecting the 3 branches |
   AirTerminal 2 ---- Duct ---- Fitting ---- Duct ---- | | ---- Duct ---- Fitting ---- Duct 1
   Duct 2 ---- Fitting ---- Duct ---- Fitting ---- Duct | |
   In this case I don't have a fan yet therefore I don't know in advance in which direction the flow will go and so my DAG. But I need to know which element is connected to another to perform analysis. AirTerminal 1 affect what happens in Duct 1 and the opposite is also true. Analysis would be probably actually modeled with nodes and edges.
3. Case 3 : similar to ventilation but in a hydraulic system flow could be reversed in a pipe using valves so there is just using DAG is not a good way to model it.

[paullee]

I have tons of examples. Using the word dependencies assume that A and B affect C and C affect A and B which is not necessarily the case. The more simple example is a Group, you can loop thought all group elements but you can also reach the parent of an element. How can I make such relationships ?

1. Case 1 : The one which brings me here. I have a boundary which have been generated based on a wall. A boundary is a room limit used in my case for energy modeling. If you have a room on each side of the wall you have at least 2 boundaries related to the wall but you can have many. I need to know from my boundary on which wall it was based (to get thermal mass, heat transfer coefficient etc…) but I also need from my wall to the list of every boundary based on this wall for example to find which boundary and room is on the opposite side of the wall.
   If this case Object A and B are boundaries, Object C is a wall. Parent 3 is a space/room, Parent 4 is a space/room.

Sounds familiar Conceiving something similar...

I have 3 objects referencing each other :

object A:
- PropertyLink -> object C

object B:
- PropertyLink -> object C

object C:
- PropertyLinkList -> object A, object B

Take this example, could you avoid Object C has the PropertyLinkList back to Object A and Object B?

Try Outlist / Inlist...

Object A.Outlist = [ ObjectC, .... etc.]
Object B.Outlist = [ ObjectC, .... etc.]

w/o the PropertyLinkList in Object C you indicates...
... use .Inlist

Object C.Inlist = [ObjectA, ObjectB, ... etc.]

[vocx]

...
[*]Case 3 : similar to ventilation but in a hydraulic system flow could be reversed in a pipe using valves so there is just using DAG is not a good way to model it.

These sound a bit like optimization problems, so I'm not sure how they are related exactly to solid modelling.

In an optimization problem, your equations may not be explicit, with a solved variable on one side and an equation on the other side.

Code: Select all

A = formula(B, C)

You may have a complex relationship in which the same quantity is used on both sides of the equation.

Code: Select all

formula(A, B) = formula(A, C)

So, to solve these problems you'd use some sort of numerical algorithm to approximate the solution, as long as you provide starting values for the interested quantities.

But this is completely different from solid modelling. In my mind, solid modelling follows a simple, direct path: parent features give way to children features in succession.

[Cyril]

These sound a bit like optimization problems, so I'm not sure how they are related exactly to solid modelling.
…
But this is completely different from solid modelling. In my mind, solid modelling follows a simple, direct path: parent features give way to children features in succession.

If I understand well you mean that FreeCAD was initially developed for solid modeling. However I have been supporting Yorik's work on Arch/BIM workbench for years by now and BIM is pretty much more about objects information and relation between objects than about a static structure with a simple and direct path.

Sounds familiar Conceiving something similar...

Really ? Maybe we should have a talk about that to avoid doing same thing on our own side.

Take this example, could you avoid Object C has the PropertyLinkList back to Object A and Object B?

Is it possible to avoid back link but it would be very much less convenient and I assume a very much more computer time consuming task.

Try Outlist / Inlist...

Thanks to these key words I found some very interesting discussion on the subject :

• Changed Document Linking: Bidirectional Graph Structure
• [Solved] Bad implementation of OutList property in Part container ?
• Face graph - implemented in FreeCAD?

About Outlist / Inlist seems very useful but I don't see how to target a specific property. I have objects with multiple PropertyLink how to know which one leads to the InList ?

Ping

Sorry to disturb. Would you mind en-light me on this subject ? Is the Bidirectional Graph Structure discussed in 2017 now possible (issue solved tends to say yes) and how to make one ?
If I understood well the issue was about to know when to stop recomputing. Does FreeCAD needs a new kind of PropertyLinkxxx set with no recompute consequence ? (eg. PropertyReferencexxx)

[vocx]

...
If I understand well you mean that FreeCAD was initially developed for solid modeling. However I have been supporting Yorik's work on Arch/BIM workbench for years by now and BIM is pretty much more about objects information and relation between objects than about a static structure with a simple and direct path.

Yes, but if my understanding of the recompute mechanism is right, all this was developed so that solid objects would update their shapes when their properties are changed. So you have a pretty linear sequence of inputs and outputs. This is needed when doing assembly of objects inside Std_Parts, for example, so that all elements inside automatically update their position when something else changes.

When you want to have this as a circular dependency, I'm not sure it was ever designed to work for that. I think I've read somewhere that you can "freeze" an object, so that it does not recompute, so that you can do all sorts of modifications and only recompute at the end. This may help you avoid these type of circular interactions.

I would ask realthunder because with the LinkMerge he's done all sorts of modifications to the recompute code.

[paullee]

Really ? Maybe we should have a talk about that to avoid doing same thing on our own side.

Mostly ideas and experiments only

I am spending most of time developing something to use Sketch / SketchFeaturePython to ease the workflow of plan layout design editing / development - I do not like separating walls objects and many individual base wire /sketches ...

In the process experimenting using edges in Sketch to define boundary of ArchSpace - so editing Sketch Layout update Wall layout + ArchSpace shape... and yes one of the idea is defining which edge (wall) a door is 'attached to, thus there will be information has a door communicating between Which one Spaces... long shot


Space 1 - (Wall X + Door M) - Space 2

(Wall X + Door M) is linked to an edge in the Sketch Layout.

(Edge / Wall X + Edges ...) define Space [1, 2, 3, ....]

[ickby]

The bidirectional graph is implemented, however, it is only useful to calculate inlist and outlier faster. There is still the restriction of non cyclic graphs, and this will lead stay: if there is a cycle in the graph as in your example it is unclear how the execution order of the document should be. Hence it is forbidden.