[Pw_forum] XSpectra can not run

2011-04-07 Thread Yu Zhang
hi, all,
  I'm a newcomer to the QE world. I want to do some XAS calculations 
with XSpectra. So I followed the steps in the file run_example_diamond, 
got the pseudopotential, finished the scf calculation, generated the 
core state (C.wfc put in the working directory). Well, when I tried to 
run xspectra.x with the example input file, e. g., 
diamond.xspectra_fermi.in, I found xspectra.x does not exist (why hasn't 
it been compiled with all the other QE modules?). So I came to the 
XSpetra directory and ran make, it came up with some error message that 
some .o files under ../GIPAW were required. I hd to go to ../GIPAW and 
ran make. This time it seemed working. Then I went back to XSpectra/ and 
ran make. It came up with some warning like


xspectra.f90(431): remark #8290: Recommended relationship between field 
width 'W' and the number of fractional digits 'D' in this edit 
descriptor is 'W>=D+3'.
  WRITE (stdout,'(a,1x,3(f10.8, 1x))') 'xepsilon(:)=', 
(xepsilon(i),i=1,3)
-^
###

but still generated the xspectra.x executable. The problem came when I 
ran xspectra.xdiamond.xspectra_fermi.out, 
with the following error:

###
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource
xspectra.x 00674016  fft_types_mp_fft_ 568  
fft_types.f90
xspectra.x 00646F8E  stick_set_mp_psti 224  
stick_set.f90
xspectra.x 0046B8AA  data_structure_62  
data_structure.f90
xspectra.x 004569D7  allocate_fft_  38  
allocate_fft.f90
xspectra.x 00431A55  read_file_xspectr 231  
read_file_xspectra.f90
xspectra.x 00405C13  MAIN__371  
xspectra.f90
xspectra.x 004050FC  Unknown   Unknown  Unknown
libc.so.6  7F71CF6F4D8E  Unknown   Unknown  Unknown
xspectra.x 00404FF9  Unknown   Unknown  Unknown
##

 My input file is:
&input_xspectra
 calculation='fermi_level',
 prefix='diamond',
 outdir='./',
 xread_wf=.true.,
  /
&plot
  /
&pseudos
 filecore='./C.wfc',
  /
&cut_occ
  /
4 4 4 0 0 0


 What's wrong with my compilation? I'm using ifort V.12 with MKL and 
under a Linux64 system. The compilation of pw.x and many other 
executables are ok.  Sorry for this long post. Any help will be greatly 
appreciated!
best regards
Yu Zhang


[Pw_forum] XSpectra can not run

2011-04-07 Thread Paolo Giannozzi

On Apr 7, 2011, at 18:56 , Yu Zhang wrote:

> (why hasn't it been compiled with all the other QE modules?)

$ make
to install, type at the shell prompt:
   ./configure
   make target
where target is one of the following:
   pw   basic code for scf, structure optimization, MD
   cp   CP code: CP MD with ultrasoft pseudopotentials
   ph   phonon code
   neb  code for Nudged Elastic Band method
   tddfpt   time dependent dft code
   pp   postprocessing programs
   gammaGamma-only version of phonon code
   pwcond   ballistic conductance
   d3   third-order derivatives
   vdw  vdW calculation
   gipawmagnetic response (NMR, EPR, ...)
   w90  Maximally localised Wannier Functions
   want Quantum Transport with Wannier functions
   plumed   Patch for calculating free-energy paths with pw or cp
   gww  GW with Wannier Functions
   yamboelectronic excitations with plane waves
   toolsmisc tools for data analysis
   ld1  utilities for pseudopotential generation
   upf  utilities for pseudopotential conversion
   xspectra X-ray core-hole spectroscopy calculations
   pwallsame as "make pw ph pp gamma pwcond d3 tools"
   all  same as "make pwall cp ld1 upf tddfpt"
  

As you can see, some specialized code are not compiled
by "make all"

> So I came to the  XSpetra directory and ran make

"make xspectra" should be run from the root QE directory

> xspectra.f90(431): remark #8290: Recommended relationship between  
> field
> width 'W' and the number of fractional digits 'D' in this edit  
> descriptor is 'W>=D+3'.

this is completely irrelevant

> forrtl: severe (174): SIGSEGV, segmentation fault occurred

does it work for the provided example?

> I'm using ifort V.12 with MKL and under a Linux64 system.

v.12.0.2 should work; v.12.0.0 doesn't

P.
---
Paolo Giannozzi, Dept of Chemistry&Physics&Environment,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222






[Pw_forum] XSpectra can not run

2011-04-07 Thread Yu Zhang
hi, Paolo,
Thank you very much for your help. I deleted *.o and *.x under /GIPAW 
and /Xspectra and then ran make gipaw and make xspectra in the QE root 
directory, as you suggested. No error found in compilation. Well, when I 
ran
xspectra.xdiamond.xspectra_fermi.out again,
I saw the same error as before. diamond.xspectra_fermi.in is from the 
example file. What should I do next? My intel fortran is V 12.0.3. Many 
thanks again!
best regards
Yu Zhang

On 2011?04?07? 10:53, Paolo Giannozzi wrote:
> On Apr 7, 2011, at 18:56 , Yu Zhang wrote:
>
>> (why hasn't it been compiled with all the other QE modules?)
> $ make
> to install, type at the shell prompt:
> ./configure
> make target
> where target is one of the following:
> pw   basic code for scf, structure optimization, MD
> cp   CP code: CP MD with ultrasoft pseudopotentials
> ph   phonon code
> neb  code for Nudged Elastic Band method
> tddfpt   time dependent dft code
> pp   postprocessing programs
> gammaGamma-only version of phonon code
> pwcond   ballistic conductance
> d3   third-order derivatives
> vdw  vdW calculation
> gipawmagnetic response (NMR, EPR, ...)
> w90  Maximally localised Wannier Functions
> want Quantum Transport with Wannier functions
> plumed   Patch for calculating free-energy paths with pw or cp
> gww  GW with Wannier Functions
> yamboelectronic excitations with plane waves
> toolsmisc tools for data analysis
> ld1  utilities for pseudopotential generation
> upf  utilities for pseudopotential conversion
> xspectra X-ray core-hole spectroscopy calculations
> pwallsame as "make pw ph pp gamma pwcond d3 tools"
> all  same as "make pwall cp ld1 upf tddfpt"
>
>
> As you can see, some specialized code are not compiled
> by "make all"
>
>> So I came to the  XSpetra directory and ran make
> "make xspectra" should be run from the root QE directory
>
>> xspectra.f90(431): remark #8290: Recommended relationship between
>> field
>> width 'W' and the number of fractional digits 'D' in this edit
>> descriptor is 'W>=D+3'.
> this is completely irrelevant
>
>> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> does it work for the provided example?
>
>> I'm using ifort V.12 with MKL and under a Linux64 system.
> v.12.0.2 should work; v.12.0.0 doesn't
>
> P.
> ---
> Paolo Giannozzi, Dept of Chemistry&Physics&Environment,
> Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
> Phone +39-0432-558216, fax +39-0432-558222
>
>
>
>
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>



[Pw_forum] XSpectra can not run

2011-04-07 Thread Paolo Giannozzi

On Apr 7, 2011, at 20:26 , Yu Zhang wrote:

> What should I do next?

answer the following question:

>> does it work for the provided example?

P.
---
Paolo Giannozzi, Dept of Chemistry&Physics&Environment,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222






[Pw_forum] XSpectra can not run

2011-04-07 Thread Yu Zhang
hi, Paolo,
I run run_example_diamond from the XSpectra example directory and the 
program stops at the XAS fermi level calculation step and produces the 
same error. Sorry for not mention this before. Thanks.
Yu Zhang

On 2011?04?07? 12:55, Paolo Giannozzi wrote:
> On Apr 7, 2011, at 20:26 , Yu Zhang wrote:
>
>> What should I do next?
> answer the following question:
>
>>> does it work for the provided example?
> P.
> ---
> Paolo Giannozzi, Dept of Chemistry&Physics&Environment,
> Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
> Phone +39-0432-558216, fax +39-0432-558222
>
>
>
>
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>



[Pw_forum] XSpectra can not run

2011-04-08 Thread Paolo Giannozzi
On Thu, 2011-04-07 at 14:25 -0700, Yu Zhang wrote:

> I run run_example_diamond from the XSpectra example directory and the 
> program stops at the XAS fermi level calculation step and produces the 
> same error. Sorry for not mention this before.

replace read-file_xspectra.f90 with the attached version

P.
-- 
Paolo Giannozzi, IOM-Democritos and University of Udine, Italy

-- next part --
A non-text attachment was scrubbed...
Name: read_file_xspectra.f90
Type: text/x-fortran
Size: 12641 bytes
Desc: not available
Url : 
http://www.democritos.it/pipermail/pw_forum/attachments/20110408/8bd504f0/attachment.bin
 


[Pw_forum] XSpectra can not run

2011-04-08 Thread Yu Zhang
hi, Paolo,
 This really solves my problem! Thank you very much. Could you 
please explain briefly what the cause  of the problem is?
best regards
Yu Zhang

On 2011?04?08? 02:36, Paolo Giannozzi wrote:
> On Thu, 2011-04-07 at 14:25 -0700, Yu Zhang wrote:
>
>> I run run_example_diamond from the XSpectra example directory and the
>> program stops at the XAS fermi level calculation step and produces the
>> same error. Sorry for not mention this before.
> replace read-file_xspectra.f90 with the attached version
>
> P.
>
>
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum

-- next part --
An HTML attachment was scrubbed...
URL: 
http://www.democritos.it/pipermail/pw_forum/attachments/20110408/6ebbb68e/attachment-0001.htm
 


[Pw_forum] XSpectra can not run

2011-04-08 Thread Paolo Giannozzi

On Apr 8, 2011, at 20:49 , Yu Zhang wrote:

> This really solves my problem! Thank you very much.

you should thank Matteo Calandra, not me

> Could you please explain briefly what the cause  of the problem is?

the problem is that some recent changes to the initialization of FFT
grids, G-vectors, and other basic stuff, had not been propagated
to that particular routine. I had forgotten that XSpectra uses a
different routine to read the data file from all other QE codes.
Just an overlook.

Paolo
---
Paolo Giannozzi, Dept of Chemistry&Physics&Environment,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222






[Pw_forum] XSpectra can not run

2011-04-11 Thread Yu Zhang
hi, Paolo,
  Thank Matteo and you very much! Well, I got some similar reading 
error when I tried to do XSpectra calculation with my own input file. 
Could you please see the post
http://www.democritos.it/pipermail/pw_forum/2011-April/020020.html
  for me (I apologize if you've already seen it)? Thank you very much!
best wishes
Yu Zhang

On 04/08/2011 12:18, Paolo Giannozzi wrote:
> On Apr 8, 2011, at 20:49 , Yu Zhang wrote:
>
>> This really solves my problem! Thank you very much.
> you should thank Matteo Calandra, not me
>
>> Could you please explain briefly what the cause  of the problem is?
> the problem is that some recent changes to the initialization of FFT
> grids, G-vectors, and other basic stuff, had not been propagated
> to that particular routine. I had forgotten that XSpectra uses a
> different routine to read the data file from all other QE codes.
> Just an overlook.
>
> Paolo
> ---
> Paolo Giannozzi, Dept of Chemistry&Physics&Environment,
> Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
> Phone +39-0432-558216, fax +39-0432-558222
>
>
>
>
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>



[Pw_forum] XSpectra can not run

2011-04-12 Thread Matteo Calandra
> hi, Paolo,
>   Thank Matteo and you very much! Well, I got some similar reading 
> error when I tried to do XSpectra calculation with my own input file. 
> Could you please see the post
> http://www.democritos.it/pipermail/pw_forum/2011-April/020020.html
>   for me (I apologize if you've already seen it)? Thank you very much!
> best wishes
> Yu Zhang
>

Dear Yu Zhang,

  I think the problem is that some of your pseudopotentials do not
have gipaw reconstruction inside.

In principle this is needed only for the absorbing atom, but for
the moment the code requires that all the pseudo do have gipaw
reconstruction.

I have to modify this as soon as I have some time.

Th second problem is that xspectra does not work with the
Gamma only version of the code. So you should run both the
scf and xspectra not with

K_POINTS gamma

but with

K_POINTS automatic
1 1 1 0 0 0

It should then work.

M.


> On 04/08/2011 12:18, Paolo Giannozzi wrote:
>> On Apr 8, 2011, at 20:49 , Yu Zhang wrote:
>>
>>> This really solves my problem! Thank you very much.
>> you should thank Matteo Calandra, not me
>>
>>> Could you please explain briefly what the cause  of the problem is?
>> the problem is that some recent changes to the initialization of FFT
>> grids, G-vectors, and other basic stuff, had not been propagated
>> to that particular routine. I had forgotten that XSpectra uses a
>> different routine to read the data file from all other QE codes.
>> Just an overlook.
>>
>> Paolo
>> ---
>> Paolo Giannozzi, Dept of Chemistry&Physics&Environment,
>> Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
>> Phone +39-0432-558216, fax +39-0432-558222
>>
>>
>>
>>
>> ___
>> Pw_forum mailing list
>> Pw_forum at pwscf.org
>> http://www.democritos.it/mailman/listinfo/pw_forum
>>
> 
> 
> 
> --
> 
> Message: 2
> Date: Mon, 11 Apr 2011 17:15:33 -0500
> From: "Nichols A. Romero" 
> Subject: Re: [Pw_forum] I/O performance on BG/P systems
> To: PWSCF Forum 
> Cc: Gabriele Sclauzero 
> Message-ID: 
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Gabriele,
> 
> A couple of other technical details that I am remembering:
> 1. The BG/P at ANL has 1 I/O node per 64 nodes, 8 I/O nodes per mid-plane
> 2. The bottleneck of writing multiple files per MPI tasks does not
> become serious
> until about 8+ racks.
> 
> On Mon, Apr 11, 2011 at 3:50 PM, Gabriele Sclauzero  
> wrote:
>> Dear Paolo and Nichols,
>> ?? ?as a follow up, I had a brief meeting with the sysadmin of our local
>> BGP. It looks like the timings I was reporting actually correspond to the
>> maximum I/O throughput of that specific rack, which depends on the number of
>> I/O nodes present on the rack itself (in that case, 4 I/O nodes per
>> midplane, each of them capable of 350 MB/s, corresponding to 1.7 GB/s for
>> that midplane).
>> In the example I was reporting:
>> ?? ? davcio ??: ??1083.30s?CPU ??1083.30s WALL ( ?38 calls)
>> I've been running on just 128 nodes (512 cores in VN mode), therefore I had
>> only one I/O node (1 midplane = 4 x 128 nodes, for the non-BG/P-ers). Now,
>> the total size of the .wfc files was around 9200 MB, which cannot be written
>> in less than 9200/350 = 26.3 sec, according to the figures that the
>> sysadmins gave me.
>> In my case the timings give:?1083.30s/38=28.5s, which is close to the
>> theoretical maximum.
>> I will perform more testing and I will take into consideration the
>> suggestion of Nichols about the number of files per node. In our machine we
>> have one rack with 16 I/O nodes per midplane, I will try to see if the I/O
>> performance scales accordingly.
>> As a side effect, I met a problem in the timing procedure. I found very
>> different davcio timings (i.e. 3 orders of magnitude!) for two jobs where
>> the size of the wavefunctions differed by a factor 2 only (the jobs?have
>> been executed on the same rack and with the same number of processors and
>> same parallelization scheme).
>> The sysadmins replied that I/O bandwidth measured in the?fastest case is not
>> attainable on BG/P, and should be imputed to an inaccurate measurement of
>> cputime/walltime.
>> I'm going to investigate this anyway.
>> I'm not aware of anyone working on MPI I/O porting.
>> Thanks so far for your suggestions,
>>
>>
>> Gabriele
>>
>>
>> Il giorno 11/apr/2011, alle ore 20.02, Nichols A. Romero ha scritto:
>>
>> Sorry for not replying earlier, but I missed this e-mail due to the
>> APS March Meeting.
>>
>> The GPFS file system on BG/P does a poor job at handling writes to more than
>> one file per node. My guess is that Gabriele was running QE in either dual
>> or VN mode (2 and 4 MPI tasks per node, respectively). So on BG/P,
>> you basically
>> want to write one file per node (which GPFS is designed to handle) or
>> one big file
>> using MPI-I/O.
>>
>> At ANL, we are thinking about re-writing some of the I/O
>> using parallel I/O (e.g. HDF5, Parallel NetCDF). The simple