Silico enables multiple levels of managing complexity as your project grows, from small through to large modelling challenges, captured in the structure of your project. This article aims to go through how the different ways to structure your project relate to one another.

The entrypoint to your project is the Main model, created automatically when you first create a project, and within that model a root Panel. By default, the main model will be given the same name as the Project, and by convention the name of the root panel is the same as the model it is contained within.

The default layout for a new project, showing the project name in the header bar, and the main model in the sidebar. Selecting the model also navigates to its root panel, shown on the right.

Panels

Panels enable the model to be split up across multiple different areas, which can be arranged into a hierarchy. This aims to help reduce the number of different elements in one place, as well as to enable the modeller to logically group different parts of a model together. In addition, names of elements within a panel are 'namespaced' to that panel, so you can use the same name in different panels, for instance the Profit of two different business areas.

Panels are created in the workspace on the right as elements, and can then be navigated into by double-clicking on the element, or using the project structure navigator on the left.

The project with two panels added to the root of the main model, and navigated into the "Unit B" panel.

Referencing Elements

Ordinarily you can use reference another element by using its name, e.g. "Revenue". You can reference an element in another panel by placing the panel name before it, with an arrow, e.g. "Unit B"->"Revenue". Note that although panels themselves are arranged hierarchically, panel names themselves are unique across a model, and so can be used without worrying where another panel is in relation to where it is being used. For instance, the above reference "Unit B"->"Revenue" would work when within the Unit A panel, even though Unit B isn't a panel within Unit A.

Referencing the Root Panel

When you need to refer to an element in the root panel from another panel, you can use the model name as the panel name, e.g. in the above example "Fresh Project"->"Variable" would refer to a variable in the root of the Fresh Project model.

See the Referencing Elements section in the Formulae article for more detail.

Modules and Submodels

In more advanced use cases, it is useful to be able to duplicate parts of a model, and parameterise them separately. This can be done by adding additional modules to the project.

Main, Models and Modules

Although very related, these three terms are used carefully as they relate to Silico, as they can be quite different concepts.

Model refers to a named hierarchical collection of panels
Main refers to the entrypoint model of the project
Module refers to any model within a project which is not the Main model

Note that when talking about 'building a model', we are usually referring to the main model of the project, being the logical 'whole' model which is representing some system, with the additional modules being useful components of that whole.

Submodel Instances

You can create a new module using the + icon within the Project Structure navigator bar. This will create another module within the project, which can be interacted with much like the main model. However you cannot refer to the elements within this module from your main model, what you must do is create an instance of the module by using a submodel.

A Project with a module 'Secondary Module' created, itself with a panel within. The navigator on the left has been expanded to show all the levels. Note that you can navigate into a Submodels' panels just as you would any other structure.

You can parameterise each instance of a module separately, for example in the above shots the 'Profit' variable shown in the module could be changed in different submodel instances, perhaps to represent different regions, business units, or other modular part of the system.

When to use Panels or Modules + Submodels?

Both panels are modules with submodels allow you to break a larger project up into smaller, more understandable pieces, allowing names to be safely used in different contexts without clashing with existing names.

The main question to answer when deciding which to use is whether the piece of the system you are representing would be duplicated. If not, then panels are the simpler and easier to use feature for organising your project, and should be the first thing to try. If you are representing very different departments, e.g. projects flowing through Project Management and finances through Accounting, then these likely have very different structures, and make sense as panels.

Examples of where duplication is useful are when you want to build an abstract representation of a part of the system, and then create multiple copies which are given different parameterisations. For instance, if you have a franchise restaurant and want to represent the finances of each location separately, then you could have a 'Franchise Finances' module, instantiated into the main model as 'Location A', 'Location B', and so forth.