Experienced Users group

undefined

Hi Jonas,

that depends a bit on what you mean by "not converging". Here the discussion is about converging the quantities of interest with respect to the underlying computational parameters, in this case k-point sampling and simulation cell size. You can see that the lines eventually get "crammed up" as the number of k-points and supercell size increase.
At the bottom of the S vs. T graph it starts with 1 k-point and 2 atoms with the obtained curve having a certain profile. When the simulation contains 4 k-points and 8 atoms, the obtained curve is quite far off from the first one, to put it simple, or not yet converged. With further increase of k-points and number of atoms in the supercell, this discrepancy diminishes and one gets very close to the black dots (which I presume are experimental values of high-quality reference calculations).
If by "not converged" you refer to the fact that the profile of the entropy is not plateaued at high temperatures, that is a whole other discussion

Hope this helps,

Cheers,
Aleks

undefined

Dear QMQDCHEM,

The calculation of a band structure is not bound by the underlying symmetry of the system (speaking of 3D bulk). The key ingredient is the path in the Brillouin zone of the reciprocal space (which depends on the reciprocal lattice, which further is univocally defined by the direct lattice). In other words, a good path needs to be identified, and there are several ways of doing so.

One can consult standard databases, such as the Bilbao Crystallographic Server (http://webbdcrista2.ehu.es/cryst/get_kvec.html) or use automagic tools like SeeK-path (https://seekpath.materialscloud.io). The format of the INPUT file otherwise remains the same for all space groups.

Hope this helps!

Cheers,
Aleks

undefined

Dear andrejsc,
Indeed, every system behaves slightly different and there is no "one size fits all" rule as to how to stabilize the SCF I would suggest testing further increasing the last two TOLINTEG numbers, as they are crucial. Something like 8 8 8 20 40 might be needed. A higher FMIXING could be tested as well, but one has to be careful not to get stuck in an unphysical solution then.
Cheers,
Aleks

undefined

Dear andrejsc,

If you have a closer look at the behaviour of the SCF itself, you will notice the following:

CYC   0 ETOT(AU) -3.272838998405E+04 DETOT -3.27E+04 tst  0.00E+00 PX  1.00E+00
CYC   1 ETOT(AU) -3.265246918926E+04 DETOT  7.59E+01 tst  0.00E+00 PX  1.00E+00
CYC   2 ETOT(AU) -3.265127076720E+04 DETOT  1.20E+00 tst  2.43E-01 PX  1.08E+00
CYC   3 ETOT(AU) -3.251404571451E+04 DETOT  1.37E+02 tst  2.32E+01 PX  1.52E+01
CYC   4 ETOT(AU) -2.643556189218E+04 DETOT  6.08E+03 tst  2.15E+01 PX  7.55E+02
CYC   5 ETOT(AU)  7.316550078797E+03 DETOT  3.38E+04 tst  9.30E+03 PX  1.32E+03

The "CYC 5" line is the last that was printed before the simulation crashed and it points to the source of the error - the SCF energy went into the positive. This is not entirely uncommon for larger systems with a somewhat complex magnetic structure. A few things things could be tried based on your input file: i) increasing the mixing percentage of the Fock/KS matrix (keyword FMIXING) or ii) increasing the last two numbers of the integral tolerance (TOLINTEG).
But if you abandoned the case, might not of immediate use to you, but hopefully to someone else stumbling upon similar errors

Cheers,
Aleks

undefined

Glad to hear you made it work! It seems it was a missing fort.xyz file? For reference if someone else stumbles upon the same issue...

Regarding OPT+FREQ, I don't think anyone has anything against it, just easier to debug if the number of "parameters" is kept minimal

Cheers,
Aleks

undefined

Ahh, I see, thanks for the heads up.
I can reproduce your error indeed...the geometry seems fine, and the displacements also do not show any unreasonable configuration. Given that the system has 600 atoms, I do get an "out of memory", but cannot rule out that this is due to the limited size of the cluster I am using...
One trivial question: did you make sure to have all the fort.* files from the frequency calculation in the folder where you run the SCANMODE keyword?
Cheers,
Aleks

undefined

Dear Jonas,

Seems there is no output file in your uploaded file? The INPUT file seems alright.

Without seeing your output file explicitly, I would imagine that the SCF for the first geometry for the scan along the mode has reached its maximum number of steps or has stopped for any given reason. I recommend checking (or uploading) the SCFOUT.LOG file, as it is there that the SCF cycles of each geometry are being printed. If that is the case, it is most likely an issue with the geometry step being too large (i.e., too far from the minimum) and you can try reducing the step size or the start/end points.

Hope this helps.

Cheers,
Aleks

undefined

Hi Similt!

You may want to try the LEVSHIFT option, see page 118 of the CYSTAL User's Manual. With this keyword you can better separate occupied and unoccupied states.

Let me know if it helps,
Eleonora

undefined

Hi Pierre,
Could you upload your input/output files for cross-checking? And and relevant fort files that contain some errors.
Cheers,
Aleks

undefined

Either way, seems you got your geometry for further optimization
Cheers,
A

Experienced Users

Posts

Member List