-
Notifications
You must be signed in to change notification settings - Fork 227
Adding documentation on link types #1174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from 5 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
acfc5e0
Adding documentation on link types
szoupanos 936b1c0
Merge branch 'develop' into links_doc
szoupanos 618d086
Minor correction
szoupanos 4b47cc5
Merge branch 'links_doc' of github.com:szoupanos/aiida_core into link…
szoupanos 5607958
More clarifications
szoupanos a70113e
Merge branch 'develop' into links_doc
giovannipizzi File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,71 @@ | ||
Node classes | ||
------------ | ||
There are two *Node* sub-classes, *Data* and *Calculation*. The *Code* nodes | ||
can be considered as sub-classes of *Data* nodes. *JobCalculations*, | ||
*InlineCalulations* and the *WorkCalculations* are subclasses of the | ||
*Calculation* class. | ||
|
||
AiIDA graph | ||
----------- | ||
The AiIDA graph is a `directed graph <https://en.wikipedia.org/wiki/Directed_graph>`_. | ||
The links of the graph are arrows connecting two nodes. An arrow (x, y) is | ||
considered to be directed from x to y; y is called the **head** and x is called | ||
the **tail** of the arrow; y is said to be a **direct successor** of x and x | ||
is said to be a **direct predecessor** of y. If a path leads from x to y, then | ||
y is said to be a **successor** of x and reachable from x, and x is said to be a | ||
**predecessor** of y. The arrow (y, x) is called the inverted arrow of (x, y). | ||
|
||
AiiDA links | ||
----------- | ||
The following table summarises the available AiiDA links and their properties. | ||
Each line of the table corresponds to a different link, it mentions the tail | ||
of the arrow (from column), the head of the arrow (to column) and finally | ||
the constraints that are related to the label of the link and the nodes involved. | ||
|
||
========= =================== ================= ========================================== | ||
Link type Tail of link (from) Head of link (to) Unique condition (combinations that should | ||
be unique in the link table) | ||
========= =================== ================= ========================================== | ||
INPUT Data Calculation (head Calculation node, link label) | ||
CREATE Calculation Data (head Data node) | ||
RETURN Calculation Data (tail Calculation node, label) | ||
CALL Calculation Calculation (head Calculation node) | ||
========= =================== ================= ========================================== | ||
|
||
|
||
There are four different links available: **INPUT**, **CREATE**, **RETURN** | ||
and **CALL**. | ||
|
||
* The **INPUT** link is always from a *Data* node (tail of the link) to | ||
a *Calculation* node (head of the link). The unique constraint means that | ||
each *Calculation* node can have only one input *Data* node with given label | ||
(i.e., a calculation cannot accept two inputs with the same label). | ||
|
||
* The **CREATE** link is always from a *Calculation* node (tail of the link) | ||
to a *Data* node (head of the link). The unique constraint means that each | ||
*Data* node can be created by one and only one *Calculation* node. | ||
|
||
* The **RETURN** link is always from a *Calculation* node (tail of the link) | ||
to a *Data* node (head of the link). The unique constraint means that a | ||
*Calculation* cannot return two or more *Data* nodes with the same label. Code | ||
implementation detail: For the moment there is always and only a **CREATE** | ||
link from a *JobCalculation* to the generated *Data*. A **RETURN** link is | ||
implied with the conditions of a **RETURN** link (the implementation will be | ||
corrected to comply shortly). | ||
|
||
* The **CALL** link is always from a *Calculation* to another *Calculation* | ||
node. A given *Calculation* node cannot be called by more than one | ||
*Calculation* node. In practice, the caller cannot be a *JobCalculation* but | ||
it is always a *WorkCalculation*. Instead called calculations can be of any | ||
subclass of *Calculation*. | ||
|
||
Graph navigation | ||
---------------- | ||
The links can be followed in both possible directions (forward & reverse) using | ||
the QueryBuilder. This requires to define additional “names” for each direction | ||
of the link, and they are documented at the | ||
:doc:`QueryBuilder section <../querying/querybuilder/usage>`. For example, | ||
if there is an **INPUT** link from data D to calculation C, D is the | ||
“input_of” C, or equivalently D is the “output_of” C. Currently, in the | ||
QueryBuilder, input_of and output_of refer to any link type, where C is the | ||
head of the arrow and D is the tail. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if we want to add the discussion on direct successor or predecessor, it is not needed for this page, and I think it introduces a new "language" that we never use elsewhere...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's true. I had the same feeling and I mainly added it because I need it for the discussion on the export that will follow (and it would be late to be mentioned at that point).
As a general comment, I would say that it would be good to follow (or start following?) the terminology of the domain that we focus on. E.g. for the moment we use input/output and ancestor/descendant that seemed natural to us (at least this is my understanding). For trees, which are DAGS, it is used parent/child & ancestor/descendant to refer to the same relationships. At https://en.wikipedia.org/wiki/Directed_graph where they talk about directed graphs (which is what we have now) they talk about (direct/indirect) predecessor /successors.