CalculationMode
Section: Calculation Modes
Type: integer
Default: gs
Decides what kind of calculation is to be performed.
Options:
%CalculationMode gs | unocc | td "run1" | "run2" | "run3" 1 | 2 | 3 %
GCMSlaterDeterminants
Section: Calculation Modes::Generator Coordinates
Type: block
Specify which Slater determinants are to be used, each generated from a previous
ground-state calculation. Supply a list of names of the directories in which the
results of each calculation was saved.
GOCenter
Section: Calculation Modes::Geometry Optimization
Type: logical
Default: no
(Experimental) If set to yes, Octopus centers the geometry at
every optimization step. It also reduces the degrees of
freedom of the optimization by using the translational
invariance. The default is no.
GOMaxIter
Section: Calculation Modes::Geometry Optimization
Type: integer
Default: 200
Even if the convergence criterion is not satisfied, the minimization will stop
after this number of iterations.
GOMethod
Section: Calculation Modes::Geometry Optimization
Type: integer
Default: steep
Method by which the minimization is performed. For more information see the
GSL documentation.
Options:
GOMinimumMove
Section: Calculation Modes::Geometry Optimization
Type: float
Default: 0.001 b
Convergence criterion, for stopping the minimization. In
units of length; minimization is stopped when the coordinates
of all species change less than GOMinimumMove, or the
GOTolerance criterion is satisfied.
If GOMinimumMove < 0, this criterion is ignored.
Note that if you use GOMethod =
simplex, then you must supply a non-zero
GOMinimumMove.
GOObjective
Section: Calculation Modes::Geometry Optimization
Type: integer
Default: minimize_energy
This rather esoteric option allows one to choose which objective function
to minimize during a geometry minimization. The use of this variable may
lead to inconsistencies, so please make sure you know what you are doing!
Options:
GOStep
Section: Calculation Modes::Geometry Optimization
Type: float
Default: 0.5
Initial step for the geometry optimizer.
WARNING: in some weird units.
GOTolerance
Section: Calculation Modes::Geometry Optimization
Type: float
Default: 0.001 H/b (0.05 eV/Ang)
Convergence criterion, for stopping the minimization. In
units of force; minimization is stopped when all forces on
ions are smaller than this criterion, or the
GOMinimumMove is satisfied. If GOTolerance < 0,
this criterion is ignored.
InvertKSConvAbsDens
Section: Calculation Modes::Invert KS
Type: float
Default: 1e-5
Absolute difference between the calculated and the target density in the KS
inversion. Has to be larger than the convergence of the density in the SCF run.
InvertKSStabilizer
Section: Calculation Modes::Invert KS
Type: float
Default: 0.5
Additive constant c in the iterative calculation of the KS potential
(v(alpha+1)=rho(alpha)+c)/(rho_target+c)*v(alpha)
ensures that very small densities do not cause numerical problems.
InvertKSTargetDensity
Section: Calculation Modes::Invert KS
Type: string
Default: target_density.dat
Name of the file that contains the density used as the target in the
inversion of the KS equations.
InvertKSVerbosity
Section: Calculation Modes::Invert KS
Type: integer
Selects what is output during the calculation of the KS potential.
Options:
InvertKSmethod
Section: Calculation Modes::Invert KS
Type: integer
Default: iterative
Selects whether the exact two-particle method or the iterative scheme
is used to invert the density to get the KS potential.
Options:
OCTCheckGradient
Section: Calculation Modes::Optimal Control
Type: float
Default: 0.0
When doing QOCT with the conjugate-gradient optimization scheme, the gradient is
computed thanks to a forward-backwards propagation. For debugging purposes, this
gradient can be compared with the value obtained "numerically" (i.e. by doing
successive forward propagations with control fields separated by small finite
differences).
In order to activate this feature, set OCTCheckGradient to some non-zero value,
which will be the finite difference used to numerically compute the gradient.
OCTControlFunctionOmegaMax
Section: Calculation Modes::Optimal Control
Type: float
Default: -1.0
The Fourier series that can be used to represent the control functions must be truncated;
the truncation is given by a cut-off frequency which is determined by this variable.
OCTControlFunctionRepresentation
Section: Calculation Modes::Optimal Control
Type: integer
Default: control_fourier_series_h
If OCTControlRepresentation = control_function_parametrized, one must
specify the kind of parameters that determine the control function.
If OCTControlRepresentation = control_function_real_time, then this variable
is ignored, and the control function is handled directly in real time.
Options:
OCTControlFunctionType
Section: Calculation Modes::Optimal Control
Type: integer
Default: controlfunction_mode_epsilon
The control function may fully determine the time-dependent form of the
external field, or only the envelope function of this external field, or its phase.
Or, we may have two different control functions, one of them providing the phase
and the other one, the envelope.
Note that, if OCTControlRepresentation = control_function_real_time, then the control
function must always determine the full external field.
Options:
OCTControlRepresentation
Section: Calculation Modes::Optimal Control
Type: integer
Default: control_function_real_time
Optimal Control Theory can be performed with Octopus in two different modes:
either considering the control function to be described in full in real time,
or to be represented by a set of parameters (which may, or may not be,
the coefficients of its expansion in a given basis). The particular choice
for these parameters is specified by variable OCTParameterRepresentation
(this variable will be ignored if the control function is to be represented
directly in real time).
Options:
OCTCurrentFunctional
Section: Calculation Modes::Optimal Control
Type: integer
Default: oct_no_curr
The variable OCTCurrentFunctional describes which kind of current target functional J1_c[j] is
to be used. EXPERIMENTAL!
Options:
OCTCurrentWeight
Section: Calculation Modes::Optimal Control
Type: float
Default: 0.0
In the case of simultaneous optimization of density n and current j, one can tune the importance
of the current functional J1_c[j], as the respective functionals might not provide results on the
same scale of magnitude. J1[n,j]= J1_d[n]+ OCTCurrentWeight * J1_c[j]. Be aware that its
sign is crucial for the chosen OCTCurrentFunctional as explained there.
OCTDirectStep
Section: Calculation Modes::Optimal Control
Type: float
Default: 0.25
If you choose OCTScheme = oct_algorithm_direct or OCTScheme = oct_algorithm_newuoa,
the algorithms necessitate an initial "step" to perform the direct search for the
optimal value. The precise meaning of this "step" differs.
OCTDoubleCheck
Section: Calculation Modes::Optimal Control
Type: logical
Default: true
In order to make sure that the optimized field indeed does its job, the code
may run a normal propagation after the optimization using the optimized field.
OCTDumpIntermediate
Section: Calculation Modes::Optimal Control
Type: logical
Default: true
Writes to disk the laser pulse data during the OCT algorithm at intermediate steps.
These are files called opt_control/laser.xxxx, where xxxx is the iteration number.
OCTEps
Section: Calculation Modes::Optimal Control
Type: float
Default: 1.0e-6
Define the convergence threshold. It computes the difference between the "input"
field in the iterative procedure, and the "output" field. If this difference is
less than OCTEps the iteration is stopped. This difference is defined as:
(If there are several control fields, this difference is defined as the sum over
all the individual differences.)
Whenever this condition is satisfied, it means that we have reached a solution point
of the QOCT equations, i.e. a critical point of the QOCT functional (not
necessarily a maximum, and not necessarily the global maximum).
OCTExcludedStates
Section: Calculation Modes::Optimal Control
Type: string
If the target is the exclusion of several targets, ("OCTTargetOperator = oct_exclude_states")
then you must declare which states are to be excluded, by setting the OCTExcludedStates variable.
It must be a string in "list" format: "1-8", or "2,3,4-9", for example. Be careful to include
in this list only states that have been calculated in a previous "gs" or "unocc" calculation,
or otherwise the error will be silently ignored.
OCTFilter
Section: Calculation Modes::Optimal Control
Type: block
The block OCTFilter describes the type and shape of the filter function
that are applied to the optimized laser field in each iteration.
The filter forces the laser field to obtain the given form in frequency space.
Each line of the block describes a filter; this way you can actually have more
than one filter function (e.g. a filter in time and two in frequency space).
The filters are applied in the given order, i.e., first the filter specified
by the first line is applied, then second line.
The syntax of each line is, then:
%OCTFilter
domain | function
%
Possible arguments for domain are:
(i) frequency_filter: Specifies a spectral filter.
(ii) time_filter: DISABLED IN THIS VERSION.
Example:
%OCTFilter
time | "exp(-80*( w + 0.1567 )^2 ) + exp(-80*( w - 0.1567 )^2 )"
%
Be careful that also the negative-frequency component is filtered since the resulting
field has to be real-valued.
Options:
OCTFixFluenceTo
Section: Calculation Modes::Optimal Control
Type: float
Default: 0.0
The algorithm tries to obtain the specified fluence for the laser field.
This works only in conjunction with either the WG05 or the straight iteration scheme.
If this variable is not present in the input file, by default the code will not
attempt a fixed-fluence QOCT run. The same holds if the value given to this
variable is exactly zero.
If this variable is given a negative value, then the target fluence will be that of
the initial laser pulse given as guess in the input file. Note, however, that
first the code applies the envelope provided by the OCTLaserEnvelope input
option, and afterwards it calculates the fluence.
OCTFixInitialFluence
Section: Calculation Modes::Optimal Control
Type: logical
Default: yes
By default, when asking for a fixed-fluence optimization (OCTFixFluenceTo = whatever),
the initial laser guess provided in the input file is scaled to match this
fluence. However, you can force the program to use that initial laser as the initial
guess, no matter the fluence, by setting OCTFixInitialFluence = no.
OCTInitialState
Section: Calculation Modes::Optimal Control
Type: integer
Default: 1
Describes the initial state of the quantum system.
Possible arguments are:
Options:
OCTInitialTransformStates
Section: Calculation Modes::Optimal Control
Type: block
If OCTInitialState = oct_is_gstransformation, you must specify an
OCTInitialTransformStates block, in order to specify which linear
combination of the states present in restart/gs is used to
create the initial state.
The syntax is the same as the TransformStates block.
OCTInitialUserdefined
Section: Calculation Modes::Optimal Control
Type: block
Define an initial state. Syntax follows the one of the UserDefinedStates block.
Example:
%OCTInitialUserdefined
1 | 1 | 1 | "exp(-r^2)*exp(-i*0.2*x)"
%
OCTLaserEnvelope
Section: Calculation Modes::Optimal Control
Type: block
Often a pre-defined time-dependent envelope on the control function is desired.
This can be achieved by making the penalty factor time-dependent.
Here, you may specify the required time-dependent envelope.
It is possible to choose different envelopes for different control functions.
There should be one line for each control function. Each line should
have only one element: a string with the function that defines the
inverse of the time-dependent penalty, which is then defined as
1 divided by (this function + 1.0e-7) (to avoid possible singularities).
The usual choices should be functions between zero and one.
If, instead of defining a function, the string is default, then
the program will use the function:
OCTLocalTarget
Section: Calculation Modes::Optimal Control
Type: string
If OCTTargetOperator = oct_tg_local, then one must supply a function
that defines the target. This should be done by defining it through a string, using
the variable OCTLocalTarget.
OCTMaxIter
Section: Calculation Modes::Optimal Control
Type: integer
Default: 10
The maximum number of iterations.
Typical values range from 10-100.
OCTMixing
Section: Calculation Modes::Optimal Control
Type: logical
Default: false
Use mixing algorithms to create the input fields in the iterative OCT schemes.
Note that this idea is still a little bit experimental, and depending on the
kind of mixing that you use, and the parameters that you set, it may or may
not accelerate the convergence, or even spoil the convergence.
Using TypeOfMixing = broyden, Mixing = 0.1 and MixNumberSteps = 3 seems
to work in many cases, but your mileage may vary.
Note that mixing does not make sense (and is therefore not done, this variable
being ignored), for some OCT algorithms (in particular, if OCTScheme is
oct_algorithm_direct or oct_algorithm_newuoa).
OCTMoveIons
Section: Calculation Modes::Optimal Control
Type: logical
If OCTTargetOperator = oct_tg_velocity, then one must specify
if the ions are assumed to be fixed or if they can move by setting
OCTMoveIons to true or false.
OCTNumberCheckPoints
Section: Calculation Modes::Optimal Control
Type: integer
During an OCT propagation, the code may write the wavefunctions at some time steps (the
"check points"). When the inverse backward or forward propagation
is performed in a following step, the wavefunction should reverse its path
(almost) exactly. This can be checked to make sure that it is the case -- otherwise
one should try reducing the time-step, or altering in some other way the
variables that control the propagation.
If the backward (or forward) propagation is not retracing the steps of the previous
forward (or backward) propagation, the code will write a warning.
OCTOptimizeHarmonicSpectrum
Section: Calculation Modes::Optimal Control
Type: block
Default: no
WARNING: Experimental
If OCTTargetOperator = oct_tg_hhg, the target is the harmonic emission spectrum.
In that case, you must supply an OCTOptimizeHarmonicSpectrum block in the inp
file. The target is given, in general, by:
,
where is the harmonic spectrum generated by the system, and
is some function that determines what exactly we want
to optimize. The role of the OCTOptimizeHarmonicSpectrum block is to determine
this function. Currently, this function is defined as:
,
where is the carrier frequency. is
the number of columns in the OCTOptimizeHarmonicSpectrum block. The values of L will be listed
in the first row of this block; in the second row, and in
the third.
Example:
%OCTOptimizeHarmonicSpectrum
7 | 9 | 11
-1 | 1 | -1
0.01 | 0.01 | 0.01
%
OCTPenalty
Section: Calculation Modes::Optimal Control
Type: float
Default: 1.0
The variable specifies the value of the penalty factor for the
integrated field strength (fluence). Large value = small fluence.
A transient shape can be specified using the block OCTLaserEnvelope.
In this case OCTPenalty is multiplied with time-dependent function.
The value depends on the coupling between the states. A good start might be a
value from 0.1 (strong fields) to 10 (weak fields).
Note that if there are several control functions, one can specify this
variable as a one-line code, each column being the penalty factor for each
of the control functions. Make sure that the number of columns is equal to the
number of control functions. If it is not a block, all control functions will
have the same penalty factor.
All penalty factors must be positive.
OCTRandomInitialGuess
Section: Calculation Modes::Optimal Control
Type: logical
Default: false
The initial field to start the optimization search is usually given in the inp file,
through a TDExternalFields block. However, you can start from a random guess if you
set this variable to true.
Note, however, that this is only valid for the "direct" optimization schemes; moreover
you still need to provide a TDExternalFields block.
OCTScheme
Section: Calculation Modes::Optimal Control
Type: integer
Default: oct_algorithm_zbr98
Optimal Control Theory can be performed with Octopus with a variety of different
algorithms. Not all of them can be used with any choice of target or control function
representation. For example, some algorithms cannot be used if
OCTControlRepresentation = control_function_real_time
(OCTScheme .gt. oct_algorithm_straight_iteration), and others cannot be used
if OCTControlRepresentation = control_function_parametrized
(OCTScheme .lt. oct_algorithm_straight_iteration).
Options:
OCTSpatialCurrWeight
Section: Calculation Modes::Optimal Control
Type: block
Can be seen as a position dependent OCTCurrentWeight. Consequently, it
weights contribution of current j to its functional J1_c[j] according to the position in space.
For example, oct_curr_square thus becomes
J1_c[j] = OCTCurrentWeight \int |j(r)|^2 OCTSpatialCurrWeight(r) dr.
It is defined OCTSpatialCurrWeight(r) = g(x)*g(y)*g(z), where
g(x) = \sum_{i} 1/(1+exp( -fact*(x-startpoint_i) )) - 1/(1+exp( -fact*(x-endpoint_i) )).
If not specified, g(x) = 1.
Each g(x) is represented by one line of the block that has the following form
%OCTSpatialCurrWeight
dimension | fact | startpoint_1 | endpoint_1 | startpoint_2 | endpoint_2 |...
%
There are no restrictions on the number of lines, nor on the number of pairs of start- and endpoints.
Attention: startpoint and endpoint have to be supplied pairwise
with startpoint .lt. endpoint. dimension .gt. 0 is integer, fact is float.
OCTStartIterCurrTg
Section: Calculation Modes::Optimal Control
Type: integer
Allows for a time dependent target for the current without defining it for the total
time-interval of the simulation.
Thus it can be switched on at the iteration desired, OCTStartIterCurrTg .ge. 0
and OCTStartIterCurrTg .lt. TDMaximumIter.
Tip: If you would like to specify a real time for switching
the functional on rather than the number of steps, just use something
like:
OCTStartIterCurrTg = 100.0 / TDTimeStep
OCTTargetDensity
Section: Calculation Modes::Optimal Control
Type: string
If OCTTargetOperator = oct_tg_density, then one must supply the target density
that should be searched for. This one can do by supplying a string through
the variable OCTTargetDensity.
OCTTargetDensityFromState
Section: Calculation Modes::Optimal Control
Type: block
Default: no
If OCTTargetOperator = oct_tg_density, and OCTLocalTarget = "OCTTargetDensityFromState",
you must specify a OCTTargetDensityState block, in order to specify which linear
combination of the states present in restart/gs is used to
create the target density.
The syntax is the same as the TransformStates block.
OCTTargetOperator
Section: Calculation Modes::Optimal Control
Type: integer
Default: oct_tg_gstransformation
The variable OCTTargetOperator prescribes which kind of target functional is
to be used.
Options:
OCTTargetTransformStates
Section: Calculation Modes::Optimal Control
Type: block
Default: no
If OCTTargetOperator = oct_tg_gstransformation, you must specify a
OCTTargetTransformStates block, in order to specify which linear
combination of the states present in restart/gs is used to
create the target state.
The syntax is the same as the TransformStates block.
OCTTargetUserdefined
Section: Calculation Modes::Optimal Control
Type: block
Define a target state. Syntax follows the one of the UserDefinedStates block.
Example:
%OCTTargetUserdefined
1 | 1 | 1 | "exp(-r^2)*exp(-i*0.2*x)"
%
OCTVelocityDerivatives
Section: Calculation Modes::Optimal Control
Type: block
If OCTTargetOperator = oct_tg_velocity, and
OCTScheme = oct_algorithm_cg then you must supply
the target in terms of the ionic velocities AND the derivatives
of the target with respect to the ionic velocity components.
The derivatives are supplied via strings through the block
OCTVelocityDerivatives.
Each velocity component is supplied by "v[n_atom,vec_comp]",
while "n_atom" is the atom number, corresponding to the
Coordinates block and "vec_comp" is the corresponding
vector component of the velocity. The first line of the
OCTVelocityDerivatives block contains the derivatives
with respect to "v[1,*]", the second with respect to "v[2,*]" and so
on. The first column contains all derivatives with respect "v[*,1]",
the second with respect to "v[*,2]" and the third w.r.t. "v[*,3]".
As an example, we show the OCTVelocityDerivatives block
corresponding to the target shown in the OCTVelocityTarget
help section:
%OCTVelocityDerivatives
" 2*(v[1,1]-v[2,1])" | " 2*(v[1,2]-v[2,2])" | " 2*(v[1,3]-v[2,3])"
"-2*(v[1,1]-v[2,1])" | "-2*(v[1,2]-v[2,2])" | "-2*(v[1,3]-v[2,3])"
%
OCTVelocityTarget
Section: Calculation Modes::Optimal Control
Type: block
If OCTTargetOperator = oct_tg_velocity, then one must supply the
target to optimize in terms of the ionic velocities. This is done by
supplying a string through the block OCTVelocityTarget.
Each velocity component is supplied by "v[n_atom,vec_comp]",
while "n_atom" is the respective atom number, corresponding to the
Coordinates block and "vec_comp" is the corresponding
vector component of the velocity. The target string can be
supplied by using several lines in the OCTTargetOperator block.
As an example, the following target can be used to maximize the
velocity difference between atom 1 and 2 (in a 3D system):
%OCTVelocityTarget
"(v[1,1]-v[2,1])^2 + (v[1,2]-v[2,2])^2 + "
"(v[1,3]-v[2,3])^2"
%
NumberUnoccStates
Section: Calculation Modes::Unoccupied States
Type: integer
Default: 5
How many unoccupied states to compute.
UnoccMaximumIter
Section: Calculation Modes::Unoccupied States
Type: integer
Default: 50
Maximum number of eigensolver iterations. The code will stop even if convergence
has not been achieved. -1 means unlimited.
UnoccShowOccStates
Section: Calculation Modes::Unoccupied States
Type: logical
Default: false
If true, the convergence for the occupied states will be shown too in the output.
This is useful only for testing.