You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 4, 2025. It is now read-only.
Copy file name to clipboardExpand all lines: README.md
+30-2Lines changed: 30 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,6 +18,10 @@ If there is a particular use-case you'd like to see, or if one of our nodes is n
18
18
19
19

20
20
21
+
In its current form, ironflow has some UI performance issues, especially when placing new nodes with many ports, or moving nodes around in a big graph.
22
+
(You can look at the movie demonstrating ontological typing below to get a sense of the delay for placing larger nodes.)
23
+
This is a [known issue](https://github.com/pyiron/ironflow/issues/143) and performance enhancements are currently our top priority -- both in terms of UI performance and underlying computations, e.g. we would like to exploit the latest pyiron developments for [running lammps without writing any files](https://github.com/pyiron/pyiron_lammps) in calculation nodes.
24
+
21
25
## Usage
22
26
23
27
The main gui can be imported directly from `ironflow`.
@@ -58,7 +62,7 @@ Ironflow is built on top of ryvencore 0.3.1.1.
58
62
There are a number of minor differences between ryven nodes and ironflow nodes discussed in the next section, but at a
59
63
high level there are two significant differences:
60
64
61
-
### Typing
65
+
### Data typing
62
66
63
67
All node ports are typed, and connection perform type-checking to ensure validity prior to establishing a connection.
64
68
By default, a special `Untyped` data type is used, which performs *all* validity checks by value, and thus does not allow pre-wiring of a graph without full data.
@@ -71,6 +75,29 @@ An output port can be connected to an input port as long as its valid classes ar
71
75
This type checking is still under development and may be somewhat brittle.
72
76
Our goal is to extend this system to be dynamically informed by an ontology on top of the graph: instead of statically insisting that input be of type `float`, we instead demand that the ontological type of the energy be `surface energy`_dynamically_ because the output value of that port is used, e.g., to calculate a grain boundary interface energy.
73
77
78
+
### Ontological typing
79
+
80
+
Nodes can also optionally carry an "ontological type" (otype).
81
+
Leaning on the [pyiron_ontology](https://github.com/pyiron/pyiron_ontology) library for representing knowledge in computational workflows, otypes give a rich _graph dependent_ representation of the data and facilitate guided workflow design.
82
+
This is fully demonstrated in the `bulk_modulus.ipynb` and `surface_energy.ipynb` notebooks, but a quick demo is also provided in the video below.
83
+
84
+
We see that there is a "recommended" tab for nodes.
85
+
After selecting this menu, clicking on the `CalcMurnaghan.engine` port populates the tab with nodes that have valid output for this port.
86
+
We can double-click to place the new node (`Lammps`) and repeat the process, e.g. for the `Lammps.structure` input.
87
+
Here we see there are two possibilities -- `BulkStructure` and `SlabStructure` -- and place both.
88
+
(Note, as mentioned at the head of the readme, there is some lag in ironflow right now; you can see this in the delay between the double-click and the placement of these larger nodes.)
89
+
Not only do we get recommendations for nodes to place in the graph, but we also get specific recommendations of which ports make valid connections!
90
+
Below we again select the `Lammps.structure` input port, and see that the output ports on both the structure nodes is highlighted.
91
+
Similarly, if we click the `Lammps.engine` output port, we see that all the valid input ports on our graph get highlighted; in this case, `CalcMurnaghan.input`.
92
+
Finally, we see the real power of otypes -- by connecting the two `engine` ports, the `Lammps` node now has access to the _ontological requirements_ of the `CalcMurnaghan` node!
93
+
In particular, `CalcMurnaghan` produces _bulk moduli_ and thus only works for calculations on _bulk structures_.
94
+
After these are connected, when we once again select the `Lammps.structure` input, _only_ the `BulkStructure` node gets highlighted, and _only_`BulkStructure` appears in the recommended nodes window.
Of course, not all ports in ironflow are otyped, and indeed not all should be -- e.g. it doesn't make sense to ontologically-type the output of the `Linspace` node, as it is just providing numbers which may be useful in many contexts.
99
+
However, for nodes which specifically produce and require physically-/ontologically-meaningful data, otyping is a powerful tool for understanding workflows and guiding their design.
100
+
74
101
### Batching
75
102
76
103
Many ports can be "batched" by selecting them to open the node controller window and pressing the "batched" button.
@@ -117,12 +144,13 @@ class My_Node(Node):
117
144
gui.register_node(My_Node)
118
145
```
119
146
120
-
Ironflow nodes differ from standard ryven (version 0.3.1.1) nodes in four ways:
147
+
Ironflow nodes differ from standard ryven (version 0.3.1.1) nodes in five ways:
121
148
- There is a new helper method `output` analogous to the existing `input` method that lets you more easily access output values, i.e. just a quality-of-life difference.
122
149
- Input/output ports and the port values are directly accessible as attributes *if* those ports were labeled, e.g. `node.inputs.ports.foo` or `node.outputs.values.bar`.
123
150
- They have a `representation` dictionary, which is used by the IPython gui front-end to give a richer look at nodes. By default, this includes all the outputs and the source code for the node, but you can append to or overwrite these values by specifying an `extra_representations` dictionary on your custom nodes.
124
151
- They have two new events: `before_update` and `after_update`, to which you can connect (e.g. `node.after_update.connect`) or disconnect (`...disconnect`) methods to fire before and/or after updates occur -- such methods must take the node instance itself as the first argument, and the canonical input integer (specifying which input value it is that's updating) as the second argument. (You can see an example of this in our base `Node` class, where we use it to force an update of the `representation` attribute after each node update.)
125
152
- It is strongly advised to specify a `dtype` for each of your nodes from among `node_tools.dtypes`.
153
+
- Ports have an additional `otype` field to facilitate ontologically-informed port and node suggestions.
126
154
127
155
Otherwise, they are just standard ryven nodes, and all the ryven documentation applies.
0 commit comments