Hi,

I understand your confusion as this is not clearly explained anywhere in the output. The values within parentheses are those obtained as such from the CPHF/KS calculation. The values outside the parentheses are those obtained with an a posteriori symmetrization.

In your case above, the large components are not affected by the symmetrization, which only helps "cleaning" the vanishing components (i.e. they become cleaner "zeros").

Hope this clarifies things a little,

Hi,

The FINALRUN option works fine in P-CRYSTAL: that sentence in the Manual must be a leftover from the past, sorry for that.

Can you elaborate on how the optimized structures are unreasonable? Is it just for the underestimation of the computed band gap or also for some structural aspects? In this case, it would help if you could show us the "expected" structure, as well as the one you obtain from the optimization.

Hi,

Jefferson Maul has run a few tests and indeed we were able to reproduce the odd behavior you've been experiencing. Those negative values for the electron population of the vacancy are indeed very strange and may be suggestive of a basis set unbalance. It seems that whenever basis functions are left on the vacant site (either with your initial ATOMSUBS approach or with the more "canonical" GHOSTS approach) those functions are much "needed" by surrounding atoms.

We have found a possible way forward for your system through the use of the ATOMREMO option. With this option, you create the vacancy by removing the selected atom alongside its basis functions. For instance, we have used this approach to study Oxygen vacancies in CaSnO3 here.

We have used this approach on your system (on a smaller supercell to be able to run the tests more efficiently) and the geometry optimization went well. See the attached output file as a guide.

Hope this helps,

Hi,

I understand your confusion, which originates from the fact that PRESSURE is an old option of FREQCALC that indeed does not apply any pressure. With this option, the structure is unchanged, the forces are unchanged, and ultimately, the harmonic vibration frequencies are unchanged. The only bit of information that is affected by this keyword is the printed value of the PV term in the thermodynamic analysis.

So, this PRESSURE keyword within FREQCALC should be used in just one way: to set the value of pressure corresponding to the structure used to run the harmonic frequency calculation, so as to have the PV term entering the thermodynamic functions (enthalpy and Gibbs free energy) right. Let me make a couple of examples:

1. You perform a full structural relaxation (atomic positions + lattice parameters). Thus, you have a zero pressure (p=0) structure. Then you compute the harmonic frequencies. If you are interested in thermodynamic potentials (i.e. enthalpy, Gibbs, Helmholtz, etc.) you should use the PRESSURE keyword and set the pressure to zero to get the PV term right in the output (otherwise by default it would be computed at p = 1 atm - do not ask me why).

2. You perform a pressure-constrained geometry optimization with the EXTPRESS keyword of OPTGEOM (let's say at 29.457 GPa as in your example). Then you compute harmonic frequencies with FREQCALC on this compressed structure. Now, again, if you are interested in thermodynamic potentials (i.e. enthalpy, Gibbs, Helmholtz, etc.) you should use the PRESSURE keyword and set the pressure to 29.457 GPa to get the PV term right in the output.

So, as I said at the beginning, the PRESSURE keyword here does not change anything on the structure/forces. It only allows you to tell the program what is the pressure of the structure you are working on, so that the printed PV term is right.

A more formally-sound way to combine temperature and pressure is provided by the quasi-harmonic approximation: See Eq. (13) of the tutorial page on the Quasi-Harmonic Approximation (QHA).

Hope this helps clarifying things a little,

Hi,

When computing (and then plotting) 2D maps of the electron density, or spin density (by use of the ECHG keyword), or electrostatic potential (by use of the POTM keyword), a plane must be specified. Now, in CRYSTAL a plane is specified by three points A, B, and C (i.e. if you specify the coordinates of three -- non rectilinear -- points, you identify a unique plane).

In CRYSTAL, you can specify the three points A, B and C in two ways:

1. You can directly input the Cartesian coordinates of the three points by use of the COORDINA keyword;

2. You can select three atoms as your three points, with the ATOMS keyword. In this case, as the system is periodic and you may need to refer to atoms outside of the reference cell, each atom is identified by four integer numbers (the sequential index of the atom within the reference cell and three indices identifying the cell where your selected atom is centered -- i.e. 4 0 0 1 for instance means atom number 4 in the list, found in cell 0 0 1, that is a cell translated by one lattice vector along the c crystallographic axis).

Now, if the three points A, B and C that you have defined are not "orthogonal", i.e. the angle \( \widehat{ABC} \neq 90^\circ\) this would produce an oblique map. To make it rectangular, you can insert the RECTANGU keyword, as shown below:

You can also change the explored range in the selected plane (relative to that identified by the three original points A, B and C) by use of the keyword MARGINS, as shown below:

Input examples can be found at this tutorial page.

Hope this helps,

Hi,

To run a calculation with a not neutral unit cell, you must insert the keyword CHARGED at the end of the basis set input block, as in:

Title
[geometry]
END
[basis set]
CHARGED
END
[SCF parameters]
END

Hope this helps,

Hi,

You can compute the electron density on a 3D grid of points and obtain data directly saved in a .cube format by use of the ECH3 keyword of the PROPERTIES module. If your system is 3D, all you have to do is insert something like:

ECH3
100
END

in your .d3 PROPERTIES input file, where 100 is the number of points in the grid along the first axis. For a cubic system, this would produce a 100x100x100 grid.

Hope this helps,

Hi,

I haven't used it in a while but I remember XCrySDen had a GUI for k path selection.

What I typically do instead is use the Bilbao Crystallographic Server as a guide. If you navigate to "Space-group Symmetry" and then to "KVEC: The k-vector types and Brillouin zones of Space Groups", you will be able to select your space group of interest and then click on "Comparative listing of k-vector types".

For instance, for your P-1 space group you get:

where you can find the coordinates of the high symmetry special points listed in the table (NOTE: if your space group admits a crystallographic cell that differs from the primitive cell, you will find both sets of coordinates in the table. Make sure you use the primitive ones to write the BAND input in the .d3 file) and also inspect the Brillouin zone:

The order at which you explore these points does not really matter (unless you want to reproduce a specific path from some reference plot), as long as you explore most/all of them.

Hope this helps,

Hi,

Would you please share your full input file?

Dear Aparajita,

Gryffindor said in Problem with restarting CPKS calculation:

I’m reaching out again regarding the CPKS step. After several attempts (and a fair bit of persistence!), I was finally able to complete the SCF calculations.

Good!

Gryffindor said in Problem with restarting CPKS calculation:

As per your previous suggestions, I ensured the SCF was converged beforehand, but unfortunately, the CPKS has never been able to finish successfully on my side.

Is there a reason for switching DIIS off in your CPKS calculation?

Also, you can change the convergence criterion for the CPKS with the TOLALPHA keyword. In your case, it may be enough to run it with:

CPKS
TOLALPHA
2
END

Gryffindor said in Problem with restarting CPKS calculation:

Since I need these results quite urgently, I was wondering if you could try running it on your end to see if there's anything I'm missing?

I am afraid I can not. It is a huge calculation that you are running on 800+ atoms/cell and I do not have the computing power for this.

Dear Aparajita,

It is strange that the fort.9 unit is empty. May it be a problem of the script in copying back that unit from the scratch folder to the working directory?

Anyway, you can try to trick CRYSTAL in this way:

• By inspection of your output file:

CYC  13 ETOT(AU) -1.952535840054E+05 DETOT -1.58E-05

the energy difference is down to 10^-5 at cycle 13. So, you can try to run the calculation with a low energy convergence threshold of just 10^-4 with something like this:

TOLDEE
4

and the SCF would be considered as converged for the program. In this way the calculation is not killed and probably you will get your fort.9 unit,;

• you can then use it to do a restart calculation with the GUESSP keyword (and by tightening the energy convergence threshold to something like TOLDEE 7, or 8):

GUESSP
TOLDEE
7

Hope this helps,

job314 said in No space left on device:

those are huge HPC nodes… they can’t be possibly out of disk…

On our cluster, although the total disk space is huge, there are limited disk quotas for each user. Maybe it is the same there for you?

job314 said in No space left on device:

will it affect my convergence or calculation speed?

Possibly, but not much I think.

I can not tell the origin of the problem for sure but one thing you could try is to use the HISTDIIS keyword to set a lower maximum number of Fock matrices to be stored on disk for the DIIS convergence accelerator.

You could try with something like:

HISTDIIS
10

or less.

Indeed, this piece of your output suggests that all Fock matrices from all previous SCF iterations are stored:

job314 said in No space left on device:

DIIS ACTIVE - HISTORY: 23 CYCLES

When the system size is large and the SCF takes many iterations to converge, this may require lots of data to be stored on disk.

Let me know if this helps.

Hi,

From what I see you get very few negative values. Typically, it is an artifact of the interpolation method. Sampling the DOSS at more energy points and/or changing the number of Legendre polynomials used in the DOSS expansion solves the problem.

job314 Yes, this makes sense now that I think about it. Still, it would be advisable to restart the frequency job from the optimized geometry for one technical - and yet important - reason: the so-called FIXINDEX strategy used in CRYSTAL.

In the evaluation of the integrals, a list of interactions to be computed is defined at the beginning of the calculation and kept constant (the list, not the interactions) throughout the calculation to ensure numerical smoothness. This list is generated from the starting geometry in the input. It is better for it to be the optimized one. In many cases this may not be critical but it could lead to numerical issues if the inputed geometry is far from the equilibrium one.

PeterRemoto At the moment I am afraid I do not have an explanation for the difference you experienced between CRYSTAL17 and CRYSTAL23 as I am unable to reproduce the erratic behavior with CRYSTAL23.

PeterRemoto I have tried to restart your calculation with CRYSTAL23 following my step-by-step recipe (described at https://forum.crystalsolutions.eu/post/339) and it worked.

This is what I did:

• I prepared an input file to run the harmonic frequency calculation, without intensities, I ran it and I killed it in the middle of the construction of the Hessian. From this incomplete frequency calculation, I obtained the FREQINFO.DAT file (I can not upload it here as it exceeds the maximum allowed file size), the external unit with the density matrix, i.e. fort.13 unit, and the external unit with the wavefunction, i.e. fort.9;

• I prepared an input file to restart the frequency calculation and provided the FREQINFO.DAT, fort.13 and the fort.9 (renamed as fort.20) files from the previous step, and ran it. The calculation of the Hessian restarted correctly, with the new SCFs converging nicely (see the attached SCFOUT.LOG file). I then stopped the calculation not to use too much compute power on my cluster.

If you follow this step-by-step process you'll be able to safely restart your frequency calculations with CRYSTAL23.

Hope this helps,

PeterRemoto I started drafting a reply but encountered problems in uploading the files. Will try later.

PeterRemoto I just started running some tests on this case. I will keep you posted on how it goes.

Dear Georg,

It is correct. Note that of course if you build a supercell, band folding will bring back at Gamma phonons that would be formally assigned to other k points, which in the end allows for QHA calculations also with phonons out of Gamma.

For instance with something like:

SUPERCEL
2 0 0
0 2 0
0 0 2
QHA
END

you would be building a 2x2x2 supercell (relative to the primitive one), and performing a QHA on it (i.e. from harmonic frequencies computed on the supercell, and thus equivalent to phonons at 8 k points).

Hope this sheds some light on the matter,