# Developping new functionals for KS or RS-DFT

## The very basics

To develop new functionals for DFT (or RSDFT) to be used in the SCF programs (ks_scf or rs_ks_scf ) or in multi-configurational RSDFT (see https://gitlab.com/eginer/qp_plugins_eginer), you need to specify, at the end of the day, two things:

*exchange/correlation***energy functionals**used to compute the**energy***exchange/correlation***potentials**for (alpha/beta electrons) used to**optimize the wave function**

The providers to define such quantities, and then used by all the all the DFT programs, are (see dft_one_e):

`energy_x`

and`energy_c`

: the*exchange*and*correlation*energy functionals (see`e_xc_genera l.irp.f`

)`potential_x_alpha_ao`

and`potential_x_beta_ao`

: the exchange potential for alpha/beta electrons on the AO basis (se e`pot_general.irp.f`

)`potential_c_alpha_ao`

and`potential_c_beta_ao`

: the correlation potential for alpha/beta electrons on the AO basis ( see`pot_general.irp.f`

)

From the AO basis, the providers for the exchange/correlation potentials of alpha/beta electrons on the MO basis are automatically obtained by a AO –> MO transformation.

So, at the end of the day, adding a new functional consists only in **setting a new value to these providers**.

### The general philosphy

The directory **functionals** contains only files ending with .irp.f whose name being the name of a specific functional.
All files in *a_functional*.irp.f **must** contain **at least** the following providers

`energy_x_a_functional`

and`energy_c_a_functional`

which are of course the exchange and correlation energies`potential_x_alpha_ao_a_functional`

and`potential_x_beta_ao_a_functional`

which are the exchange alpha/beta potentials`potential_c_alpha_ao_a_functional`

and`potential_c_beta_ao_a_functional`

which are the correlation alpha/beta potentials

For instance, the file `sr_lda.irp.f`

contains the following providers

`energy_x_sr_lda`

and`energy_c_sr_lda`

which are of course the exchange and correlation energies`potential_x_alpha_ao_sr_lda`

and`potential_x_beta_ao_sr_lda`

which are the exchange alpha/beta potentials`potential_c_alpha_ao_sr_lda`

and`potential_c_beta_ao_sr_lda`

which are the correlation alpha/beta potentials

Therefore, if you want to develop a new functional, just design a provider

To use a functional

## Using the density for DFT calculations in the *Quantum Package*

### Different ways of defining the density for the DFT

There are many ways of defining a density, and the keyword to define it is `density_for_dft density_for_dft`

.
Here are the following options for that keyword:

“KS” : density is obtained from

**a single Slater determinant**“WFT” : density is obtained from

**the wave function**which is stored in the EZFIO data base“input_density” : a one-body density matrix on the MO basis is read from the EZFIO data base, and the density is built from there (see

`data_one_e_dm_alpha_mo`

)“damping_rs_dft” : damped density between “WFT” and “input_density” with the damping factor

`density_for_dft damping_for_rs_dft`

.

Once that you have defined how to define the density, you can easily access to the providers associated to it.

### Value of the density and its gradients in real space

The density and its gradients evaluated on all grid points are (see dft_utils_in_r):

`one_e_dm_alpha_at_r`

and`one_e_dm_beta_at_r`

: alpha/beta density at grid points`one_e_dm_and_grad_alpha_in_r`

,`one_e_dm_and_grad_beta_in_r`

: alpha/beta gradients (and densities)

If you want to evaluate the density and its gradients at a given point in space, please refer to:

`density_and_grad_alpha_beta_and_all_aos_and_grad_aos_at_r()`

If you use these *providers* and subroutines, the density computed will be coherent with the choice of density that you specified
with `density_for_dft density_for_dft`

, and it will impact automatically the general providers of dft_one_e.