Thanks for all valuable suggestions.
First, I'm using MVAPICH 1.0.1
and searched error related with reading input.
With my friend's help, I just realized that somehow, standard input is
not working. So, we instead named my input fdf to INPUT_DEBUG, which
is the default input file. Since this INPUT_DEBUG is default, the code
itself found this input and job ran successfully.
Without directing input.fdf through standard input and using default
name for input, my problem is at leat resolved temporarily.
Quoting Marcos Veríssimo Alves <[email protected]>:
Guys,
I'm sorry I cannot provide a solution to the problem, but I can tell you it
has absolutely nothing to do with cell size, energy shift and cutoff.
The information provided is insufficient to say anything about the probable
origin of the error. Since your problem involves "node 0" and "lack of time
to converge well" I would guess you are running parallel siesta on a cluster
with a queuing system. The I'd say it is most likely a matter of
compilation, be it mpi, be it siesta. Supposing you are trying to run it in
parallel:
1) Are you using mpich, mpich2, openmpi, mvapich (in case your cluster has
infiniband interconnection), mpich-gm (for myrinet interconnection)...?
2) What are the fortran and C compilers used for building
mpich/mpich2/openmpi/mvapich/mpich-gm, siesta and the scalapack and blas?
Are they the exactly the same in **all** cases?
3) What are the compiler options used in the compilations?
One simple test you can do to see if it's a compilation problem is to start
the calculation, using the exact same fdf file you have sent us, using
siesta compiled **serially**, not in parallel. Do it on your desktop
computer (if it's Linux), then in your cluster submitting your job to the
queue. If it doesn't yield any errors, then the problem is somewhere in
compilation of the parallel executable.
One thing that helps is to set up an interactive parallel session and trying
to run it "manually", then looking at the errors that come by, besides those
in the siesta output file (usually ugly, scary and unintelligible stuff).
Usually they are all redirected to an error file when you run them on a
cluster, but you never know.
Welcome to the wonderful world of parallel calculations! :)
Cheers,
Marcos
On Thu, Dec 10, 2009 at 3:01 PM, <[email protected]> wrote:
Hi
If your error is >> No species found!!! i think you need to check the size
of your unit cell, make it larger,
and also make sure that the energy shift parameter in your input file is
tuned well, for your system use it around 300 Ry,
yours,
sufian
>
>
>
> On Wed, 9 Dec 2009, [email protected] wrote:
>
>>
>> Dear All siesta users!
>>
>> I have some random(?) errors.
>> With the same input fdf file, it ran successfully, but due to lack of
>> time,
>> it didn't converge well.
>> So, I just start over using the same fdf file with increased time. ( I
>> didn't
>> restart from the previous run). But, this time, unexpected error occurs.
>> <error>
>> No species found!!!
>> ERROR STOP from Node: 0
>>
>> I checked the fdf.log and realized my input was not written, instead all
>> default values with Number_of_species = 0 were written in fdf.log (It
>> makes
>> the error)
>>
>> When I used the same fdf, my input fdf was read correctly and ran well.
>> But, when I tried later, my input couldn't be read.
>>
>> I attached my fdf file and fdf.log file.
>>
>> In advance, I appreciate any help.
>>
>> Kyoung Kweon
>
