AbstractNode class is the basic class that represents all the possible objects at the AiiDA world. More precisely it is inherited by many classes including (among others) the
AbstractCalculation class, representing computations that convert data into a different form, the
AbstractCode class representing executables and file collections that are used by calculations and the
Data class which represents data that can be input or output of calculations.
A node can store information through attributes. Since AiiDA guarantees a certain level of provenance, these attributes become immutable as soon as the node is stored.
This means that as soon as a node is stored any attempt to alter its attributes, changing its value or deleting it altogether, shall be met with a raised exception.
Certain subclasses of nodes need to adapt this behavior however, as for example in the case of the
AbstractCalculation class (see calculation updatable attributes), but since the immutability
of stored nodes is a core concept of AiiDA, this behavior is nonetheless enforced on the node level. This guarantees that any subclasses of the Node class will respect this behavior unless it is explicitly overriden.
Methods & properties¶
In the sequel the most important methods and properties of the
AbstractNode class will be described.
Node subclasses organization¶
AbstractNode class has two important variables:
~aiida.orm.implementation.general.node.AbstractNode._plugin_type_stringcharacterizes the class of the object.
~aiida.orm.implementation.general.node.AbstractNode._query_type_stringcharacterizes the class and all its subclasses (by pointing to the package or Python file that contain the class).
The convention for all the
AbstractNode subclasses is that if a
class B is inherited by a
class A then there should be a package
aiida/orm that has a file
__init__.py and a
B.py in that directory (or a
B package with the corresponding
An example of this is the
ArrayData and the
ArrayData is placed in
KpointsData which inherits from
ArrayData is placed in
This is an implicit & quick way to check the inheritance of the
General purpose methods¶
__init__(): The initialization of the Node class can be done by not providing any attributes or by providing a DbNode as initialization. E.g.:
dbn = a_dbnode_object n = Node(dbnode=dbn.dbnode)
is_stored()informs whether a node is already stored to the database.
query()queries the database by filtering for the results for similar nodes (if the used object is a subclass of
AbstractNode) or with no filtering if it is a
AbstractNodeclass. Note that for this check
_plugin_type_stringshould be properly set.
get_computer()returns the computer associated to this node.
get_user()returns the user that created the node.
_increment_version_number_db(): increment the version number of the node on the DB. This happens when adding an
extrato the node. This method should not be called by the users.
copy()returns a not stored copy of the node with new UUID that can be edited directly.
uuid()returns the universally unique identifier (UUID) of the node.
pk()returns the principal key (ID) of the node.
dbnode()returns the corresponding Django object.
AbstractNode can be annotated with labels, description and comments. The following methods can be used for the management of these properties.
label()returns the label of the node. The setter method can be used for the update of the label.
_update_db_label_field()updates the label in the database. This is used by the setter method of the label.
description(): the description of the node (more detailed than the label). There is also a setter method.
_update_db_description_field(): update the node description in the database.
add_comment()adds a comment.
get_comments()returns a sorted list of the comments.
_get_dbcomments()is similar to
get_comments(), just the sorting changes.
_update_comment()updates the node comment. It can be done by
verdi comment update.
_remove_comment()removes the node comment. It can be done by
verdi comment remove.
Folder objects represent directories on the disk (virtual or not) where extra information for the node are stored. These folders can be temporary or permanent.
folder()returns the folder associated to the
get_folder_list()returns the list of files that are in the
pathsub-folder of the repository folder.
_repository_folder()returns the permanent repository folder.
pathsub-folder in the repository.
nodefolder in the temporary repository.
remove_path()removes a file/directory from the repository.
add_path()adds a file or directory to the repository folder.
get_abs_path()returns the absolute path of the repository folder.
Store & deletion¶
store_all()stores all the input
nodes, then it stores the current
nodeand in the end, it stores the cached input links.
_store_input_nodes()stores the input
_check_are_parents_stored()checks that the parents are stored.
_store_cached_input_links()stores the input links that are in memory.
store()method checks that the
nodedata is valid, then check if
node’s parents are stored, then moves the contents of the temporary folder to the repository folder and in the end, it stores in the database the information that are in the cache. The latter happens with a database transaction. In case this transaction fails, then the data transfered to the repository folder are moved back to the temporary folder.
__del__()deletes temporary folder and it should be called when an in-memory object is deleted.
DbNode is the Django class that corresponds to the
AbstractNode class allowing to store and retrieve the needed information from and to the database. Other classes extending the
AbstractNode class, like
AbstractCode use the
DbNode code too to interact with the database. The main methods are:
get_aiida_class()which returns the corresponding AiiDA class instance.
get_simple_name()which returns a string with the type of the class (by stripping the path before the class name).
attributes()which returns the all the attributes of the specific node as a dictionary.
extras()which returns all the extras of the specific node as a dictionary.
Folder and its subclasses to add an abstraction layer between the functions and methods working directly on the file-system and AiiDA. This is particularly useful when we want to easily change between different folder options (temporary, permanent etc) and storage options (plain local directories, compressed files, remote files & directories etc).
This is the main class of the available
Folder classes. Apart from the abstraction provided to the OS operations needed by AiiDA, one of its main features is that it can restrict all the available operations within a given folder limit. The available methods are:
mode_file()return the mode with which folders and files should be writable.
get_subfolder()returns the subfolder matching the given name
get_content_list()returns the contents matching a pattern.
insert_path()adds a file/folder to a specific location and
remove_path()removes a file/folder
get_abs_path()returns the absolute path of a file/folder under a given folder and
abspath()returns the absolute path of the folder.
create_symlink()creates a symlink pointing the given location inside the
create_file_from_filelike()creates a file from the given contents.
open()opens a file in the
folder_limit()returns the limit under which the creation of files/folders is restrained.
exists()returns true or false depending whether a folder exists or not.
isfile()and py:meth:~aiida.common.folders.Folder.isdir return true or false depending on the existence of the given file/folder.
replace_with_folder()copies/moves a given folder.
Objects of this class correspond to the repository folders. The
RepositoryFolder specific methods are:
__init__()initializes the object with the necessary folder names and limits.
get_topdir()returns the top directory.
section()returns the section to which the
folderbelongs. This can be for the moment a
subfolder()returns the subfolder within the section/uuid folder.
uuid()the UUID of the corresponding
AbstractCalculation class is a subclass of the
AbstractNode class, which means that its attributes become immutable once stored.
However, for a
Calculation to be runnable it needs to be stored, but that would mean that its state, which is stored in an attribute can no longer be updated.
To solve this issue the
Sealable mixin is introduced. This mixin can be used for subclasses of
Node that need to have updatable attributes even after the node has been stored in the database.
The mixin defines the
_updatable_attributes tuple, which defines the attributes that are considered to be mutable even when the node is stored.
It also allows the node to be sealed, after which even the updatable attributes become immutable.
Below you find an overview of the main classes in the AiiDA object-relational mapping.
For the complete API documentation see