You are absolutely right, there should be some more error reporting done. Semantic errors such as unknown elements or attributes are handled but the syntax is not handled very well.
For minimizing frustration, some kind of xml editor is very, very helpful. I can recommend eclipse (how-to-setup-eclipse-as-xml-editor) or if you are prepared to spend money: oXigen.

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.

Thank you. Just slid that in and it seems to be working.

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).

Hi, this is not valid xml. The error is that you did not close the first species element

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

Sorry if this messages seems a little "ranty", but I feel like I'm bashing my head against a wall.

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>

This is very interesting. You are right it is peculiar. Might well be a Bug. I need to research this one.

Hello,

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

Hello,

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'm afraid you didn't paste the error message :-)

Dear colleagues,

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

Hello 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

Hello,

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

Hello,

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

Dear colleagues,

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

Thank you in advance,

Thomas Chanier

Update: the serial veri=sion seems to work, but when I run the Ag example case, it ends with the following:
Remaining memory: 52592 bytes at 00849e18 allocated at line 401 of ../../src/init0.f90
Remaining memory: 0 bytes at 00700f18 allocated at line 57 of fox_m_fsys_array_str.F90
Remaining memory: 9 bytes at 00700578 allocated at line 57 of fox_m_fsys_array_str.F90
Remaining memory: 232 bytes at 00700478 allocated at line 776 of m_dom_dom.F90
Remaining memory: 5 bytes at 007003c8 allocated at line 57 of fox_m_fsys_array_str.F90
Remaining memory: 4 bytes at 00700388 allocated at line 10 of ../../src/src_inputparser/initatomcounter.F90
Remaining memory: 331776 bytes at 00640018 allocated at line 52 of ../../src/gengvec.f90
Remaining memory: 165888 bytes at 00616018 allocated at line 45 of ../../src/gengvec.f90
Remaining memory: 220800 bytes at 00692018 allocated at line 191 of ../../src/init1.f90
Remaining memory: 221184 bytes at 006c9018 allocated at line 48 of ../../src/gencfun.f90
Remaining memory: 4 bytes at 00700458 allocated at line 751 of m_dom_dom.F90
Remaining memory: 4 bytes at 007003e8 allocated at line 4830 of m_dom_dom.F90
Remaining memory: 48 bytes at 00700408 allocated at line 124 of ../../src/setdefault.f90
Remaining memory: 12 bytes at 00700688 allocated at line 252 of ../../src/setdefault.f90
Remaining memory: 24 bytes at 00700658 allocated at line 174 of ../../src/setdefault.f90
Remaining memory: 232 bytes at 00700948 allocated at line 776 of m_dom_dom.F90
Remaining memory: 260 bytes at 00700828 allocated at line 7314 of m_dom_dom.F90
Remaining memory: 232 bytes at 00700728 allocated at line 776 of m_dom_dom.F90
Remaining memory: 260 bytes at 00700a48 allocated at line 7314 of m_dom_dom.F90
Remaining memory: 8 bytes at 00734518 allocated at line 397 of ../../src/src_inputparser/speciesmodules.f90
Remaining memory: 0 bytes at 0070bad8 allocated at line 143 of m_common_entities.F90
Remaining memory: 192 bytes at 007065f8 allocated at line 20 of ../../src/src_sym/setupsym.F90
Remaining memory: 120 bytes at 007062a8 allocated at line 334 of ../../src/init0.f90
Remaining memory: 4 bytes at 00701498 allocated at line 18 of ../../src/readspeciesxml.f90
Remaining memory: 0 bytes at 00701268 allocated at line 57 of fox_m_fsys_array_str.F90
… More segments remain

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

I tried to do make clean and then make. I still have the error message:

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

The module format is not standardized, when you change the compiler you must make sure that all .mod files get recompiled.

"make clean"

should do the trick.

Dear colleagues,

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

This is a compiler bug. Workaround is using g95 which is also available on mac. see http://exciting-code.org/supported-platforms

Dear colleagues,

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

Thank you!

I will simply use the current installation then.

K Jorissen