Onto codevelopment

[liamhuber]

This is the base PR for integrating ontological typing with pyiron_ontology. The ontology module is still under active development and not even available as a dependency on conda forge yet. This will stay as a draft until that dependency is available.

WARNING: the binder link will fail because the pyiron_ontology dependency is not yet listed!

Since the ontology module is still quite new, I'll be actively developing it together with ironflow until I'm satisfied enough to release it on conda. To get far enough along the ironflow development to really know what I even need from pyiron_ontology would make this a beast of a PR, so I'll use the stacked-PR paradigm again.

In this particular PR, I lay the most fundamental groundwork:

• [x] Introduce a new port field, otype, to track ontological typing
• [x] Add a new node for selecting material properties from the ontology, and convert input to generic units in output
• [x] Add available ontological typing to the Murnaghan node
• [x] (De)serialization working with otypes
• [x] Perform ontological validation for ontologically typed input ports (not output ports -- their output can be valid regardless of where it gets used downstream)
• [x] Add ontological typing to Lammps and BulkStructure nodes
• [x] Pass ontological conditions upstream for ontological validation of input connections

Note that for now I plan to keep all the type checking with the dtype. On the one hand, this makes node definitions a bit verbose, as both dtype and otype should be defined. On the other hand...

• I can imagine many places where a value could come from a typed port...or it could just come from, like, a np.linspace as user input. There is a field in the ontology for user input, so we could get fancy here at some point, but for now let's keep it simple and let users manually feed in data of the correct dtype if they want.
• Type checking also watches for batched/unbatched data conflicts, but in terms of ontological hinting it will be very useful to get node suggestions that ignore this since you can always index/batch those fields to change their effective batch status. So for the time being I want to keep separate the idea of using ontological typing for workflow construction hints and suggestions, and data typing for workflow connection requirements.

As of this PR, you can send Murnaghan output to the material property node and get it correctly converted to the generic units. When building up the graph, where both input and output are ontologically typed, input validation now also confirms that the ontological type being input matches the ontological conditions, and these conditions are collected by traversing the graph downstream and collecting all downstream conditions. Thus, in the simple graph below, the Lammps structure input is aware that it needs a bulk-like structure.

From here on out we'll make stacked PR's to handle the recommender system. Then hopefully merge and get a release based on a conda-forge version of pyiron_ontology, then extend everything to the surface energy use-case.

Edit: Stacked PRs (to be) merged in

• [x] Add a "recommended" nodes tab powered by the ontology
• [x] Highlight ontologically-valid ports within the graph
• [x] Add an example for ontologically-driven design of a bulk modulus workflow
• [x] Add ontological typing of projects
• [x] Add a slab surface creator
• [x] Add a surface energy node
• [x] Add an example for ontologically-driven design of a surface energy workflow
• [x] Sync dependency with a new version of pyiron_ontology
• [x] Update readme

[github-actions[bot]]

:point_left: Launch a binder notebook on branch _pyiron/ironflow/ontocodevelopment

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[liamhuber]

Updated everything here to pyiron_ontology-0.1.0.

Also updated the logic so that when I search for downstream conditions, only paths where both input and output are otyped actually shows up.

Had to drop the unit conversion, because that's not supported in the ontology library any more (at least for now), but everything else was a pretty straightforward conversion.

Happiest check was to set up the graph pictured above and see struct.outputs.ports.structure.get_downstream_requirements()[0].is_a change from [atomistics.Bulk, atomistics.ThreeD] to [atomistics.Structure] when we disconnect the Lammps node from CalcMurnhaghan (where struct is the BulkStructure node). (This ought to be included in the tests, but given the current developments over in pyiron_contrib between pyiron v1.0 and graph based workflows, I don't want to go overboard spending time on tests here right now...)

[review-notebook-app[bot]]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB