Assembly data structures

[tomvanmele]

@gonzalocasas @chenkasirer @funkchaser

perhaps we can continue the discussion about the assembly data structure here, such that others can contribute as well...

[gonzalocasas]

Sure, at least we can document on-going decisions.
Based on past experience debating the assembly data structure, an open thread/discussion might not be the most fruitful of media if there's not an existing implementation that goes with it to exemplify things. Otherwise, everything stays in the theoretical plane and discussions are lost in the details.

[tomvanmele]

Sure, at least we can document on-going decisions. Based on past experience debating the assembly data structure, an open thread/discussion might not be the most fruitful of media if there's not an existing implementation that goes with it to exemplify things. Otherwise, everything stays in the theoretical plane and discussions are lost in the details.

fair enough. will indeed start by posting example code for the sample problems...

[chenkasirer]

For good measure, gonna paste here my personal take-aways from previous discussions (mostly the last session we had):

• At this point, Assembly.graph can be manipulated directly to achieve the wanted representation.
• Ultimately, we should look at the consumers of Assembly (e.g. compas_fea). Whatever representation we choose, it should play nice with the algos&datos using it.
• With regards to upstreaming to core, the largest common denominator is yet to be found. A pragmatic idea would be to work on another project which uses an assembly (Brick Design?)

Additionally, the situation currently in https://github.com/gramaziokohler/compas_timber is that:

• Beams are added as nodes
• Joints are added as nodes
  • For each beam connected by this node, an edge is added between the two

[gonzalocasas]

In my opinion, mixing beams and joints (which have fundamental different semantics and even mechanical properties) in the same graph container screws up with the possibility of treating the data structure in any algorithmically significant way, because it would always need to be filtered in order to produce meaningful results, ie. adjacency queries for beam-to-beam suddenly need to extend to 2nd level neighborhood just to get a basic "which beams are connected to this other beam".

Perhaps worth pointing out to this paper by @ebruun and @stefanaparascho, which -if I'm not mistaken- uses the reverse, beams are edges and joints are nodes, and it uses that configuration based on structural rigidity theory.

[tomvanmele]

i think this is all way too specific to timber assemblies. but this will also be the case for meaningful interpretations of an assembly data structure for other applications, such as discrete element modelling.

i would therefore propose that we start with some code examples of a variety of situations could be handled, and then start the discussion and further development from there.

if the conclusion is that there is no meaningful common ground, other than using a graph, then maybe the conclusion is that the assembly does not belong in core. but we will cross that bridge when we get there :)