In VMD you need to create two representations in "Graphics" - "Representation" panel to respectively display positive and negative parts. For example, if you hope to visualize isosurface of electron density difference of ±0.001 a.u., you should set isovalue of the first representation as 0.001, while the isovalue of the second representation should be set to -0.001.

In addition, I strongly suggest following section "4.A.14 Very easily rendering cube files as state-of-the-art isosurface map via VMD script" of Multiwfn manual, in this section I provide a VMD script, by which you can very easily plot very nice isosurface map (containing both positive and negative parts) based on a .cub file.

Best,

Tian

Sincerely,
David

1 Unlike Gaussian, ORCA doesn't automatically translate or reorientate the system, therefore you do not need to add any additional keyword

2 I don't know what the "abrupt results" refers to. In principle you can UKS to calculate open-shell system and then calculate EDD. ROKS is highly deprecated, because it is much slower than UKS, and sometimes SCF doesn't easily get converged. In addition, the ROKS density is not as realistic as UKS.

I have encountered a problem in EDD. I have optimized a NCI complex using m062x/def2tzvpp in ORCA. The .wfn files are formed.
1. In the 4.5.5 section, you have mentioned to use NOSYMM keyword for gaussian, does the similar happens with ORCA?
2. One of my monomer is open-shell, so I used UM062X, other one is closed-shell and the complex is thus treated in UKS. The EDD using UKS shows abrupt results, should I treat the system as ROKS or UKS?

Thank you

I was a bit confused, because for more "complicated" radial+angular grid the weight for each point is not just dx*dy*dz.
One gets large density contribution close to nuclei, which vanishes once it is multiplied by weights.

Thank you for the explanation, it make sense in the case of simple cubic grid.
Is it the case for Multiwfn?
What is the reason not to have it multiplied by default?

Is there a similar trick for plane and line?

Multiwfn also supports rectangle grid, the program is never limited to cubic grid.

According to common convention, grid data stores electron density at each grid point (i.e. the unit is 1/Bohr^3), rather than number of electron contained in the space of each grid.

For plane map of electron density, the data at each point is also "density" of electron.

Is there a similar trick for plane and line?

Simply summing up all values from output.txt or density.cub does not have physical meaning, the sum should be multiplied by differential element (i.e. dx*dy*dz, where dx/dy/dz are grid spacing in X/Y/Z direction), so that the result directly correpsonds to number of electrons. The dx,dy,dz are always printed on screen when calculating grid data, e.g.

Grid spacing in X,Y,Z is    0.220163    0.220163    0.220163 Bohr

So, you can manually multiply the data in the output.txt by 0.220163^3.

Tian

thank you for sharing this nice tip, I wanted to do almost the same.

I have another question related to density and density differences plots.
How to produce a plot of normalized density difference (and density too)?

The output.txt file produced via 5 - 1 - 3 - 3 contains non-normalized density.
I check this by simply summing all values in the file, which turns out to be very large and not equal to the total number of electrons.
In the output there is statement  " Summing up all value and multiply differential element:" with sum close to total number of electrons.
Is there a way to get all the values multiplied by corresponding differential elements or all the differential elements printed to a file?

I guess in the case of density differences it is important to have normailzed densities, as those will not have large contribution close to nuclei.

My reply

water_tetramer.rar