3.30 Real-Time and Imaginary-Time TDDFT
Real-time time-dependent density functional theory simulations in FHI-aims were pioneered by Joscha Hekele and Peter Kratzer and described in a first arXiv publication [132].
A complete journal publication (Ref. [133]) also covers imaginary-time time-dependent density functional theory and provides specific guidance and benchmarks regarding basis sets. Please cite Ref. [133] when using the current RT- or IT-TDDFT implementation in FHI-aims.
Currently, one can do RT-TDDFT simulations for finite and periodic systems, including Ehrenfest dynamics for both cases. All modes of parallelism are supported.
In Ref. [133], the following qualitative guidance regarding basis sets is substantiated:
-
•
For light-element molecules (not periodic), the “tier2+aug2” basis sets appear to be a good choice (more specifically, the “tight+aug2” prescription is constructed and used).
-
•
For periodic systems, the FHI-aims “light”, “intermediate” and “tight” basis sets are used successfully, presumably because of the overall higher density of non-zero basis functions (overlapping from different atoms) in a periodic structure, which makes for a more complete basis set.
The current implementation incorporates a large set of control keywords of which only the most important are noted here. Several keywords controlling debugging/development features are not captured here but can be found in the code. Please contact us if you want to learn more about this.
This functionality was tested thoroughly, but there is always a possibility for remaining bugs or inconsistencies. If you have any questions regarding usage and/or functionality, if you encouter problems/bugs, or if you have suggestions - please contact us (peter.kratzer@uni-due.de or one of the other authors).
Theory
Basic Principles
Real-Time TDDFT - as the name suggests - calculates the response of a Kohn-Sham system in real time. The time-dependent Kohn-Sham equation
| (3.110) |
is solved and describes the time-evolution of the electronic wave function . The Hamiltonian has an explicit
time-dependence in this case, e.g. by an external electric field and/or a time-dependent external ionic potential.
In contrast to the linear response approach, real-time TDDFT is able to capture the whole nonlinear characteristic of the
given system in real time. Possible applications include absorption spectrum calculations based on the dynamical dipole response,
high-harmonic generation simulations or ion bombardment simulations based on non-adiabatically coupled electron-ion dynamics
(Ehrenfest dynamics). Please see [212] for a comprehensive review.
Real-Time Propagation in FHI-aims
What is actually done is the time propagation of the atomic basis function coefficients from the LCAO ansatz
The coefficients are expressed as a matrix by considering all (occupied) states and basis indices: . The time-dependent KS matrix equation to be solved is then
where is the overlap matrix and
is the Hamiltonian matrix. The efficient and accurate solution of this equation is the key mechanic in a real-time TDDFT implementation. Note that
very large basis sets will lead to an ill-conditioned overlap matrix, causing to be a problematic object, yielding entirely wrong results or blow-up.
The time-dependence of the Hamiltonian is implicit via the time-dependent density and explicit by the possible dependence
on an external field, e.g. a laser or a dynamical ionic potential. An external electric field can here be incorporated via
where the dipole approximation – neglecting any spatial dependence of the electric field – is used. Electric field and vector potential are connected by the relation . Both gauges are physically equivalent but have different technical implications. In this implementation, only the velocity gauge can be applied in case of periodic systems. We note here that the (atomic ZORA) relativistic kinetic operator is currently not considered in the expression for the velocity gauge but that is on the to-do list (it can nevertheless be used). Scaled ZORA can not be applied.
Ehrenfest Dynamics
In Ehrenfest dynamics, non-adiabatically coupled motion between the electronic and ionic subsystems is simulated. Mobile atoms and thus mobile basis functions lead to a modified differential equation for the electrons,
where the matrix describes the time-dependence of the atomic basis functions and effectively conserves the norm of the time-propagated wavefunctions.
Furthermore, the forces on the nuclei are complemented by specific non-adiabatic contributions,
where are the standard Hellmann-Feynman forces, are multipole force contributions and are XC related forces, e.g. GGA. The force term
stands for "Dynamical Basis Correction" and can be seen as the time-dependent analogue to Pulay forces. The last term is denoted as the nonadiabatic coupling force, possibly consisting of two terms:
Including the full above-mentioned expression guarantees full energy- and momentum conservation, but usually only incorporating is sufficient and noticeably cheaper. The energy-conserving force term can be written as
The remaining force term restoring momentum conservation is given as
The integration of the nuclear equations of motion is performed via a Velocity Verlet based algorithm, i.e.,
where is the corresponding Ehrenfest time stepping. Based on each coordinate change, a geometry update is performed. Please see [183, 235] for further details.
Observables
Depending on what task has to be performed, different physical observables are of interest in a RT-TDDFT simulation. The computation of the most important ones is briefly explained here. These are also computed and sent to output by default.
-
•
Electronic energy: The time-dependent electronic energy for the current time step is computed via
where the adiabatic approximation is used, i.e., the instantaneous density is employed to evaluate the functionals (this is indicated by the ad superscript). The electronic energy is not necessarily a conserved quantity, e.g. when energy is absorbed from an external field.
-
•
Total electronic and nuclear kinetic energy: In case when Ehrenfest dynamics is performed, the nuclear kinetic energy contribution to the total energy has to be taken into account, i.e.
In the absence of external fields, this quantity must be conserved.
-
•
Electronic dipole moment: Important quantities that can be computed from the dynamical electronic dipole response are the polarisability and absorption strength :
The electronic dipole moment is by default computed for cluster systems. One can also compute tranisition dipole moments which are obtained by projection onto the ground state Kohn-Sham orbitals [46].
-
•
Electronic current: From the current density , one can compute the conductivity and the dielectric function via the total current :
-
•
Trajectories: In case of Ehrenfest dynamics, trajectories are written to .xyz file/s.
Please note that a python-based post-processing tool named eval_tddft.py is located in the utilities/rt-tddft folder which is made for RT-TDDFT output files. It can currently compute, visualize and write the absorption strength function/polarisability (by input electronic dipole and external field) and also the conductivity/dielectric function (by input electronic current and external field) with possibly more functionality to come.
Important Notes
Some general important remarks regarding different topics are given here. Please also pay attention to this.
-
•
Exchange-Correlation: Due to technical and/or formal limitations, not all available XC functionals can be used. We tested for LDA- and GGA-based functionals which should work fine. Other choices were not tested or are in development process and the code will stop for unreasonable settings. Hybrid functionals like B3LYP can be used for finite systems. This also applies for the long-range corrected LC-PBE functional.
-
•
Compatibility: We tested our software for Intel-based parallelization together with the MKL numerical linear algebra library, and for GNU OpenMPI-based parallelization together with the numerical linear algebra libraries ScaLAPACK/OpenBLAS (versions 2019 / 2020). It seems like there exists a bug in the recent MKL versions (Intel Parallel Studio XE 2019 / 2020) that affects the linear equation solver subroutines pzgetrs and pzgesv, causing memory leakage at every call, resulting in excessive memory usage by the code. This was not observed with the non-Intel framework. These operations are conducted when the Crank-Nicolson propagator is used or when the scaling and squaring method for matrix exponentials is employed. We implemented a fix that will result in the code using explicit inversion instead of solving a linear system, i.e.:
(3.111) (3.112) For this, the user has to provide the flag
-
RT_TDDFT_crank_nicolson_solve_inv .true.
in the control.in file.
-
Tags for general section of control.in
Core Settings
Tag: RT_TDDFT_input_units(control.in)
Usage: RT_TDDFT_input_units units
units: String that specifies in which unit system the input is given. If atomic, the remaining parameters
are read in atomic units, if spec, the remaining parameters are read in as what we call spectroscopic (see table below).
This setting affects every physical input quantity given such that one has to pay attention to the consistent use of units. The following table depicts possible unit sets.
| Quantity | atomic | spec | Example |
|---|---|---|---|
| Time | fs | Sim. time, steppings, pulse center/width | |
| Frequency | fs-1 | Ext. field frequency | |
| Electric field | eV/Å | – |
Quite ’typical’ values for time steppings are 0.1 a.u. fs or for electric field amplitudes
0.01 a.u. eV/Å (in the perturbative regime).
This keyword must be set by the user or the code will not run which is intended to prevent unit confusions.
Tag: RT_TDDFT_propagation(control.in)
Usage: RT_TDDFT_propagation t_tot dt_prop dt_output
Purpose: Performing a real-time TDDFT simulation.
t_tot: Total simulation time for which the time-propagation will be performed.
dt_prop: Time step which will be used.
dt_output: Time step for which output like energy, dipole, etc. is sent to standard output and is written to file/s.
The choice of the time step heavily affects the accuracy and stability of the time-propagation and is restricted by internal or external degrees of freedom, e.g., the spectral range of the Hamiltonian or the frequency of an external field oscillation. Generally, a small time step yields better results but significantly increases the computation time. The possible time step also depends on the propagation scheme which is explained later. A conservative choice is dt_prop ) but a.u. to a.u. might also be possible. Remember using consistent units set by the RT_TDDFT_input_units keyword. Note that the time step is also a convergence parameter for spectral information.
Tag: RT_TDDFT_td_field_gauge(control.in)
Usage: RT_TDDFT_td_field_gauge gauge
Purpose: Setting the gauge for a possible external field (in the dipole approximation).
gauge: String. The field can be applied either in length gauge (electric field) or velocity
gauge (vector potential). Default: length for cluster systems, velocity for periodic systems.
While this makes no difference formally, it has some technical implications. When doing periodic simulations, only the velocity gauge can be used. In the cluster case, the length gauge should be used because it is computationally cheaper. However, the formal gauge invariance is broken in any numerical approximation and it is likely possible that basis set and/or real-space grid settings converge differently for length and velocity gauge.
Note that the gauge is a universal setting for each individual RT-TDDFT simulation and applies to all fields specified.
Tag: RT_TDDFT_td_field(control.in)
Usage: RT_TDDFT_td_field t_start t_end type
freq cycle center width Ex Ey Ez
Purpose: Setting the type and shape of a possible external field (in the dipole approximation).
t_start: Start time after which the field is evaluated.
t_end: End time before which the field is evaluated ( infinite).
type: Integer that defines the field type as in rt_tddft_external_field.f90. Possible choices are defined below.
freq: Frequency if applicable (see type).
cycle: Cycle if applicable (see type).
center: Center if applicable (see type).
width: Width if applicable (see type).
Ex, Ey, Ez: Electric field amplitudes.
The choice of the external field depends on the type of calculation that one wants to perform. To obtain an absorption spectrum
via the dynamical electronic dipole response, a delta-kick field can be applied by, e.g., setting type = 2,
center, width and Ez to some values which will apply a Gaussian pulse of given amplitude at center
time/width and along the z-axis. width should then be chosen quite small, e.g., to 0.05 fs. Alternatively, one can provide a constant field for the first time step, which saves computation time and provides a sharp pulse naturally. This would be type = 1 and t_end = dt.
To apply a field pulse with a defined wavelength, one can, e.g., set type = 3, freq, cycle,
Ez which will result in a modulated Gaussian pulse of given wavelength around center time.
Multiple instances of this keyword with different settings can be given, e.g., to apply multiple different pulses over time.
Internally, all defined fields are simply added up, so pay attention to temporal localization (if intended).
For all field types, the length and velocity gauge implementation are related by .
Note that the field amplitudes are always given as the amplitudes of the electric field, even in the case when the velocity
gauge is used (see RT_TDDFT_td_field_gauge).
Currently, the following field types are implemented:
-
•
0: No field at all. This is the default when RT_TDDFT_td_field is not specified.
-
•
1: Constant Electric field.
-
•
2: Delta kick pulse via Gaussian:
-
•
3: Localized field oscillation via modulated Gaussian:
with , .
-
•
4: Sinusoidal field with reference frequency:
-
•
5: Sin2 envelope pulse:
-
•
6: Ramp Electric field:
-
•
7: Delta kick Electric field via Lorentzian:
-
•
8: Constant Vector Potenital:
where t_start, and freq, cycle, center,
width, t_end, and . Parameters not occurring in a function definition are not referenced and
can be set to any value.
Note that user-defined fields can easily be included in the corresponding subroutine src/rt-tddft/src/rt_tddft_ext_field.f90.
Remember using consistent units set by the RT_TDDFT_input_units keyword.
Tag: RT_td_field_spin_set(control.in)
Usage: RT_td_field_spin_set spin
Purpose: Setting this will result in the external field only being applied to spin = 1 or 2 eigenvectors.
spin: Integer that specifies the spin component.
If this setting is specified for a collinear calculation (see keyword spin in the FHI-aims manual), only the spin spin time-dependent eigenvectors will be excited by the specific external field. This may, e.g., be used to model triplet excitations.
Tag: RT_TDDFT_propagator(control.in)
Usage: RT_TDDFT_propagator propagator
Purpose: Setting the propagation scheme used in RT-TDDFT.
propagator: String that defines the numerical integration scheme. See below for possible options. Default:
crank_nicolson.
The possible integration schemes are (see, e.g., [111, 53, 17]) :
-
•
exponential_midpoint (EM):
-
•
crank_nicolson (CN): The order can be set via the keyword
RT_TDDFT_crank_nicolson_order order. -
•
etrs (Enforced Time-Reversal Symmetry):
-
•
cfm4 (Commutator-Free Magnus Expansion 4):
-
•
m4 (Magnus Expansion 4):
-
•
runge_kutta_4: Standard explicit Runge-Kutta 4 scheme. Works only for very small time steps but is a good choice for doing accurate reference simulations because its properties are well-known.
-
•
parallel_transport_cn: Crank-Nicolson integration scheme within the parallel transport approach [158]. This requires the accelerated Anderson solver, see RT_TDDFT_propagator_solver. [EXPERIMENTAL]
Note that all above mentioned implicit schemes are defined as implicit, as they require evaluation of the Hamiltonian matrix at some future time. Currently, there are
two ways implemented on how to solve this type of equation which can be set by the RT_TDDFT_propagator_solver keyword.
It should also be noted here that, when using a predictor-corrector scheme (which is the default solver for all implicit propagators), accuracy can be enhanced by
using extrapolation, see the keyword RT_TDDFT_extrapolate_predictor.
Some additional schemes are implemented for testing purposes, namely the M6 (m6), CFM4:3 (cfm4_3) and CFM6:5 (cfm6_5) schemes [17].
For general purpose, we recommend to use the crank_nicolson propagation scheme.
Tag: RT_TDDFT_propagator_solver(control.in)
Usage: RT_TDDFT_propagator_solver solver
Purpose: Lets one choose the solver technique used for time propagation and for the selected propagator.
solver: String that can be
-
•
predictor_corrector: Standard semi-implicit predictor-corrector scheme.
-
•
forward_extra: Uses extrapolation to approximate future Hamiltonian in implicit schemes. This is not an implicit scheme, as no corrector step is performed.
-
•
anderson: Anderson acceleration to solve implicit schemes, see [311]. Currently only works with the crank_nicolson and parallel_transport_cn propagators. [EXPERIMENTAL]
This keyword must usually not be set explicitly since every RT_TDDFT_propagator has its own default setting for the solver. Anyway, one can set the solver manually, e.g., to use one of the implicit exponential propagators with extrapolation, which is much cheaper since the corrector integration of the Hamiltonian matrix is not applied (however, this may be much less stable, not justifying the setting). Some combinations are not possible and a warning will be given that default settings will be used. Please use this option with caution.
Tag: RT_TDDFT_use_precor_tol(control.in)
Usage: RT_TDDFT_use_precor_tol tol
Purpose: Sets a tolerance of density change after which no more corrector steps are applied when multiple
corrector steps may be performed.
tol: Float that sets convergence criterion to exit the corrector-loop. Not used by default.
Performing additional corrector steps until a convergence criterion is reached will formally increase accuracy. It should nevertheless be noted that the biggest error is probably introduced already by the predictor step and that significant improvements by doing additional corrector steps are not to be expected. Every corrector update involves another integration of the Hamiltonian matrix which is the most expensive part in RT-TDDFT usually. Before doing more corrector steps, it probably makes more sense to choose a smaller time step – if accuracy is a problem. If one wants to use this functionality anyway, values of - would make sense usually. Note that a maximum number of 10 corrector steps is hardcoded to avoid unnecessarily many corrector updates (one should check settings when this happens).
Tag: RT_TDDFT_precor_steps(control.in)
Usage: RT_TDDFT_precor_steps steps
Purpose: Lets the user choose the (fixed) number of corrector steps to be done in the predictor-corrector solver.
steps: Integer setting a fixed number of corrector steps. Default: 1
Please see RT_TDDFT_use_precor_tol for further remarks. The default value is usually a good choice.
Tag: RT_TDDFT_extrapolate_predictor(control.in)
Usage: RT_TDDFT_extrapolate_predictor extrapol
Purpose: Extrapolation is used for the predictor step in case a predictor-corrector scheme is used.
extrapol: Bool that defines whether the Hamiltonian in a predictor propagator is extrapolated.
Default: .false.
The Hamiltonian (matrix) used in the predictor step will be extrapolated by a given method which can be set via the RT_TDDFT_ham_extrapolation keyword. This also means that additional storage is needed. The extrapolated Hamiltonian (matrix) is applied in the predictor step. Tests indicate that extrapolation can noticeably improve accuracy. However, one should check this setting when unexpected instabilities occur.
Tag: RT_TDDFT_ham_extrapolation(control.in)
Usage: RT_TDDFT_ham_extrapolation method order
Purpose: Controls order and method of extrapolation for the Hamiltonian matrix if applicable.
method: String that can be either linear or lagrange. Default: linear.
order: Integer that defines the order of the extrapolation, i.e., how many past Hamiltonian matrices are
used (and saved) for extrapolation. Default: 1.
The default setting indicating linear extrapolation works well in tests, whereas, in contrast, the Lagrange extrapolation approach sometimes produces odd results and should be used only with caution. Some of our tests indicate that higher-order extrapolation () can yield instabilities, thus one should check this.
Tag: RT_TDDFT_propagator_predictor(control.in)
Usage: RT_TDDFT_propagator_predictor prop
Purpose: A specific predictor propagator can be set in case a predictor-corrector scheme is used.
prop: String that defines the propagator to be used in the predictor step.
This only makes sense if an explicit scheme like runge_kutta_4 is used as a predictor, or, and this is the usual setting here, if any applicable implicit scheme is used in combination with extrapolation. A well-functioning scheme consists of an extrapolated exponential_midpoint predictor in combination with the cfm4 propagator for the corrector. This keyword is ignored if no predictor-corrector scheme is in use.
Tag: RT_TDDFT_exponential_method(control.in)
Usage: RT_TDDFT_exponential_method method
Purpose: Lets one choose the method for the calculation of matrix exponentials as required by some propagators.
method: String that can be either eigenvectors, scaling_squaring or taylor. Default:
eigenvectors.
Currently, three different approaches to compute matrix exponentials needed for the exponential-type propagators can be used.
The diagonalization-based approach is usually working perfectly but in the current implementation, it cannot be used
for non-Hermitian matrices – this can be the case for effective Hamiltonian matrices occurring in Ehrenfest dynamics.
In this case, the scaling and squaring - method [142] will be applied. Anyway, this setting will then be adjusted automatically. One can modify this setting mainly for benchmarking or testing. Note that using the taylor method requires to choose an order of the expansion, see
RT_TDDFT_exponential_taylor_order.
Tag: RT_TDDFT_exponential_taylor_order(control.in)
Usage: RT_TDDFT_exponential_taylor_order order
Purpose: Sets the order of the truncated Taylor expansion method for the matrix exponential.
order: Integer that sets the order. Default: 10.
The Taylor method applies to general matrices and can be an economic choice. However, the order must be set with caution, as we found that the here employed all-electron approach likely requires higher orders. It may not even work when heavy elements are involved. This setting also highly depends on the time step. We found values of 10-20 to work well in certain cases.
Tag: RT_TDDFT_crank_nicolson_order(control.in)
Usage: RT_TDDFT_crank_nicolson_order order
Purpose: Sets the order of the expansion used in the Crank-Nicolson propagator.
order: Integer that sets the order. Default: 1.
Usually, 1st order seems to suffice for most applications. However, it can be beneficial to use higher order, e.g., 2/3, when instabilities are observed, especially possibly for heavier elements.
Tag: RT_TDDFT_crank_nicolson_solve_inv(control.in)
Usage: RT_TDDFT_crank_nicolson_solve_inv solve
Purpose: Sets the inversion method in the Crank-Nicolson scheme.
solve: Boolean that sets the direct inversion method. Default: .false.
This only makes sense when the software bug explained above occurs. Setting the flag to .true. should resolve the issue. It is possible that the performance is impacted by this setting.
Tag: RT_TDDFT_check_total_energy(control.in)
Usage: RT_TDDFT_check_total_energy start_time thresh
Purpose: Compares the total energy to a fixed value at t start_time and checks whether it is conserved below thresh.
start_time: Float that sets the time for which the reference energy is saved.
thresh: Float that sets the maximum energy deviation (in eV).
This can be used to prevent a simulation of ’blowing up’, i.e., becoming unstable, as measured by the degree of energy conservation. The start time should be chosen such that the reference value makes sense: for example, when applying a finite resonant excitation, the total energy will increase, but should stay constant thereafter; thus, the reference value should be set a while after the excitation ends.
Tag: RT_TDDFT_imaginary_time(control.in)
Usage: RT_TDDFT_imaginary_time flag
Purpose: Peforms the simulation with imaginary time.
flag: Boolean that sets imaginary time. Default: .false.
Imaginary time propagation can be used as an alternative approach to the standard SCF procedure to converge a ground-state solution [93]. This does only require a time step as control parameter and may be used to converge situations where SCF fails. Note that we recommend the Crank-Nicolson propagator for this functionality (higher orders may also be beneficial in order to enable higher time steps).
After convergence is reached, the eigenvectors are written back into the native data structures so that postprocessing methods should be usable.
Tag: RT_TDDFT_anderson_order_iter(control.in)
Usage: RT_TDDFT_anderson_order_iter order iter tol
Purpose: Sets specific parameters that are important in the anderson solver.
order: Order of the scheme, i.e., the number of eigenvectors used for the Anderson acceleration. Default: 4.
iter: Maximum number of steps in the fixed-point iteration. Default: 30.
tol: Convergence criterion for the fixed-point iteration. Default: 1e-14.
These parameters are explained in detail by Walker et al. [311]. We refer to algorithm ’AA’ in this reference. The parameter = order, iter as in the reference. The tolerance parameter depends on the setting RT_TDDFT_anderson_cond_type and should generally be chosen as a very small number. The most important parameter here is iter, which can be crucial to obtain a converged fixed-point iteration, but may also increase the possible numerical demand.
Tag: RT_TDDFT_anderson_cond_type(control.in)
Usage: RT_TDDFT_anderson_cond_type type
Purpose: Sets the type of the convergence check in the accelerated Anderson fixed-point iteration.
type: String that can be either ev_maximum, ev_individual or delta_rho. Default: delta_rho.
This defines which quantity is used as convergence measure in the fixed-point iteration. ev_maximum defines that must be below tol as defined via RT_TDDFT_anderson_order_iter. ev_individual means that all solutions must be below the threshold tol. delta_rho only requires that the average change in charge density must be below the tolerance.
Ehrenfest Dynamics Settings
Tag: RT_TDDFT_ehrenfest(control.in)
Usage: RT_TDDFT_ehrenfest type dt_geo
Purpose: Performing a RT-TDDFT+Ehrenfest simulation, i.e., coupled electron-ion dynamics.
type: String that defines the Ehrenfest scheme. Must currently only be chosen as default.
dt_geo: Time step for geometry update and force computation.
The time step for Ehrenfest dynamics must obviously be at least the same value as for electron propagation. Usually, it can be chosen
around 5- to 20-fold while maintaining stable propagation. Since updating the geometry and calculating forces is expensive,
the Ehrenfest time step should be as large as possible. Additionally, the specific interplay of time propagation, force update and
geometry update works very good when dt_geo dt with . A reasonable choice for doing Ehrenfest dynamics should be dt a.u. in combination with dt_geo
a.u. Monitoring energy conservation and norm conservation of the eigenvectors is advised when trying out settings.
Remember using consistent units set by the RT_TDDFT_input_units keyword.
Tag: RT_TDDFT_ehrenfest_start_time(control.in)
Usage: RT_TDDFT_ehrenfest_start_time t_start
Purpose: Setting the start time for Ehrenfest dynamics.
t_start: Time after which non-adiabatic forces are calculated and geometry is updated in case an Ehrenfest simulation
is requested. Default: 0.
Usually, Ehrenfest dynamics start with the begin of a RT-TDDFT simulation when requested, but employing this key can modify the
start time in case specific tasks require this.
Remember using consistent units set by the RT_TDDFT_input_units keyword.
Tag: RT_TDDFT_ehrenfest_full_nc_forces(control.in)
Usage: RT_TDDFT_ehrenfest_full_nc_forces key
Purpose: When requested, the full non-adiabatic Ehrenfest forces are evaluated.
key: Boolean that controls whether the full force contributions are calculated at each force computation step. Default: .false.
Usually, it seems that using the ’normal’ non-adiabatic Ehrenfest forces conserving the energy (but not necessarily the momentum) is sufficient, but by using this keyword, the complete expression is evaluated – this might be important in specific situations and is of course more general. Anyway it is more expensive.
Tag: RT_TDDFT_ehrenfest_remove_com(control.in)
Usage: RT_TDDFT_ehrenfest_remove_com key
Purpose: Controls whether the center of mass is set to origin in Ehrenfest dynamics.
key: Boolean. Default: .false.
Output Settings
Tag: RT_TDDFT_write_file_prefix(control.in)
Usage: RT_TDDFT_write_file_prefix prefix
Purpose: Controls naming of all output files produced by the RT-TDDFT module.
prefix: String that is used to specify output files. Default: output.
All output files have the format PREFIX.rt-tddft.OBSERVABLE.SUFFIX or
PREFIX.rt-tddft-ehrenfest.OBSERVABLE.SUFFIX
where PREFIX can be set by the user to specify simulation settings. For example, energies are by default written to
a file named output.rt-tddft.energies.dat. The corresponding quantities are always specified (format, units, etc.) in
comment headers inside the files. Note that for any file output, existing files will not be overwritten. Instead, new files named
PREFIX.N.rt-tddft.OBSERVABLE.SUFFIX with N will be created.
Tag: RT_TDDFT_write_ext_field(control.in)
Usage: RT_TDDFT_write_ext_field key
Purpose: Controls whether the time-dependent external field is written to a file.
key: Boolean. Default: .true.
The external field and all corresponding parameters are written to a file before a real-time simulation in this case. This information can, e.g., be used for postprocessing or visualization. Note that our postprocessing tool eval_tddft.py requires this file.
Tag: RT_TDDFT_write_cube(control.in)
Usage: RT_TDDFT_write_cube dt_cube
Purpose: Controls whether time-dependent cube files are written.
dt_cube: Real value determining the time step for which output will be generated. If possible, this
value should be much higher than the real-time time stepping since computing cubes is costly.
Default cube output is deactivated until this flag is given and the output frequency is specified. All options that
can be used for cube output via the output cube keyword can be applied here and must be set in
addition to this keyword.
Remember using consistent units set by the RT_TDDFT_input_units keyword.
Tag: RT_TDDFT_output_level(control.in)
Usage: RT_TDDFT_output_level level
Purpose: Controls the amount of console output written by the RT-TDDFT subroutine.
level: Integer with valid values of:
-
•
0: Min output - nearly nothing except basic information is written (NOTE: no information about physical observables is written in this case, too – use file output then)
-
•
1: Low output - some additional information is written, e.g., energies, dipole moment
-
•
2: Mid output - more is written out, e.g., convergence or accuracy parameters, timings
-
•
3: Max output - this prints info on anything that is being performed
Default: 1.
Since RT-TDDFT simulations are usually performed for a significant number of time-integration/density
update/force calculation/etc. operations, the associated output will result in very large amounts of mostly unnecessary
data which can be avoided by setting this keyword. The default should yield sufficient information on what is happening, but
setting it to 2 will give some more information about numerical properties which can be important to follow.
Please note that important observables, e.g., energies, dipole moment, geometry, etc. are written to separate files which
can be controlled further and which eases post-processing (see RT_TDDFT_write_file_prefix).
Tag: RT_TDDFT_output_priority_override(control.in)
Usage: RT_TDDFT_output_priority_override priority
Purpose: Lets one override the FHI-aims native output level for functionality used within RT-TDDFT.
priority: Integer that sets the output level. Default: 3 (minimal).
In the RT-TDDFT module, several routines from the parent code are called which may produce their own output. By default, the output level for these calls is set to minimal, i.e., not output will be sent to the console. However, this can be overridden by this keyword. We refer to the keywork output_level in the FHI-aims manual for specific choices.
Tag: RT_TDDFT_output_energies(control.in)
Usage: RT_TDDFT_output_energies key_std key_file
Purpose: Controls whether time-dependent energies are calculated, sent to output and written to a file.
key_std: Boolean controlling whether energies are written to standard output. Default: .true.
key_file: Boolean controlling whether energies are written to a file. Default: .false.
Energy should always be observed in order to validate a properly running simulation, i.e., total energy conservation. Note that when values are written to a file too, the corresponding file is named PREFIX.rt-tddft.energies.dat where PREFIX can be changed via the RT_TDDFT_write_file_prefix keyword.
Tag: RT_TDDFT_output_dipole(control.in)
Usage: RT_TDDFT_output_dipole key_std key_file
Purpose: Controls whether the time-dependent dipole moment is calculated, sent to output and written to a file.
key_std: Boolean controlling whether the dipole moment is written to standard output. Default: .true. for cluster systems, else .false.
key_file: Boolean controlling whether dipole moment is written to a file. Default: .false.
The electronic dipole is usually an observable of major interest in many RT-TDDFT applications.
Note that when values are written to a file too, the corresponding file
is named PREFIX.rt-tddft.dipole.dat where PREFIX can be changed via the
RT_TDDFT_write_file_prefix keyword.
Tag: RT_TDDFT_output_dipole_xyz(control.in)
Usage: RT_TDDFT_output_dipole_xyz out_x out_y out_z
Purpose: Controls whether the x, y, z components of the electronic dipole moment are actually computed.
out_x: Boolean controlling whether the x-component is computed. Default: .true.
out_y: Boolean controlling whether the y-component is computed. Default: .true.
out_z: Boolean controlling whether the z-component is computed. Default: .true.
This keyword can be used to save unnecessary computation time for components that are not of interest. However, the computational effort for observables is generally low, as compared to the remaining functionality.
Tag: RT_TDDFT_output_transition_dipole(control.in)
Usage: RT_TDDFT_output_transition_dipole key_std key_file state_min state_max
Purpose: Controls whether and which transition dipole moments are computed.
key_std: Boolean controlling whether transition dipole moments are written to standard output. Default: .false.
key_file: Boolean controlling whether transition dipole moments are written to files. Note that a file for each transition is created. Default: .false.
state_min: Index of the lowest occupied state that will be considered.
state_max: Index of the highest unoccupied state that will be considered.
The computation of transition dipole moments can be requested here. The lower and upper index define the set of occupied/unoccupied Kohn-Sham states for which time-dependent transition dipole moments will be computed. It is necessary that the native keyword empty_states is set accordingly high (e.g., to the number of basis functions or, e.g., 10000), else it is possible that not enough unoccupied states are available in the corresponding arrays. This is one of the rather computationally expensive observables.
Tag: RT_TDDFT_output_transition_dipole_xyz(control.in)
Usage: RT_TDDFT_output_transition_dipole_xyz out_x out_y out_z
Purpose: Controls whether the x, y, z components of the transition dipole moments are actually computed.
out_x: Boolean controlling whether the x-component is computed. Default: .true.
out_y: Boolean controlling whether the y-component is computed. Default: .true.
out_z: Boolean controlling whether the z-component is computed. Default: .true.
This keyword can be used to save unnecessary computation time for components that are not of interest.
Tag: RT_TDDFT_output_state_dipoles(control.in)
Usage: RT_TDDFT_output_state_dipoles key_std
Purpose: Controls whether time-dependent dipole moments of individual occupied states are calculated and sent to standard output.
key_std: Boolean. Default: .false.
If given, the dipole expectation values for all occupied (and thus, time-propagated) states are computed and sent to output. Note that this computation requires the explicit evaluation of the dipole matrix and could cause additional computational cost.
Tag: RT_TDDFT_output_magnetic_moment(control.in)
Usage: RT_TDDFT_output_magnetic_moment key_std key_file
Purpose: Controls whether the time-dependent magnetic moment is calculated, sent to output and written to a file.
key_std: Boolean controlling whether the magnetic moment is written to standard output. Default: .false.
key_file: Boolean controlling whether the magnetic moment is written to a file. Default: .false.
The magnetic moment is usually an observable of major interest in RT-TDDFT applications for circular dichroism.
Note that when values are written to a file too, the corresponding file
is named
PREFIX.rt-tddft.magmom.dat where PREFIX can be changed via the
RT_TDDFT_write_file_prefix keyword.
Tag: RT_TDDFT_output_magnetic_moment_xyz(control.in)
Usage: RT_TDDFT_output_dipole_xyz out_x out_y out_z
Purpose: Controls whether the x, y, z components of the magnetic moment are actually computed.
out_x: Boolean controlling whether the x-component is computed. Default: .true.
out_y: Boolean controlling whether the y-component is computed. Default: .true.
out_z: Boolean controlling whether the z-component is computed. Default: .true.
This keyword can be used to save unnecessary computation time for components that are not of interest. However, the computational effort for observables is generally low, as compared to the remaining functionality.
Tag: RT_TDDFT_output_current(control.in)
Usage: RT_TDDFT_output_current key_std key_file
Purpose: Controls whether the time-dependent electronic current is calculated, sent to output and written to a file.
key_std: Boolean controlling whether the current is written to standard output. Default: .false. for cluster systems, else .true.
key_file: Boolean controlling whether the current is written to a file. Default: .false.
The electronic current is often the main observable of interest in periodic RT-TDDFT simulations (analog to the dipole in finite systems). Note that when values are written to a file too, the corresponding file is named PREFIX.rt-tddft.current.dat where PREFIX can be changed via the RT_TDDFT_write_file_prefix keyword.
Tag: RT_TDDFT_ehrenfest_output_trajectory(control.in)
Usage: RT_TDDFT_ehrenfest_output_trajectory key_std key_file
Purpose: Controls whether time-dependent coordinates, velocities and forces are sent to output and written to a file in Ehrenfest dynamics.
key_std: Boolean controlling whether trajectory information is written to standard output. Default: .true. for Ehrenfest dynamics, else .false.
key_file: Boolean controlling whether trajectory information is written to a file. Default: .false.
Note that when values written are to a file too, the corresponding file
is named PREFIX.rt-tddft-ehrenfest.trajectory.xyz where PREFIX can be changed via the
RT_TDDFT_write_file_prefix keyword.
Tag: RT_TDDFT_output_n_excited(control.in)
Usage: RT_TDDFT_output_n_excited key_std
Purpose: Controls whether the time-dependent number of excited electrons based on ground-state projection is computed and sent to standard output.
key_std: Boolean controlling whether this quantity is computed and written to standard output. Default: .false.
This quantity is computed as
| (3.113) |
i.e., via projection of time-dependent orbitals on ground-state orbitals [238]. This refers to the number of electrons that are possibly excited within the introduced dynamics.
Restart Settings
Tag: RT_TDDFT_restart_write(control.in)
Usage: RT_TDDFT_restart_write t_write_restart
Purpose: Writes a RT-TDDFT restart file for a specified time.
t_write_restart: Real value corresponding to specific time for which a restart file should be written.
All necessary information to perform a RT-TDDFT restart is written to file/s in this case. In detail, all the eigencoefficients, coordinates, settings, etc. Multiple entries of this keyword for different times can be given. Note that this can potentially produce huge files, especially when periodic boundary conditions are in use (as for every -point, eigenvectors are written).
Tag: RT_TDDFT_restart_write_period(control.in)
Usage: RT_TDDFT_restart_write_period t_write_restart_period
Purpose: Writes a RT-TDDFT restart file repeatedly after each specified time period.
t_write_restart: Real value corresponding to specific time period after which a restart file should be written.
See RT_TDDFT_restart_write for details. When doing very demanding simulations and/or very long simulations, one should set a sensible value here to avoid needing to restart from the beginning after a job was canceled. Writing a restart file automatically when a kill signal is received is on the to-do list.
Tag: RT_TDDFT_restart_read(control.in)
Usage: RT_TDDFT_restart_read restart_file
Purpose: Reads a RT-TDDFT restart file and starts the simulation based on it.
restart_file: String describing the corresponding restart file.
Besides the physical quantities, the restart file contains all relevant real-time simulation parameters which are compared to what is given in control.in. The settings must be the same or the simulation will abort. This also works for Ehrenfest dynamics. Note that when performing a restart, FHI-aims will run a SCF cycle, but the resulting eigenvectors, etc. will be overwritten from what is read in the restart file - based on this, the real-time simulation will be re-initialized.
Tags for geometry.in
Tag: RT_TDDFT_initial_velocity(geometry.in)
Usage: RT_TDDFT_initial_velocity v_x v_y v_z
Purpose: Initial velocity of corresponding (i.e. last specified) atom when peforming RT-TDDFT-Ehrenfest dynamics.
v_x, v_y, v_z: Initial velocities in units of Å/ps.
Putting initial kinetic energy into the ionic subsystem is a common initial condition used in Ehrenfest dynamics, e.g. when simulating ion bombardment or to evaluate molecular potential energy surfaces.