Calculation tree visualization labels parameters as attributes

What happened, and what I expected instead

The Jupyter kernel's default tree visualization does not clearly render calculation parameters. For the calculation below, OpenSysML shows x and y as «attribute» nodes and renders the result as an unlabeled attribute node. The parameter direction and the result role are lost in the visualization.

This report concerns visualization only; it does not claim that parsing or calculation semantics are incorrect.

Reproduction

In a SysML Jupyter kernel, execute:

package A {
    private import ScalarValues::*;
    calc add {
        in x : Integer;
        in y : Integer;
        return : Integer;
        x + y
    }
}

Then render the calculation with the OpenSysML visualization command (for example, %viz A::add).

OpenSysML's output represents x and y as «attribute» and the result as a generic attribute node.

Comparison with the OMG Pilot

Running the same model and %viz A::add in the OMG SysML v2 Pilot produces a calculation box labeled «calculation» add, with x and y shown as input ports and result shown as an output port. This makes the calculation's parameters and result explicit. The pilot output is comparative implementation evidence, not the authority for the standard.

SysML graphical-notation reference

Compared against SysML 2.0, release 2026-08:

Section 7.19.2, Calculation Definitions and Usages (pp. 156–157) explains that directed usages declared in a calculation body are parameters and that a calculation has a result parameter.
Section 8.2.3.19, Calculations Graphical Notation (pp. 269–271) describes a calculation usage node with parameter positions (param-t*, param-l*, param-r*, param-b*), an action-flow view, and compartments including the result compartment.

These graphical-notation clauses are informative, so this is reported as a rendering discrepancy against the standard's described notation, not as a violation of a normative requirement. The rendered nodes should identify calculation inputs/results as parameters rather than generic attributes, and distinguish the result from other parameters.

This is a separate calculation-rendering case from #1532, which reports other tree visualization discrepancies.

fix(view): render calculations with the behaviour view and parameter …

Thanks for the precise report — confirmed, and the framing is right: this is a view-layer problem only.

Reproduced with your exact model on the latest release (v0.11.0) and on the current develop head. Both render A::add as a tree whose children are «attribute» x, «attribute» y and an unlabelled attribute for the anonymous return parameter; parsing and evaluation are unaffected (add(1, 2) → 3). So it is not a recent regression, it has always rendered this way.

Why. Two things combine:

The default view kind for a calculation is the tree. The renderer classifies states, actions and cases as behaviour renderings (with parameter pins), but not calc, so %viz falls back to the generic tree; asking for the action view explicitly is rejected ("not an action").
In the tree renderer, only port usages, case parameters and constraint parameters are pinned at the owner's border; directed parameters of a calculation (in/out/inout/return) fall through to the ordinary child path, where a keyword-less usage is labelled by its default kind — attribute — and the direction is never consulted. The pin infrastructure already knows how to map return/out/in/inout to output/input pins; it is just not reached for calcs.

Spec. §7.19.2 makes directed usages in a calc body parameters and gives every calc a result parameter (return = out). The informative notation in §8.2.3.19 renders a calc/calc def node as parameter pins around an action-flow view (param-l* action-flow-view param-r* …), optionally with a parameters compartment, which is the shape you expected and the pilot shows.

Scope is a bit wider than the report: a named result (calc def Add { … return r : Integer = x + y; }) renders as attribute r, calc usages typed by a calc def do the same, and action parameters show the same labels when a tree is forced on an action.

Fix (in progress, two PRs against develop):

directed calc parameters become labelled input/output parameter pins in tree renderings, with the anonymous result shown as result;
calculations are classified like actions for the default view, so %viz on a calc gives the behaviour rendering with its parameter pins, and the action view accepts calcs.

The behaviour rendering with parameter pins is what the pilot shows in your screenshot; our action view already draws action parameters that way, so the fix is to route calculations through it rather than to invent a new notation.

Merge pull request #1583 from Open-MBEE/fix/calc-default-behaviour-view

Sorry for the delay in response, but my agent did a pretty good job assessing, so I left it. Here's what was done, let me know if you have concerns:

fix(view): render calculations with the behaviour view and parameter pins by default #1583 - calculations are classified like actions for rendering: %viz on a calc (and --view=ACTION / #action:) now gives the action/calculation node form instead of falling back to the tree, and an anonymous return is drawn as the result out-pin. Parameter pins are drawn by default for calculations and actions (previously only under show=all / parameter-symbols); parameter-symbols remains as an additive option.
fix(view): render directed calc parameters as parameter pins in tree views #1584 - the tree renderer routes directed parameters (in / out / inout / return) of calc, action and constraint definitions and usages through the parameter-pin path instead of listing them as attribute children; inherited pins show as ^name.
feat(view): list an action's unconnected parameter pins in a parameters compartment #1598 - the Mermaid, D2 and PlantUML forms (Mermaid is what the Jupyter kernel displays first) list unconnected parameter pins in a parameters compartment rather than dropping them with a "pins not drawn" notice.

Your model on develop now renders, for %viz A::add:

calc add
  in x
  in y
  out result

and the Mermaid node the kernel emits is

«calc» add
parameters
in x
in y
out result

#tree:A::add gives the same three pins; calc def Add { ... return r } shows out r, and a usage calc c : Add under a part def shows its inherited pins as in ^x / in ^y / out ^r. Parsing and evaluation were never affected (add(1, 2) -> 3 before and after).

Should be included in our next release heading out the door shortly. Thank you for the report!

Thanks for the fixes in #1583, #1584 and #1598. On v0.12.0 (760c4d1), %viz A::add now produces a «calc» add node with x, y and result pins, so the original report is resolved. Two calculation-rendering issues remain:

1. Graphviz parameter pins are drawn inside the node, not on its border

The Graphviz/SVG output draws x, y and result as table cells in rows inside the rounded node. They do not appear on the calculation's border. §8.2.3.19 places parameters around the node (param-t*, param-l*, param-r*, param-b*), and the Pilot draws them on the border.

This looks like the action-kind route through the DOT writer:

ports.go:106 sets minimal only when Kind.SupportsPorts() is true, which covers only interconnection and mixed renderings.
That means pinned is false for an action/calc rendering. The node therefore goes through dotPortedLabel, which puts the ports in rows of the label table. It does not go through dotPinnedAttributes, which already draws squares on the box's outer edge.

Expected: calc/action parameter pins use the on-border form, as interconnection ports already do.

2. `declares no nodes` appears on a calculation whose body is an expression

The node includes the detail line declares no nodes in the Graphviz, Mermaid and text forms. The calculation is well formed: its body is the result expression x + y (§7.19.2), and it is not meant to contain an action flow. Readers may take the note as a model problem.

It comes from behavior.go:792, which adds the note to any top-level behavior rendering with an empty action graph. Since #1583, calculations reach that path too.

Expected: no declares no nodes note for a calculation, or at least for one with a result expression. Showing the result expression (for example, x + y in a result compartment) would fit §8.2.3.19 better, but omitting the note is the minimum fix.

Both points concern visualization only. Parsing and evaluation are unaffected. I checked develop (21 commits after v0.12.0), and neither point appears to have been addressed there.

Navigation Menu

Repository navigation

Calculation tree visualization labels parameters as attributes #1576

What happened, and what I expected instead

Reproduction

Comparison with the OMG Pilot

SysML graphical-notation reference

1. Graphviz parameter pins are drawn inside the node, not on its border

2. `declares no nodes` appears on a calculation whose body is an expression

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Calculation tree visualization labels parameters as attributes #1576

Description

What happened, and what I expected instead

Reproduction

Comparison with the OMG Pilot

SysML graphical-notation reference

Activity

devin-ai-integration commented on Oct 27, 2026

HuiJun commented on Oct 30, 2026

l-johnston commented on Nov 4, 2026

1. Graphviz parameter pins are drawn inside the node, not on its border

2. declares no nodes appears on a calculation whose body is an expression

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions

2. `declares no nodes` appears on a calculation whose body is an expression