Like what you are doing with 'event watchers' and symmetry (Your blog dated 1/7/09) very much.
Do you know Jereon Coenders, who I believe works at Arup Amsterdam? He gave an interesting presentation at SmartGeometry 2010, which highlighted a lot of the problems faced by structural engineers trying to process complex geometry coming in from architects. mainly..
Some of the problems include:
1. The use of scripting or procedural based design tools like GH or GC tend to be based on strict uni-directional Directed Acyclic Graphs or dataflow approaches that do not allow much in the way of bi-directional or dynamic out of order solving.
Some of the problems are:
1. Need to run processes on types of nodes that are 'cross - cutting' wrt the creation / generation sequence of the 3d construct (Definition in GH-speak?). This entails collecting elements based on different criteria, that is often not made explicit by the generating party (mainly pesky architects, but really applies to all in a cross discipline context). He mentioned using rules based methods. Not really sure whether his idea of rules extends to replacing the procedural tools like GH /GC with something like Design++. Although, apparently these kind of tools also have their own problems / complexities.
Also, what do you think of Bentley's new ISM? I understand that this is a unified data model that provides a common repository for both design and analysis applications (Bentley only, but apparently ISM is an open format). Problems or weaknesses ? One side effect is that they must have developed a large structures specific data dictionary / ontology that should reduce ambiguity, thereby reducing translation problems. Would be great if the project specific 'sorting' could be done once and some intelligence would be embedded into the data when round tripping.
2. Need to run processes that run 'upstream' wrt the DAG script.
Jereon presented a tower 3d model that way based on two ellipses, which were rotated 90 degrees apart. The perimeter diagrid columns spanning between the two ellipses results in the smallest floor plate in the middle of the tower. I guess the lateral forces created problems at this level, which he wanted to control by defining a minimum radius or size. The problem is that the floorplate geometry at the tower's mid height is generated / derived by the two ellipses at the top and bottom, so the script could not be used to work out their resultant sizes based on an user-defined size for the middle floorplate. I bet this kind of problem must occur a lot. Material or engineering limitations trying to resolve themselves in the geometry as, part of a feedback mechanism (aren't physic, spring, relaxation, GA solvers getting fashionable, lately?) or a set of simultaneous math equations. Maybe, the constraints solving guys at D-Cubed or LEDAS will give it a shot... It would be interesting if 'imperative' script defined geometry can be translated into 'declarative' math functions; it sounds like what is needed if backsolving is needed. I guess we can fall back on brute force or GA solvers if all else fails.
Have you thought of expanding the way the symmetry / nodes work? I could see this developing into a cool way of modelling 3d frames or meshes. How are the nodes grouped, so that modifications in one can be propagated in a controlled way? Can a grammar be developed using symmetry or other geometric concepts?