Hi Mo,

I believe the correct way to remove an atom while keeping the basis set is to use the GHOSTS keyword (see page 82 of the User manual) instead of ATOMSUBS, without modifying the original basis set.

Could you try that and check if the energy makes sense afterward?

GiacomoAmbrogio Great! It works now! Thanks a lot!

Hi Giacomo,

thank you for your answer.
You are right, D4 is mentioned in the JCTC article as "further developments to the code", which I misunderstood.
The article clearly mentions it as future development, not as list of further developments not laid out in detail in the article.

Thank you for your help in clarifying this.

Kind regards,
Georg

Dear Jonas,

A good option just for visualization is using the CRYSPLOT webpage, which includes a tool for this based on JSMol and only requires your output file. Another option would be to use JMol, which requires a local installation of Java. Using JSMol locally is not an easy task, as its developed for its usage on web servers. If you really need to do so, you can find some guidance in the the following sites (it will depend on which browser you want to use, and probably also on your OS):

Recent thread on usage of JSMol locally JSMol Wiki post

Hope this helps.

Marcos

Hi Jonas,

Would you mind adding the INPUT file as well, for easier checks?

It generally doesn't look too bad, I would wait until the calculations finishes and see how the results look like. There is nothing obviously "wrong", but you can always try tightening the convergence criteria. See earlier post for a great overview of options (especially if you notice in the end that you have negative frequencies appearing!):
Earlier post on "Imaginary frequencies", see comment by Prof. Erba
I personally wouldn't run a geometry optimization together with a frequency calculation, I would split them in too, but I guess that is a matter of taste as the code can handle it : )

Cheers,
Aleks

Hi,

I am trying to perform a calculation to compute the defect formation energy. First I performed geometry optimization in Unit cell. Used the optimized structure to make a super cell and removed a particular atom. Due to system size and memory issue with Pcrystal, I used MPPcrystal calcualtion.

The first SCF run was OK (in terms of atomic charges) but due to time limit the calculation was not converged. So I used fort.79 file as initial WF GUESSP to continue the SCF run. But the Total atomic charges is not right, even in the second cycle of the SCF run. As can be seen in output file, the atomic charge change from 8 to 2 in the Run2 output file. Could you kindly guide me regarding my mistake.

Thanks for your help in advance

INPUT_Run1.d12
INPUT_Run2.d12
OUTPUT_Run1.d12
OUTPUT_Run2.d12

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.

Thanks a lot! I will take your advice.

Dear Jonas,

first of all, 450 atoms is impressive indeed!
Now moving on to a few comments/thoughts that might be of use to you.

i) From your input file, it appears you still have a few symmetry operators in your simulation cell. Worth checking whether/if that applies to the atoms in the Fe-centred octahedra as that might force a particular solution to the electronic configurations.

ii) Given that your octahedra are not aligned with any particular crystallographic axis in your system, it is not always straightforward to extract the (d-)orbital occupations. You can have a look at the ROTREF keyword in the manual by which you can rotate the eigenvectors in the properties calculation to orient the frame along a principal axis.

iii) In Scenario 1 you are right - you removed 1 H atom, from which indeed the symmetry of the octahedron has been reduced/broken. You could test the case without "neutralization", to see whether the extra electron would stay on the site or delocalize...formation energies might be a good guide...?

iv) Scenario 2 is a bit more complicated. Given that you removed a whole NH4+ tetrahedron, I would expect significant structural distortions occurring in the surrounding of the defect. From there, a conducting state might be not so unrealistic - did you optimize the atomic positions and/or cell parameters following the inclusion of that defect? If so, could be worth seeing where the metallic states originate from (e.g., in the DOS or a charge density difference plot would be sufficient...don't forget SMEAR). The question is where is the extra electron from the anticipated Fe3+ ending if you remove the whole tetrahedron?

v) Finally, I guess it really depends on what you see experimentally and what would be the most representative simulation cell matching the measurements to be able to extract meaningful data for the oxidation state. What could be potentially useful is to take simple bulk structures for which you know the oxidation state of Fe (e.g., Fe2O3, Fe3O4, ...), analyse the corresponding charge densities (e.g., Mulliken) and have a reference state for comparing the charge on the Fe-ion in your Struvite structure.

Hope any of this is useful.

Cheers,
Aleks

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.

It makes sense, thank you.

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.

Dear Alessandro,
thank you for this explanation!
Kind regards,
Georg

Hi Alessandro,
thank you very much for these detailed explanations!
Crystal is an amazing program, and I am just starting to explore its powerful thermoelastic capabilities.
Kind regards,
Georg

Hi Erba,
Honestly, I have ANDERSON acceleration on because I inherited a file with these keywords written in when I was taught how to use CRYSTAL for frequency calculations - and worked pretty well so far with our other systems so I thought to leave it alone (though it was more for pharmacuetical systems). Thanks for the suggestion, I'll try it out if with the original TOLINTEG 10 10 10 10 20 and see what happens.

Thanks,
Peter

Alessandro, the setback is temporary. What I really appreciate is that you gave CRYSTAL more life via user support than it ever had. I am very grateful for it

Hi,

The first data series corresponds to the first set and the second to the second.
If you need more insight on the specifics of your calculation, please share your files.

Hope this helps,

Hi,

In CRYSTAL, the most general syntax to specify exchange-correlation (xc) functionals is, within the DFT input block through the EXCHANGE and CORRELAT keywords as:

DFT EXCHANGE label of exchange functional (e.g. VBH, BECKE, PBE, ...) CORRELAT label of correlation functional (e.g. VWN, LYP, PBE, ...) ENDDFT

For certain standard combinations of exchange and correlation functionals, we have implemented single keywords. For instance:

DFT BLYP ENDDFT

is equivalent to

DFT EXCHANGE BECKE CORRELAT LYP ENDDFT

Another example (here the "XC" letters are appended at the end of the name to reflect that the functional is used for both the exchange and correlation part):

DFT PBESOLXC ENDDFT

is equivalent to

DFT EXCHANGE PBESOL CORRELAT PBESOL ENDDFT

For PBE, there are three equivalent ways to define it in CRYSTAL:

DFT PBEXC ENDDFT

or

DFT PBE ENDDFT

or

DFT EXCHANGE PBE CORRELAT PBE ENDDFT

There isn't a general rule, I'm afraid. This syntax aspects are discussed at page 134 of CRYSTAL23 User's Manual.

Hope this clarifies things a little,

Hi,

Direct piezoelectric constants of a 3D lattice in CRYSTAL are defined and computed as:
$$
e_{ci}^{3D} = \left( \frac{\partial P_c}{\partial \eta_i}\right) = \frac{1}{V}\left( \frac{\partial^2 E}{\partial E_c\partial \eta_i}\right)
$$
that is as first derivatives of Cartesian components of the polarization (c=x,y,z) with respect to strain components, or, equivalently as second derivatives of the energy density (V is the volume of the 3D lattice cell) with respect to Cartesian components of an electric field \(E_c\) and strain components, where the strain \( \eta \) is dimensionless and thus the direct piezoelectric constants have units of \( \textup{charge/length}^2 \).

For 1D and 2D periodic lattices, as the volume (V) is not uniquely defined (or not defined at all in some cases), one may divide by the length \(l \) and area \( A\) of the lattice cell instead:
$$
e_{ci}^{1D} = \frac{1}{l}\left( \frac{\partial^2 E}{\partial E_c\partial \eta_i}\right) \quad \textup{and} \quad e_{ci}^{2D} = \frac{1}{A}\left( \frac{\partial^2 E}{\partial E_c\partial \eta_i}\right)
$$
that would thus be expressed in units of \( \textup{charge} \) or \( \textup{charge/length} \) for 1D and 2D lattices, respectively.

However, in CRYSTAL for 1D and 2D lattices we do not divide by \(l \) or \( A\) , and just define and compute the piezoelectric constants as:
$$
e_{ci}^\textup{1D and 2D} = \left( \frac{\partial^2 E}{\partial E_c\partial \eta_i}\right)
$$
with units of \( \textup{charge}\cdot\textup{length} \).

Yes, these constants are physically meaningful for 1D and 2D systems. For a 2D monolayer system, for instance, depending on what you need to compare with, you can do one of two things:

keep them as they are printed in the CRYSTAL output (units of \( \textup{charge}\cdot\textup{length} \))

divide the values you get in the CRYSTAL output by the area of the 2D cell (and thus express them in units of \( \textup{charge/length} \))

I would not divide by a volume because I would not know the physical meaning of the volume of a 2D monolayer system.

Hope this helps,

Hi,

The MP2 option is no longer supported in recent versions of the CRYSTAl program. If you are interested in a periodic MP2 calculation, my suggestion is to contact Lorenzo Maschio ([email protected]) and Denis Usvyat ([email protected]) directly, who may provide guidance in the use of the CRYSCOR program.