RuNNer¶

Dependencies¶

Module Variables¶

• data_loader : type(FileDataLoader)
• models : type(ModelPtr) (dim: (:,:))– List of all trainable models that predict physical properties. Depending on the generation and requested workflow, we often initialize more than a single model. For example, a 3G-HDNNP consists of a short-range `HDNN` and an electrostatic `HDNN`. This `num_models` is the second dimension of the array. The first dimension of the array holds all members of the ensemble/committee for one model type in the second dimension. Committees are used as a practical tool of uncertainty quantification. Crucially, committee members share their input features, which makes evaluation very efficient. Committee members must always be evaluated with the same feature vector. In general, models are separate entities that can be updated and evaluated independently of one another. However, having one array containing all models is very practical. It allows us to call procedures that operate on all models (e.g. parameter initialization). Nevertheless, it is important to note that the members of `models` may all be in very different states at any given point in the code. Accessing the second dimension of this list should be done via the `*_model_idx` variable stored on the `global_settings` object (e.g. `short_model_idx`). Dimensions: (num_committee_members, num_models)
• optimizers : type(OptimizerPtr) (dim: (:,:))– List of all optimizers (like Kalman filter, Adam, etc). that update the parameters of `models`. The second dimension of this array is the total number of optimizers that have been requested by the user. The first dimension of the array is the number of committee members. While committee members share many properties, most importantely their input features, the can be updated by different optimizers, if so requested by the user. During initialization, each optimizer will store the index of the committee member to which it has been assigned. Dimension: (num_committee_members, num_optimizers).
• loss_functions : type(LossFunctionPtr) (dim: (:))– List of all loss functions that were requested by the user. Loss functions are used to calculate the training loss. This is the difference between model predictions and reference values for a batch of samples taken from the training dataset. The loss and its gradient are then used to update the parameters of a machine-learning model. Loss functions are always requested for an optimizer. The objects in `optimizers` store their `loss_function_type`. If all optimizers share the same loss function (as is often the case), the length of this array will be one.
• cost_functions : type(LossFunctionPtr) (dim: (:))– List of all cost functions requested by the user. The training cost is an error metric measuring the difference between model predictions and reference values across the entire training and testing datasets. As it employs the same mathematical functions as loss calculation (RMSE, MAE, etc.), it uses the same type as the `loss_functions`. Nevertheless, `cost_functions` are never used during training to update the model parameters. They only report back the current training accracy at the end of an epoch. Users may request multiple cost functions in the input.nn file, which directly corresponds to the length of this array. All requested cost values are calculated at the end of an epoch and reported back. The first requested cost function is also used to dynamically filter which samples are used for a parameter update (by comparing to the loss function value for the current optimizer). Therefore, it is always advisable to match loss functions and the first cost function (they should have the same unit).
• feature_calculators : type(FeatureCalculator) (dim: (:))– List of all feature calculators required by the `models`. They orchestrate the calculation of feature vectors and their derivatives for atomic environments, which serve as the input to machine-learning `models`. [RuNNer(program):models] may share feature calculators (if `feature_map_default` is used as an input.nn argument by the user, in which case this list only contains a single object. Otherwise, it will contain one object per model. The list may also contain an additional empty feature calculator that is used as a dummy for models which do not require input features.
• qeq_feature_calculators : type(QEqFeatureCalculator) (dim: (:))
• ee4g_feature_calculators : type(EE4GFeatureCalculator) (dim: (:))
• elec_calc : class(AbstractElectrostaticsCalculator)
• vdw_calc : class(HirshfeldVdwCalculator)
• two_body_calc : class(TwoBodyCalculator)
• cutoff_functions : type(CutoffFunctionPtr) (dim: (:))– List of all cutoff functions specified by the user. Smooth cutoff functions are used for constructing neighbor lists and make sure that we have well-defined local atomic environments. In principle, users can request an arbitrary number of cutoff functions. They are mapped to the feature maps in the various feature calculators through their cutoff function index, which corresponds to their position in this list.
• qeq_solver : class(AbstractChargeEquilibrator)
• max_cutoff : real(DP)
• cutoff : real(DP)
• ifc : integer
• icomm : integer
• imodel : integer