Lesson 8 – Strategies for Managing Large, Complex Models

As you build larger and more complex models, it is possible that you may want to take advantage of several advanced GoldSim features that can help improve the computational efficiency of your model.  We will briefly discuss these in this Lesson.

The first is not actually specific to the Contaminant Transport Module (but is applicable to any large model). To understand this feature, we need to revisit something discussed in Unit 8, Lesson 3 of the Basic Course. In particular, it is important to understand that in order to correctly calculate the values for all the elements in a GoldSim model, GoldSim automatically analyzes the entire model to identify "who affects who" to ensure that the "upstream" elements are calculated prior to the "downstream" elements. This is referred to as the causality sequence. At each timestep the elements are updated in this causality-based sequence.

So why is this of importance for large, complex models? The reason is that the manner in which GoldSim goes about computing a causality sequence can be quite complex (particularly in cases where there are many feedback loops in the system). Computing this in a very large model (with many thousands of elements) can sometimes take a significant amount of time.  And whenever you edit an element, GoldSim needs to recompute the causality sequence.

If you find that it is becoming noticeably slow to edit your large model, this is an indication of a slow causality sequence calculation.  Fortunately, there is a way to address this in many cases.  You do so by breaking the causality sequence into separate pieces.  By doing so, when you edit you model, instead of having to re-sequence the entire model, GoldSim only needs to re-sequence the portion of the model where that element is located.

So how do you do this? You can break a model into separate causality sequences by breaking the model into SubSystems. The contents of a Container can be turned into a SubSystem using the properties dialog for the Container:

By checking the Treat as SubSystem box you can turn the contents of the Container into a SubSystem. 

SubSystems have their own causality sequence that does not extend outside of the Container. Computationally, you can think of a SubSystem as being “self-contained”. The SubSystem as a whole may rely on inputs from outside the SubSystem, and affect things outside the SubSystem, but in terms of the causality sequence for the entire model, the SubSystem is treated like a single element.  What this means is that if you edit something inside the SubSystem, only the causality sequence inside the Container needs to be updated.  Moreover, if you edit something outside of the SubSystem, the causality sequence inside the Container does not need to be updated. This can greatly speed up the re-sequencing process.

However, you may not always be able to turn a Container into a SubSystem.  In particular, there are two important limitations:

• Feedback loops cannot cross the SubSystem boundary. 
• Cell nets cannot cross the SubSystem boundary.

We will discuss the issue of breaking Cell nets below.  In many cases, however, you may not be able to easily break a feedback loop. What this means from a practical standpoint is that when creating SubSystems (to speed up re-sequencing), you should start from the top down.  That is, you should try to create SubSystems in the highest level Containers in your model and continue to work your way down (creating SubSystems) until it is no longer possible (due to feedback loops across Containers).

The issue discussed above impacts only the editing process for large models (large complex causality sequences can slow editing, and using SubSystems can speed this up).  This, however, has no noticeable impact on how fast the model actually runs (since the model needs to be sequenced only once, at the beginning of the simulation).

However, there is another issue that can significantly impact the simulation time for large complex Contaminant Transport models that is worth discussing. In Unit 6, Lesson 11 we discussed the concept of cell nets. In particular, Cells that are linked together via Coupled mass flux links are treated as a single computational entity (referred to as a Cell net). This is because the equations represented by Cells that are linked in this way are coupled equations that GoldSim solves simultaneously. The key point is that the computational effort to solve the coupled equations of a Cell net increases rapidly (i.e., not linearly) with the size of the Cell net.

What this means is that models with very large Cell nets can potentially run slowly. If the Cells are all linked via diffusive mass flux links, there is no action you can take.  However, you can take action if Cells in the Cell net are linked via advective mass flux links.  In this case, You can break a large Cell net into two or more smaller Cell nets by replacing a Coupled link with a Normal link (defining the link type was discussed in Unit 6, Lesson 11).

Cells that are connected using Normal links are not solved simultaneously; instead they are solved sequentially in series (like all other elements in GoldSim). That is, the mass is propagated asynchronously (i.e., the “upstream” pathway is solved first, followed by the “downstream” one).  Solving the Cells asynchronously (rather than in a coupled manner) does decrease the accuracy of  the solution to some degree.  For most systems, however, using Normal links in a model in several locations (as opposed to throughout the entire model) would be highly unlikely to affect the results in a noticeable way. More importantly, however, doing so (particularly for very large Cell nets) could significantly improve computational efficiency (i.e., reduce run times).

Similarly, when using Aquifer pathways, you should always using the smallest number of Cells that is capable of representing the specified dispersivity (recall from Unit 9, Lesson 4 that if the specified number of Cells is too small to represent the dispersivity, GoldSim will write a warning to the Run Log). Using more Cells than necessary results in a larger Cell net than necessary (and slower run times).