Commonly received error messages


  • Errormessage: "Parametrization type not the same for all molecules. Please parametrize all molecules with same settings in DihedralParametrizer. Check 'parametrization_info' in spf files."
    • The dihedral_parametrizer module offers different options to generate customized internal forcefields. Each option requires a slightly different setup of the respective internal forcefield in Deposit. For performance reasons, the forcefield is initialized once at the beginning and not for each species separately, and the same type of force-field has to be used for all species. We therefore assert at the beginning of Deposit that all flexible molecules have been parametrized the same fashion. This error may therefore occur in a mixed morphology, if:
      • One molecule has been parametrized including the "optimize forcefield" function in the dihedral_parametrizer, and one without. Please only use molecules that have been parametrized with the same options.
      • One molecule (flexible) has been parametrized recently, whereas one spf file was generated with a previous version of the dihedral_parametrizer module. Please download the script below to update the old spf file.
      • Only one molecule was run through the new dihedral_parametrizer, while the other one is from the parametrizer (so a rigid molecule) generated with an older version. Please update the spf file of the rigid molecule with the script below.
    • The script to update the spf file is available this script. You can check which spf file needs to be updated by checking for an entry labeled "parametrization_info" in the top of the file. Usage of the script: " old.spf new.spf"
    • Note that new spf files containing the "parametrization_info" will initialize a different forcefield which is similar in functionality as the old one, but provides a speedup of X5 to X6.


  • QuantumPatch crashes without obvious error message: Check your shredder_mpi_stderr in the execution folder
  • QP error message: "QuantumPatch.QuantumPatchMain.QPMainGracefulExit: Wrong DFT Engine chosen for EAIP analysis. Exiting". Some calculations (i.e. EA, IP, CT) require specific engines, so not all engines-settings are supported. Please refer to the respective tutorials. Examples:
    • CT computation: This error may occur if you are not using a Turbomole engine for the last iteration in all shells. Either use TM engine throughout the full run, or set a "Last Iter engine" in shells where DFTB is used for charge equilibration.
  • QP does not converge in CT computation (EA/IP mode on host+dopand): In systems where charge transfer occurs, DFT runs may have trouble converging. In this case, we recommend to try using the M06-2X functional.
  • Couplings: Dimer computations crash for most pairs (see error files in runtime folder): This may occur for dimers where a charge transfer is possible, e.g. in doped injection layers. Here we recommend to use m06-2x for the core engine instead of BP.


If LightForge terminates in a parallel run, errors are printed in files named "date-time_rank_id.stderr", e.g. "2020-06-30-08-32-11_rank_2.stderr". Usually, multiple of these files are generated with the same content. If LightForge terminates unexpectedly but lightforge2.stderr is empty or does not generate any insight, check these files instead.

  • Lightforge run with explicit input for sites and energies (a file for COM and for energies was supplied in the device tab, no range expansion applied) crashed, with an error message "could not broadcast input array from shape X into shape Y": This may occur if only one type of particles is activated (e.g. for hole mobilities). Solution: Check all particle types (electrons, holes, excitons) in the general tab and set particle number of types you do NOT wish to simulate to 0 in the operations tab.
  • A LightForge mobility run terminates with an error similar to
    File "/home/nanomatch/nanomatch/V3/lightforge/lightforge/io/", line 53, in _get_qp_id
    qp_id = np.where(mol_names_output == settings.mat_uuid[mol_name])[0][0];
    index 0 is out of bounds for axis 0 with size 0

or Error during execution on node <localhost.localdomain> rank <2> Traceback: File "/scr/student/tmp/nanomatch/server/nanomatch/V3/lightforge/", line 68, in <module> main(args.load, args.replay, args.settings_file, args.morphology_only, args.num_iterations, args.collect_current_density, args.collect_density_plots_only,, args.analysis_autorun) index 0 is out of bounds for axis 0 with size 0

You may have provided the wrong pdb file in the materials tab, so the assignment of QP input does not work properly. Please assert that the pdb file in the materials tab corresponds to the molecule/morphology that was used to compute Disorder and Couplings with QP. 
  • LightForge terminates with an error similar to:

    insufficient data to compute transfer integrals in QP_output_0/Analysis/files_for_kmc/Js_homo_mol_pairs_0_0.dat

    This is the case when transfer integrals should be computed from QuantumPatch input, but the respective calculation of QuantumPatch did not have sufficient molecules of this type in the core shell. This may occur e.g. for guest host systems, especially at low guest concentrations. To solve this issue, either:

    • increase the core shell in the QuantumPatch calculation
    • run J computation in QP on a morphology with higher concentration or even a pristine guest morphology (note: only use this QP output then as input for guest-guest couplings)
    • use parametric coupling for guest-guest molecules (see e.g. here) under "Topology"
    • Dirty quick-fix (not recommended unless you are sure what you are doing) 1: Unpack the containing Js and in the folder Analysis/files_for_kmc copy e.g. Js_homo_mol_pairs_0_1.dat to Js_homo_mol_paris_0_0.dat. Only do this when you expect Js to have minor impact.
    • Dirty quick-fix (not recommended unless you are sure what you are doing) 2: Unpack the containing Js. In the folder Analysis/files_for_kmc open the file with too few data, e.g. Js_homo_mol_pairs_0_0.dat, and copy existing lines until a total of 20 lines or more is reached. Only do this when you expect Js to have minor impact.

The results of the search are