Sharing one parameter across relationships

October 16, 2026

A model often has the same physical quantity in several places. Two rooms in one building share the same insulation. The reserves leg and the liability leg of one lending facility have to move together. If each relationship carries its own copy of the number, changing one and forgetting the other produces a model that is wrong without looking wrong. A shared parameter is one value that any number of relationships and source terms can point to, so there is only one place to change it.

This page builds the smallest case: two rooms, each losing heat to the outside through its own relationship.

Two copies of the same number

Create three nodes, Room A and Room B at 20 degrees and Outside at 0, each with one state called Temperature. Connect Outside to each room with a relationship named Heat loss A and Heat loss B. Each one has a parameter, Heat loss rate (loss), and updates the room's temperature with this equation:

loss * (sourceTemperature - targetTemperature)

Give A's rate the value 0.2, and B's 0.05, deliberately different. Open the Parameters table from the title bar:

The Parameters table listing two Heat loss rate parameters, one per relationship
Two rows with the same name and symbol, each belonging to a different relationship, which is exactly how the two copies get out of step.

The table lists every parameter in the model in one place, with a search box, a filter for live, constant or tunable ones and a Belongs to column. It is also an editing surface: values, units and modes can be changed here without opening each relationship.

Turning one into a shared parameter

Open Heat loss A and look at its parameter. Next to its name and value is a Shared parameter menu, set to Not shared. Choose New shared parameter from this row…:

The relationship editor for Heat loss A, with the Shared parameter menu changed to the new shared parameter
The new shared parameter takes the row's name, symbol and value. The row now points at it instead of holding its own value.

That creates a shared parameter from this row, with its name, symbol, value and unit, and links the row to it. The row keeps its own name and symbol, since its equation refers to that symbol, but the value and mode now come from the shared definition.

Linking the other one

Open Heat loss B and open the same menu. It now lists the shared parameter by name and symbol. Choose it:

The relationship editor for Heat loss B, linked to the shared Heat loss rate, with an initial value of 0.2
B's own 0.05 is no longer used. The row shows the shared value of 0.2, and the shared parameter is what the engine reads.

B's row now shows 0.2. Its own 0.05 is not used any more, and nothing else in the relationship needed to change.

One row, two uses

Back in the Parameters table there is a single row for the pair:

The Parameters table showing one shared parameter, labeled Shared and used twice
The header reads 1 parameter and 1 shared. The Belongs to column says Shared and how many places use it.

The Shared label and the use count say how many relationships point at it. Change the value here, once, and both change. Run the model and the proof is on the canvas:

The result after ten seconds, with Room A and Room B at exactly the same temperature
Both rooms end at 2.70129, though B started with a different rate of its own. One shared value, one result.

Both rooms land on 2.70129 after 10 seconds, where B on its own would have cooled much more slowly.

What a shared parameter does for you later

  • Live control. A shared parameter can be live, and then one slider moves every place that uses it. During an online run, and when you fork a run as "Forking a run to try a what-if" describes, the change is addressed to the shared parameter, so the reserves leg and the liability leg of that lending facility cannot drift apart.
  • Fitting. If you fit a model to measured data, a shared parameter counts as one variable however many places use it, and the fit moves all of them together. The rows that link to it cannot be fitted themselves, because the shared definition owns the value.
  • A schedule. A shared parameter can carry a stored schedule instead of a constant: a table of times and values that it follows in every run, export and FMU, either interpolated between the samples or held at each value until the next. The table shows a summary of the schedule where the value would be, with a button to remove it. A scheduled parameter cannot also be a fitting target.
  • Unlinking. Choose Not shared on a row to give it a value of its own again.

Standalone code and FMU exports have no notion of sharing, so they use the shared value wherever it was linked.

Bundles do this for you

Some component libraries go a step further. A bundle is a ready-made group of relationships placed among several nodes in one step, with the parameters that must agree already shared between them. The Fintech toolbox's bundles share the parameters their legs must agree on, and the Logistics toolbox's shipment bundles wire a lane to both of its ends in one step. A model assembled from them does not ask you to keep matching numbers in step by hand.

Where to go from here

Shared parameters share a single value across otherwise unrelated relationships. "Subsystems and edge groups" covers the other kind of sharing, where one whole relationship is defined once and applied across a mesh of edges.

Follow Konjugate on LinkedIn for updates, or subscribe via RSS.

Comments