Representing Flow Networks (February 2016)

This webinar was presented by Jason Lillywhite in February 2016. Below is a brief summary and video recording of the presentation. You can also download materials used during the presentation by clicking on the link(s) at the end of the article.

GoldSim is often used to represent flow networks that involve dynamic controls and feedback loops. These networks might be impacted by discrete events and random behavior. There are different ways to represent a flow network in GoldSim. This article describes 2 common ways, which both have their strengths and weaknesses. It is recommended that you choose the style that suites your needs before completing your model.

Before actually building the GoldSim model, it is a good idea to develop your model requirements and conceptual framework. Once this is understood, you can move on to sketching the flow network schematic. Below is an example of a simple flow network, showing storage nodes (blue trapezoids), river nodes (blue squares), and demand sinks (red rectangles).

Flow Network Design Concepts

There are some concepts you should consider when designing and building a flow network in GoldSim.

Flow Drivers

What are the forces that drive flows in your network? Is there a demand for using water like an industrial consumer or irrigation user? Are you trying to maintain a water level in a tank or pond and need to turn a pump on in order to maintain that level? Is there water flowing down a river? Are there natural forces causing loss of water like evaporation and seepage? As you answer these questions, you can make notes on your flow schematic that will eventually provide critical information for the process of building the actual model.

Direction

From what direction are these flow drivers coming from? Some flow systems are simply driven by flows that start at 1 end and flow down through to the other end. Other times, the flow network is driven by demands that "pull" the water through the network from 1 or more sources. But most of the time, it is more complicated than this and the direction of such drivers come from both directions: the source and the demand. You might have water flowing in from sources and at the same time demands that are trying to pull water from the system. Make note of these drivers with labels of either source or sink.

Media Types

The examples described in this article are focused on water but it doesn't mean you can't model other types of media in your flow network. In fact, you might even have multiple types of media flowing through the network at the same time (i.e. water and sediment). You should consider the types of media you need to consider for your flow network and design it accordingly.

Contamination?

Is there contamination in the media that needs to be modeled? This is something that GoldSim is very capable of handling using a special module known as the Contaminant Transport (CT) module. 

Feedback Loops

Often times, you will find feedback loops within the flow network such as recycle streams, irrigation return flows, and effluent reuse. These are flow loops. Another type of feedback loop is the logical feedback, which is not necessarily representing flows of material moving in a circle but rather logic that affects an outcome that is a function of that outcome. A good example of this is a pump that turns on. A common way to handle a feedback loop is by passing the signal through a state variable like a reservoir. Another way to break the recursive loop is through a delay or previous value. Look at your flow schematic and determine the locations where you might need

How Should We Represent Flows in GoldSim?

There are at least 2 ways to represent flow networks in Goldsim.

Container Objects

The most common way is through the use of Containers, where each Container represents a flow node or object such as a tank, reservoir, junction, treatment plant, or pump station. The data, parameters, influences, and any drivers associated with a particular object are included within the container used to represent that object. For example, let's say you have a Container called "Tailings". Inside this container, you might have functions to define the geometric relationships along with pump controls and evaporation data. The influence lines shown in this view will include both logical influences and those that represent flows of media (like water). There is no difference in the way the 2 types of influence appear to the user.

Flow Elements

Another way to represent the flow network is by separating the logical functions and data from the flow elements. Using this approach, the emphasis is on the flow network where drivers, parameters, and data are separate from the visual representation of the flows. Many of the flow elements can refer to drivers located outside the flow network but all influence lines shown inside this view represent the flow of water (or other media). There is a strict separation between logical influence and the flow network but the 2 model components are interacting with each other at a higher level in the model.

Examples Showing Different Ways to Representation

The image on the left uses the Container Objects method while the one on the right uses the Flow Elements method. Both of these models produce the same result but the one on the right does not include much of the auxiliary logic at this level. Instead that information has been moved to a different location in the model.

If you navigate up a level from that view in both of these models, you will see that in the case of the Container Object method, the inputs drive the flow network as indicated by the unidirectional influence line. In this case, the flow network is located inside the container called "Water_Management_Model".

On the other hand, if you navigate up from the Flow Element method, you will see there is a second influence line coming back from the flow network to the inputs. This is because the flow drivers have been moved into the inputs and these are a function of the state of the flow network.

Below is another example comparing 2 versions of the same model side by side where the one on the left uses the Container Object method and the one on the right uses the Flow Element method. Both of these models produce the same outcome but the one on the right shows much more clearly the flow network while the one on the left shows the logical interaction between objects represented in this model.

Conclusions

As seen in the above examples, GoldSim does offer different ways to represent the flow network. It is up to you to choose how to organize it and should be based on your specific needs. The Container Objects method is object-oriented while the other is flow centric. The latter method separates the flow network from the functions that drive them and provides you with a straightforward view of the flows. Using the Flow Elements method it is easier to keep track of your mass balance because you can visualize the inflows and outflows. Also, if you strictly adhere to the method of only including flow elements, you will naturally account for all the inflows and outflows from the system. I have found this method to be more foolproof in regards to mass balance accounting. I also find that I'm less likely to duplicate outputs that refer to the state of the flow network because I can see them all in one place. For me, a huge advantage of the Flow Element method is that I can see where the water is moving in the network only by glancing at the page. I don't have to drill into each container or analyze the influence lines to see what is going on.

On the other hand, the benefit of using the Container Object method is that the functionality related to the object is contained within a single container instead of being spread throughout the higher levels of the model. 

I hope you find this article useful. Please feel free to leave a comment if you have any questions about my descriptions.

Download a video recording of a webinar presented on this topic here.

Download Example models: