ABINIT Discussion Forums

Thank you very much! It has been some months. I do not see a mention in the 8.8.3 release notes. Could you please tell me the status? Thank you!

Ron

Thank you very much! I was wondering if there was any update on when this will be available?
Sincerely,
Ron

Someone must know the status?! Apparently it has been years and no response to the forum?

It has been a few months and there has been no response. Someone must know the status of the vdw code in abinit? Thanks!
Ron

Things are worse than I realized. After much work with abinit, seems the vdw_xc 2 flag (or 1) does nothing! This is true even in the test case abinit-8.6.1/tests/vdwxc where running without all the vdw flags in the example gives exactly the same result as running with them! It would be great if some...

The vdw test in abinit-8.6.1/tests/vdwxc/t03.in gives the results in abinit-8.6.1/tests/vdwxc/Refs/t03.out , but also the sa,e results if I remove all vdw lines in the input. So: Unit cell acell 3*10.0 angstrom chkprim 0 # Atoms ntypat 1 znucl 4 natom 2 typat 1 1 # Positions xcart -1.5 0.0 0.0 1.5 0...

Apparently this is still the case. Including df2 does absolutely nothing but print the variable out. I trusted abinit too much. At least an error should be printed if one tries to use an unimplemented feature.

Well I ran without the vdw flag, and get the same results, so it seems that vdw_xc 2 was just ignored with no error. No wonder results are terrible.

I am getting crazy results with abinit 8.6.1, with huge negative and positive frequencies fir the acoustic modes, and even the highest frequencies are crazy, like 12000 cm-1 instead of 3000 cm-1. I have relaxed the structure well with abinit and used tight constraints for the SCF WFs. I am using non...

I tried turning on timings with timopt 3 and timopt -3 and all I get for a single total energy iteration: IO operation completed. cpu_time: 0.0 [s], walltime: 0.1 [s] outwf with iomode: -1, cpu_time: 14.63[s], walltime: 48.62 [s] Proc. 0 individual time (sec): cpu= 12153.9 wall= 12414.3 overall_cpu_...

I am wondering if anyone understands why the efield calculations are so slow, and if anything can be done to speed them up. Only k-point parallelism works, and for a 42 atom cell it takes 1.5-5 hours per single total energy cycle.

make_grad_berry should be replaced with the attached version. This is not related to the BUG reported before.

I spoke too soon. The self-consistency normally runs with paral_kgb 1 (that even occasionally dies) , but the berry's phase parts (data sets 3 and 4) always crash with allocation problems with paral_kgp 1 . I tried many different sets of processors, autoparal, and manual setting of parallelization p...

I recompiled everything with no openmp and it works fine now!

This job runs OK with only k-point parallelization, but crashes for all sets of other parallelization I have tried. I used autoparal 1 paral_kgb 1 max_ncpus=128 to find recommended sets of parameters, and they all crash for the latest version 8.6.1 as well as earlier versions. This is with the lates...

I recompiled 8.4.3 with the debugging intel MPI library and now it is running. Not sure if that was the fix, or if something else was corrupted in the build. I simply did
export I_MPI_LINK=dbg_mt
configured and make
We will see.

Again, thanks for ll the help! But I seem to be having the same or similar problem after setting prtden to 1, switching to ONCV norm-conserving pseudopotentials, setting up a spin-polarized computation explicitly, and getting rid of +U. ITER STEP NUMBER 1 vtorho : nnsclo_now=2, note that nnsclo,dbl_...

Thank you so much! So as I understand it, there is way to do DF2 and DFT+U, because I think DFT+U requires PAWs. This kind of sinks what I wanted to do. I either have to drop the +U or use a different vdw functional, if I understand properly. Thank you so much for figuring this all out!

Ron

Dr. Andreas Marek, ELPA developer, was kind enough to update the abinit routine m_elpa.F90 (attached) to work with the current ELPA distribution (elpa-2017.05.001 ) as a backwardly compatible interface. You need to fool with the build process, but then it seems to run fine and with great performance...

I finally got an actual usable error message. It is:
-- !BUG
src_file: m_pawrhoij.F90
src_line: 1179
mpi_rank: 0
message: |
Wrong sizes sum[nrhoij_ij]/=nrhoij_out !
...


leave_new: decision taken to exit ...
application called MPI_Abort(MPI_COMM_WORLD, 13) - process 0

I am getting a crash after the first iteration for a large system with LDA+U and DF2 vdW and have not been able to get past this changing many things. The error looks like: ETOT 1 -397.67895452777 -3.977E+02 2.061E-03 8.769E+05 scprqt: <Vxc>= -2.6931088E-01 hartree Simple mixing update: residual squ...

Has anybody ne ported elpa2017 in abinit? The interface has changed signifucantly, but elpa niw support intel knights landing (KNL) and works well with qe.

I built ABINIT 7.10.5 and ran with the same input and environment, and it seems to run OK. So it does seem to be a problem with ABINIT 8. I attached the beginning of the output for 7.10.5 . I also include abinit -b output from both builds. Thanks,

Ron

I have been trying to do constant D computations wth abinit and having occasional success but some structures always crash. I compiled initberry and berryphase_new with bounds checking and extra printouts, and it seems clear there is a problem. Usually it just crashes with no useful traceback or err...

OK, the problem I guess is compiler bugs. Adding: -fp-model precise -fp-model source -O2 -traceback to the compile leads to correct behavior, although I still had one job crash in parallel diagonalization. Running that job on more processors fixed that. The full configure line on superMUC that works...