ABINIT Discussion Forums

Hi Positronner, (not that this is not the correct forum place for this topic) Thanks for pointing us a bug, apparently appeared since a modification of Abinit default behviour related to forces calculations. If you are not interested in structure relaxation, you can simply add this in your input fil...

Hi,

This doesn't work? This is strange...
On my MacBook it works.

You could try this or, last resort: This should do the job.

Good luck

OK, I was able to reproduce the issue. A new version of the homebrew formula is now available. If you use the bottle, a wrapper to the runtests script will be installed. If you recompile from scratch, you have to use the -with-testsuite option. You'll be able to run the test suite with the 'ABINIT-r...

Dear Outerplanets,

To analyse the problem, we need more information :
- how did you install abinit via homebrew (using homebrew-science or the new formula provided on abinit github?)
- what did you exactly type to lauch the runtests.py script?, from which directory?
- did you use "brew clean abinit"?

Dear all, Some comments... * DFPT+PAW+U is not guaranteed, especially in 8.10.3. This is an on-going development... that will be better in v9.0 (january). * The warning "The matrix seems to have high value!" is just a warning. It means -- as explained -- that the PAW datasets is a bit hard to conver...

Dear Zhishuo Huang, I suppose you had a look at : Phys. Rev. B 92, 125113. In this paper several details are given about PAW datasets to be used for positron calculations. In the case of defect, it is strongly recommended to use specific PAW datasets using semicore states (to be built by yourself us...

Dear pauwawa87, Thanks for pointing us this bug. It is related to the use of ionmov = 5, which is not very common (for relaxation, we often prefer to use a Broyden algorithm). The fix has been submitted for the next version of Abinit. In the meantime, you can work around the problem by adding "...

Dear Xavier, Thank you for detecting this bug. Fortunately, the concerned file is not used by Abinit (because abinit uses m_xmpi MPI module ), but only in the standalone version of the PAW library. To compile abinit with gcc8, just comment temporarily the concerned lines. The correction has been mad...

Dear johnbrehm, I think the NEB with variable cell is not implemented (or, at least buggy). Im pretty sure you'll not succeed in running it. This should be forbidden by the code but apparently it's not. Sorry for this. There is a hope for the future: one of the developer is currently working on that...

Dear Ron, I think I have found a bug fix from your test case. Apparently, the parallelism over atoms (automatically activated) was not compatible with prtden<0. So, I can propose 3 ways to run your case: 1- deactivate parallelism over atoms, setting paral_atom 0 in the input file (will be more memor...

Hello, I made a few tests and found that the problem is not coming from the k-points but from the "non-symmoprhic symetries" (symetries with a translation vector). This is mentionned in the berryopt documentation (see m), but only for PAW calculations. It seems that it is also an issue for...

BTW... Why do you use the screened_coulomb_kernel function? There is only one way to activate it: using the HSE hybrid functional in the PAW formalism. This feature is not opened and totally buggy at present. HSE is available for norm-conserving pseudopotential, not in PAW. We are working on it. The...

Dear Dominic, Concerning the exponential function: Have you first tried to link an efficient math library? For exemple, you can link the gsl library (m) by: with_math_flavor="gsl" Concerning the opernlb function: the computational load depends strongly on the system you are studying. If th...

Dear Hazem, For the time being, it is not possible to restart a non-self-consistent calculation with Hybrid functional (Fock) from a density file. It make sense because Fock operator depends directly on the WF. In a future realease of Abinit, it will (for sure) be possible to restart from the WF. Me...

Are you sure that you're using abinit-8.0.8 ?
This error message doesn't exist anymore in abinit v8 (and Fox is no more supported).
Check the ABINIT version you're using.

Ok, found! it seems that you have identified a (recently introduced) bug. Thanks! First of all, I guess you could explain some differences between version 7.10.5 and version 8.0.8 version. The main one is that the default value for tsmear (smearing temperature) has changed: from 0.0.4 Ha to 0.0.1 Ha...

Dear bmatt,

It's difficult to help you without an input file, showing that 7.10.5 and 8.0.8 give different results.

Hello Natalie, I confess that the manual is not clear about the pawoptmix input variable (which was introduced during the debugging process and should not really be used). pawoptmix has no effect on the nature of the mixed objects. It has just an effect on the mixing algorithm (Pulay): ABINIT always...

Hi,

I tried to reproduce your problem:
- official abinit v7.10.5
- ../../tests/runtests.py --loglevel=INFO -v -v -n 2 --pedantic atompaw

...and everything went fine.
(except some errors in logging due to my python version)

Hi, You cannot launch the atompaw#02 automatic test alone. It has to be chained with the test atompaw#01 because the latter is suppposed to generate the pseudopotential file. So, instead, launch: ~abinit/tests/runtests.py atompaw[01:02} (see "test_chain = t01.in, t02.in" in atompaw/Input/t...

Hi, I have corrected this problem in the dev version of Abinit (will be available in Abinit v8)... In the meanwhile, there is an easy "patch": if you don't need the stress tensor (it is likely), you can put "optstress 0" in your input file... and everything should run fine. Regar...

Hi Joe, I finally took time to look at this issue. I ran the v5[05] and ... guess what... everything is correct. I got the same values in the EIG file and in the output file (the correct eigenvalue derivatives), at least on my laptop. So, ... try again in a clean directory.. on another computer... a...

Hello,

The electron-positron was not fully comptaible with paral_kgb=1 in the 7.8 version.
Try first to use the last 7.10 version.
Also the pawstgylm=0 keyword was buggy, if A remember correctly; I think it;'s corrected now but you should try without it.

Hi Eric, I think the last printed message has nothing to do with the crash; it is just the last printed message... If you run in parallel it can occur that the relevant error message is not printed. Is it possible for you to run this job in sequential? just to see if an different error message appea...

Hi Joe, You should have a look in routines doing a similar job, for instance hartre.F90. I see several modifications to perform: - eliminate mpi_enreg_seq and replace it by the true mpi_enreg (passed as argument) - call the ptabs_fourdp routine to inialize (if necessary) the parallel fft tabs - add ...