[Paraview] Paraview 4.4 Openfoam native reader decomposed read issue

[Leonard Cassady]

Takuya,

    Thank you for your response.   I now see how pvserver (when run in
parallel) opens up the decomposed data files.

To the group,

    I have sent out another email detailing the bug in native paraview
openfoam reader.

    My case is about 20 million cells and the reconstructed file sizes are
150 MB for scalar data and 500 MB for vector data.

    I still have questions about data processing.   Are filters processed
on the client or server?  Are complicated filters (such as stream lines
that cross boundaries of the parallel (decomposed) solution) faster when
pvserver is run in parallel?

    I have re-compiled paraview 4.4.0 to be mpi-enabled.  I have selected
the "enable Auto MPI" with 24 processes (same number as my cores).  If I
open a serial (reconstructed) solution, paraview takes much longer (>10x)
to open a case.  Paraview is slightly slower when opening a decomposed case
with the 24 processes.  What should I know to improve the performance of
paraview?

Thanks,

Lenny




On Fri, Dec 25, 2015 at 11:45 AM, Takuya OSHIMA <oshima at eng.niigata-u.ac.jp>
wrote:

> Hi Leonard,
>
> I am not using OpenFOAM recently so this is what I can only answer:
>
> > Is pvserver (when
> > run in parallel) smart enough to not open every data file on every
> process for
> > the native openfoam reader, but to smartly allocate the directories to
> > different instances?
>
> Yes. For the allocation strategy, see slide 7 of [1]. And if you
> choose "Reconstructed Case" and if the reader still works as intended,
> the whole recousructed case should be loaded only by process 0.
>
> [1]
> http://www.opencae.jp/data/OpenSourceCAEWorkshop/200811/slides/OpenSourceCAEWorkshop200811Ohshima2.pdf
>
> Takuya OSHIMA, Ph.D.
> Faculty of Engineering, Niigata University
> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
>
> From: Leonard Cassady <lenny at intuitivemachines.com>
> Subject: [Paraview] Paraview 4.4 Openfoam native reader decomposed read
> issue
> Date: Wed, 23 Dec 2015 16:33:50 -0600
>
> > Hi,
> >
> >   I've recently upgraded to Openfoam 3.0 and installed paraview 4.4.  To
> speed
> > up reading, I'm using pvserver in parallel (with mpirun) and open the
> openfoam
> > solution with the native openfoam reader as a "decomposed case".
> >   I was able to visualize scalar data as expected.  I was not able to
> render
> > the vector velocity data "U".   It just doesn't show up as an option for
> > coloring surfaces or to apply filters to.  Is this a bug in paraview, or
> am I
> > doing something wrong?
> >
> >   Above is my main question.  Below are general questions regarding
> paraview
> > performance.
> >
> >   As you may know, Openfoam creates directories for each processor (say
> 192)
> > when solving the case in parallel. It requires the user to run the same
> number
> > of parallel processes (mpirun -np 192 <openfoamsolver> -parallel)  as
> there
> > are processor directories.  Does pvserver require the user to also run
> the
> > same number of processes as there are processor directories? Is pvserver
> (when
> > run in parallel) smart enough to not open every data file on every
> process for
> > the native openfoam reader, but to smartly allocate the directories to
> > different instances?  (I know that if I open a "reconstructed case" with
> > pvserver running in parallel each instance of pvserver opens the same
> file and
> > greatly slows the system and overloads ram.)
> >
> >    I believe that my computer has good enough graphics processors to
> handle
> > rendering.  Once I load in a data set I can re-orient and re-color and
> slice
> > very fast.  I also believe that I can open and read the data files
> quickly (
> > about 230 MB/s read rate for my large files).  I believe that the
> slowest part
> > of my data processing is the step between reading and rendering.  It also
> > takes a long time to apply complicated filters like stream lines.  How
> can I
> > speed up this part of my visualization?  I have multiple computers and
> one of
> > them is much faster at analysis and I can't figure out why.
> >
> >
> > --
> > Leonard Cassady PhD
> > Senior Development Engineer
> > Intuitive Machines
> > Cell: 281-755-2553
> >
>



-- 
Leonard Cassady PhD
Senior Development Engineer
Intuitive Machines
Cell: 281-755-2553
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20151228/ca0bb793/attachment.html>