Functional Dependencies between Objects

Features & Ideas
1

Hey there,

just starting this as a thought dump. Haven’t gone into detail about the implications or implementations of this. But here’s the gist:

Additionally to the composition of objects (I.e. a Column within a timber frame wall) there are often functional dependencies between object in a building model. This is especially so in case of parametric workflows with GH. There it would be: Data X in, data Y out, where if X changes, the output Y is invalid in some sense.

For a future design process, where design automation takes over parts of a workflow (i.e. form-finding, section design) based on a specified input, modelling this kind of dependencies would be of interest. Obviously, one could just build that sort of relationship on top of the current Object schema, by providing a dependsOn or basedOn property to an object that is functionally dependent on or automatically created with a script given another object.

A usage of this feature in words would be: I am structural engineer and made a preliminary design, now the architect pushes a new commit, where the facing layer material specification of a wall changed. Now, if I implemented a perfectly functional workflow I could ask: “Speckle, what objects depend on this wall (i.e. which calculations did I run with it)?”

Just curiuous to hear if you guys (and gals) stumpled across this sort of use-case before?

Let me know if I should make my thoughts a bit clearer :slight_smile:

Thanks already,

3 Likes
2

Hi @maxmodugen - another good challenge! I think the way we’re scaffolding Speckle for the future, which should account for this, is the way most modern CI systems have workflows.

Circle CI has some nice diagrams in its docs that could explain “visually” where we probably will end up.

Basically, in the scenario you describe, every time the architect pushes a new commit, some compliance checks that you’ve set up could run and inform you of any possible actions from the structural engineer’s end. These checks could essentially perform the check you’ve just described - ah, ok, all these objects “depend on” this other ones, which changed, so extra attention is required.

As we’re already bringing along the object graph itself, having these extra relationships - that do are not reflected in the OG - can be useful. It might be tricky to reconcile though with the immutability of objects, but you could rely either on your own application id generating system, or the default application ids that come from host apps.

1 Like