On Wed, 2013-05-08 at 17:48 +0200, Henning Glawe wrote:
> > Anyway: is your problem solved? if not, please specify
> > what you need data file for.
>
> Basically just for running some code patched into pp.x.
if you can run the postprocessing code on the same number
of processors that were used
On Wed, May 08, 2013 at 04:54:20PM +0200, Paolo Giannozzi wrote:
> inside QE there is actually a sort of "wrapper" (PW/src/buffers.f90)
> that can read/write to file or to RAM depending upon the value of a
> variable. It used to work for a single unit, but now it has been
> extended to an
On Wed, May 08, 2013 at 05:00:27PM +0200, Paolo Giannozzi wrote:
> On Wed, 2013-05-08 at 15:09 +0200, Henning Glawe wrote:
> > As far as I understand the code, all IO to outdir is performed via IOTK;
>
> actually only "small" xml files and files in "collected" format are
> written using iotk (the
On Wed, 2013-05-08 at 15:09 +0200, Henning Glawe wrote:
> As far as I understand the code, all IO to outdir is performed via IOTK;
actually only "small" xml files and files in "collected" format are
written using iotk (the latter, in binary format). Large temporary
scratch files are written
On Wed, 2013-05-08 at 09:48 +0200, Axel Kohlmeyer wrote:
> if there are some people here on the list that would be interested in
> having such a wrapper and would be volunteering some time testing and
> providing feedback, i might be tempted to give it a try and write such
> a wrapper.
inside QE
On Wed, May 08, 2013 at 09:48:39AM +0200, Axel Kohlmeyer wrote:
> have you tried using a ramdisk? if your machine is linux based, then
> you can usually access up to half of the physical memory via /dev/shm.
Yes, I tried this and it seems to work, in conjunction with tar to
transfer data to the
On Wed, May 08, 2013 at 11:39:54AM +0200, Paolo Giannozzi wrote:
> On Tue, 2013-05-07 at 22:32 +0200, Henning Glawe wrote:
>
> > Is this compatible to all postprocessing codes, such as dos.x
> > and pp.x and the phonon code ph.x?
>
> I think it should. It is presently incompatible with option
>
On Tue, 2013-05-07 at 22:32 +0200, Henning Glawe wrote:
> Is this compatible to all postprocessing codes, such as dos.x
> and pp.x and the phonon code ph.x?
I think it should. It is presently incompatible with option
"wf_collect".
P.
--
Paolo Giannozzi, Dept. Chemistry,
Univ. Udine, via
On Tue, May 7, 2013 at 8:57 PM, Henning Glawe wrote:
> Moin,
> we have recently discovered performance problems on our parallel scratch file
> system (fhgfs) in a 400-node-cluster.
> Much of the blame went to my quantum espresso jobs (custom-patched 4.3.2). I
> am performing calculations on
On Tue, May 07, 2013 at 09:29:42PM +0200, Paolo Giannozzi wrote:
> On Tue, 2013-05-07 at 20:57 +0200, Henning Glawe wrote:
>
> > QE/iotk creates one directory per k-point, with only one small file
> > (eigenval.xml) contained in it.
>
> have you tried option "lkpoint_dir"?
Not yet, thanks for
On Tue, 2013-05-07 at 20:57 +0200, Henning Glawe wrote:
> QE/iotk creates one directory per k-point, with only one small file
> (eigenval.xml) contained in it.
have you tried option "lkpoint_dir"?
> Are there any plans to move away from the 'many-small-files' paradigm?
plans for a better I/O
Moin,
we have recently discovered performance problems on our parallel scratch file
system (fhgfs) in a 400-node-cluster.
Much of the blame went to my quantum espresso jobs (custom-patched 4.3.2). I
am performing calculations on thousands of small crystals, most having no
symmetry, leading to a
12 matches
Mail list logo
