Skip to content
April 12, 2013 / jeroencoenders



In the previous posts we have seen Objects, Properties and Methods which are some of the basic building blocks in NetworkedDesign. But what if you would want to build a little more complicated object? Or do not feel like all those actions for just a point defined by Cartesian coordinates.

NetworkedDesign uses the concept of an ‘Assembly’ for this. In the image the Assembly is represented by the fenced area. Assemblies combine Objects and Methods in one go. So a PointByCartesianCoordinates becomes possible that models an interconnected Point object with a Definition By Cartesian Coordinates method.

The rest is simply a combination of what you normally do for objects, properties and methods as you have seen in the previous posts.

Thank you for reading this and if you have any questions or comments, please use the comments section below.


April 5, 2013 / jeroencoenders

Property input


It has been a while since the last post, but do not despair. I have not given up on NetworkedDesign. I have been quite busy with another interesting initiative, called sustainability-open, which is an open-source framework for sustainable design, analysis and assessment. Go check it out at

In the post on Methods (part 1), we got our first introduction to giving input to NetworkedDesign. In this post I will elaborate a bit further on providing input to the system. When adding a method to an object or when an object is edited, the user is queried to input the properties (see Figure).

Properties are the data fields on objects. For example for a Point defined by a Cartesian coordinate system the properties are the base coordinate system, and the x,y and z components of the coordinate. A line has a begin point and end point as properties or a begin point, a direction and a length.

Properties have a name, a type and a value.


In NetworkedDesign properties have preferred types which are strictly enforced. For example in the figure is can be seen that the Coordinatesystem of a Point needs to be of the type CoordinateSystem, the X, Y and Z components need to be of type Double. The type check allows inheritance. This means that for example if an object allows a Point as a property, also a Node or a Vertex can be entered as long as these are subtypes of Point.

Multiple types

Some properties might be relevant for multiple object types which are not necessarily subtypes. In this case the ‘or’ between two types indicates that multiple types are allowed. For example in the figure the definition property on the Definition by cartesian coordinates method can apply to a Point, a CoordinateSystem or a Direction. This trick circumvents some of the object-oriented best practice, but in this case allows methods to be available to many different object types without the need to implement the same method for each different object type. Also semantic ‘strange’ inheritance work-arounds can be prevented which plague the object-oriented programming paradigm.


Properties store their data in a value. For example the value of a Coordinatesystem of a Point can be ‘coordinatesystem_1’ which refers to a specific object. The value of X component for example is 10.

Things like numbers, simple text and yes-or-no (true or false in this case) we call primitives. NetworkedDesign supports the following types as primitives: Double (used to store floating point numbers), Integer (used to store real number), Boolean (true or false) and String (used to store text).

Referencing objects and properties of objects

As mentioned objects can also be entered as input by referencing the object by name. This creates a dependency between two objects. For example if line_1 has point_1 as start point and point_2 as end point, NetworkedDesign will maintain the relationship between the line_1 and the two points. Whenever one of the points (or one of its upstream relationships) is updated, line_1 is also updated. This is called associativity.

NetworkedDesign also allows using properties of another objects as value by accessing those properties through the dot-notation. For example, point_1.X refers to the X-component of the coordinate of point_1. In case the value of the property references is an object this also creates a relationship between these objects. So, if line_2 has line_1.Startpoint referenced as a start point and this point is point_1, a relationship is created between the line_2 and point_1. You can concatenate the dot notation to drill down object properties, e.g. line_2.Startpoint.X.


NetworkedDesign supports the concept of replication. Dr. Robert Aish, at the time employed by Bentley, now at Autodesk building his new DesignScript system (, included replication first in his GenerativeComponents system ( Other modern parametric and associative systems, such as Grasshopper (, have also adopted this concept. How it exactly works in NetworkedDesign will be explained in a later post.

If you have any questions and/or comments, please feel free to write a comment.



August 19, 2012 / jeroencoenders

Methods in NetworkedDesign (Part 3)

Methods in action

Hi, welcome back. In part 3 I am going to explain one last method type. In part 1 we saw methods in general and Definition Methods. This method type we used to define Properties on Objects. In part 2 we saw Calculation Methods. This method type we used to perform a calculation with the properties of an object to produce one or more properties. The next method type, Transformation Method, we use in case we have defined an object but want to transform it to another definition type.

Transformation Methods

Transformation methods are used when you have defined an object and want to transform it to another definition. So, let’s remember what a Definition Method did for example a Point object. Initially the object only acts as a container, but does not have any properties defined. By for instance using a Definition By Cartesian Coordinates method we ask the user for input and specify the properties on the object. In case of the Definition By Cartesian Coordinates this would be the coordinate system to position the point against and the X, Y and Z coordinates. So this point now exists in the coordinate system. NetworkedDesign has a really neat trick to now tell the system that the point also exists in another coordinate system and automatically calculate the coordinates of this position. We use the Transformation Method for this which performs a bi-directional calculation on the object update between different property sets. For example, a Transform XYZ to Spherical transformation method will automatically add spherical coordinate properties to the point (the azimuth, the inclination and the radial distance) and automatically calculates these from the Cartesian coordinates the object already has. On each update of the point this calculation automatically takes place. Now the point also exists in a second coordinate system. Neat or not?

Other method types

There are a few other method types defined in the original concepts of NetworkedDesign (see my PhD thesis) which I will explain some other time.

As always, if you have any questions or comments, let me know. I am interested in hearing your feedback.


August 10, 2012 / jeroencoenders

Methods in NetworkedDesign (Part 2)

Methods in action

In the last post we covered the first Method type, Definition Methods, and we looked at how we could define Objects and Properties on these Objects through Methods. In this post, part 2, we continue to talk about other method types. We saw in the last post that a Definition Method can be used to add a definition (or multiple) to an object. By selecting a definition method and attaching an object the system assumes that the object can be defined by this method and the user can specify the exact details of this definition by expression of property values. These property values are attached to instances of the properties on the object that come with the method. We have also seen that these values can be primitives (number, text, etc) but also relationships to other properties or objects. In this way we are able to express inputs as a ‘derivative’ of inputs of other objects. Please note that it is up to the solver (explained in a later post) how these relationships are interpreted.

So, for now and simply speaking, we can say that definition methods add properties to an object and the user can specify the values of these properties. But what if we want the system to do something with these inputs? Or create an output on an object? That is where Calculation Methods come in.

Calculation Methods

Calculation methods are methods that do not take any input, but calculate an output based on properties of an object. For example a line in 3D space has a length we can calculate based on the coordinates of the start- and endpoint of the line. We would use the LengthCalculationMethod for this. How this length is calculated is specified in the code of the method. I will cover at a later stage how to manipulate this in posts about how the APIs of NetworkedDesign work and how you can define methods by coding. When you apply a Calculation Method the user has to specify the object it applies to. The method will check for the availability of properties it requires and will automatically create additional properties it calculates. It also creates relationships to the object. Every time the object gets updated (it’s properties), the calculation will rerun.

This was it for now. Next time, I’ll cover one more method type: Transformation Methods. If you have any questions, feel free to contact me.


August 5, 2012 / jeroencoenders

Methods in NetworkedDesign (Part 1)

Image 1: Methods

Today we will take a look at the concept of Methods in NetworkedDesign. In Part 1 of this post I will introduce methods in general and will zoom in on the definition method.


Methods add definition and actions to Objects. Objects without Methods are empty containers. Methods can be used to add Properties to the container as well as behavior (or actions) that modify Properties.

In this post (and the next few) I will only focus on the currently implemented method types as these are the most well-defined. Please note that NetworkedDesign actually support multiple methods on a single object as long as they are non-conflicting. This means that you can add as many methods as you like and need, but the names of the properties the method is adding to the object cannot be the same, because otherwise the system would not be able to figure out anymore what property you are referring to when you for example are pointing to property “point_1.X”.

In the image (Image 1) you can see a number of methods, these can be recognized by the boxes with rounded corners. Note that this might not be the same for all implementations of NetworkedDesign.

Definition Methods

Well, probably you already guessed it: Definition methods are methods that add definition to the object by adding a number of properties that the user can fill out (or choose to reference to a property on another object so that the system figures out the value). For example, in the example figure, we can see a “point_1” object which started out as an empty container object of the type “Point”. By adding a “definition_by_cartesian_coordinates” definition method, the point gets cartesian definition. In the property window figure (Image 2) we can see that this means that the user has to define a number of properties. First, the “definition” property which specifies to which object this method applies. In this case, we define “point_1”. (Note that the current implementation is a bit limited and not always optimized for usability. We could have actually automatically derived this property for example from the object we had selected on the graphical interface). Next we need to define a number of properties that come along with the cartesian definition: we need to supply a coordinate system to calculate the position against as well as the X, Y and Z components for the three directions which are double precision values. I will leave the other options on the property window interface for now. If we simply press the “Create” button, the method will be added to the model and the properties will be added to the object. Note that NetworkedDesign “detects” the relationship between the object and method in bright red (for specified relationships) and the relationship between the coordinate system object (“coordinate system_1”) and the point object (“point_1”) in dark red (for derived relationships).

Image 2: Property window

You might have noticed the type on the definition property in the figure: it says “Point or CoordinateSystem or Direction”. There is some trickery going on here. Methods “know” to which objects they can be applied and actually it can be multiple types. So, the method type “DefinitionByCartesianCoordinates” knows it can be applied to objects of the type “Point”, the type “CoordinateSystem” or the type “Direction”. If you specify another type, the system will complain and require you to modify it. As you will notice if you would develop for NetworkedDesign, this is a dynamic relationship that can be further expanded. So, for instance, if you create another object type that can also be defined by Cartesian coordinates, say a “Node”, it is possible in the API to specify this extension so that the method knows that it can also be applied to the object type “Node”.

Also note that you can specify primitive values (e.g. Doubles for the X, Y and Z coordinates) and object names as a property value. Object names create relationships to that object.

 In Image 1 another definition method is present: “definition_by_two_points_1”. This method works on the line “line_1” and you already guessed it, it defines the line by specifying two points: the begin and end point of the line. You might wonder why both these properties are referring to the same point (“point_1”). This is another piece of trickery called Replication which will be explained further in one of the next articles.

Other methods you see are of the Transformation Method type and Calculation Method type. These two method types will be covered in the coming articles.

Well, I hope that makes NetworkedDesign another step closer to being a bit clearer for everybody. If you have any questions and/or comments, feel free to post any.


June 30, 2012 / jeroencoenders

Properties in NetworkedDesign

As mentioned in my previous post in NetworkedDesign objects start out as empty containers. In this post we will look at properties of objects which ‘fill’ these containers.

Example of properties on an object

Properties are characteristics of objects with a key (name) and a value. For example, an object Point can have properties X, Y and Z which respective value 0, 0 and 1. Typically these values are primitives, such as booleans (true or false), strings of characters (“this is a string value), a whole number (integer) or floating point number (double).Properties can also be names of other objects which recreate a relationship to that object. That will be discussed in a later post.

Properties get added to objects by Methods, which will also be discussed in one of the later posts.

In NetworkedDesign it is important to understand that properties can be assigned by the user, by a relationship to another object or by a method.

In case of the example image we see an example of all: point_1 has a number of properties:

  • a CoordinateSystem: a relationship to another object named coordinatesystem_1. The user can created the relationship by typing the object name on creation of the object.
  • a X, Y, Z coordinate: each a user-assigned double of 50. Note the brackets behind the first 50. The first 50 is the value the user entered. The second value is the interpretation of the system.
  • a RadialDistance, Azimuth and Inclination: each doubles assigned by the transformation method transform_XYZ_to_spherical_1 which transforms objects defined by a Cartesian coordinate system to a spherical coordinate system and vice versa. Transformation methods will be discussed in later posts too.

In last thing to mention, but not further explain in this post, is that NetworkedDesign inherited a special trick called Replication from Robert Aish (as far as I know) introduced the concept. So, for those familiar with the concept, yes, we can use one object definition to define multiple sub-objects.

I hope you enjoyed this second post just as much as the first one. Again, if you have any questions, feel free to add a comment.


June 22, 2012 / jeroencoenders

Objects in NetworkedDesign

As I promised, I will gradually explain the concepts of NetworkedDesign on this site. If you have any questions or comments, feel free to use the comments section on this post.

Examples of NetworkedDesign objects

This first post discusses one of the most basic concepts NetworkedDesign contains: objects. NetworkedDesign largely follows the object-oriented paradigm (OOP) of modelling the world as objects which can have properties, relationships and behaviour. Objects can be inherit from parent objects, which means that they have the same properties, relationships and behavior. However, because NetworkedDesign is a bit different from a programming language, there are also some differences.

First of all, objects are initially empty containers. This means that they have a name and a type, and some other things the system can recognise them with, but nothing more. The user is now free to start defining the objects by applying methods to the objects with all properties and relationships to the object. Methods, properties, relationships, etc. will be discussed another time. This has some advantages:

  1. Objects in NetworkedDesign carry the minimal data and behaviour with them, which means that they are very lightweight and just have the things they need.
  2. Objects in NetworkedDesign can become anything the user would like them to be. So, if you want to derive your own special point type, you can simply add some additional methods and you have your point type. This is especially useful with you are e.g. working on data exchange between two different applications (interoperability). If one application defines a beam by two sets of x, y and z coordinates and the other application defines a beam by two points by the two sets plus a section shape, it is easy to build a BeamApp1 and BeamApp2 object which are slightly different and transfer the data between the two (will also be discussed at a later stage how you can do this).

Second, objects do not define their own behaviour. The methods take care of this. So, a line does not know its length until a LengthCalculationMethod has been added to object. Advantage is that the objects do not do any unnecessary calculation, which makes the system lightweight.

Third, objects have representations, actually as many as you like. Everything you see, including the graphical interface on the system, is a representation that defines how the object is shown and what interaction is allowed. You can easily activate and deactivate sets of representations to set up drawing your objects in different systems. In a later post I’ll explain more details about representations

These are some of the basics of the object concept in NetworkedDesign. I might get back to this topic once I have introduced more of the other concepts to you.

I hope you enjoyed this first post. Again, if you have any questions, feel free to add a comment.