This file is indexed.

/usr/share/doc/quantum-espresso/html/node19.html is in quantum-espresso-data 5.0.2-5build1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  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
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<!--Converted with LaTeX2HTML 2008 (1.71)
original version by:  Nikos Drakos, CBLU, University of Leeds
* revised and updated by:  Marcus Hennecke, Ross Moore, Herb Swan
* with significant contributions from:
  Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
<HTML>
<HEAD>
<TITLE>3.4 Tricks and problems</TITLE>
<META NAME="description" CONTENT="3.4 Tricks and problems">
<META NAME="keywords" CONTENT="user_guide">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">

<META NAME="Generator" CONTENT="LaTeX2HTML v2008">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">

<LINK REL="STYLESHEET" HREF="user_guide.css">

<LINK REL="previous" HREF="node18.html">
<LINK REL="up" HREF="node15.html">
<LINK REL="next" HREF="node20.html">
</HEAD>

<BODY >
<!--Navigation Panel-->
<A NAME="tex2html386"
  HREF="node20.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A> 
<A NAME="tex2html382"
  HREF="node15.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A> 
<A NAME="tex2html378"
  HREF="node18.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A> 
<A NAME="tex2html384"
  HREF="node1.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A>  
<BR>
<B> Next:</B> <A NAME="tex2html387"
  HREF="node20.html">About this document ...</A>
<B> Up:</B> <A NAME="tex2html383"
  HREF="node15.html">3 Parallelism</A>
<B> Previous:</B> <A NAME="tex2html379"
  HREF="node18.html">3.3 Parallelization levels</A>
 &nbsp; <B>  <A NAME="tex2html385"
  HREF="node1.html">Contents</A></B> 
<BR>
<BR>
<!--End of Navigation Panel-->
<!--Table of Child-Links-->
<A NAME="CHILD_LINKS"><STRONG>Subsections</STRONG></A>

<UL>
<LI><UL>
<LI><A NAME="tex2html388"
  HREF="node19.html#SECTION00044010000000000000">3.4.0.1 Trouble with input files</A>
<LI><A NAME="tex2html389"
  HREF="node19.html#SECTION00044020000000000000">3.4.0.2 Trouble with MKL and MPI parallelization</A>
<LI><A NAME="tex2html390"
  HREF="node19.html#SECTION00044030000000000000">3.4.0.3 Trouble with compilers and MPI libraries</A>
</UL></UL>
<!--End of Table of Child-Links-->
<HR>

<H2><A NAME="SECTION00044000000000000000">
3.4 Tricks and problems</A>
</H2>

<P>

<H4><A NAME="SECTION00044010000000000000">
3.4.0.1 Trouble with input files</A>
</H4>
Some implementations of the MPI library have problems with input 
redirection in parallel. This typically shows up under the form of
mysterious errors when reading data. If this happens, use the option 
<TT>-in</TT> (or <TT>-inp</TT> or <TT>-input</TT>), followed by the input file name. 
Example:
<PRE>
   pw.x -in inputfile -npool 4 &gt; outputfile
</PRE> 
Of course the 
input file must be accessible by the processor that must read it
(only one processor reads the input file and subsequently broadcasts
its contents to all other processors).

<P>
Apparently the LSF implementation of MPI libraries manages to ignore or to
confuse even the <TT>-in/inp/input</TT> mechanism that is present in all
Q<SMALL>UANTUM </SMALL>ESPRESSO codes. In this case, use the <TT>-i</TT> option of <TT>mpirun.lsf</TT>
to provide an input file.

<P>

<H4><A NAME="SECTION00044020000000000000">
3.4.0.2 Trouble with MKL and MPI parallelization</A>
</H4>
If you notice very bad parallel performances with MPI and MKL libraries, 
it is very likely that the OpenMP parallelization performed by the latter 
is colliding with MPI. Recent versions of MKL enable autoparallelization
by default on multicore machines.  You must set the environmental variable
OMP_NUM_THREADS to 1 to disable it. 
Note that if for some reason the correct setting  of variable
OMP_NUM_THREADS  
does not propagate to all processors, you may equally run into trouble. 
Lorenzo Paulatto (Nov. 2008) suggests to use the <TT>-x</TT> option to <TT>mpirun</TT> to 
propagate OMP_NUM_THREADS to all processors.
Axel Kohlmeyer suggests the following (April 2008): 
"(I've) found that Intel is now turning on multithreading without any
warning and that is for example why their FFT seems faster than
FFTW. For serial and OpenMP based runs this makes no difference (in
fact the multi-threaded FFT helps), but if you run MPI locally, you
actually lose performance. Also if you use the 'numactl' tool on linux
to bind a job to a specific cpu core, MKL will still try to use all
available cores (and slow down badly). The cleanest way of avoiding
this mess is to either link with
<BLOCKQUOTE>
<TT>-lmkl_intel_lp64 -lmkl_sequential -lmkl_core</TT> (on 64-bit: 
x86_64, ia64)
<BR><TT>-lmkl_intel -lmkl_sequential -lmkl_core</TT> (on 32-bit, i.e. ia32 )

</BLOCKQUOTE>
or edit the <TT>libmkl_'platform'.a</TT> file. I'm using now a file 
<TT>libmkl10.a</TT> with:
<PRE>
  GROUP (libmkl_intel_lp64.a libmkl_sequential.a libmkl_core.a)
</PRE>
It works like a charm". UPDATE: Since v.4.2, <TT>configure</TT> links by
default MKL without multithreaded support.

<P>

<H4><A NAME="SECTION00044030000000000000">
3.4.0.3 Trouble with compilers and MPI libraries</A>
</H4>
Many users of Q<SMALL>UANTUM </SMALL>ESPRESSO, in particular those working on PC clusters,
have to rely on themselves (or on less-than-adequate system managers) for 
the correct configuration of software for parallel execution. Mysterious and
irreproducible crashes in parallel execution are sometimes due to bugs
in Q<SMALL>UANTUM </SMALL>ESPRESSO, but more often than not are a consequence of buggy
compilers or of buggy or miscompiled MPI libraries.

<P>
<HR>
<!--Navigation Panel-->
<A NAME="tex2html386"
  HREF="node20.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A> 
<A NAME="tex2html382"
  HREF="node15.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A> 
<A NAME="tex2html378"
  HREF="node18.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A> 
<A NAME="tex2html384"
  HREF="node1.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A>  
<BR>
<B> Next:</B> <A NAME="tex2html387"
  HREF="node20.html">About this document ...</A>
<B> Up:</B> <A NAME="tex2html383"
  HREF="node15.html">3 Parallelism</A>
<B> Previous:</B> <A NAME="tex2html379"
  HREF="node18.html">3.3 Parallelization levels</A>
 &nbsp; <B>  <A NAME="tex2html385"
  HREF="node1.html">Contents</A></B> 
<!--End of Navigation Panel-->
<ADDRESS>
root
2013-12-16
</ADDRESS>
</BODY>
</HTML>