Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - sukhito teh

Pages: 1 [2] 3
16
Dear developers and users,
May I know if there is a way to change the fermi level in calculation of optical conductivity? From what I understand, anomalous hall conductivity (AHC) can be calculated from optical conductivity at E=0. But with the default fermi energy, I can only calculate AHC at the fermi level. Thanks you for your time.

best regards,
Sukhito

17
A small update: When using filling_method=Anisotropic, HSE06 also leads to solution with a band gap.

Yes, LDA+U also leads to result with band gap.

18
Thank you for the helps!

19
ADMM is indeed a method to speed up the calculations, but in theory should not really influence the results. It might be a random effect in the numerics, but no bandgap vs a bandgap is not a small effect. I wonder if we can solve the time-reversal issue and combine if with HSE06 (no ADMM) to see a band gap there, and then just use ADMM as intended to speed it up.

Can you share a few more details about how you determine the time-reversal didn't work?

Yes, I believe it is numeric random effect, right now I can't reproduce the band gap opening's results (with ADMM is on). I initially ran a calculation (with ADMM on) and able to open the band gap, I later rewrite the script with some minor changes in parameters and using the previous calculation (with band gap) as initial state, this indeed reproduce band gap solution as expected. However, I had forgotten what parameters had been used in the initial run and cant reproduce the band gap result without reading the "right" initial state, so the band gap opening is probably unrelated to ADMM. May I know if there is a way to initialize different density matrix during beginning of  calculation (without using pre-converged calculation)? Or is there a way to fix selective occupation state throughout the calculation?

I also tried a dozen of calculation with and without ADMM, in some cases (e.g. MnO), I do notice significant difference (band gap differ by about 10%),  not sure if such a difference is within reasonable range.

Regarding the time-reversal symmetry, in the bulkscf.log file, the "Diagonalization solver parallelization report" states there are 260 kpoints in 8x8x8 MK grids, so I assumed the time reversal symmetry is on (please correct me if I am wrong). 


20
Define "doesn't work". The calculation ran fine and I don't any density of states being calculated so how can you tell there is no band gap?

You might want to try the Dielectric Dependent Hybrid model as discussed in https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8007096/ where FeO is an included example. This model is available QuantumATK using

exchange_correlation = HybridGGA.HSE06DDH

(cf. https://docs.quantumatk.com/manual/DFTLCAO.html#dielectric-dependent-hybrid-functionals)

I am so sorry that I didn't make it clear in my previous reply, doesn't work refer to unable to turn off the time reversal symmetry. Anyway, I tried few more approaches and these are the summary:
1. Using SG15 basis + PBEU --> no Band Gap
2. USing SG15 basis + HSE06 --> no Band Gap
3. Using Dojo basis +HSE06 --> no Band Gap
4. Using Dojo basis + DDH --> no Band Gap
5. Using Dojo basis + local DDH --> no Band Gap
6. Using Dojo basis + local DDH + ADMM --> band gap open!

I am not sure what is the explanation for this, but I am really thankful for your help. The ADMM is interesting, it speeds up the calculation for more than 10 times (per step), although it takes much larger steps to converge. Have a nice day!

21
Thank you for your reply. I tried rerun with this setting, but it doesn't seem to work.

22
Dear Staffs and Users,
I noticed that both GGA+U and HSE06 failed to open the bandgap of FeO. FYI, calculations with VASP can have similar issue, but those can usually be solved by turning off the K-Points symmetry. However,  even if I am setting use_symmetries  = False in AlgorithmParameters, the calculation still assume time reversal symmetry, so I am not sure if similar approach would solve the problem. May I know if there is any suggestion to solve this problem?
Thank you for your time.

best regards,
Sukhito

23
We are planning to support this analysis in a future version of QuantumATK. For now, you can use the attached compiled module. The file also contains an example of how to use it.
The alpha values are saved as a real-space 3d grid in the HDF5 file, and can be analyzed as usual in NanoLab via the Grid Tool etc

Dear Mr Blom,
According to this paper (https://pubs.acs.org/doi/abs/10.1021/acs.jctc.7b00853), they neglect the derivatives of mixing functions to save computational costs, thus the forces cannot be treated as derivative of energy. QATK doesn't support force calculation for this exchange correlation either, does the same approximation has been used in QATK?

24
Our MD experts have looked at the details of this case. All cases where we observed that energy was not conserved in NVE, it was caused by a too large time step for the chosen potential, when it e.g. uses a spring that is too stiff, or it can also happen with ReaxFF. In the case here, we didn’t see any obvious reason, but also noticed that it is a slow drift which happens over 100s of ps. On this timescale it is not necessarily something unusual given that the numerical integration with a finite time step is an approximation and does not guarantee to conserve the energy 100% exactly. And your potential uses harmonic springs, which have fast vibrations, which would normally indicate a relatively fast time step to accurately conserve the energy.

So, the main suggestion is to lower the time step.

Thank you for your advice, I would play with the time step parameters to see if the results improve.

25
We are planning to support this analysis in a future version of QuantumATK. For now, you can use the attached compiled module. The file also contains an example of how to use it.
The alpha values are saved as a real-space 3d grid in the HDF5 file, and can be analyzed as usual in NanoLab via the Grid Tool etc

Thank you for the quick response, this is really helpful. Have a nice day.

26
Dear users and developers,
Is there a way to extract local g or local exchange fraction when implementing local dielectric dependent hybrid in DDHCustomExchangeCorrelation? It would be useful for analysis or fitting ddh paramters.

I also tried to calculate the alpha based on the average g using the attached script, however the value always  differ ( usually about 10%) from the value given by ...exchangeCorrelation().exactExchangeFraction(). Other than that, I also wonder if there's a faster way to obtain derivative of electron density other than using the iteration method as stated in the attached script.
Thank you and have a nice day.

27
Yes, I think you are right about the tags.

I don't personally have so much experience with NVE, but have you checked with smaller time steps?
Maybe also use a tighter accuracy for the Coulomb term or try some of the other charge equilibration methods like CoulombDebye which is actually the one used in Pedone

Thank you for your suggestion. I had tried the above methods and the problem (energy decreasing in NVE simulation) persists. I recently used the same force field for NVE simulation using LAMMPS, though I haven't evaluate the accuracy of the results yet,  the energy of the NVE simulation is conserved, so I think the forcefield isn't the cause of problem above. It would be great if QuantumATK staffs can check if similar problems happen for MD using other bonded potentials.

28
I note that you didn't add the torsion parts of the potential in the papers, but maybe that is just a small term.

However, upon opening the forcefield from the HDF5 file in the GUI (in the Editor) I think it might be possible that your forcefield generation script is not working as intended, with respect to the tags etc. There are terms generates for "Mo" with tag "sio2", and "Si" in "mos2" and other mismatched cross-terms it seems.

Thank you so much for helping me looking into the details. The torsion term (for sio2) was ignored in the referenced paper as well, and I am aware of those mismatched cross-terms, they are there because I use TremoloXPotentialSet.setTags() (similar to example given in https://docs.quantumatk.com/tutorials/combining_potentials/combining_potentials.html), I think the wrong cross-term would simply be ignored as long as I tag my structure correctly.

And if I optimize the structure before running the NVT MD, then the calculation can run smoothly (so I considered the problem solved). However,  when I later use the results of NVT MD (configuration + velocities) to continue as NVE-MD simulation, the energy is not conserved. Again, such problem doesn't exist if if use Pedone_2006Fe2 force field.

I would try using bonded potential on other system to see if the problem persist; before that, do you have any idea what can be the cause for non-conserving energy in NVE MD run?

Thank you for your attention.

29
Maybe there are some parameter in the forcefield that causes very large forces on the atoms?

The "leaving the domain" only is an issue when running an MD calculation in parallel over MPI, and using domain decomposition. This can provide a nice performance boost, if each domain contains 1000+ atoms, as in your case. But, I would first start to check if the potential is generally stable by just running in serial. With 27000 atoms it will still be relatively fast, esp. if you run threaded on 16 cores or so. I don't see your submit script or output, it would be useful, but general advise is only use MPI if you go beyond a single node, since the MPI and OpenMP performance intranode is about equivalent, and OpenMP is easier and potentially more stable.

Also, you can save some code by using
Code
from AddOns.VASPPlugins.IO import readPOSCAR
bulk_configuration = readPOSCAR("./POSCAR")

I think you are right, I tried to relax the structure with the force field and the force is unreasonably large. I would look into the parameter used.

30
Maybe there are some parameter in the forcefield that causes very large forces on the atoms?

The "leaving the domain" only is an issue when running an MD calculation in parallel over MPI, and using domain decomposition. This can provide a nice performance boost, if each domain contains 1000+ atoms, as in your case. But, I would first start to check if the potential is generally stable by just running in serial. With 27000 atoms it will still be relatively fast, esp. if you run threaded on 16 cores or so. I don't see your submit script or output, it would be useful, but general advise is only use MPI if you go beyond a single node, since the MPI and OpenMP performance intranode is about equivalent, and OpenMP is easier and potentially more stable.

Also, you can save some code by using
Code
from AddOns.VASPPlugins.IO import readPOSCAR
bulk_configuration = readPOSCAR("./POSCAR")

Thank you for your reply. I tried to use single domain but surprisingly the problem persists(input and output files are included).
The parameters of force  fields are retrieved from this paper(https://pubs.acs.org/doi/10.1021/la504178g), although the paper use these parameters for cristobalite phase (while I used it for quartz phase),.
https://pubs.acs.org/doi/10.1021/la504178g

Pages: 1 [2] 3