Move Assembly/Element data structures to compas

[gonzalocasas]

Feature Request

Currently, discrete assembly data structures are spread all over the place: there is a WIP implementation on a branch of compas_fab, another one in compas_assembly (heavily biased towards structural design), and multiple other ones in various past projects. We should consolidate the basics, move them to compas core to be able to share the same base structure, and eventually other packages can sub-class it to create specialized versions of it.

[xarthurx]

Usually structural analysis use different abstract models than geometric ones, and there’re also different type of structural / geometrical model for different type of assembly.

Putting them all together may not be a good idea for future extension, but several meta-class is good to keep the base framework organized.

On 2 Dec 2019, 09:33 +0100, Gonzalo Casas notifications@github.com, wrote:

Feature Request Currently, discrete assembly data structures are spread all over the place: there is a WIP implementation on a branch of compas_fab, another one in compas_assembly (heavily biased towards structural design), and multiple other ones in various past projects. We should consolidate the basics, move them to compas core to be able to share the same base structure, and eventually other packages can sub-class it to create specialized versions of it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[gonzalocasas]

CC'ing people that was/is involved in the topic: @yijiangh @inesariza @funkchaser @stefanaparascho @arashadel @brgcode @kathrindoerfler

[tomvanmele]

in my opinion, the base class for an assembly would be a mesh network, without any further requirement on how the network is constructed or used. it basically encodes relationships between elements represented as meshes, but makes no assumptions about where these relationships come from...

[tomvanmele]

i would also just add it as a core data structure and not in compas.structures as previously discussed at some point. it is basically a generalised version of the volumetric mesh, where the cells are not necessarily compatible nor connected (this is how it is used in compas_3gs for example)

[gonzalocasas]

The idea so far is to build a simple (but extensible base class) for assemblies and elements to standardize at least a few of the different terminology/approaches that we've used. For example:

1) Element instead of vertex, or block, or rod, etc. Assembly instead of any other abstract name, Connection instead of edge. 2) Assembly class will use (contain) a compas.datastructures.Network to store adjacency data and attributes, but it won't inherit from it. Network is an abstract component that has a lot of abstract terminology attached to it, and we don't want it to spread to the more concrete Assembly class. 3) Elements will be stored in vertices of the underlying Network. Connections will be stored in the edges of the underlying Network. 4) Assembly will also not include the features that compas_assembly has now to automatically find interfaces, nor will it include default attributes for path planning. Those are extensions that should be handled by the respective packages that know how to deal with these things.

i would also just add it as a core data structure

agree. so compas.datastructures.Assembly

[kathrindoerfler]

I would highly agree, that the mesh network has misleading terminology (although I am using it now as it is). And I would appreciate a core data structure compas.datastructures.Assembly for an assembly base class. I am not sure, if solutions of pt. 2 and 3 are the most logical solutions, because then it is one core datastructure containing another core datastrcuture, but I suppose you know best. Best Kathrin

Am Mo., 2. Dez. 2019 um 11:58 Uhr schrieb Gonzalo Casas < notifications@github.com>:

The idea so far is to build a simple (but extensible base class) for assemblies and elements to standardize at least a few of the different terminology/approaches that we've used. For example:

1. Element instead of vertex, or block, or rod, etc. Assembly instead of any other abstract name, Connection instead of edge.
2. Assembly class will use (contain) a compas.datastructures.Network to store adjacency data and attributes, but it won't inherit from it. Network is an abstract component that has a lot of abstract terminology attached to it, and we don't want it to spread to the more concrete Assembly class.
3. Elements will be stored in vertices of the underlying Network. Connections will be stored in the edges of the underlying Network.
4. Assembly will also not include the features that compas_assembly has now to automatically find interfaces, nor will it include default attributes for path planning. Those are extensions that should be handled by the respective packages that know how to deal with these things.

i would also just add it as a core data structure

agree. so compas.datastructures.Assembly

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/compas-dev/compas_fab/issues/94?email_source=notifications&email_token=ABLEW7CBUVSC5YVEHEP3D23QWTS6XA5CNFSM4JTSD6ZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFTDDOY#issuecomment-560345531, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLEW7CVTDIYLCE75BXO3H3QWTS6XANCNFSM4JTSD6ZA .

[xarthurx]

Based on what I've seen in structure & graphics field, below are an incomplete list of commonly used types. We can possibly borrow some:

1. bar (2 pts, abstract linear element)
2. rod (2 pts + rotation)
3. beam (rod + bending)
4. isosurface/surface structure (parametrically described or discrete described as a "network")
5. volumetric mesh (only geometric or with material info for FEM, can be stone brick, timber element, etc.)

1,2,3 are mainly for different types of structural purposes.

I guess there might be some perception difference among us here. Based on the different sub-field BRG and GKR are working on, it seems to me that the "assembly" in BRG is more like "4+5" (shell and stone brick), while for GKR is more like "5", with sometimes additional structural analysis requirements using "1, 2, or 3, or any combination".

A balance of what extent do we want to generalize the "Element" class but also allow extension with ease is worth considering.

On Mon, 2 Dec 2019 at 12:14, Kathrin Dörfler notifications@github.com wrote:

I would highly agree, that the mesh network has misleading terminology (although I am using it now as it is). And I would appreciate a core data structure compas.datastructures.Assembly for an assembly base class. I am not sure, if solutions of pt. 2 and 3 are the most logical solutions, because then it is one core datastructure containing another core datastrcuture, but I suppose you know best. Best Kathrin

Am Mo., 2. Dez. 2019 um 11:58 Uhr schrieb Gonzalo Casas < notifications@github.com>:

The idea so far is to build a simple (but extensible base class) for assemblies and elements to standardize at least a few of the different terminology/approaches that we've used. For example:

1. Element instead of vertex, or block, or rod, etc. Assembly instead of any other abstract name, Connection instead of edge.
2. Assembly class will use (contain) a compas.datastructures.Network to store adjacency data and attributes, but it won't inherit from it. Network is an abstract component that has a lot of abstract terminology attached to it, and we don't want it to spread to the more concrete Assembly class.
3. Elements will be stored in vertices of the underlying Network. Connections will be stored in the edges of the underlying Network.
4. Assembly will also not include the features that compas_assembly has now to automatically find interfaces, nor will it include default attributes for path planning. Those are extensions that should be handled by the respective packages that know how to deal with these things.

i would also just add it as a core data structure

agree. so compas.datastructures.Assembly

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub < https://github.com/compas-dev/compas_fab/issues/94?email_source=notifications&email_token=ABLEW7CBUVSC5YVEHEP3D23QWTS6XA5CNFSM4JTSD6ZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFTDDOY#issuecomment-560345531 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABLEW7CVTDIYLCE75BXO3H3QWTS6XANCNFSM4JTSD6ZA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/compas-dev/compas_fab/issues/94?email_source=notifications&email_token=AAOVGVVKXD433DYD25JGSQLQWTUZ5A5CNFSM4JTSD6ZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFTERCA#issuecomment-560351368, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOVGVTCS2SDMAF7MOL3SWDQWTUZ5ANCNFSM4JTSD6ZA .

-- MA Zhao

"SAVE PAPER - PLEASE THINK BEFORE YOU PRINT!"

[gonzalocasas]

The proposal for Element would be to represent any discrete element without specifically having to add the parameters that describe it (eg. 2 points + 1 rotation for rod-like elements) to the core of it, so, in essence, an element would be described by 2 basic parts: 1) its local coordinate frame 2) the ability to build a mesh out of itself.

For a rough example of that, see this Element implementation for the compas course , but please ignore the path-planning specifics. The element requires a frame to be constructed, but then provides different constructors to build elements out of different inputs, e.g. from_shape() builds one out of a compas shape primitive (roughly your points 1-3), from_mesh builds one based on a mesh (roughly points 4-5), and as so on, leaving the door open to implement more constructors in the same style. But regardless of the mechanics for constructing the object, the Element class always needs to be able to return a mesh representation of itself.

[yijiangh]

Sorry for being late on this great discussion...

I agree with @gonzalocasas 's idea of having an abstract base class for describing Element. But I would suggest that having two types of vertices in the connectivity graph to help us model joints between elements.

This is needed because we have connection details that involve:

1. extra physical objects (e.g. dowels to connect two timber beams)
2. no extra physical object (e.g. friction connection between two rigid blocks)

In the cases where joints have physical objects, it complicates the modeling if we leave these Joint out from the assembly network. People have to do some "double-layer" graph modeling techniques to properly capture the joints and elements in the same connectivity graph.

So what I'm proposing last summer was to have two types of vertices in the Assembly network: Element and VirtualJoint. Both of these vertices can optionally have an attribute called UnitGeometry, where all the shape's abstract geometric data (from_mesh, from_shape, to_mesh, etc.), abstract robot manipulation data (base class of Grasp, Carve, Extrude end effector relationship to the part), and abstract structural property data (base class of Rod, VolumetricCell, ShellUnit etc.) are stored. A structural model for analysis (no matter it involves volumetric units (tet/hex cells) or linear units (bars)) can be reconstructed from the Assembly network by using its connectivity information and the attributes of its Elements and Joints.

I've been swamped by various other stuff this semester so the progress has been much slower than I expected, but I am trying to summarize all of my thoughts into this Compas Enhancement Proposal here (still work in progress!). And I have a small working prototype that @stefanaparascho and I have been using for the DMS workshop on robotic assembly of spatial double-tangent tet structures. Here is the slides that I used for our discussion this summer on designing this assembly data structure. My prototype is a bit specific to robot picknplace applications now and I need a bit more work to complete the VirtualJoint connectivity modeling part, but it already has a to_data, from_data pipeline that can export the assembly data into json and OBJ meshes and later fed into pychoreo for path planning, which has been (a bit painfully) tested by our participants at the DMS workshop.

I was thinking about having a more detailed comment here after I finish my CompasEP, but I have to first survive through this wave of conference deadlines...

Edit: The Compas Ehancement Proposal is completed and can be found here.

[funkchaser]

Hi folks, and sorry for joining this discussion late, although I see some of the thoughts shared with Gonzalo have already been mentioned. It might be going a bit too far, but I'd advocate for smth like this:

• A bare-bone abstract class implementing a "graph", just like the Network class, but without "mesh-specific" features like xyz-coordinates of a vertex, or edge-to-line methods.
• As already mentioned above, nodes/vertices would store Elements. For me, Elements are representing both:
  • real objects (a bar, dowel, beam's side) - here I don't mean the Brep or the mesh of the object, rather instances of classes that can generate them.
  • abstract entities (e.g. a "logical joint" clustering multiple elements in meaningful way) - similar to Yijiang's VirtualJoint, but I think it could be more generic than this, for example: if you have information in the model which is re-used/shared by multiple elements: where would you store it without duplicating it?
• Graph's edges should therefore not be used to describe connections between real objects, but just semantic links between entities, both real and abstract.
• Thinking further, with such an abstract assembly class, a structural line+point model could be hooked up to the "design model". I wonder, however, if this goes more into the direction of a relational database?

Last but not least, a model of an assembly might have two "lives": 1) when it's designed, the elements can be interdependent (e.g. the end-cut of a beam is derived from the side plane of an other beam), and 2) for assembly, the geometry of each element can be frozen so that each element can be "moved" independently (e.g. to simulate fabrication). What do you think?

[gonzalocasas]

Still many things to sort out, but the main task has already been done.