shankar1729 / jdftx Goto Github PK

View Code? Open in Web Editor NEW

79.0 79.0 51.0 83.97 MB

JDFTx: software for joint density functional theory

Home Page: http://jdftx.org

CMake 0.78% C++ 93.49% C 1.63% Shell 1.26% Cuda 2.04% Python 0.60% HTML 0.01% TeX 0.16% Dockerfile 0.03%

jdftx's People

Contributors

Stargazers

Watchers

Forkers

abhishandy hezhengda elseviersoftwarex zhenxingwang yukisakamoto choudarykvsp xhnzhang ssthurai chen314156 darnoceloc jialema2 buck54321 joshua-sexton wangd11 realac khyeoh abc201904 ganlinwang zishengz mchandra 627450867 2013311026 jacobclary unkcpz theonov13 jizhongpeng lwk205 ngaro anjohan hwmmm1 moyulyy daisywang20 jxuucsc abagusetty stunningllama fermiq wwjcmp xitanna alighorashicmt mperezjigato eminsight rraffiu lenhanpham lyy1234567890 chrinide benrich37 mfkiwl

jdftx's Issues

Is it possible to use TB09 exchange and LDA-PW(or other) correlation in JDFTx?

Hello, dear Shankar,

I tried to use TB09 exchange functional in calculations in order to find out how well fast XC functionals work with my intermetallics. I used JDFTx, linked with LIBXC 4.
Unfortunately JDFTx emitted error after LCAO minimize :

[user@localhost 16x16x16_TB09+LDA]$ jdftx_gpu -i X.in -o X.out
Functional 'Tran & Blaha 09' does not provide an implementation of Exc
Functional 'Tran & Blaha 09' does not provide an implementation of Exc
Functional 'Tran & Blaha 09' does not provide an implementation of Exc
Functional 'Tran & Blaha 09' does not provide an implementation of Exc
Segmentation Fault.
Segmentation Fault.
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------

I tested lda-c-pw, mgga-c-tpss as correlation functional. But with the same result. I tried mgga-c-tpss as hint from here http://listserv.fysik.dtu.dk/pipermail/gpaw-users/2017-March/004576.html

Is it possible to use this functional? If yes, could you give me some hints how to use it?

Best wishes,
Igor.

The input file I tested is below:

lattice 4.4081001282         2.2040500641         2.2040500641\
        0.0000000000         3.8175266934         1.2725088978\
        0.0000000000         0.0000000000         3.5991986830

        #scale angstrom to bohr
latt-scale 1.889725989 1.889725989 1.889725989

ion-species SG15/$ID_ONCV_PBE.upf
#ion-species GBRV/$ID_lda.uspp

#U-J for Zn d10 orb 5eV [Ha]
#add-U Zn d 0.183745167502


cache-projectors no
coords-type lattice    
ion Li 0.125000000         0.125000000         0.125000000 0
ion Li 0.875000000         0.875000000         0.875000000 0
ion Zn 0.375000000         0.375000000         0.375000000 0
ion Zn 0.625000000         0.625000000         0.625000000 0


#for 300K
elec-smearing Fermi  0.00095


converge-empty-states yes

elec-cutoff 40
#100
#50
elec-n-bands 30
#30

kpoint-folding 16 16 16 # 
kpoint 0 0 0 1 # gamma-centered k-point mesh
#fftbox 320  480  600

#dump-only



electronic-scf \
nIterations 200 \
energyDiffThreshold 1e-8

elec-ex-corr mgga-x-tb09 mgga-c-tpss
#mgga-x-m06-l mgga-c-m06-l
#hyb-PBE0
#hyb-HSE12s
#hyb-HSE06
#van-der-waals


density-of-states Total Occupied Total


dump electronic state forces dos
dump End DOS CoreDensity ElecDensity  State EigStats lattice  IonicPositions 
#All

#wavefunction read X.wfns 24 100

initial-state X.$var
dump-name X.$var

The out-file with results of runs of jdftx, jdftx_gpu with different parameters is attached.

X.out.txt
jdftx-stacktrace.txt

Large energy shifts in monolayer MoS2

Hi Shankar,

I am trying to look at an MoS2 monolayer cell of larger size. I have noticed there are instances in which the total system energy will radically change with slight changes to the input file. These changes are sometimes not even related to the system, but instead the computational resources. I can only suspect that this may be somewhat related to the Coulomb truncation, but I am not too sure. The individual changes which seem to introduce the shift include:

Changing the charge density cutoff from 80 to 100 hartrees (it works well at 80 hartrees, but surprisingly reverts to a much different -8000 ha solution at 100 hartrees)
Changing the jdftx_mempool_size by 100 MB.

I have attached the respective output files here in case they are useful.

I've tried to see if this was a pseudopotential issue but I've noticed this for both norm-conserving and ultrasoft. I was wondering if you had any thoughts on this or if I was doing something incorrectly. Thank you for your help, as always!

Regards,
Chris

outputs.zip

jdftx through the ASE interface

Hi, everyone
when I use jdftx through the ASE interface to calculate the bond length of CO molecule, however, it not work, could you help me?

this is wrong message: Input parsing failed with 2 errors (run with -t for command syntax)

In my views, it can't add pseudopotential, however, I already modify the paths.

please tell me if you need any other information.

best wishes

co.zip

Compilation error using icc in file core/Coulomb.cpp

Dear @shankar1729, I have encountered error when trying to build jdftx-1.4.1 using Intel compilers.

Here is the output of make:

Scanning dependencies of target PseudopotentialLibrary
Scanning dependencies of target jdftxlib
[  0%] Building CXX object CMakeFiles/jdftxlib.dir/core/AutoThreadCount.cpp.o
[  1%] Building CXX object CMakeFiles/jdftxlib.dir/core/BlasExtra.cpp.o
[  2%] Building CXX object CMakeFiles/jdftxlib.dir/core/Blip.cpp.o
[  2%] Building CXX object CMakeFiles/jdftxlib.dir/core/Coulomb.cpp.o
/home/efefer/mysoftwares/jdftx-1.4.1/jdftx/core/Coulomb.cpp(57): error: no suitable constructor exists to convert from "int" to "std::shared_ptr<Coulomb>"
  		default: return 0; //never encountered (to suppress warning)
  		                ^

compilation aborted for /home/efefer/mysoftwares/jdftx-1.4.1/jdftx/core/Coulomb.cpp (code 2)
make[2]: *** [CMakeFiles/jdftxlib.dir/core/Coulomb.cpp.o] Error 2
make[2]: *** Waiting for unfinished jobs....
[  2%] Built target PseudopotentialLibrary
make[1]: *** [CMakeFiles/jdftxlib.dir/all] Error 2
make: *** [all] Error 2

Are there any work around for this ?
For the moment, I might try using GNU compiler instead.

I am sorry if this issue has been reported before.

<< compilation OK, but test fail >>

Hello,

I successfully compiled JDFTx.

Running make test, I got:

Running tests...
Test project /root/Downloads/JDFTx/build
      Start  1: openShell
 1/10 Test  #1: openShell ........................***Failed    0.18 sec
      Start  2: vibrations
 2/10 Test  #2: vibrations .......................***Failed    0.17 sec
      Start  3: moleculeSolvation
 3/10 Test  #3: moleculeSolvation ................***Failed    0.66 sec
      Start  4: ionSolvation
 4/10 Test  #4: ionSolvation .....................***Failed    0.32 sec
      Start  5: latticeOpt
 5/10 Test  #5: latticeOpt .......................***Failed    1.16 sec
      Start  6: metalBulk
 6/10 Test  #6: metalBulk ........................***Failed    1.46 sec
      Start  7: plusU
 7/10 Test  #7: plusU ............................***Failed    1.36 sec
      Start  8: spinOrbit
 8/10 Test  #8: spinOrbit ........................***Failed    1.34 sec
      Start  9: graphene
 9/10 Test  #9: graphene .........................***Failed    0.48 sec
      Start 10: metalSurface
10/10 Test #10: metalSurface .....................***Failed    1.28 sec
0% tests passed, 10 tests failed out of 10
Total Test time (real) =   8.42 sec
The following tests FAILED:
          1 - openShell (Failed)
          2 - vibrations (Failed)
          3 - moleculeSolvation (Failed)
          4 - ionSolvation (Failed)
          5 - latticeOpt (Failed)
          6 - metalBulk (Failed)
          7 - plusU (Failed)
          8 - spinOrbit (Failed)
          9 - graphene (Failed)
         10 - metalSurface (Failed)
Errors while running CTest
Makefile:61: recipe for target 'test' failed
make: *** [test] Error 8

Running ./jdftx to check for specific error messages return:

*************** JDFTx 1.3.1  The playground for joint density functional theory ****************

Start date and time: Mon Aug 14 17:36:59 2017
Running on hosts (process indices):  lamodel ( 0 )
Executable ./jdftx with empty command-line (run with -h or --help for command-line options).
Maximum cpu threads by process: 4
Run totals: 1 processes, 4 threads, 0 GPUs
Waiting for commands from stdin (end input with EOF (Ctrl+D)):

Which I think is ok.

Running ldd ./jdftx, I got:

linux-vdso.so.1 (0x00007ffc8eff9000)
       libjdftx.so => /root/Downloads/JDFTx/build/libjdftx.so (0x00002b70b95f2000)
       libmpicxx.so.12 => /software/intel/MPI/compilers_and_libraries_2017.1.132/linux/mpi/intel64/lib/libmpicxx.so.12 (0x00002b70ba15b000)
       libmpifort.so.12 => /software/intel/MPI/compilers_and_libraries_2017.1.132/linux/mpi/intel64/lib/libmpifort.so.12 (0x00002b70ba37c000)
       libmpi.so.12 => /software/intel/MPI/compilers_and_libraries_2017.1.132/linux/mpi/intel64/lib/libmpi.so.12 (0x00002b70ba725000)
       libdl.so.2 => /lib64/libdl.so.2 (0x00002b70bb465000)
       librt.so.1 => /lib64/librt.so.1 (0x00002b70bb66a000)
       libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b70bb872000)
       libgsl.so.0 => /usr/lib64/libgsl.so.0 (0x00002b70bba8f000)
       libfftw3_threads.so.3 => /usr/lib64/libfftw3_threads.so.3 (0x00002b70bbec3000)
       libfftw3.so.3 => /usr/lib64/libfftw3.so.3 (0x00002b70bc0ca000)
       libmkl_intel_lp64.so => /software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64/libmkl_intel_lp64.so (0x00002b70bc4c7000)
       libmkl_intel_thread.so => /software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64/libmkl_intel_thread.so (0x00002b70bcddb000)
       libmkl_core.so => /software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64/libmkl_core.so (0x00002b70be176000)
       libiomp5.so => /software/intel/compiladores/composer_xe_2015.1.133/compiler/lib/intel64/libiomp5.so (0x00002b70bfccf000)
       libm.so.6 => /lib64/libm.so.6 (0x00002b70c0005000)
       libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002b70c0302000)
       libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b70c068b000)
       libc.so.6 => /lib64/libc.so.6 (0x00002b70c08a3000)
       libimf.so => /software/intel/compiladores/composer_xe_2015.1.133/compiler/lib/intel64/libimf.so (0x00002b70c0c46000)
       libsvml.so => /software/intel/compiladores/composer_xe_2015.1.133/compiler/lib/intel64/libsvml.so (0x00002b70c1101000)
       libirng.so => /software/intel/compiladores/composer_xe_2015.1.133/compiler/lib/intel64/libirng.so (0x00002b70c1fe0000)
       libintlc.so.5 => /software/intel/compiladores/composer_xe_2015.1.133/compiler/lib/intel64/libintlc.so.5 (0x00002b70c21e7000)
       /lib64/ld-linux-x86-64.so.2 (0x000055f9ebb14000)

That also looks ok to me.

What I am missing?

Atoms are too close, have overlapping pseudopotential cores.

I took optimized Graphene structure from VASP.
In order to use JDFT for optimization, I just followed the tutorial given in http://jdftx.org/Pt100.html
my .lattice file contains parameters converted in Bohr from VASP.
and I also have .ionpos generated from the xyzToionpos script. Now having said that, when I proceed with dryrun as instructed in the above link. I get the above error.

fen4c-ooh.lattice
lattice
18.881480721 0.0000000000000000 0.0000000000000000
0.0000000000000000 15.841132463 0.0000000000000000
0.0000000000000000 0.0000000000000000 28.292656874

fen4c-ooh.ionpos

Ionic positions in cartesian coordinates:

ion C 15.176443731891698 1.175948245691613 4.427212661467652 0
ion C 17.561255473591832 2.445001409735718 4.406289613384703 1
ion C 17.594061119791252 5.103655259523653 4.384015411094809 1
ion C 15.279248614641750 6.406205709543041 4.399076528618391 1
ion C 15.283113104646231 9.093611742909559 4.401960250743985 1
ion C 17.597390817291448 10.393219889292283 4.377633805840463 1
ion C 17.564923432075304 13.053217334382509 4.401480260298441 1
ion C 15.179214070447479 14.323975031426146 4.424395079757783 1
ion C 10.480927749721644 1.226150710952777 4.568685120976490 1
ion C 12.857005177093797 2.586275447997382 4.497257251446207 1
ion C 12.862600656264101 12.913196184567287 4.492323176433150 1
ion C 10.481453093595114 14.271831817395006 4.553510619883093 1
ion C 5.783327399593180 1.176530281349990 4.493976686826265 1
ion C 8.101567868003384 2.589899942779092 4.576561499626212 1
ion C 5.682338543686312 6.403053646302221 4.503081387482303 1
ion C 5.680231499013941 9.088246810331208 4.474474712818314 1
ion C 8.104551745615646 12.912729422204889 4.530299113416073 1
ion C 5.784519816802387 14.323107647117073 4.474913129288261 1
ion C 1.039150968711426 1.151345900768211 4.425608283954789 1
ion C 3.396387826232876 2.443937493905633 4.454647705910232 1
ion C 3.367412654966994 5.103887695841771 4.436428855967339 1
ion C 1.041246675026815 6.423154663504021 4.388250287427350 1
ion C 1.041019907887188 9.071290297465575 4.383590222708007 1
ion C 3.368140199539965 10.391507797388096 4.417096957314110 1
ion C 3.399460520974827 13.051318159588131 4.432420746774427 1
ion C 1.040596609226550 14.344915087044566 4.419117074582957 1
ion Fe 10.490928180579209 7.764949056762084 5.065448775948775 1
ion H 9.630265627468454 5.885828036430897 11.129803022503614 1
ion H 6.535170071575268 12.570928981823103 11.760999907025472 1
ion H 8.279982584283678 10.166919512027350 11.620597032525211 1
ion H 13.056911749032270 4.949034085368758 12.646073942717109 1
ion H 11.627725079614162 2.293186478933711 12.547825189747405 1
ion H 10.687794183120513 13.794581474787652 12.309746149304997 1
ion H 13.188657787977260 14.331518818271082 13.771931216991208 1
ion H 16.648050974229424 8.372102955304953 10.881848273130437 1
ion H 13.753487489634852 8.125554162197465 10.268392137832091 1
ion N 12.978522128315429 5.210315183647368 4.475939250595075 1
ion N 12.986712201508304 10.296001037081718 4.495034933477860 1
ion N 7.983136839606846 5.210848086425492 4.627064431347383 1
ion N 7.978187646784479 10.286291624053343 4.538526981132218 1
ion O 8.756133106263837 7.282634248036385 10.067533143907182 1
ion O 10.891550127254160 7.984714760953421 8.433116543947850 1
ion O 8.091648695370852 11.862574578043045 12.422800906766202 1
ion O 11.383357030499424 4.152289630014294 12.771394912705990 1
ion O 12.206795757640352 14.921030233350946 12.335155407300240 1
ion O 15.053373425763619 7.777298417240954 11.565048531947332 1

Si lattice parameter for LDA

Hi,

I was doing some test calculations for Si bulk and was a little bit surprised about the lattice parameter I obtained using internal lattice optimization as well as Birch-Murnaghan-equation.
I am using the GBRV pseudopotentials and oversampled the unit cell with 20x20x20 kpoints and cutoff energies of 40 and 200 hartree.
The obtained value of 5.433 Angstrom matches the experimental value of 5.431 Angstrom (see https://physics.nist.gov/cgi-bin/cuu/Value?asil) extremely well. However, for LDA I would expect a lattice parameter that is around 1% LOWER than the experimental one.
Can you comment on that? Has there been some "tuning" of internal parameters in the pseudopotential?

Thank you in advance!

Linker errors

I am having the following error while installing jdftx-1.4.1

[ 96%] Linking CXX executable jdftx
libjdftx.so: error: undefined reference to '__intel_avx_rep_memcpy'
libjdftx.so: error: undefined reference to '__intel_avx_rep_memset'
libjdftx.so: error: undefined reference to '__intel_ssse3_rep_memmove'
collect2: error: ld returned 1 exit status
make[2]: *** [jdftx] Error 1
make[1]: *** [CMakeFiles/jdftx.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 96%] Building CXX object CMakeFiles/wannier.dir/wannier/commands.cpp.o
[ 97%] Building CXX object CMakeFiles/wannier.dir/wannier/WannierMinimizerRS.cpp.o
[ 98%] Linking CXX executable phonon
/eb/software/binutils/2.26-GCCcore-5.4.0/bin/ld.gold: fatal error: phonon: open: Is a directory
collect2: error: ld returned 1 exit status
make[2]: *** [phonon] Error 1
make[1]: *** [CMakeFiles/phonon.dir/all] Error 2
[100%] Linking CXX executable wannier
/eb/software/binutils/2.26-GCCcore-5.4.0/bin/ld.gold: fatal error: wannier: open: Is a directory
collect2: error: ld returned 1 exit status
make[2]: *** [wannier] Error 1
make[1]: *** [CMakeFiles/wannier.dir/all] Error 2
make: *** [all] Error 2

My install script is
module load imkl/11.3.3.210-iimpi-2016b
module load CMake/3.4.3-intel-2016b
module load GSL/1.16-intel-2016b
module load FFTW/3.3.4-intel-2016b
module load Doxygen/1.8.11-intel-2016b

CC=/eb/software/GCCcore/5.4.0/bin/gcc CXX=/eb/software/GCCcore/5.4.0/bin/g++
cmake
-D EnableMPI=YES
-D EnableMKL=yes
-D ForceFFTW=yes
-D MKL_PATH="/eb/software/imkl/11.3.3.210-iimpi-2016b/mkl"
../jdftx

make -j12

Any help will be appreciated.

An error in ExCorr.cpp

ExCorr.cpp requires xc_func_info_get_ref from LIBXC, but the function doesn't exist.

New user in JDFTx, installing issue

Hello,
This is Fanglin, few days ago, I asked about installing JDFTx in a BGQ cluster with 1024 cpu per 64 nodes per node.
The technician installed JDFTx however, it runs into the issue:
'

*************** JDFTx 1.3.1 The playground for joint density functional theory ****************

Start date and time: Tue Oct 17 12:36:54 2017
Running on hosts (process indices): bgq-R01-IC-J00 ( 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 ) bgq-R01-IC-J02 ( 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 )
Executable /scinet/bgq/src/jdftx/jdftx-1.3.1/build/jdftx with command-line: -i jdft.in
Maximum cpu threads by process: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
Run totals: 1024 processes, 1024 threads, 0 GPUs
Inconsistency in command map: 'ion' in 'add-U's requires list is not a valid command.
End date and time: Tue Oct 17 12:36:55 2017 (Duration: 0-0:00:00.15)
Failed.
2017-10-17 12:36:56.490 (WARN ) [0x40001388f90] :848126:ibm.runjob.client.Job: normal termination with status 1 from rank 327''

The input file is also attached ''I didn't see the add-U term though''
input file:
lattice
14.491772863339085 0.000000000000001 0.000000000000002
0.000000000000000 14.491772863339085 0.000000000000000
0.000000000000000 0.000000000000000 38.593199505881024

coords-type lattice
ion Cu 0.000000000000000 0.000000000000000 0.186440006000000 0
ion Cu 0.000000000000000 0.000000000000000 0.363449991000000 0
ion Cu 0.166669995000000 0.166669995000000 0.097929999000000 0
ion Cu 0.166669995000000 0.166669995000000 0.274940014000000 0
ion Cu 0.333330005000000 0.000000000000000 0.186440006000000 0
ion Cu 0.333330005000000 0.000000000000000 0.363449991000000 0
ion Cu 0.500000000000000 0.166669995000000 0.097929999000000 0
ion Cu 0.500000000000000 0.166669995000000 0.274940014000000 0
ion Cu 0.666670024000000 0.000000000000000 0.186440006000000 0
ion Cu 0.666670024000000 0.000000000000000 0.363449991000000 0
ion Cu 0.833329976000000 0.166669995000000 0.097929999000000 0
ion Cu 0.833329976000000 0.166669995000000 0.274940014000000 0
ion Cu 0.000000000000000 0.333330005000000 0.186440006000000 0
ion Cu 0.000000000000000 0.333330005000000 0.363449991000000 0
ion Cu 0.166669995000000 0.500000000000000 0.097929999000000 0
ion Cu 0.166669995000000 0.500000000000000 0.274940014000000 0
ion Cu 0.333330005000000 0.333330005000000 0.186440006000000 0
ion Cu 0.333330005000000 0.333330005000000 0.363449991000000 0
ion Cu 0.500000000000000 0.500000000000000 0.097929999000000 0
ion Cu 0.500000000000000 0.500000000000000 0.274940014000000 0
ion Cu 0.666670024000000 0.333330005000000 0.186440006000000 0
ion Cu 0.666670024000000 0.333330005000000 0.363449991000000 0
ion Cu 0.833329976000000 0.500000000000000 0.097929999000000 0
ion Cu 0.833329976000000 0.500000000000000 0.274940014000000 0
ion Cu 0.000000000000000 0.666670024000000 0.186440006000000 0
ion Cu 0.000000000000000 0.666670024000000 0.363449991000000 0
ion Cu 0.166669995000000 0.833329976000000 0.097929999000000 0
ion Cu 0.166669995000000 0.833329976000000 0.274940014000000 0
ion Cu 0.333330005000000 0.666670024000000 0.186440006000000 0
ion Cu 0.333330005000000 0.666670024000000 0.363449991000000 0
ion Cu 0.500000000000000 0.833329976000000 0.097929999000000 0
ion Cu 0.500000000000000 0.833329976000000 0.274940014000000 0
ion Cu 0.666670024000000 0.666670024000000 0.186440006000000 0
ion Cu 0.666670024000000 0.666670024000000 0.363449991000000 0
ion Cu 0.833329976000000 0.833329976000000 0.097929999000000 0
ion Cu 0.833329976000000 0.833329976000000 0.274940014000000 0

#Brillouin zone sampling
kpoint-folding 3 3 1 # 3x3x1 uniform k-mesh
kpoint 0 0 0 1 # gamma-centered k-point mesh

ion-species GBRV/$ID_pbe_v1.2.uspp
ion-species GBRV/$ID_pbe_v1.uspp
elec-ex-corr gga-PBE # Why not mix in exact exchange? (gga-PBE by default)
elec-cutoff 20.0 # Plane-wave cutoff in Hartrees (20 by default)
electronic-minimize
nIterations 1000
energyDiffThreshold 1e-5 # who needs 16 digits?

elec-fermi-fillings 0 0.003675 # Fillings are a fermi function with T = 0.1 eV

fluid SaLSA
fluid-solvent H2O
fluid-cation K+ 0.1
fluid-anion F- 0.1

target-mu -0.163167

dump-name cu.$VAR

Could you please comment on it?

Regarding formation energy differences between JDFTx and QE

Hey @shankar1729 ,

I've been comparing jDFTx energies with the ones I get from QE pwscf for the formation energy of CO and adsorption formation energies of CO on Pt(111) and Cu(111) and I get some deviation in numbers.

I tried switching between the GBRV pseudopotentials from the installation and the one at my cluster and they get the same results.

The XC functional I'm using is PBE. And I kept the elec/ rho energy cutoff to be 500eV / 5000eV. (in hartrees, 18.3746545014 183.746545014)

What I get with jDFTx is similar to the values in the example in the documentation;

BFGS: 0 15:12:29 -591.216686 8.6057
BFGS: 1 15:15:01 -591.705210 2.9871
BFGS: 2 15:17:30 -591.735280 1.8346
BFGS: 3 15:19:59 -591.748251 0.1889
BFGS: 4 15:22:29 -591.748399 0.0123

What I get with a very similar setting in QE is:

BFGSLineSearch: 0[ 0] 15:19:04 -593.902306 8.6049
BFGSLineSearch: 1[ 2] 15:22:24 -594.419610 1.7779
BFGSLineSearch: 2[ 4] 15:25:12 -594.434013 0.0597
BFGSLineSearch: 3[ 5] 15:26:24 -594.434028 0.0044

The E components in both codes seem to only agree on E_xc (I'm not sure how to connect the others from jDFTx to pwscf.) It appears Eewald disagrees between the two codes. I'm just multiplying jDFTx hartree energies by 2 to get the rydberg values from pwscf.

jDFTx:

 Eewald =       11.1193940300900049
 EH =       28.7476069859467707
 Eloc =      -69.8132696518777323
 Enl =        3.1415972827461465
 Exc =       -5.2632552603605181
 Exc_core =        0.0987190434473193
 KE =       10.2228625447723616

 Etot =      -21.7463450252356481
 TS =        0.0000000000000001

 F =      -21.7463450252356481

Pwscf:
The total energy is the sum of the following terms:

 one-electron contribution =     -98.23791950 Ry
 hartree contribution      =      50.17414508 Ry
 xc contribution           =     -10.52677357 Ry
 ewald contribution        =      14.90045088 Ry
 smearing contrib. (-TS)   =      -0.00000000 Ry

Could you point me to a potential area I may have missed in setting up the CO calculation?

my jdftx input looks like this:

lattice
22.676711 0.000000 0.000000
0.000000 22.676711 0.000000
0.000000 0.000000 25.038869

elec-cutoff 18.3746545014 183.746545014
spintype no-spin
elec-smearing Cold 0.00459366362534
elec-ex-corr gga-x-pbe gga-c-pbe
davidson-band-ratio 1.1
kpoint 0 0 0 1
kpoint-folding 1 1 1

coords-type cartesian
ion C 11.338356 11.338356 11.338356 1
ion O 11.338356 11.338356 13.700513 1

ion-species ..//jdftx-1.4.2/psp/gbrv/c.upf
ion-species ..//jdftx-1.4.2/psp/gbrv/o.upf

coulomb-interaction isolated

pw.inp looks like:
&CONTROL
calculation='relax',
prefix='calc',
pseudo_dir='/home/users/ttgmichael/psp/gbrv1.5pbe',
outdir='.',
tprnfor=.true.,
/
&SYSTEM
ibrav=0,
celldm(1)=1.8897261245650618d0,
nat=2,
ntyp=2,
ecutwfc=36.7493237909d0,
ecutrho=367.493237909d0,
nbnd=15,
occupations='smearing',
smearing='fd',
degauss=0.00734986475817d0,
input_dft='PBE',
/
&ELECTRONS
diagonalization='david',
conv_thr=7.34986475817e-08,
mixing_beta=0.7d0,
electron_maxstep=100,
conv_thr=7.34986475817e-08,
/
&IONS
ion_dynamics='ase3',
/
CELL_PARAMETERS
20.000000000000000d0 0.000000000000000d0 0.000000000000000d0
0.000000000000000d0 21.250000000000000d0 0.000000000000000d0
0.000000000000000d0 0.000000000000000d0 20.000000000000000d0
ATOMIC_SPECIES
C1 12.011d0 C.UPF
O1 15.9994d0 O.UPF
ATOMIC_POSITIONS {crystal}
C1 0.500000000000000d0 0.470588235294118d0 0.500000000000000d0
O1 0.500000000000000d0 0.529411764705882d0 0.500000000000000d0
K_POINTS automatic
1 1 1 0 0 0

cmake doesn't install anything

It has built executables: jdftx, phonon, wannier, and shared lib libjdftx.so.
How can I know what should be installed?

Linker errors while building static JDFTx

Hello, dear Shankar.

Several days before I started installing linux (mageia 6) and JDFTx on new laptop.
Hardware is: CPU Core i7-7700HQ(avx,avx2,sse4.1,4.2), 2x8Gb DDr4 2400 MHz, Nvidia 1060 6Gb.

Unfortunately gcc spits lot of linker errors at the last stage while linking executables, see jdftx_build.txt.
As for me, many of them are because lapack.a misses symbols from ATLAS.

I have installed every library dependency from source, in order to obtain well optimized static libs (my distro has only dynamic ones). Long time ago I tried statifier for making static bins from dynamic ones, but it fails with JDFTx.

I tried installing JDFTx with script
install-jdftx1.4.1.sh.txt, which produced that big amount of linker errors.

The biggest problem with ATLAS is that installs FOUR HOURS due to many speed tests.
I used this script for installing it
atlas.sh.txt

I am not sure that I managed to switch off throttling, by disabling intel-pstate in the bootloader, setting frequency to 2.8GHz, performance governor and disabling boost cpufreq.sh.txt, as ATLAS still complained about throttling.

L1 and L2 cache sizes guesses are 128K and 32M,which are far from reality (L1 32K insructions+32K data, L2 256K, L3 6M)
Besides that, it shows quite good performance in make time.

Then after installing ATLAS, I installed gsl (install-gsl.sh.txt) and libfftw (install-fftw.sh.txt)

I did not change C_INCLUDE_PATH, LIBRARY_PATH and other enc. vars, as I thought they will not greatly affect compiling process for static binaries. I just added locations of libs directly to cmake arguments.

As a result, linking failed. Even after adding LIBRARY_PATH and LDFLAGS to install-jdftx1.4.1.sh, I was unable to improve something.

Could you give me some hints what to try,
in order to fix this problem with static linking?

If I succeed, I think it is good idea to post these revised scripts, as a starting point for others. May be they could be helpful for someone.

Thank you in advance,
with best wishes,
Igor.

Complieing

Hello,
This is Fanglin. I looked at the JDFTx code. Is that possible to parallelize to at least 1024 cores? I would like to ask the technician guy from BGQ-scinet to compile JDFTx to work on my project.

fixed-potential calculations

Dear Ravishankar,

I want to calculate a single-point calculation of Pt slab model with adsorbates at fixed-potential.
Since I want to calculate from 0.0 V (SHE) to 1.3 V (SHE), so I constructed my script file, like below.

for iMu in {0..13}; do
export mu="$(echo $iMu | awk '{printf("%.4f", -0.17125+0.1*$1/27.2114)}')"

I used the calibrated standard hydrogen electrode of -4.66 eV because I'm using CANDLE. (JCP, 142, 064107)

But all the calculations from the que scripts were stopped in the middle of electronic minimization.
I can't interpret "jdftx-stacktrace". Could you please take a look into it?
archive.zip

Thank you!
Happy New Year!

Soonho

phonons in hBN

Hi Shankar,

I've been trying to model some defects in hBN and I've run into some issues which I haven't been able to figure out. I am able to avoid imaginary frequencies in all instances of using a supercell of defect-free hBN. Then, upon introducing the defect and performing an ionic-minimization, the phonon calculations generates some troubling results. The results are attached for the C_BV_N defect. Some general trends I found:

The imaginary frequencies showed up for both the bulk and monolayer calculations. I was thinking maybe there was something going on with the Grimme van der Waals correction, but I don't use that in the monolayer.
I was able to get exactly the same imaginary frequencies using electronic-minimize and electronic-scf for the select cases where I tested this.
This was a widespread outcome across 6+ defects studied in bulk, monolayer and bilayer hBN. There appeared to be this rouge unstable mode between ~ 50 and 100 meV below zero, despite the defect-free cells showing no issue.
I wouldn't think cell size is the issue. The monolayer is on a 6 6 1 grid of monolayer hBN cells, and the bulk is modeled using a 5 5 2 grid of bulk hBN unit cells.

Do you have any thoughts on this? I'm a bit puzzled by these outcomes. As always, thank you very much for your help.

Regards,
Chris

phonons-hBN.zip

Convergence report / check

Hej,

I noticed what I think is an inconsistency in either reporting or detecting convergence. When I set i.e. 1E-6 as criteria I get

==== snip ====
SCF: Cycle: 81 G: -1695.487691123765899 dG: +9.598e-07 |Residual|: 9.957e-04 |deigs|: 2.585e-04 t[s]: 21300.77
FillingsUpdate: mu: -0.107401297 nElectrons: 450.000000 magneticMoment: [ Abs: 0.02868 Tot: +0.01464 ]
SCF: Cycle: 82 G: -1695.487691396125228 dG: -2.724e-07 |Residual|: 9.426e-04 |deigs|: 1.728e-04 t[s]: 21527.07
FillingsUpdate: mu: -0.107371870 nElectrons: 450.000000 magneticMoment: [ Abs: 0.02537 Tot: +0.01242 ]
SCF: Cycle: 83 G: -1695.487693612757539 dG: -2.217e-06 |Residual|: 5.921e-04 |deigs|: 3.370e-04 t[s]: 21753.71
FillingsUpdate: mu: -0.107360279 nElectrons: 450.000000 magneticMoment: [ Abs: 0.02329 Tot: +0.01091 ]
SCF: Cycle: 84 G: -1695.487693928076396 dG: -3.153e-07 |Residual|: 5.764e-04 |deigs|: 3.331e-04 t[s]: 21980.58
FillingsUpdate: mu: -0.107335098 nElectrons: 450.000000 magneticMoment: [ Abs: 0.02256 Tot: +0.00840 ]
SCF: Cycle: 85 G: -1695.487692831408140 dG: +1.097e-06 |Residual|: 6.822e-04 |deigs|: 3.574e-04 t[s]: 22206.98
FillingsUpdate: mu: -0.107327722 nElectrons: 450.000000 magneticMoment: [ Abs: 0.02215 Tot: +0.00664 ]
SCF: Cycle: 86 G: -1695.487692082159811 dG: +7.492e-07 |Residual|: 6.768e-04 |deigs|: 3.742e-04 t[s]: 22433.59
FillingsUpdate: mu: -0.107311768 nElectrons: 450.000000 magneticMoment: [ Abs: 0.02120 Tot: +0.00497 ]
SCF: Cycle: 87 G: -1695.487692802139463 dG: -7.200e-07 |Residual|: 7.188e-04 |deigs|: 3.848e-04 t[s]: 22660.05
FillingsUpdate: mu: -0.107301472 nElectrons: 450.000000 magneticMoment: [ Abs: 0.01949 Tot: +0.00346 ]
SCF: Cycle: 88 G: -1695.487694482572124 dG: -1.680e-06 |Residual|: 4.556e-04 |deigs|: 2.554e-04 t[s]: 22886.44
FillingsUpdate: mu: -0.107290081 nElectrons: 450.000000 magneticMoment: [ Abs: 0.01693 Tot: +0.00235 ]
SCF: Cycle: 89 G: -1695.487694311465248 dG: +1.711e-07 |Residual|: 5.151e-04 |deigs|: 2.866e-04 t[s]: 23112.93
FillingsUpdate: mu: -0.107279558 nElectrons: 450.000000 magneticMoment: [ Abs: 0.01182 Tot: +0.00185 ]
SCF: Cycle: 90 G: -1695.487688216131573 dG: +6.095e-06 |Residual|: 5.563e-04 |deigs|: 2.855e-04 t[s]: 23339.43
FillingsUpdate: mu: -0.107270014 nElectrons: 450.000000 magneticMoment: [ Abs: 0.01081 Tot: +0.00134 ]
SCF: Cycle: 91 G: -1695.487692918003404 dG: -4.702e-06 |Residual|: 4.676e-04 |deigs|: 9.755e-05 t[s]: 23558.92
FillingsUpdate: mu: -0.107268421 nElectrons: 450.000000 magneticMoment: [ Abs: 0.00925 Tot: +0.00152 ]
SCF: Cycle: 92 G: -1695.487690849039836 dG: +2.069e-06 |Residual|: 4.062e-04 |deigs|: 1.418e-04 t[s]: 23778.94
FillingsUpdate: mu: -0.107266126 nElectrons: 450.000000 magneticMoment: [ Abs: 0.00872 Tot: +0.00150 ]
SCF: Cycle: 93 G: -1695.487690564602190 dG: +2.844e-07 |Residual|: 3.651e-04 |deigs|: 1.149e-04 t[s]: 24000.44
FillingsUpdate: mu: -0.107266135 nElectrons: 450.000000 magneticMoment: [ Abs: 0.00819 Tot: +0.00158 ]
SCF: Cycle: 94 G: -1695.487692948609492 dG: -2.384e-06 |Residual|: 2.994e-04 |deigs|: 1.375e-04 t[s]: 24226.79
FillingsUpdate: mu: -0.107263531 nElectrons: 450.000000 magneticMoment: [ Abs: 0.00900 Tot: +0.00135 ]
SCF: Cycle: 95 G: -1695.487694216540376 dG: -1.268e-06 |Residual|: 2.429e-04 |deigs|: 3.559e-04 t[s]: 24448.87
FillingsUpdate: mu: -0.107261996 nElectrons: 450.000000 magneticMoment: [ Abs: 0.00850 Tot: +0.00115 ]
SCF: Cycle: 96 G: -1695.487694229407907 dG: -1.287e-08 |Residual|: 2.276e-04 |deigs|: 7.577e-05 t[s]: 24668.75
FillingsUpdate: mu: -0.107259591 nElectrons: 450.000000 magneticMoment: [ Abs: 0.00875 Tot: +0.00077 ]
SCF: Cycle: 97 G: -1695.487695213891129 dG: -9.845e-07 |Residual|: 2.538e-04 |deigs|: 1.760e-04 t[s]: 24895.45
SCF: Converged (|Delta E|<1.000000e-06 for 2 iters).
==== snip ====

Convergence reports that |dE| was < 1E-6 for two iterations which is the case for SCF 96/97 there, too. Only dE was actually lower than that for two iterations, when looking at SCF cycle 81/82 and 86/87 |dE| actually already was < 1E-6. Is that intended in this way? I don't see a reason why only dE would have to be smaller than threshold, |dE| makes sense, or am I missing something here? Besides the code is reporting |Delta E| < 1E-6.

Have a nice day, Jan

Something kills phonon or jdftx

Hello dear Shankar,
I am reporting some strange problem, most likely unrelated to phonon or jdftx itself.

SYMPTOMS:
phonon is often killed by system w/o any notice and stack trace. My bash emits only word "killed". I have syslog disabled, due to some kernel bug, spamming logs and eating all free space.

Several days ago I have also triggered killing jdftx for the first time.

WHAT TRIGGERS:
It is always after several days of uptime+running extensive calculations almost for 24/7+several suspend/resume cycles on my notebook with Mageia 6, kernel 4.14.40-desktop-1.mga6 x86-64. Running on both CPU and GPU sometimes helps to trigger problem. Only program on CPU is killed. "Killing" of phonon/jdftx is often preceded by extensive I/O and freezing of the system for some time, regardless of "nice" and I/O priorities of phonon/jdftx. Rerunning phonon after being killed by system doesn't help. If the first failed run was terminated say after 5th iteration of Electronic minimization of phonon, the next run will be terminated earlier and may not even reach the 1st Electronic minimization cycle.

What always helps - reboot, until several days of uptime.

How do you think, who is guilty? Heap fragmentation? But why it doesn't produce stack trace and logs like "unable to malloc"?

Here are my ulimits. They look quite reasonable.

[root@localhost /]# ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 63651
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 63651
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

What settings should I change?

Best wishes,
Igor.

Magnetic Anisotropy

Dear all,
my name is Mauro.
I'm working on simulation of permanent magnets.
Is there a procedure to calculate the magnetic anisotropy of materials using JDFTx?
Any tutorial?
Thanks a lot in advance for your replies.
Best regards,
Mauro.

Charged Defect Calculations

Hello,
I am interested in doing charged defect calculations (with correction) using JDFTx. Further, i would like to calculate formation energy etc. I could not find any examples/tutorials on it. If you could please post some tutorials that would be great. I have already performed calculations using espresso, but it does not have corrections due to potential misalignment.
Manu
(SFU, Canada)

How to choose coulomb-truncation-embed？

Hi dear shankar，
I‘m a beginner and I had some problem when choosing coulomb-truncation-embed ：
I used the comand：
coulomb-interaction Slab 001
coulomb-truncation-embed 0 0 0
but it failed：
Coulomb truncation embedding center is not invariant under symmetries.

and here is my Ni（111）slab ionpos：

ion Ni 0.000000000 0.000000000 0.000000000 1
ion Ni 0.333330005 0.166669995 -0.143050000 1
ion Ni 0.166669995 0.333330005 -0.286100000 1
ion Ni 0.500000000 0.000000000 0.000000000 1
ion Ni 0.833329976 0.166669995 -0.143050000 1
ion Ni 0.666670024 0.333330005 -0.286100000 1
ion Ni 0.000000000 0.500000000 0.000000000 1
ion Ni 0.333330005 0.666670024 -0.143050000 1
ion Ni 0.166669995 0.833329976 -0.286100000 1
ion Ni 0.500000000 0.500000000 0.000000000 1
ion Ni 0.833329976 0.666670024 -0.143050000 1
ion Ni 0.666670024 0.833329976 -0.286100000 1

the tutorial about this is too short so i don't understand.
what coulomb-truncation-embed should i use？
thank you very much！

Make Test Error

Dear Dr. Sundararaman,
Below are the last few lines from the terminal after executing make test.
90% tests passed, 1 tests failed out of 10

Total Test time (real) = 688.95 sec

The following tests FAILED:
9 - graphene (Failed)
Errors while running CTest
Makefile:83: recipe for target 'test' failed
make: *** [test] Error 8

Below are the contents of the summary file within the graphene directory.
FAILED: mismatch in number of checks (most likely a parse error)

Your guidance is much appreciated.
Thank you

fluid-anion OH-

Hi,
I am running the following solvation settings:

fluid LinearPCM
pcm-variant CANDLE
fluid-solvent H2O
fluid-anion OH- 0.1
fluid-cation K+ 0.1

First I noticed that jDFTx quits with the error of the solvent being not charge neutral. I discovered that during fluid initialization it throws:

Initializing fluid molecule 'H2O'
Initializing site 'O'
Electron density: proportional to exp(-r/0.36935)*erfc((r-0.51523)/0.36823) with norm 6.826
Charge density: gaussian nuclear width 0.478731 with net site charge 0.826
Polarizability: cuspless exponential with width 0.32 and norm 3.73
Hard sphere radius: 2.57003 bohrs
Positions in reference frame:
[ +0.000000 +0.000000 +0.000000 ]
Initializing site 'H'
Electron density: proportional to exp(-r/0.34641)*erfc((r-0)/0.390882) with norm 0.587
Charge density: gaussian nuclear width 0.377945 with net site charge -0.413
Polarizability: cuspless exponential with width 0.39 and norm 3.3
Positions in reference frame:
[ +0.000000 -1.441945 +1.122523 ]
[ +0.000000 +1.441945 +1.122523 ]
Net charge: 0 dipole magnitude: 0.927204
Initializing spherical shell mfKernel with radius 2.61727 Bohr
deltaS corrections:
site 'O': -7.54299
site 'H': -6.83917
Initializing fluid molecule 'K+'
Initializing site 'K'
Electron density: proportional to exp(-r/0.35529)*erfc((r-0.82179)/0.45583) with norm 8.323
Charge density: gaussian nuclear width 0.475581 with net site charge -1
Hard sphere radius: 2.70798 bohrs
Positions in reference frame:
[ +0.000000 +0.000000 +0.000000 ]
Net charge: -1 dipole magnitude: 0
Initializing gaussian mfKernel with width: 2.01772 Bohr
deltaS corrections:
site 'K': -51.3309
Initializing fluid molecule ''
Net charge: 0 dipole magnitude: 0
Initializing spherical shell mfKernel with radius 0 Bohr
deltaS corrections:

wherein the OH- is missing. No wonder we are not charge neutral here so I looked into the source (FluidComponent.cpp, line 505, case Hydroxide) and discovered there is no specification for it. So I added the following:

Rvdw = 1.67Angstrom; // TODO what is RvdW here? I just took water here...
//Site properties:
molecule.name = "OH-";
auto siteO = std::make_sharedMolecule::Site("O",int(AtomicSymbol::O));
siteO->Znuc = 6.; siteO->sigmaNuc = sigmaNucO;
siteO->Zelec = 7.413; //6.826; //siteO->aElec = 0.32;
siteO->aElec = 0.36935; siteO->sigmaElec = 0.36823; siteO->rcElec = 0.51523;
siteO->alpha = 3.73; siteO->aPol = 0.32;
siteO->Zsite = siteO->Zelec-siteO->Znuc;
molecule.sites.push_back(siteO);
auto siteH = std::make_sharedMolecule::Site("H",int(AtomicSymbol::H));
siteH->Znuc = 1.; siteH->sigmaNuc = sigmaNucH;
siteH->Zelec = 0.587; //siteH->aElec = 0.31;
siteH->aElec = 0.34641; siteH->sigmaElec = (siteH->aElec)/sqrt(M_PI); siteH->rcElec = 0.0;
siteH->alpha = 3.30; siteH->aPol = 0.39;
siteH->Zsite = siteH->Zelec-siteH->Znuc;
molecule.sites.push_back(siteH);
//Geometry:
const double rOH = 0.98369053Angstrom; // Value from tight relaxation in FHI-aims
siteO->positions.push_back(vector3<>(0., 0., 0.));
siteH->positions.push_back(vector3<>(0., 0., rOH));
break;

I basically copy/pasted the water definition, removed one hydrogen from the geometry and accumulated most of the remaining charge on the oxygen atom. Also removed the norm factor "2" in front of sigmaElec. The radial distance is taken from a different DFT code here, I had it handy. Now I do get during initialization
---snip---
Initializing fluid molecule 'OH-'
Initializing site 'O'
Electron density: proportional to exp(-r/0.36935)*erfc((r-0.51523)/0.36823) with norm 7.413
Charge density: gaussian nuclear width 0.478731 with net site charge 1.413
Polarizability: cuspless exponential with width 0.32 and norm 3.73
Positions in reference frame:
[ +0.000000 +0.000000 +0.000000 ]
Initializing site 'H'
Electron density: proportional to exp(-r/0.34641)*erfc((r-0)/0.195441) with norm 0.587
Charge density: gaussian nuclear width 0.377945 with net site charge -0.413
Polarizability: cuspless exponential with width 0.39 and norm 3.3
Positions in reference frame:
[ +0.000000 +0.000000 +1.858906 ]
Net charge: 1 dipole magnitude: 0.767728
Initializing gaussian mfKernel with width: 2.23152 Bohr
deltaS corrections:
site 'O': 22.406
site 'H': -13.8035
---snip---

The jDFTx fuild is now charge neutral and computation continues beyond this point. The total DFT energy corrections are in a reasonable range at ~0.002 Ha for H2 in water with 0.1M KOH.

My questions now:

Are the charge accumulations correct? How are they computed for other solvents / ions? When I have a formula I could run them myself and update the values accordingly.
Do these values make sense to you? I.e. the deltaS corrections etc? I have no experience with these.
I do expect a noticeable effect when applying external fields. How do I specify an external electric field of i.e. 1 V/m? (offtopic maybe here but for testing important)
If needed I can provide inputs/outputs from my test runs

Thank you very much, have a nice day, Jan

About adsorption energy

Hi Shankar，
Recently I used JDFTx to calculate species adsorbed on metal surface. I have some problems and need your help.
In output files we got Etot, F(Helmholtz free energy) and G(grand free energy,if target-mu). As you mentioned in the tutorial, F should be used when calculated surface energy. Which one should we use when calcutate adsorption energy?
Shall we use F again ,or Etot as usual？
If the slab is charged，shall we use G to calculate adsorption energy？
Thank you very much!

Does two-dimensional material(fixed-potential)calculation needs geometry optimization?

Dear all,
I 'm going to do a fixed-potential calculation. In the tutorial, the structure of Pt slab model is fixed. Now I am about to study a single layer graphene. In fixed-charge calculation(from other codes instead of JDFTx), I have to optimize the structure, because two-dimensional structure could vary under different charge state. How about geometry optimization at constant potential calculation? Do I have to do target-mu+ionic minimize both? This seems to be very time-consuming. Could any one give me some suggestions?Thank you!

Best Regards!

Wolffett

About convergence threshold

Hi shankar，
I noticed that in the command ionic-minimize there are two convergence threshold:
knormThreshold 0.0001 \ Hartree/bohr?
energyDiffThreshold 1e-06 \ Hartree
I wondered if these two parameters are equal to EDIFFG in VASP. If I set both of the two parameters, the calculation will end when saitisfied one convergence condition or two?
What do you recommend?

Best wishes

Bound charge in solvated calculations

Dear Shankar,

thank you very much for the fast response! I am testing the different solvation models for a slab of IrO2. I realized, just as in the tutorial on the oxide surface, that there is bound charge at the border of the unit cell, in a somewhat layered structure. I would have expected the bound charge to be primarily localized at the interface and to find homogeneously mixed charged regions in the bulk?
Another point is that for iso-surfaces (of the order of E-6 and smaller) there is bound charge in the region of the explicit system. I thought that the cavity is defined such as that the bound charge there is zero (no penetration of the liquid into the explicit system)?

gpu_jdftx singularity container build

Hey Shankar,

Hope all is well!
I've being trying to build jdftx inside a Singularity container (mostly for reproducibility, but also to facilitate compiling in certain clusters w/o module support etc).
I've successfully built container images with cuda (+openmpi, hdf5, fftw, mkl) which compile and run properly on one GPU. I.e. if I were to run srun -N1 -n2 -c1 --gres=gpu:2 singularity exec --nv jdftx-image.simg jdftx_gpu -ni totalE.in[1,2], I can 'see' all the available GPUs, yet jdftx_gpu selects to only use one of them (output below bolded for emphasis):

Executable jdftx_gpu with command-line: -ni totalE.in
Running on hosts (process indices): seasdgx101.rc.fas.harvard.edu (0)
Divided in process groups (process indices): 0 (0)
gpuInit: Found compatible cuda device 0 'Tesla V100-SXM2-16GB'
gpuInit: Found compatible cuda device 1 'Tesla V100-SXM2-16GB'
gpuInit: Selected device 0
Resource initialization completed at t[s]: 1.14
Run totals: 1 processes, 1 threads, 1 GPUs

I was wondering if I need to specify any compilation options explicitly so that it uses all available GPUs?

Cheers,
George

[1] Not sure how familiar you are with with singularity containers, so here's a brief workflow just in case - and I'm obviously happy to provide more details on this:
So to build a singularity image one would run (either on the cluster directly or to a workstation/laptop with sudo privileges) sudo singularity build jdftx-image.simg singularity-recipe, where the singularity recipe is a text file with the compile script (including things like apt-get install commands, and wget of packages etc). I've attached my recipe file here singularity-recipe.txt.
[2] The --nv flag loads the nvidia drivers on the host. This step works properly (as seen by commands like singularity exec --nv jdftx-image.simg nvidia-smi -L
[3] I'm debugging this on a DGX1 machine (8 GPUs with cuda_code=sm_70)

Problems with installation on cygwin

I followed the installation guide on cygwin. After typing the command "cmake ../jdftx-git/jdftx/" I got the follow output:
`
-- The C compiler identification is GNU 6.4.0
-- The CXX compiler identification is GNU 6.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++.exe
-- Check for working CXX compiler: /usr/bin/c++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Git: /usr/bin/git.exe (found version "2.15.0")
-- Git revision hash: 8120d29
-- Forcing static linking for Cygwin/Windows
-- Looking for gsl_integration_glfixed_point
-- Looking for gsl_integration_glfixed_point - found
-- Found GSL: /lib/libgsl.dll.a
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
-- Found FFTW3: /lib/libfftw3_threads.dll.a /lib/libfftw3.dll.a
-- Looking for sgemm_
-- Looking for sgemm_ - not found
CMake Error at /usr/share/cmake-3.6.2/Modules/FindBLAS.cmake:690 (message):
A required library with BLAS API not found. Please specify library
location.
Call Stack (most recent call first):
/usr/share/cmake-3.6.2/Modules/FindLAPACK.cmake:165 (find_package)
CMake-Modules/FindLAPACK_ATLAS.cmake:20 (find_package)
CMakeLists.txt:85 (find_package)

-- Configuring incomplete, errors occurred!
See also "/home/build_jdft/CMakeFiles/CMakeOutput.log".
See also "/home/build_jdft/CMakeFiles/CMakeError.log".

Later, I typed: cmake -DLAPACK_LIBRARIES=/usr/lib/liblapack.dll.a ../jdftx-git/jdftx/ and after it tried the follow command: cmake -DLAPACK_LIBRARIES=/usr/lib/liblapack.dll.a -DMPI_CXX_LIBRARIES=/usr/lib/libmpi_mpifh.dll.a ../jdftx-git/jdftx/ These command I saw on the webpage https://stackoverflow.com/questions/50928885/how-to-solve-the-issue-a-required-library-with-blas-api-not-found. And got the same results. I typed "make tests, I got:
Running tests...
Test project /home/build_jdft
Start 1: openShell
1/10 Test #1: openShell ........................***Failed 2.94 sec
Start 2: vibrations
2/10 Test #2: vibrations .......................***Failed 0.55 sec
Start 3: moleculeSolvation
3/10 Test #3: moleculeSolvation ................***Failed 0.51 sec
Start 4: ionSolvation
4/10 Test #4: ionSolvation .....................***Failed 0.51 sec
Start 5: latticeOpt
5/10 Test #5: latticeOpt .......................***Failed 0.81 sec
Start 6: metalBulk
6/10 Test #6: metalBulk ........................***Failed 0.68 sec
Start 7: plusU
7/10 Test #7: plusU ............................***Failed 0.55 sec
Start 8: spinOrbit
8/10 Test #8: spinOrbit ........................***Failed 0.42 sec
Start 9: graphene
9/10 Test #9: graphene .........................***Failed 0.36 sec
Start 10: metalSurface
10/10 Test #10: metalSurface .....................***Failed 0.30 sec

0% tests passed, 10 tests failed out of 10

Total Test time (real) = 7.76 sec

The following tests FAILED:
1 - openShell (Failed)
2 - vibrations (Failed)
3 - moleculeSolvation (Failed)
4 - ionSolvation (Failed)
5 - latticeOpt (Failed)
6 - metalBulk (Failed)
7 - plusU (Failed)
8 - spinOrbit (Failed)
9 - graphene (Failed)
10 - metalSurface (Failed)
Errors while running CTest
make: *** [Makefile:73: test] Ошибка 8

Then I entered "ldd ./jdft.exe", and got:
ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x76fe0000)
KERNEL32.DLL => /cygdrive/c/Windows/SYSTEM32/KERNEL32.DLL (0x74f40000)
KERNELBASE.dll => /cygdrive/c/Windows/SYSTEM32/KERNELBASE.dll (0x75270000)
cygfftw3-3.dll => /usr/local/bin/cygfftw3-3.dll (0x6c480000)
cygfftw3_threads-3.dll => /usr/bin/cygfftw3_threads-3.dll (0x53560000)
cyggsl-19.dll => /usr/bin/cyggsl-19.dll (0x6d380000)
cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
cyglapack-0.dll => /usr/lib/lapack/cyglapack-0.dll (0x33990000)
cygmpi-12.dll => /usr/bin/cygmpi-12.dll (0x407a0000)
cygmpi_cxx-1.dll => /usr/bin/cygmpi_cxx-1.dll (0x40780000)
cygblas-0.dll => /usr/bin/cygblas-0.dll (0x61d40000)
cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x51950000)
cyggfortran-3.dll => /usr/bin/cyggfortran-3.dll (0x4db90000)
cygopen-pal-13.dll => /usr/bin/cygopen-pal-13.dll (0x3f870000)
cygopen-rte-12.dll => /usr/bin/cygopen-rte-12.dll (0x3f780000)
cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x3bc80000)

`
I have no idea how to treat this issue. Please, help me.

classical DFT for fluid

Dear Ravishankar

I'd like to play with fluid1D sub-project to study the fluid properties with different functionals, after compiled the fluid1D separately, I got "libfluid1D.dylib", can you kindly let me know how to use fluid1D (like input, output, or scripts)to study the fluid properties, e.g., pair distribution function etc?

Thank you
cheers
maofeng

How to force continuing lattice-minimize with old wfns after stopping program or crash?

Hi dear, Shankar.

I often need to stop jdftx_gpu with lattice-minimize, because I need to pack my notebook and bring it home/in my office. Thus I need to shutdown or suspend it. CUDA apps either crash or freeze system during suspend completely. Thus I need stop jdftx_gpu.

Is there any way to continue lattice-minimize using old wfns after stopping program?

Some objects take several hours for initial elec-minimize and converge much faster after that.
Another possible usage is stopping JDFTx to adjust some parameters, not related to wavefunctions/kpoint-folding/spin-type directly, with subsequent reuse of old wfns.
Then I can rerun lattice-minimize from scratch, say two times , for converging to best results with stress less than 1e-5.

Best wishes,
Igor.

can't read wave-function in vibration run

Dear Ravishankar

I am running a calculation with molecular adsorbed on surface, meet a error (below) in read wave function ("vacuum.wfns") during the vibration calculation. But this wave function was read successfully during fluid calculation (Classical DFT).The input files of vacuum, vibration, and fluid are enclosed (changed to .txt).

Error:
---------- Allocating electronic variables ----------
Initializing wave functions: reading from 'vacuum.wfns'
Length of 'vacuum.wfns' was 8922471456 instead of the expected 14275816048 bytes.
Hint: Did you specify the correct nBandsOld, EcutOld and kdepOld?

Thank you
BR
maofeng

vacuumin.txt
vibrationin.txt
cdftin.txt

Some problems about free energy

Hi Shankar
Sorry to bother you again. This may be a stupid problem, but it really bothers me. When I dealed with the calculated energies listed in the bottom of output files (something concerned in the free energy tutorial), like ZPE, the vibrational energy {including Evib, TSvib and Avib}, it was difficult for me to distinguish the meaning of these energies between JDFTx and VASP. In VASP, Gibbs free energy △G =Etot+ZPE-TS, while in JDFTx, I don't know how to calculate it, △G =Etot+ZPE-TSvib? However, the fianl result is far from the ideal result when I use this equation. And I don't know the meaning of 'the vibrational free energy' and ' vibrational energy'. Looking forward for your reply. Thank you.
Regards,
Chen

meta-gga or hybrid functionals

Old forum on Sourceforge down?

Dear Shankar,

just a quick question: Is the old forum on Sourceforge down? I can't get access to old Tickets anymore, since it says "Read Access required".

Thank you very much and best regards,

Lennart

How many cores can be used for calculating?

Dear Shankar,

as written in the title, I wanted to ask: how many cores can be used during a bandstructure calculation?
In the tutorials were always used 4, but can also let's say 16 cores be used?

The critical point in calculating bandstructures is the number of kpoints, which can be controlled over the bandstruct command. How much RAM would you advise is enough? (64GB) The more the better :) ?

Thank you as always for your help and your answer.

With best regards,

Lennart

Titaniumdioxide

Dear Shankar,

I just wanted to calculate the bandstructure of titaniumdioxide and I have an Error in common.in (see attached)

I garuntee for the lattice constants to be right I assume the error is in the ion-species command.
But something like ion-species GBRV/Ti_pbe_v1.2.uspp
didn't work.

I would kindly ask of some advice.

Thank you very much and best regards

Lennart
common.txt
totalE.txt

phonons in hBN

Hi Shankar,

Thanks for your suggestion. I have relaxed the lattice to account for the new symmetry, and stuck with testing the monolayer case for computational efficiency. I have found that the system is still showing imaginary frequencies, unfortunately. The system generally has some difficulty in minimizing grad_K, and will instead converge with the Etot criteria. I've tried removing the energyDiffThreshold and still the grad_K will not effectively minimize below 1e-4. Perhaps this could be related to the imaginary frequencies, however the system does find the lower symmetry structure from the original hexagonal lattice. I was wondering if you had any more thoughts as to what could be causing this issue.

Thank you very much for your help.
CBVN-sevens.zip

Regards,
Chris

<< compiling/configuring error >>

Hello,

I am trying to configure JDFTx (v1.3.1) to be compile with compilers, MPI and MKL from Intel and with LibXC (compiled with Intel).

To do that I am using the following command line:
CC=mpiicc FC=mpiifort CXX=mpicxx cmake -D EnableMKL=yes -D LinkTimeOptimization=yes -D ForceFFTW=yes -D EnableLibXC=yes -D MKL_PATH=/software/intel/compiladores/composer_xe_2015.1.133/mkl -D LIBXC_PATH =/software/LIBS/LibXC ../jdftx-1.3.1/jdftx

But I am getting the error:

Parse error in command line argument: -D
Should be: VAR:type=value
CMake Error: No cmake script provided.
CMake Error: Problem processing arguments. Aborting.

What I am doing wrong?

Regards,

Camps

Classical DFT, solution with charged species, convergency problem

Dear Shankar,

I tried to extend the tutorial on ions in solution to the case of Classical DFT:

lattice Cubic 15
coulomb-interaction Isolated
coulomb-truncation-embed 0 0 0
ion-species GBRV/$ID_pbe.uspp
elec-cutoff 20 100
coords-type cartesian

include ${CONFIG}.ionpos
initial-state ${CONFIG}_withoutNaF.$VAR
dump-name ${CONFIG}.$VAR
dump End State BoundCharge

elec-initial-charge ${CHARGE}

fluid ClassicalDFT
fluid-solvent H2O
fluid-cation Na+ 1.
fluid-anion F- 1.

It seems that there are problems to minimize the fluid (e.g. in the case of H3O+):
-------- Electron <-> Fluid self-consistency loop -----------

---------------------- Fluid Minimization # 1 -----------------------
FluidMinimize: Iter: 0 Etot: -0.112314314797106 |grad|_K: 6.726e-04 alpha: 1.000e+00
FluidMinimize: Test step failed with Etot = nan, reducing alphaT to 1.000000e-01.
FluidMinimize: Iter: 1 Etot: -0.113684120916717 |grad|_K: 6.475e-04 alpha: 2.257e-03 linmin: -5.820e-02 cgtest: 9.940e-01 t[s]: 50.05
FluidMinimize: Encountered beta<0, resetting CG.
FluidMinimize: Predicted alpha/alphaT>3.000000, increasing alphaT to 6.771822e-03.
FluidMinimize: Predicted alpha/alphaT>3.000000, increasing alphaT to 2.031546e-02.
FluidMinimize: Predicted alpha/alphaT>3.000000, increasing alphaT to 6.094639e-02.
FluidMinimize: Step failed with Etot = nan, reducing alpha to 2.264617e-02.
FluidMinimize: Iter: 2 Etot: -0.125970640910727 |grad|_K: 8.415e-04 alpha: 2.265e-02 linmin: -8.800e-03 cgtest: 6.197e-01 t[s]: 87.07
FluidMinimize: Iter: 3 Etot: -0.126213844302949 |grad|_K: 8.517e-04 alpha: 1.755e-04 linmin: -1.330e-02 cgtest: 9.998e-01 t[s]: 101.87
FluidMinimize: Wrong curvature in test step, increasing alphaT to 5.264390e-04.
...
FluidMinimize: Step increased Etot by 7.808285e-04, reducing alpha to -4.743449e-05.
FluidMinimize: Step increased Etot by 6.284198e-05, reducing alpha to -4.743449e-06.
FluidMinimize: Step failed to reduce Etot after 3 attempts. Quitting step.
FluidMinimize: Undoing step.
FluidMinimize: Step failed along negative gradient direction.
FluidMinimize: Probably at roundoff error limit. (Stopping)
Fluid minimize took 6.16e+02 s.

Fluid minimization # 1 changed total free energy by -3.409663e-02 at t[s]: 636.73

-------------------- Electronic Minimization # 1 ---------------------
ElecMinimize: Iter: 0 Etot: -17.552467983906091 |grad|_K: 3.014e-04 alpha: 1.000e+00
ElecMinimize: Iter: 1 Etot: -17.556383547399736 |grad|_K: 1.256e-04 alpha: 7.479e-01 linmin: 2.824e-03 t[s]: 640.36
ElecMinimize: Iter: 2 Etot: -17.556922039525979 |grad|_K: 6.568e-05 alpha: 5.949e-01 linmin: -4.891e-04 t[s]: 642.36
ElecMinimize: Iter: 3 Etot: -17.557065290112568 |grad|_K: 2.747e-05 alpha: 5.777e-01 linmin: 7.724e-04 t[s]: 644.38
ElecMinimize: Iter: 4 Etot: -17.557100159165245 |grad|_K: 1.419e-05 alpha: 8.044e-01 linmin: -8.364e-04 t[s]: 646.40
ElecMinimize: Iter: 5 Etot: -17.557109778103854 |grad|_K: 7.744e-06 alpha: 8.302e-01 linmin: -3.270e-02 t[s]: 648.43
ElecMinimize: Iter: 6 Etot: -17.557112733643866 |grad|_K: 3.605e-06 alpha: 8.370e-01 linmin: -5.939e-05 t[s]: 650.44
ElecMinimize: Converged (|Delta Etot|<1.000000e-05 for 2 iters).
Setting wave functions to eigenvectors of Hamiltonian
...
Electronic minimization # 1 changed total free energy by -4.644750e-03 at t[s]: 650.44

---------------------- Fluid Minimization # 2 -----------------------
FluidMinimize: Iter: 0 Etot: -0.143990422635435 |grad|_K: 1.203e-03 alpha: 1.000e+00
FluidMinimize: Test step failed with Etot = -nan, reducing alphaT to 1.000000e-01.
FluidMinimize: Test step failed with Etot = nan, reducing alphaT to 1.000000e-02.
FluidMinimize: Test step failed with Etot = nan, reducing alphaT to 1.000000e-03.
FluidMinimize: Step failed with Etot = -nan, reducing alpha to 1.000000e-01.
FluidMinimize: Step failed with Etot = nan, reducing alpha to 1.000000e-02.
FluidMinimize: Step failed with Etot = nan, reducing alpha to 1.000000e-03.
FluidMinimize: Step failed to reduce Etot after 3 attempts. Quitting step.
FluidMinimize: Undoing step.
FluidMinimize: Step failed along negative gradient direction.
FluidMinimize: Probably at roundoff error limit. (Stopping)
Fluid minimize took 6.68e+01 s.

Fluid minimization # 2 changed total free energy by nan at t[s]: 717.95
...
---------------------- Fluid Minimization # 10 -----------------------
FluidMinimize: Iter: 0 Etot: +nan |grad|_K: 3.133e+11 alpha: 1.000e+00
FluidMinimize: E=nan. Stopping ...
Fluid minimize took 1.48e+01 s.

Fluid minimization # 10 changed total free energy by nan at t[s]: 850.08

-------------------- Electronic Minimization # 10 ---------------------
ElecMinimize: Iter: 0 Etot: +nan |grad|_K: 5.791e-01 alpha: 1.000e+00
ElecMinimize: E=nan. Stopping ...
Setting wave functions to eigenvectors of Hamiltonian

Electronic minimization # 10 changed total free energy by nan at t[s]: 851.15

Fluid<-->Electron self-consistency loop not yet converged to 1.000000e-05 hartrees after 10 minimization pairs at t[s]: 851.15.

I tried to use different starting points, e.g. a Classical DFT calculation with H20 solvent (but without Na and F ions), but the result is the same.

Do you have an idea what the problem could be?

Best regards

jdftx_gpu crashes at the beginning of initialization (SOLVED?)

Hi dear Shankar.

I'd like to ask for your advice. Without lots of your help, I would never master this cool program.

At last, after 4 failed attempts, I managed to install CUDA8.0, optimus and bumblebee. Programs from cuda samples run, at least those, which do not use graphics.

Unfortunately, jdftx_gpu crashes at the beginning of initialization just after reading pseudopotentials. Thus all tests fail.

At the end of all *.out files is:

Stack trace:
	 0: /src/jdftx-1.4.1_cuda/build/libjdftx_gpu.so(_Z10printStackb+0x21) [0x7f43c12749e1]
	 1: /src/jdftx-1.4.1_cuda/build/libjdftx_gpu.so(_Z14stackTraceExiti+0xd) [0x7f43c1274e3d]
	 2: /src/jdftx-1.4.1_cuda/build/libjdftx_gpu.so(_Z16matrixSubSet_gpuiiiiiiiPK7complexPS_+0x118) [0x7f43c1537ca8]
	 3: /src/jdftx-1.4.1_cuda/build/libjdftx_gpu.so(_ZN6matrix3setEiiiiiiRKS_+0x130) [0x7f43c1286990]
	 4: /src/jdftx-1.4.1_cuda/build/libjdftx_gpu.so(_ZN11SpeciesInfo5setupERK10Everything+0xcbd) [0x7f43c140e10d]
	 5: /src/jdftx-1.4.1_cuda/build/libjdftx_gpu.so(_ZN7IonInfo5setupERK10Everything+0xd4) [0x7f43c13daaf4]
	 6: /src/jdftx-1.4.1_cuda/build/libjdftx_gpu.so(_ZN10Everything5setupEv+0x4c4) [0x7f43c13ad674]
	 7: /src/jdftx-1.4.1_cuda/build/jdftx_gpu(main+0x8fa) [0x40d04a]
	 8: /usr/lib64/libc.so.6(__libc_start_main+0xf0) [0x7f43b1ec0600]
	 9: /src/jdftx-1.4.1_cuda/build/jdftx_gpu(_start+0x29) [0x40e269]
Writing 'jdftx-stacktrace' (for use with script printStackTrace):

Full output is here:
LinearPCM.out.txt

Graphical cuda samples crash with this:

  X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  24 (X_GLXCreateNewContext)
  Value in failed request:  0x0
  Serial number of failed request:  31
  Current serial number in output stream:  32

I mean that not everything works ok. But VESTA works.

Finally, adding cuda compute capability parameters for cmake maybe fixed the problem, as seen below.

Compilation OK, but test fail 4 systems

Hi,
I've successfully compiled JDFTx on my server.
But when I run "make test", after the running, I got this:

The running time is reasonable for successful tasks, but I don't know why other 4 tasks (3, 4, 9, 10) are wrong.
Could you help me clarify?
Thanks,
Best,
Zhengda

How to speed up the convergence?

Hi dear Shankar.

I'd like to ask you how to speed up the convergence?

I often face the following convergence issues - E steadily decreases, |grad|_K and SubspaceRotationAdjust oscillate and I need enormous number of cycles to converge to EnergyDiffThreshold 1e-8. There are XC functionals, that show such behaviour more often, like TPSS, orbGLLB-SC, maybe SCAN. But I often face convergence issues with GGA PBE. Just a few days ago I spent 15 hours for ElecMinimize with GGA PBE on Mg-transition metal compound, in contrary ElecMinimize took only 5h using SCAN with similar compound.

Facing problems with convergence, I often see similar messages:
ElecMinimize: Predicted alpha/alphaT>3.000000, increasing alphaT to 1.242439e-01.
ElecMinimize: Wrong curvature in test step, increasing alphaT to 3.094212e-02.
ElecMinimize: Undoing step.
ElecMinimize: Step failed: resetting search direction.

Convergence problems are with bulk, slabs, regardless of containing transition elements, etc. Thus they are not connected with some particular type of objects.

What settings could you advice me for electronic-minimize?
K-point folding?
Ecutoff?
I use mostly SG15 PPs, as they support wider range of functionals.

Here I submit output for several calculations for magnesium, XC SCAN. I just wanted to test it on simple objects.

Best wishes,
Igor.
X.zip

About surface energy

Hi shankar，
I have some trobules during calculating surface energy.(This may sound like a stupid question , but it really bother me!)
After Test compiled executable I got a file: /jdftx/build/test/metalSurface/netural.out,
neutral.out.txt
and I tried to calculate Esurf from this output file :
△E = ( Etot(netural.out))-3*-89.035087)= 0.076361 Hartree = 2.0778 eV
A= unit cell volume* 2/Lz= 475.518* 2/20 =47.5118 bohr^2 = 47.5118*0.05292^2 nm2 = 0.13317 nm2
Esurf =△E/A= 2.0778/ 0.13317 = 15.602 eV/nm2 （totally different from Tutorial：Metal surfaces ， in which the Esurf of Pt（111）is around 5 eV/nm2）
Could you point out my mistake?

Thanks for helping!

How to set parameters properly to accelerate calculation?

Hi dear shankar，
I‘m a beginner and I want to optimize N-doped graphene with JDFTx, I used this command:
include NiN4.ionpos
include NiN4.lattice
ion-species GBRV/$ID_pbe.uspp
elec-cutoff 20 100
coulomb-interaction Slab 001
elec-ex-corr gga-PBE
coulomb-truncation-embed 0 0 0.11332
coords-type Lattice
ionic-minimize
nIterations 10
energyDiffThreshold 1e-6
knormThreshold 2e-4
kpoint-folding 3 3 1
elec-smearing Fermi 0.01
electronic-SCF
add-U Ni d 3.79
fluid LinearPCM
pcm-variant CANDLE
fluid-solvent H2O
dump-name NiN4.$VAR
dump Ionic IonicPositions ElecDensity BoundCharge

I want to know is there something wrong with my input? The test takes much time and it's still unfinished.
Thank you very much.

Octave crashes when doing createVASP

Hi dear Shankar,
I've found another trouble - Octave crashes when doing createVASP.

[user@localhost ecut30]$ createVASP X.out X.vasp X.n 5
terminate called after throwing an instance of 'octave::exit_exception'
panic: Aborted -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 6

The same trouble is with scale factor 1.

Version:
[user@localhost ecut30]$ octave --version
GNU Octave, version 4.2.1
Copyright (C) 2017 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.

Octave was configured for "x86_64-mageia-linux-gnu".

It creates vasp file but it is truncated:
[user@localhost ecut30]$ bader X.vasp

GRID BASED BADER ANALYSIS (Version 1.03 11/13/17)

OPEN ... X.vasp
VASP4-STYLE INPUT FILE
At line 89 of file chgcar_mod.f90 (unit = 100, file = 'X.vasp')
Fortran runtime error: End of file

Where can I look in order to give you more info?

Best wishes, Igor

Using MathJax for formulae in documentation

To improve readability, I suggest to enable USE_MATHJAX in Doxy and convert all plain-text/HTML formulae to math format.
Look at the attached pics. Which one looks better?

How to obtain CoreDensity

Hello dear Shankar,

how could I obtain CoreDensity and then total electron density from JDFTX? I'd like to calculate atomic charges using "bader" program. The problem is, that if I specify CoreDensity in dump commands, JDFTx does not export this vaues, only ElecDensity and rhoAtom.
I am using v. 1.4.0.

I want to try to obtain total density (maybe add CoreDensity and ElecDensity), as this is more accurate data source for bader program. Preliminary calculations from low-res ElecDensity and knowing number of core electrons look quite reasonable
Li- atoms have no core density, but Zn have 10 electrons.

My input file is given below.

With best wishes,
Igor.

ion-species /src/jdftx-1.4.0/build/pseudopotentials/GBRV/li_pbe_v1.uspp
ion-species /src/jdftx-1.4.0/build/pseudopotentials/GBRV/zn_pbe_v1.uspp

#U-J for Zn d10 orb 5eV [Ha]
add-U Zn d 0.183745167502

cache-projectors no
coords-type lattice
include X.ionpos
include X.lattice

#for 10*300K
elec-smearing Fermi 0.0095

elec-n-bands 722
converge-empty-states yes

kpoint-folding 1 1 1 #
kpoint 0 0 0 1 # gamma-centered k-point mesh
#fftbox 320 480 600

#dump-only

electronic-minimize
nIterations 200
energyDiffThreshold 1e-8

elec-ex-corr gga-pbe
#van-der-waals

density-of-states Total Occupied Total

dump electronic state forces dos
dump End DOS CoreDensity ElecDensity State EigStats
#All

#wavefunction read ../X.wfns 656

initial-state X.$var
dump-name X.$var

HDF5 option is broken: use of undeclared identifier 'H5Pset_dxpl_mpio'

In file included from /usr/ports/science/jdftx/work/jdftx-1.4.2-73-g73b17437/jdftx/electronic/DumpBGW.cpp:34:
/usr/ports/science/jdftx/work/jdftx-1.4.2-73-g73b17437/jdftx/core/H5io.h:85:2: error: use of undeclared identifier 'H5Pset_dxpl_mpio'
        H5Pset_dxpl_mpio(plid, H5FD_MPIO_COLLECTIVE);
        ^

<< compiling using gcc version 4.4.7 >>

Hello @shankar1729,

After the compilation in my local computer I am trying to compile in a cluster.

In this cluster, there is available:
gcc version 4.4.7
OpenMPI 1.10.1, with wrappers:

mpic++     mpicxx     mpif90-vt   ompi-ps       orte-clean  orte-server  oshrun         otfmerge        shmemcc    vtcxx            vtfilter-mpi  vtunify-mpi
mpicc      mpicxx-vt  mpifort     ompi-server   orted       orte-submit  otfaux         otfmerge-mpi    shmemfort  vtf77            vtfort        vtwrapper
mpiCC      mpiexec    mpifort-vt  ompi-top      orte-dvm    orte-top     otfcompress    otfprint        shmemrun   vtf90            vtrun
mpicc-vt   mpif77     mpirun      opal_wrapper  orte-info   oshcc        otfconfig      otfprofile      vtc++      vtfilter         vtsetup
mpiCC-vt   mpif77-vt  ompi-clean  opari         orte-ps     oshfort      otfdecompress  otfprofile-mpi  vtcc       vtfiltergen      vtsetup.jar
mpic++-vt  mpif90     ompi_info   ortecc        orterun     oshmem_info  otfinfo        otfshrink       vtCC       vtfiltergen-mpi  vtunify

Trying to compile JDFTx with:
CC="/usr/local/clustertools/mpi/openmpi-1.10.1/bin/mpicc -fPIC" FC=/usr/local/clustertools/mpi/openmpi-1.10.1/bin/mpif90 CXX="/usr/local/clustertools/mpi/openmpi-1.10.1/bin/mpicxx -fPIC" cmake -D EnableMKL=yes -D LinkTimeOptimization=yes -D ForceFFTW=yes -D EnableLibXC=yes -D LIBXC_PATH=/home/ihosvanyrodriguez/bin/LibXC -D GSL_PATH=/usr/local/clustertools/gsl-2.4-install ../jdftx-1.3.1/jdftx

gave me the following errors:

[  1%] Building CXX object CMakeFiles/jdftxlib.dir/core/CoulombKernel.cpp.o
In file included from /home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/CoulombKernel.h:23,
                 from /home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/CoulombKernel.cpp:20:
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h: In member function ‘vector3<double> WignerSeitz::restrict(const vector3<double>&) const’:
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:46: error: expected initializer before ‘:’ token
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:55: error: expected primary-expression at end of input
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:55: error: expected ‘;’ at end of input
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:55: error: expected primary-expression at end of input
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:55: error: expected ‘)’ at end of input
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:55: error: expected statement at end of input
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:55: error: expected ‘}’ at end of input
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:41: warning: unused variable ‘tol’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:55: error: expected ‘}’ at end of input
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:55: warning: no return statement in function returning non-void
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h: In member function ‘vector3<int> WignerSeitz::restrict(const vector3<int>&, const vector3<int>&, const vector3<double>&) const’:
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:64: error: expected initializer before ‘:’ token
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:78: error: expected primary-expression at end of input
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:78: error: expected ‘;’ at end of input
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:78: error: expected primary-expression at end of input
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:78: error: expected ‘)’ at end of input
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:78: error: expected statement at end of input
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:78: error: expected ‘}’ at end of input
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:59: warning: unused variable ‘tol’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:78: error: expected ‘}’ at end of input
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:78: warning: no return statement in function returning non-void
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h: In member function ‘double WignerSeitz::boundaryDistance(const vector3<double>&, int) const’:
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:85: error: expected initializer before ‘:’ token
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:92: error: expected primary-expression before ‘return’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:92: error: expected ‘;’ before ‘return’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:92: error: expected primary-expression before ‘return’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:92: error: expected ‘)’ before ‘return’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h: In member function ‘bool WignerSeitz::onBoundary(const vector3<double>&, int) const’:
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:100: error: expected initializer before ‘:’ token
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:107: error: expected primary-expression before ‘return’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:107: error: expected ‘;’ before ‘return’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:107: error: expected primary-expression before ‘return’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/WignerSeitz.h:107: error: expected ‘)’ before ‘return’
In file included from /home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/LatticeUtils.h:29,
                 from /home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/CoulombKernel.cpp:22:
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/Util.h: In function ‘bool fftSuitable(int)’:
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/Util.h:174: error: expected initializer before ‘:’ token
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/Util.h:176: error: expected primary-expression before ‘return’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/Util.h:176: error: expected ‘;’ before ‘return’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/Util.h:176: error: expected primary-expression before ‘return’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/Util.h:176: error: expected ‘)’ before ‘return’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/Util.h:172: warning: unused variable ‘primes’
In file included from /home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/CoulombKernel.cpp:22:
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/LatticeUtils.h: In member function ‘size_t PeriodicLookup<T>::find(vector3<double>, Tag, const std::vector<Tag, std::allocator<_Tp1> >*, TagEquality) const’:
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/LatticeUtils.h:144: error: expected initializer before ‘:’ token
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/LatticeUtils.h:148: error: expected primary-expression before ‘return’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/LatticeUtils.h:148: error: expected ‘;’ before ‘return’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/LatticeUtils.h:148: error: expected primary-expression before ‘return’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/LatticeUtils.h:148: error: expected ‘)’ before ‘return’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/CoulombKernel.cpp: In member function ‘void CoulombKernel::computeWire(double*, const WignerSeitz&) const’:
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/CoulombKernel.cpp:275: error: expected initializer before ‘:’ token
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/CoulombKernel.cpp:284: error: expected primary-expression before ‘mJobCount’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/CoulombKernel.cpp:284: error: expected ‘;’ before ‘mJobCount’
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/CoulombKernel.cpp:284: error: ‘mJobCount’ was not declared in this scope
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/CoulombKernel.cpp:284: error: expected ‘)’ before ‘;’ token
/home/ihosvanyrodriguez/temp/JDFTx/jdftx-1.3.1/jdftx/core/CoulombKernel.cpp:285: error: ‘mJobCount’ was not declared in this scope
At global scope:
cc1plus: warning: unrecognized command line option "-Wno-unused-result"
make[2]: *** [CMakeFiles/jdftxlib.dir/core/CoulombKernel.cpp.o] Error 1
make[1]: *** [CMakeFiles/jdftxlib.dir/all] Error 2
make: *** [all] Error 2

I am not sure if I am using the correct wrappers. Also, I tried to compile with the -std=c++0x or -std=gnu++0x directive obtaining the same errors.

Many thanks in advance.

Camps

shankar1729 / jdftx Goto Github PK

jdftx's People

Contributors

Stargazers

Watchers

Forkers

jdftx's Issues

Ionic positions in cartesian coordinates:

Recommend Projects

Recommend Topics

Recommend Org