Is thos normal?

F.G.

do="skip"

inside the <groundstate> element.

Further explanations can be found in the input reference:
http://exciting-code.org/input-reference-essential-expert#attdo

Cheers,
Stephan

I'm trying to calculate the ELF1,2,3D on a simple crystal (LiOH).

I wish to know what i have to do to perform a ELF without calculate everytime the groundstate, in other words, what is the key to resume STATE.OUT when you want to calculate the properties.

Thanks in advice!

F. G.

best wishes,
Stephan

I downloaded the newest version of exciting! . Now I tried to calculate the first component of the optical tensor of Fe. For this I used the input file of the examples of Fe and I added the properties momentummatrix, dielectric and linresptensor (optcomp 1 1 1).

inputfile:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="inputtohtml.xsl" type="text/xsl"?>

<input xsi:noNamespaceSchemaLocation="../../xml/excitinginput.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsltpath="../../../xml/" scratchpath="/tmp/chm/1">
<title></title>
<structure speciespath="../../species/">
<crystal scale="2.708">
<basevect>1.0 1.0 -1.0</basevect>
<basevect> 1.0 -1.0 1.0</basevect>
<basevect> -1.0 1.0 1.0</basevect>
</crystal>
<species speciesfile="Fe.xml">
<atom coord="0.0 0.0 0.0" bfcmt="0.0 0.0 0.0"></atom>
</species>
</structure>
<groundstate vkloff="0.5 0.5 0.5" nempty="10" ngridk="10 10 10" mixer="lin">
<spin bfieldc="0.0 0.0 0.01" spinorb="false"></spin>
</groundstate>
<properties>
<bandstructure>
<plot1d>
<path steps="200">
<point coord="0.00000 0.00000 0.00000" label="GAMMA"></point>
<point coord="0.50000 0.50000 -0.50000" label="H"></point>
<point coord="0.50000 0.00000 0.00000" label="N"></point>
<point coord="0.00000 0.00000 0.00000" label="GAMMA"></point>
<point coord="0.25000 0.25000 0.25000" label="P"></point>
</path>
</plot1d>
</bandstructure>
<momentummatrix>
</momentummatrix>
<dielectric>
</dielectric>
<linresponsetensor>
<optcomp>1 1 1</optcomp>
</linresponsetensor>
</properties>
</input>

But after starting I only get a error message:

Info(writegeom):
EXCITING lattice vectors and atomic positions written to geometry.xml
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
excitingser 0826CECB Unknown Unknown Unknown
excitingser 08203AFB Unknown Unknown Unknown
excitingser 082C8DA2 Unknown Unknown Unknown

Stack trace terminated abnormally.

Can you explain, why it does not work.
Thank you

Svenja Vollmar

Any XML editor will alarm you if your XML is invalid. They will even validate the input file against the schema and assist with the input.

I think my original point still stands, though. It would be nice if the error message said something meaningful. It is obvious that there was a parse error with the input file but no other information can be gleaned from the message. Any kind of information, for example "error near line x" or "unclosed declaration <species>", would be really nice. In this particular case I was just being an idiot, but but this input file is fairly simple and basic; with more complicated and complex input files, tracking down errors might prove more difficult (and frustrating).

This should work

 <?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet href="inputtohtml.xsl" type="text/xsl"?> <input> <title></title> <structure speciespath="../../species/"> <crystal scale="4.128"> <basevect> 0.8660 0.5000 0.0000</basevect> <basevect>-0.8669 0.5000 0.0000</basevect> <basevect> 0.0000 0.0000 1.4024</basevect> </crystal> <species speciesfile="Mn_Jim.xml"> <atom coord="0.0 0.0 0.0" bfcmt="0.0 0.0 0.0"></atom> <atom coord="0.0 0.0 0.5" bfcmt="0.0 0.0 0.0"></atom> </species> <species speciesfile="Sb_Jim.xml"> <atom coord=" 0.2887 0.5000 0.3506" bfcmt="0.0 0.0 0.0"></atom> <atom coord="-0.2887 0.5000 1.0518" bfcmt="0.0 0.0 0.0"></atom> </species> </structure> <groundstate vkloff="0.5 0.5 0.5" nempty="10" ngridk="5 5 5"> <spin bfieldc="0.0 0.0 0.01" spinorb="true"></spin> </groundstate> <properties> <bandstructure> <plot1d> <path steps="200"> <point coord="0.00000 0.00000 0.00000" label="GAMMA"></point> <point coord="1.00000 0.50000 0.00000" label="M"></point> <point coord="1.00000 0.00000 0.00000" label="K"></point> <point coord="0.00000 0.00000 0.00000" label="GAMMA"></point> <point coord="0.00000 0.00000 0.50000" label="A"></point> <point coord="1.00000 0.50000 0.50000" label="L"></point> <point coord="1.00000 0.00000 0.50000" label="H"></point> <point coord="0.00000 0.00000 0.50000" label="A"></point> </path> </plot1d> </bandstructure> <dos/> </properties> </input> 

parse error usually means that the xml is not valid xml

I've adapted the example Fe input.xml file to my material system - MnSb. It is a double hexagonal crystal of the NiAs type. I have included all of the atoms, specified the basis vectors and all other necessary variables. I have attempted to run the input file with increasingly fewer things to calculate - getting down to just the groundstate - and yet the input file doesn't run. All I get is:

 PARSE_ERR 81 runParser abort: 

There is no reason that I can see in my input file for this error message. This new input file (copied in full below) is in a new directory in examples/, so the relative paths to the xml and species directories are the same as for Fe, and all the other example input.xml files.

I think this highlights however why I feel that informative error messages are absolutely vital. The above error message is next to useless as it provides no information to the user as to what is wrong, which part of the input file it cannot parse and give indications on how to correct the error. (Although the last part isn't necessary the first two are hugely important.)

Anyway, I really need to get this to work, so any help would, as always, be hugely appreciated.

 <?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet href="inputtohtml.xsl" type="text/xsl"?> <input xsi:noNamespaceSchemaLocation="../../xml/excitinginput.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsltpath="../../../xml/"> <title></title> <structure speciespath="../../species/"> <crystal scale="4.128"> <basevect> 0.8660 0.5000 0.0000</basevect> <basevect>-0.8669 0.5000 0.0000</basevect> <basevect> 0.0000 0.0000 1.4024</basevect> </crystal> <species speciesfile="Mn_Jim.xml"> <atom coord="0.0 0.0 0.0" bfcmt="0.0 0.0 0.0"></atom> <atom coord="0.0 0.0 0.5" bfcmt="0.0 0.0 0.0"></atom> <species speciesfile="Sb_Jim.xml"> <atom coord=" 0.2887 0.5000 0.3506" bfcmt="0.0 0.0 0.0"></atom> <atom coord="-0.2887 0.5000 1.0518" bfcmt="0.0 0.0 0.0"></atom> </species> </structure> <groundstate vkloff="0.5 0.5 0.5" nempty="10" ngridk="5 5 5"> <spin bfieldc="0.0 0.0 0.01" spinorb="true"></spin> </groundstate> <properties> <bandstructure> <plot1d> <path steps="200"> <point coord="0.00000 0.00000 0.00000" label="GAMMA"></point> <point coord="1.00000 0.50000 0.00000" label="M"></point> <point coord="1.00000 0.00000 0.00000" label="K"></point> <point coord="0.00000 0.00000 0.00000" label="GAMMA"></point> <point coord="0.00000 0.00000 0.50000" label="A"></point> <point coord="1.00000 0.50000 0.50000" label="L"></point> <point coord="1.00000 0.00000 0.50000" label="H"></point> <point coord="0.00000 0.00000 0.50000" label="A"></point> </path> </plot1d> </bandstructure> <dos/> </properties> </input> 

I tried a 64 atoms supercell calculation with 8x8x8 k-point grid. There was the following error message :

excitingmpi(36114) malloc: * mmap(size=2405527552) failed (error code=12)
* error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
At line 197 of file ../../src/init1.f90
Traceback: not available, compile with -ftrace=frame or -ftrace=full
Operating system error: Cannot allocate memory
Memory allocation failed

when I add either -g -ftrace=full or frame, I have the following error message :

excitingmpi(27612) malloc: * mmap(size=2405527552) failed (error code=12)
* error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
At line 197 of file ../../src/init1.f90
Traceback: (Innermost first)
Called from line 45 of file ../../src/gndstate.f90
Called from line 31 of file ../../src/src_inputparser/tasklauncher.f90
Called from line 21 of file ../../src/mainxml/main.f90
Operating system error: Cannot allocate memory
Memory allocation failed

mpirun has exited due to process rank 5 with PID 27612 on
node supernano.physics.uiowa.edu exiting without calling "finalize". This may
have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).

The critical lines are :

The critical line is this:

init1.f90:197 allocate(sfacgk(ngkmax, natmtot, nspnfv, nkpt))

which is where the allocation failure occurs. From the mpi communication:

gndstate.f90: call MPI_Bcast(sfacgk, size(sfacgk), MPI_DOUBLE_PRECISION, 0, MPI_COMM_WORLD, ierr)

it appears that sfacgk is *not* split up among the different processes, but rather each process has a complete copy of sfacgk. Is it correct, and if it is a bug or was intentional?

Best,

Thomas

Yes sorry about that, I was in galaxy far far away.

/home/chanier/G95/g95-install/bin/i386-apple-darwin8.11.1-g95 -O3 -m64 -cpp -DXS -DISO -DTETRA -m64 -I./finclude -c ../../src/libbzint/tetra_internal.f90
../../src/libbzint/tetra_internal.f90:0: sorry, unimplemented: 64-bit mode not compiled in
make[3]: * [tetra_internal.o] Error 1
make[2]: * [libbzint.a] Error 2
make[1]: * [all] Error 2
make: * [serial] Error 2

Do you have an idea to solve this problem?

Thank you for your help,

Thomas

I have some problems to install EXCITING with g95 -m64 (it compiles in 32 bit architecture but I need the 64 arch to overcome the memory allocation limitation for fortran 32 bits on Mac). Here is the compiler lines in make.inc :
F90=/home/chanier/G95/g95-install/bin/i386-apple-darwin8.11.1-g95
F77=$(F90)
F90_OPTS = -O3 -m64
F77_OPTS = -O3 -freal-loops -m64
CPP_ON_OPT = -cpp -DXS -DISO -DTETRA

I have the following error message when I run make :

F90=/home/chanier/G95/g95-install/bin/i386-apple-darwin8.11.1-g95
F77=$(F90)
F90_OPTS = -O3 -m64
F77_OPTS = -O3 -freal-loops -m64
CPP_ON_OPT = -cpp -DXS -DISO -DTETRA

Do you have any idea to overcome the problem? Thank you for your help.

Thomas

Yes of course it is possible to take part in the EXCITING project. We are happy that you are interested to include spin in TDDFT.
So I would like to ask you to contact me on my e-mail (which can be found here: http://amadm.unileoben.ac.at/sag.html) and I will provide you with further information about taking part in the project.
Thanks for your involvement!

Best wishes,
Stephan

I need to do spin-polarized TDDFT calculation for 3D periodic boundary condition system. The EXCITING code is the most advanced code in what I have in mind. So, I would like to get involved in the EXCITING project and include spin in the TDDFT routine. Is it possible to take part of the EXCITING project?

Best,

Thomas Chanier

for the moment, the TDDFT implementation is done for the spin-unpolarized case.
However, efforts are focussed towards a spin-polarized version of TDDFT which could
be part of a future release of exciting.

Thanks,
best wishes,
Stephan

I would like to know if the TDDFT implemented in EXCITING is applicable to spin-polarized system?

Thank you in advance,

Thomas Chanier

Is there a memory problem? make fails with mpi, after make clean , make, I got the following error message :

end module control
1
Error: Non-numeric character in statement label at (1)
Fatal Error: Error count reached limit of 25.
make[3]: * [tetra_internal.o] Error 1
make[2]: * [libbzint.a] Error 2
make[1]: * [all] Error 2
make: * [mpi] Error 2

Do you have any idea?

Thanks

Thomas

Makefile.mkmf:2196: warning: overriding commands for target ‘version.inc’
Makefile.mkmf:1694: warning: ignoring old commands for target ‘version.inc’
/home/chanier/G95/g95-install/bin/i386-apple-darwin8.11.1-g95 -O3 -cpp -DXS -DISO -DTETRA -I./finclude -c ../../src/src_inputparser/modinputdom.f90
Fatal Error: While reading module 'fox_dom' found module version 0, expected 6.
make[3]: * [modinputdom.o] Error 1
make[2]: * [bin] Error 2
make[1]: * [all] Error 2
make: * [serial] Error 2

Do you have another idea?

Thanks,

Thomas

"make clean"

should do the trick.

I tried with an executable version of g95 for Mac. Now, I get this error:

/home/chanier/G95/g95-install/bin/i386-apple-darwin8.11.1-g95 -O3 -cpp -DXS -DISO -DTETRA -I./finclude -c ../../src/src_inputparser/modinputdom.f90
Fatal Error: While reading module 'fox_dom' found module version 0, expected 6.
make[3]: * [modinputdom.o] Error 1
make[2]: * [bin] Error 2
make[1]: * [all] Error 2
make: * [serial] Error 2

Do you have an idea to solve this problem?

Thanks

TC

I am experiencing some difficulties to install EXCITING on Mac Snow Leopard, with gfortran compiler and openmpi. The code compilation is OK, apparently, it issues at the end the executable excitingser and excitingmpi. The problem is that when I run exciting for the simple case of Ag (input file given in the example directory), it issues directly a Segmentation Fault without running.
Here is my make.inc file:

#############################
F90=gfortran
F77=$(F90)
F90_OPTS =# -g -DEBUG #-O2
F77_OPTS = # -O2 -freal-loops
CPP_ON_OPT = -cpp -DXS -DISO -DTETRA
LIB_ARP =libarpack.a
LIB_LPK = -L./ -llapack -lblas
LIB_FFT = -L./ fftlib.a
LIB_BZINT= libbzint.a
#####################################
LIBS= $(LIB_ARP) $(LIB_LPK) $(LIB_FFT) $(LIB_BZINT)

F90_DEBUGOPTS=-g -ftrace=full
F77_DEBUGOPTS=-g -ftrace=full

#Ignore if you don't have MPI or smplibs

MPIF90=/sw/openmpi/bin/mpif90
MPIF90_OPTS= $(F90_OPTS) $(CPP_ON_OPT) -DMPI -DMPIRHO -DMPISEC

F77MT=$(F77)
F90MT=$(F90)

SMP_LIBS=
SMPF90_OPTS=$(F90_OPTS)
SMPF77_OPTS=$(SMPF90_OPTS)

BUILDMPI=true
BUILDSMP=false

Do you have any idea to solve this problem?

best regards,

Thomas Chanier

I will simply use the current installation then.

K Jorissen

cheers

I've just installed the latest version of exciting on a linux machine running ifort 9.1. When installing, I simply copied the ifort make.inc. I'm not looking at MPI or SMP yet. No other changes.

When I run the tests (again, simply running the Makefile without changes), several tests fail as shown below. I take it that's bad news. I haven't tried to do anything different yet - hoping someone has advice on what to try first.

Thanks!

Kevin

[jorissen@raphael exciting]$ more test/report/all.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="./report.xsl" type="text/xsl"?>
<report>
<test>
<name>Broydenfile S rwtest</name>
<description>- - </description>
<directory>test04</directory>
<status>passed</status>
</test>
<test>
<name>Broydenfile Y rwtest</name>
<description>- - </description>
<directory>test04</directory>
<status>passed</status>
</test>
<test>
<name>Eigenvalues_same_as_reference_file</name>
<description>The test is passed if the eigenvalues differ
less than 1e-05 between runlapack/EIGVAL.OUT and reference file reference/EIGVAL.OUT
difference=0</description>
<directory>test02/ </directory>
<status>passed</status>
</test>
<test>
<name>Pulay mixing works</name>
<description>The test run using pulay (3) finished without errors</description>
<directory>test03/runmixer3</directory>
<status>failed</status>
</test>
<test>
<name>arpack run</name>
<description>The arpack solver was correctly invoked</description>
<directory>test02/runarp</directory>
<status>passed</status>
</test>
<test>
<name>check iteration number of Al</name>
<description>iterations is 18 reference is 17</description>
<directory>test03/run</directory>
<status>failed</status>
</test>
<test>
<name>check iteration number of Al for Pulay mixing (3) </name>
<description>iterations is 10 reference is 10</description>
<directory>test03/runmixer2</directory>
<status>passed</status>
</test>
<test>
<name>check iteration number of Al for mixer2</name>
<description>iterations is 3 reference is 10</description>
<directory>test03/runmixer2</directory>
<status>passed</status>
</test>
<test>
<name>debug binary run</name>
<description>The test run standard mixing finished without errors</description>
<directory>test03/run</directory>
<status>failed</status>
</test>
<test>
<name>debug binary run mixer2</name>
<description>The test run using multicecant broyden finished without errors</description>
<directory>test03/runmixer2</directory>
<status>failed</status>
</test>
<test>
<name>eigenvalue_comparison_LAPACK ARPACK </name>
<description>The test is passed if the eigenvalues differ
less than 1e-05 between lapack and Arpack
difference=0.1599309358</description>
<directory>test02/ </directory>
<status>failed</status>
</test>
<test>
<name>is_it_Pulay</name>
<description>Pulay Mixing is used</description>
<directory>test03/runmixer3</directory>
<status>passed</status>
</test>
<test>
<name>is_it_linadapt</name>
<description>linadapt mixer was invoked</description>
<directory>test03/run</directory>
<status>passed</status>
</test>
<test>
<name>is_it_msec</name>
<description>used msec</description>
<directory>test03/runmixer2</directory>
<status>failed</status>
</test>
<test>
<name>lapack_run</name>
<description>The test run using lapack finished without errors</description>
<directory>test02/runlapack</directory>
<status>failed</status>
</test>
<test>
<name>totalenergy_compare_LAPACK_ARPACK </name>
<description>The test is passed if the total energy differs
less than 1e-07 between lapack and Arpack
difference=-5.42000009318144e-07</description>
<directory>test02/ </directory>
<status>failed</status>
</test>
</report>
[jorissen@raphael exciting]$

The error occurs just after the beginning of the first SCF iteration in the second optimization cykle. The last lines of INFO.OUT look like this:

Maximum force magnitude (target) : 0.8854817892E-03 ( 0.4999999874E-04)

+------+
| Updated atomic positions |
+------+

Species : 1 (Mg)
atomic positions (lattice) :
1 : 0.00000000 0.00000000 0.00000000
2 : 0.50000000 0.50000000 0.50000000

Species : 2 (H)
atomic positions (lattice) :
1 : 0.00000000 0.30411459 0.30411459
2 : 0.00000000 0.69588541 0.69588541
3 : 0.50000000 0.19588541 0.80411459
4 : 0.50000000 0.80411459 0.19588541

+------+
| Self-consistent loop started |
+------+

+-----+
| Iteration number : 1 |
+-----+

Using advanced method for search of linearization energies

I can send you the results of strace it you want. the input file goes below:

<title>MgH2</title>
<structure primcell="true" speciespath="../../source/species/">
<symmetries HermannMauguinSymbol="P42/mnm" HallSymbol="-P 4n 2n" SchoenfliesSymbol="D4h^14" spaceGroupNumber="D4h^14">
<lattice a="8.58018" b="8.58018" c="5.71567" ab="90.0" ac="90.0" bc="90.0"></lattice>
<WyckoffPositions>
<wspecies speciesfile="Mg.xml">
<wpos coord="0.000000000 0.000000000 0.000000000"/>
</wspecies>
<wspecies speciesfile="H.xml">
<wpos coord="0.3041000000 0.3041000000 0.000000000"/>
</wspecies>
</WyckoffPositions>
</symmetries>
<crystal>
<basevect>8.58018 0.00000 0.00000</basevect>
<basevect>0.00000 8.58018 0.00000</basevect>
<basevect>0.00000 0.00000 5.71567</basevect>
</crystal>
<species speciesfile="Mg_natanzon.xml">
<atom coord="0.0000 0.0000 0.0000"/>
<atom coord="0.5000 0.5000 0.5000"/>
</species>
<species speciesfile="H_natanzon.xml">
<atom coord="0.3041 0.3041 0.0000"/>
<atom coord="0.6959 0.6959 0.0000"/>
<atom coord="0.1959 0.8041 0.5000"/>
<atom coord="0.8041 0.1959 0.5000"/>
</species>
</structure>
<structureoptimization resume="true"></structureoptimization>
<groundstate ngridk="3 3 5" rgkmax="6" chgexs="0" xctype="GGAPerdew-Burke-Ernzerhof"></groundstate>
</input>

In src/setdefault.f90 I change ldapu=0 by ldapu=1 (Fully Localised Limit)

Then after ujlu(:, :)=0.d0 I add:
llu(1)=1 ! p orbital of the first specie
ujlu(1,1)=0.33 ! U for the first specie
ujlu(2,1)=0.00 ! J for the first specie

Then I recompile exciting and use the input:
<groundstate ngridk="1 1 2" rgkmax="6" chgexs="0" xctype="GGAPerdew-Burke-Ernzerhof">

the program performs LDA+U calculations by default.

I now have two versions of exciting located in different directories: the one with U enabled and the one with U disabled.

Not very convenient, but works. I confirm that neigther ldapu nor LDAplusu are read from the input. The first one results in parse error and the second one is just ignored (I've checked it by inspecting INFO.OUT file as well as the code).

The input file which I use goes below:

<input xsi:noNamespaceSchemaLocation="../../source/xml/excitinginput.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsltpath="../../../xml/" scratchpath="/tmp/chm/1">
<title>MgH2</title>
<structure primcell="true" speciespath="../../source/species/">
<symmetries HermannMauguinSymbol="P42/mnm" HallSymbol="-P 4n 2n" SchoenfliesSymbol="D4h^14" spaceGroupNumber="D4h^14">
<lattice a="8.58018" b="8.58018" c="5.71567" ab="90.0" ac="90.0" bc="90.0"></lattice>
<WyckoffPositions>
<wspecies speciesfile="Mg.xml">
<wpos coord="0.000000000 0.000000000 0.000000000"/>
</wspecies>
<wspecies speciesfile="H.xml">
<wpos coord="0.3041000000 0.3041000000 0.000000000"/>
</wspecies>
</WyckoffPositions>
</symmetries>
<crystal>
<basevect>8.58018 0.00000 0.00000</basevect>
<basevect>0.00000 8.58018 0.00000</basevect>
<basevect>0.00000 0.00000 5.71567</basevect>
</crystal>
<species speciesfile="Mg.xml">
<atom coord="0.0000 0.0000 0.0000"/>
<atom coord="0.5000 0.5000 0.5000"/>
<LDAplusu U="0.33" J="0.0" L="0"/>
<LDAplusu U="0.33" J="0.0" L="1"/>
<LDAplusu U="0.33" J="0.0" L="2"/>
</species>
<species speciesfile="H.xml">
<atom coord="0.3041 0.3041 0.0000"/>
<atom coord="0.6959 0.6959 0.0000"/>
<atom coord="0.1959 0.8041 0.5000"/>
<atom coord="0.8041 0.1959 0.5000"/>
</species>
</structure>
<groundstate ngridk="1 1 2" rgkmax="6" chgexs="0" ldapu="FullyLocalisedLimit" xctype="GGAPerdew-Burke-Ernzerhof"></groundstate>
</input>

actually this ldapu attribute should work, could you post an input file and the version of the code you use

$ ../../source/bin/excitingser
»»> unrecognized attribute:
ldapu="FullyLocalisedLimit" in element groundstate

I've tried ldapu="1" and even ldapu="none", but with no success. But after looking at the code it seems that LDA+U is implemented, so could you suggest how I can use it?

Another question not related to this topic is how I can introduce the charge defects in the cell? does chgexs="+1" correspond to a cell with an electron added or removed? You have the positive electron charge, so I can't well understand how it is related to the charge of the cell. Also, in Wien2k if one needs to remove an electron it changes the number of valence electrons in case.in2 and adds the background charge in mixer. What about exciting, I cannot find where I can change the number of electrons, so I just change chgexs parameter, but does it really changes the electron number or it is a kind of background charge?

Thank you in advance for the help,
Yurko.

I've had a look at the Al example that comes with the exciting source code. I see that the following high symmetry points are defined in the input file:

  <point coord=" 0.75000 0.50000 0.25000" label="W" /> <point coord=" 0.50000 0.50000 0.50000" label="L" /> <point coord=" 0.00000 0.00000 0.00000" label="GAMMA" /> <point coord=" 0.50000 0.50000 0.00000" label="X" /> <point coord=" 0.75000 0.50000 0.25000" label="W" /> <point coord=" 0.75000 0.37500 0.37500" label="K" /> 

but I cannot seem to tally these co-ordinates with those in the Brillouin zone. The gamma point is at the centre of the zone and is being taken as the origin, but I'm having difficulty in figuring out why the other points have their specified locations. As I understand it, the gamma, K, x and w points are all co-planar, but each have different values of 'z'. I also understand that the x point is taken to be at the centre of a square face in the Brillouin zone and along the y-direction but that doesn't seem to be the case here.

I have tried to determine the band structure of my material (MnSb) which is a hexagonal crystal but the points that I have used do not seem to be high symmetry points and, frankly, the plotted band structure is a mess! The following are the co-ordinates that I use:

  <point coord="0.00000 0.00000 0.00000" label="GAMMA" ></point> <point coord="0.75000 0.43300 0.00000" label="M" ></point> <point coord="1.00000 0.00000 0.00000" label="K"></point> <point coord="0.00000 0.00000 0.00000" label="GAMMA" ></point> <point coord="0.00000 0.00000 1.00000" label="A" ></point> <point coord="0.75000 0.43330 1.00000" label="L" ></point> <point coord="1.00000 0.00000 1.00000" label="H" ></point> 

I calculated these co-ordinates with James Annett during last year's Psi-k DFT workshop held at Bristol University. We were happy that, given the definition of the gamma point being the origin and the location of the high symmetry points given at http://www.ioffe.ru/SVA/NSM/Semicond/Append/figs/fmd21_5.gif that these co-ordinates were correct, but that does not seem to be the case.

So, my questions are: how were the aluminium high symmetry points determined and what are the corresponding points for the hexagonal Brillouin zone?

Kind regards,
James

yes, exciting is designed for infinte systems with 3D periodic boundary conditions.

Cheers,
Stephan

I would like to know if the TDDFT within the EXCITING code can address infinite system with 3D periodic boundary condition.

Thank you in anticipation,

Best,

Thomas Chanier

The computer cluster comprises of a front end with 5 slave computational nodes. Each box contains two quad core Intel processors operating at ~2.2 GHz and is running a Debian-based operating system. The version of the Intel Fortran compiler used on the cluster is 10.1.015. The following are the necessary files to get the MPI and Serial codes to work. I have compiled a version of the SMP codes, but they seem somewhat broken.

I have run the Fe example included with the code with the addition of a DOS calculation. The serial calculation takes about 6 minutes 10 seconds; the MPI code takes about 3 minutes 40 seconds across four different cores on the same node, which is about 60% of the time. I suspect that one core is being used as a "master" core, whilst the other three farm out specific calculations to the three "slave" nodes. Thus only three cores are doing the computational work that a single core would do in the serial calculation. Perhaps someone can clarify that point?

I suspect I would see better results across more cores and with a more computationally heavy calculation, e.g. a structural optimisation. I'll test these out, but for the time being these are the results I have obtained.

I should also perhaps attach a slight "health warning" with the following files insofar as I'm utterly new to editing makefiles. I have essentially fiddled and played with the files until all library dependencies were solved and everything compiled without complaining. The codes also do appear to have compiled correctly - the band structure plots are identical between the two calculations - but the final binaries may not be fully optimised or use the best libraries and compiler options. At this stage however I'm happy they have compiled OK and appear to work!

I will continue to play with the library and compiler options in my own time. Until then, these are the files that I used to compile the MPI and serial binaries.

MAKE.INC

 F90=ifort F90_OPTS = -parallel -O3 -ip -unroll -prefetch -scalar_rep -w90 -fpp -cpp CPP_ON_OPT = -DXS -DISO -DTETRA F77=$(F90) F77_OPTS = -parallel -O3 -ip -unroll -prefetch -scalar_rep -w90 -fpp -cpp LIB_ARP =libarpack.a #export USE_SYS_LAPACK=true MKLPATH =/usr/local/intel/mkl/10.0.3.020/lib/em64t MKLINCLUDE=/usr/local/mpich2/include LIB_LPK_SMB = -L$(MKLPATH) -I$(MKLINCLUDE) -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread LIB_LPK = liblapack.a libblas.a LIB_FFT = fftlib.a LIB_BZINT=libbzint.a LIBS= $(LIB_ARP) $(LIB_LPK) $(LIB_FFT) $(LIB_BZINT) F90_DEBUGOPTS=-g -O0 -warn all -check all -traceback -ftrapuv F77_DEBUGOPTS=-g -O0 -warn all -check all -traceback -ftrapuv #Ignore if you don't have MPI or smplibs MPIF90=mpif90 MPIF90_OPTS=$(F90_OPTS) -DMPI -DMPIRHO -DMPISEC F77MT=$(F77) F90MT=$(F90) SMP_LIBS= $(LIB_ARP) $(LIB_LPK_SMB) $(LIB_FFT) $(LIB_BZINT) SMPF90_OPTS=$(F90_OPTS) SMPF77_OPTS=$(SMPF90_OPTS) MPISMPF90_OPTS=$(SMPF90_OPTS) -DMPI -DMPIRHO -DMPISECBUILDMPI=false BUILDSMP=false #test BUILDMPI=true BUILDSMP=true 

build/mpi/template

 include ../make.inc include ../libraries.inc FC = $(MPIF90) ### default FFLAGS = $(MPIF90_OPTS) -Ifinclude ### debug LD = $(FC) LDFLAGS =$(MPI_OPTS) $(SMP_LIBS) $(INTERNALLIBS) TMPFILES = *.mod SUFFIX=mpi 

The SMP versions of the code are a little more tricksy. They did compile and a binary was made, however, when I submitted an smp+MPI job to a node it sat there for ages and took far longer than the serial took. In the end I just deleted the job. I am looking into this…

Regards,
James

The .agr files open up OK in xmgrace version 5 (I have that installed on my local laptop and home PC) but the same file will not open on the remote computer cluster which runs xmgrace version 6. The given error is:

  syntax error: PAGE RESIZE 600, 600 Failed loading project file 

I also appreciate that this isn't strictly an Exciting problem, but I felt like it should be mentioned as other people may encounter this same problem.

I guess it is possible that the syntax has changed between versions, and it is also possible that the version of xmgrace on our computer cluster may be borked. I will check this out by installing version 6 on my local machine, but I wondered if anyone knew for definite before I set about investigating this problem as I really have very little experience with xmgrace.

The problem with the smpmpi not compiling properly appears to stem from the template file in build/mpiandsmp directory not pointing to the correct compiler and compiler options. I've done what I think needs to be done and it is currently compiling the source code…. And it has finished as I type.

I will post the relevant make files when I am happy that I these make files work. =)

Regards,
James

I now have an excitingsmp binary - but I've no idea if it works yet! - but it will not build the smpmpi binary…. I have an idea or two; looking into it now =)

What is causing me some confusion at the moment is that there seem to be two different locations for Intel BLAS/LAPACK libraries, which I think is normal. I'm looking into which set of libraries is the correct one to use.

For completeness, I did try that make.inc file you posted and I got the following:

 F90_OPTS = -O3 -ip -unroll -prefetch -scalar_rep -w90 -fpp CPP_ON_OPT = -cpp -DXS -DISO -DTETRA F77=$(F90) F77_OPTS = -O3 -ip -unroll -prefetch -scalar_rep -w90 -fpp LIB_ARP =libarpack.a #export USE_SYS_LAPACK=true LIB_LPK_SMB = -L/usr/local/intel/mkl/10.0.3.020/lib/em64t -lmkl -lmkl_em64t -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lguide -lpthread -lmkl_lapack LIB_LPK = liblapack.a libblas.a LIB_FFT = fftlib.a LIB_BZINT=libbzint.a LIBS= $(LIB_ARP) $(LIB_LPK) $(LIB_FFT) $(LIB_BZINT) F90_DEBUGOPTS=-g -O0 -warn all -check all -traceback -ftrapuv F77_DEBUGOPTS=-g -O0 -warn all -check all -traceback -ftrapuv #Ignore if you don't have MPI or smplibs MPIF90=mpif90 MPIF90_OPTS=$(F90_OPTS) -DMPI -DMPIRHO -DMPISEC F77MT=$(F77) F90MT=$(F90) SMP_LIBS= $(LIB_ARP) $(LIB_LPK_SMB) $(LIB_FFT) $(LIB_BZINT) SMPF90_OPTS=$(F90_OPTS) SMPF77_OPTS=$(SMPF90_OPTS) MPISMPF90_OPTS=$(SMPF90_OPTS) -DMPI -DMPIRHO -DMPISECBUILDMPI=false BUILDSMP=false #test BUILDMPI=true BUILDSMP=true 

I also checked in the build/smp directory and do have the libarpack.a and libbzint.a libraries:

 $ ls build/smp *.a fftlib.a leblaiklib.a libarpack.a libblas.a libbzint.a liblapack.a libmsec.a 

Regards,
James

Try this for Make.inc and see if it at least compiles.

 F90_OPTS = -O3 -ip -unroll -prefetch -scalar_rep -w90 -fpp CPP_ON_OPT = -cpp -DXS -DISO -DTETRA F77=$(F90) F77_OPTS = -O3 -ip -unroll -prefetch -scalar_rep -w90 -fpp LIB_ARP =libarpack.a #export USE_SYS_LAPACK=true LIB_LPK_SMB = -L/usr/local/intel/mkl/10.0.3.020/lib/em64t -lmkl -lmkl_em64t -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lguide -lpthread -lmkl_lapack LIB_LPK = liblapack.a libblas.a LIB_FFT = fftlib.a LIB_BZINT=libbzint.a LIBS= $(LIB_ARP) $(LIB_LPK) $(LIB_FFT) $(LIB_BZINT) F90_DEBUGOPTS=-g -O0 -warn all -check all -traceback -ftrapuv F77_DEBUGOPTS=-g -O0 -warn all -check all -traceback -ftrapuv #Ignore if you don't have MPI or smplibs MPIF90=mpif90 MPIF90_OPTS=$(F90_OPTS) -DMPI -DMPIRHO -DMPISEC F77MT=$(F77) F90MT=$(F90) SMP_LIBS= $(LIB_ARP) $(LIB_LPK_SMB) $(LIB_FFT) $(LIB_BZINT) SMPF90_OPTS=$(F90_OPTS) SMPF77_OPTS=$(SMPF90_OPTS) MPISMPF90_OPTS=$(SMPF90_OPTS) -DMPI -DMPIRHO -DMPISECBUILDMPI=false BUILDSMP=false #test BUILDMPI=true BUILDSMP=true 

If you have them already included in the link command, it still could be the order.

I am sorry for your inconvenience you will get special honorable mentioned in the next report if you manage to succeed. :-)

 iterativearpacksequn.o: In function `iterativearpacksecequn_': ../../src/src_iterative_solver/iterativearpacksequn.F90:(.text+0xe3b): undefined reference to `znaupd_' ../../src/src_iterative_solver/iterativearpacksequn.F90:(.text+0x1621): undefined reference to `zneupd_' zfftifc.o: In function `zfftifc_': ../../src/zfftifc.f90:(.text+0x4): undefined reference to `cfftnd_' modtetra.o: In function `modtetra_mp_tetcwifc_1kbc_': ../../src/modtetra.F90:(.text+0x36d): undefined reference to `tetcw_1kbc_' modtetra.o: In function `modtetra_mp_tetcwifc_1k_': ../../src/modtetra.F90:(.text+0x737): undefined reference to `tetcw_1k_' modtetra.o: In function `modtetra_mp_tetcwifc_': ../../src/modtetra.F90:(.text+0xc3e): undefined reference to `tetcw_' modtetra.o: In function `modtetra_mp_tetiwifc_': ../../src/modtetra.F90:(.text+0x1965): undefined reference to `tetiw_' modtetra.o: In function `modtetra_mp_fermitetifc_': ../../src/modtetra.F90:(.text+0x242d): undefined reference to `fermitet_' modtetra.o: In function `modtetra_mp_gentetlink_': ../../src/modtetra.F90:(.text+0x43c0): undefined reference to `kqgen_exciting_' modtetra.o: In function `modtetra_mp_genkpts_tet_': ../../src/modtetra.F90:(.text+0x58f4): undefined reference to `tetrasetifc_' ../../src/modtetra.F90:(.text+0x5900): undefined reference to `tetrasetdbglv_' ../../src/modtetra.F90:(.text+0x590c): undefined reference to `tetrasetpointerhandling_' ../../src/modtetra.F90:(.text+0x5918): undefined reference to `tetrasetresptype_' ../../src/modtetra.F90:(.text+0x5924): undefined reference to `tetrasetkplusq_' ../../src/modtetra.F90:(.text+0x592b): undefined reference to `tetrareportsettings_' ../../src/modtetra.F90:(.text+0x66ac): undefined reference to `kgen_' make[3]: *** [exciting] Error 1 make[3]: Leaving directory `/home/spja/workspace/exciting/build/smp' make[2]: *** [bin] Error 2 make[2]: Leaving directory `/home/spja/workspace/exciting/build/smp' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/spja/workspace/exciting/build/smp' make: *** [smp] Error 2 

My build/make.inc looks like:

 insert the code hereF90=ifort F90_OPTS = -O3 -ip -unroll -prefetch -scalar_rep -w90 -fpp CPP_ON_OPT = -cpp -DXS -DISO -DTETRA F77=$(F90) F77_OPTS = -O3 -ip -unroll -prefetch -scalar_rep -w90 -fpp LIB_ARP =libarpack.a #export USE_SYS_LAPACK=true LIB_LPK = -L/usr/local/intel/mkl/10.0.3.020/lib/em64t -lmkl -lmkl_em64t -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lguide -lpthread -lmkl_lapack #LIB_LPK = liblapack.a libblas.a LIB_FFT = fftlib.a LIB_BZINT=libbzint.a LIBS= $(LIB_ARP) $(LIB_LPK) $(LIB_FFT) $(LIB_BZINT) F90_DEBUGOPTS=-g -O0 -warn all -check all -traceback -ftrapuv F77_DEBUGOPTS=-g -O0 -warn all -check all -traceback -ftrapuv #Ignore if you don't have MPI or smplibs MPIF90=mpif90 MPIF90_OPTS=$(F90_OPTS) -DMPI -DMPIRHO -DMPISEC F77MT=$(F77) F90MT=$(F90) SMP_LIBS= -L/usr/local/intel/mkl/10.0.3.020/lib/em64t -lmkl -lmkl_em64t -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lguide -lpthread -lmkl_lapack -lmkl_scalapack_lp64 -lmkl_blacs_lp64 SMPF90_OPTS=$(F90_OPTS) SMPF77_OPTS=$(SMPF90_OPTS) MPISMPF90_OPTS=$(SMPF90_OPTS) -DMPI -DMPIRHO -DMPISECBUILDMPI=false BUILDSMP=false #test BUILDMPI=true BUILDSMP=true 

You will see that I have extensively edited the included library lists - this is to point to the Intel MKL libraries available on our computer cluster.

You will also see that I have kind of fired just about every single library at the make file in the hope that it will help. This is obviously completely the wrong approach, but I am also pretty much a total n00b when it comes to making make files and the Intel MKL libraries! What I will also say is that adding a few of them first did help to reduce the number of lines like those above, but cannot "solve" the rest of it.

I am quite keen to get the SMP version built if it will offer improvements in speed, so any help will be gratefully appreciated. =)

Regards,
James

If you heave it working please post the make.inc files with a short description of your system. We currently have no serious intel ifort system available to test the code on. We know that it is probably the mot popular system and really care for making it work.

It has taken me about 2 and a half months to find the time to try and compile Exciting again and I have made some progress on the Intel MKL library front, but there is still an issue that I cannot figure out how to solve.

I believe that I have included the MKL libraries properly into the make.inc file. The serial and MPI binaries compile OK. However, I get the same errors as above when trying to compile the SMP:

normalizep.o: In function ‘normalizep_’:
../../src/src_iterative_solver/normalizep.F90:(.text+0xe0): undefined reference to ‘zhpmv_’
../../src/src_iterative_solver/normalizep.F90:(.text+0x103): undefined reference to ‘zdotc_’
../../src/src_iterative_solver/normalizep.F90:(.text+0x15e): undefined reference to ‘zscal_’

etc so on and so forth. I dozens of these lines. The SMP version of the code doesn't seem to want to compile no matter what I do - whether I have the MKL libraries or the default libraries that come with Exciting.

I have the new version of the smp/template file, and it is that which I am using, but no joy.

Do you have any ideas/suggestions?

I've just been trying to build exciting on my group's Intel computer cluster. I had forgotten which compiler option is needed to stop the bad preprocessor error, but I have no remembered!

You need to add the "-fpp" option in the compiler options in the build/make.inc file. That should help.

I am currently (well, have been tinkering in the last few months) in the process of making a makefile that will compile Exciting on Intel systems using the Intel Fortran compiler and the MKL library. Unfortunately, that has been on the back burner in the last few months, but there are a couple of things I've noticed.

Firstly, I have "mpif90" as the MPI Intel fortran compiler, not mpiifort.

Secondly, I think I managed to correct the "bad preprocessor line" error by adding the -prefetch switch to the F90_OPTS variable.

I've been meaning to have another stab at compiling exciting over the last few weeks; perhaps I'll try that now. If I do manage to get something working I'll be sure to distribute the makefile.

Kind regards,
James Aldous
(University of Warwick)

please find enclosed the error message found when compiling with mpiifort:

make[3]: Entering directory ‘/data/leuven/300/vsc30016/codes/excitinghydrogen/installSTD/exciting/build/mpi’
Makefile.mkmf:2196: warning: overriding commands for target ‘version.inc’
Makefile.mkmf:1694: warning: ignoring old commands for target ‘version.inc’
mpiifort -O3 -ip -unroll -prefetch -scalar_rep -w90 -DMPI -DMPIRHO -DMPISEC -DMPI -DMPIRHO -DMPISEC -Ifinclude -c ../../src/src_advanced/oepvnl.f90
ifort: command line remark #10010: option '-prefetch' is deprecated and will be removed in a future release. See '-help deprecated'
../../src/src_advanced/oepvnl.f90(22): warning #5117: Bad # preprocessor line
#ifdef MPIEXX
-^
../../src/src_advanced/oepvnl.f90(25): warning #5117: Bad # preprocessor line
#endif
-^
../../src/src_advanced/oepvnl.f90(26): warning #5117: Bad # preprocessor line
#ifndef MPIEXX
-^
../../src/src_advanced/oepvnl.f90(29): warning #5117: Bad # preprocessor line
#endif
-^
../../src/src_advanced/oepvnl.f90(35): warning #5117: Bad # preprocessor line
#ifdef MPIEXX
-^
../../src/src_advanced/oepvnl.f90(52): warning #5117: Bad # preprocessor line
#endif
-^
../../src/src_advanced/oepvnl.f90(27): error #8093: A do-variable within a DO body shall not appear in a variable definition context. [IK]
do ik=1, nkpt
-^
../../src/src_advanced/oepvnl.f90(27): error #6511: This DO variable has already been used as an outer DO variable in the same nesting structure. [IK]
do ik=1, nkpt
-^
../../src/src_advanced/oepvnl.f90(23): error #6321: An unterminated block exists.
do ik=firstk(rank), lastk(rank)
^
compilation aborted for ../../src/src_advanced/oepvnl.f90 (code 1)
make[3]: * [oepvnl.o] Error 1
make[3]: Leaving directory ‘/data/leuven/300/vsc30016/codes/excitinghydrogen/installSTD/exciting/build/mpi’
make[2]: * [bin] Error 2
make[2]: Leaving directory ‘/data/leuven/300/vsc30016/codes/excitinghydrogen/installSTD/exciting/build/mpi’
make[1]: * [all] Error 2
make[1]: Leaving directory ‘/data/leuven/300/vsc30016/codes/excitinghydrogen/installSTD/exciting/build/mpi’
make: * [mpi] Error 2

M Perez Jigato
KU Leuven

the compilation with mpiifort fails at OEP

let me give you some details: (no external linear algebra libraries (lapack, blas, arpack) used whatsoever, only local ones,
all contaied within exciting)

- sequential compilation with this compiler is OK!: compilation with ifort 11.1 (exactly the same compiler than above, but this time MPI is off
(smp off as well) works fine and also runs the tests fine -having said that, the right version is 11.0.069, since i tried 11.0.081 as well, and the latter does not work-

- after switching on the MPI option, i had to create a new entry under platforms (in build) and simply
changed "mpif90" by "mpiifort" in order to get the right make.inc containing mpiifort
This set up seems to start fine the compilation with mpiifort, but once it gets into OEP it fails:

i am not sure this is related, but it looks like there is a precompiler directive MPIEXX that should be there (according to the code)
but the set up does not seem to put it there, is this correct?
(i am sending the exact error message in another message)

otherwise, will you please let me know where the problem could be

thanks

M Perez Jigato
KU Leuven

PS probably another detail could be of interest: the main reason i do not use mpif90 is that i have open-MPI in
my computer set up for gfortran, and that takes mpif90. Furthermore, when i try to compile with gfortran and mpif90
from open-MPI, after several code little changes, i get it to start compiling fine, but surprise!, once it gets into OEP,
it fails exactly at the same place and with the same error message than with mpiifort

p.s. Yes this is one of the right places to ask questions. You probably should start a new thread for a new question. Or you can subscribe to the mailinglist http://exciting-code.org/contact.

i've got a different compilation problem, but it is unusual in the sense that it compiles fine on my own linux laptop and also on a intel linux cluster (with quadcores); the problem is when i try to compile on a different intel linux cluster (quadcores), in which case, the compilation of the FoX library fails, with the following error message:

ifort -c -g -I../objs/finclude FoX_sax.f90
FoX_sax.f90(33): internal error: Please visit 'http://www.intel.com/software/products/support' for assistance.
end module FoX_sax
^
[ Aborting due to internal error. ]
compilation aborted for FoX_sax.f90 (code 1)
make[4]: * [FoX_sax.o] Error 1
make[4]: Leaving directory ‘/data/leuven/300/vsc30016/codes/excitinghydrogen/installSTD/exciting/src/FoX/sax’
make[3]: * [sax_lib] Error 2
make[3]: Leaving directory ‘/data/leuven/300/vsc30016/codes/excitinghydrogen/installSTD/exciting/src/FoX’
make[2]: * [lib/libFoX_common.a] Error 2
make[2]: Leaving directory ‘/data/leuven/300/vsc30016/codes/excitinghydrogen/installSTD/exciting/build/serial’
make[1]: * [all] Error 2
make[1]: Leaving directory ‘/data/leuven/300/vsc30016/codes/excitinghydrogen/installSTD/exciting/build/serial’
make: *** [serial] Error 2

the compiler is intel-ifort in all cases, and all options requested upon by "perl setup.pl" are answered with "No", ie, no external LAPACK-BLAS libraries, no MPI, no SMP (eclipse and java are both )

any idea?

thanks

Manuel Perez Jigato

PS i am not sure this is the right channel to send an e-mail…

Has anyone tried to calculate adsorption energies with exciting? I would like to calculate the adsorption energy of a hydrogen atom on a (2x2) Ru(0001) surface consisting of 4 layers using PBE. So, I need to do three calculations: Eads=E(HRu)-E(H)-E(Ru). Since I am only interested in an energy difference, I should get a lot of error cancellation, so I think something like 6x6x1 k-points should do. Can exciting do this (16 Ru atoms plus one H atom)?

I would like to use the adsorption energy as the *correct* value without any pseudopotential errors or basis set errors and compare this number with what I get from other DFT codes. Is this realistic?

Jens Jørgen

I'll also try that version of the template a little later and get back to you.

Cheers,
James