[Paraview] PV 3.12.0 coprocessing problem
Andy Bauer
andy.bauer at kitware.com
Tue Jan 10 10:56:01 EST 2012
Hi John,
Glad you got the bug fixed. As far as I can tell, ParaView has now been
bug-free for 3 years so I knew it must have been with your code :)
I can't say for sure but I would think that you'd want to add in the
vtkGhostLevel array. The trivial producer that's used to inject the data
object into the pipeline probably isn't smart enough to pass that
information along yet though. This is something which I've been wondering
for a while but haven't gotten around to looking into deeper. It will
probably be a bigger issue when we get the live-data working with
coprocessing such that people can interact with the data coming out of
their simulation code through the coprocessing library. Utkarsh is
spending time on that now so someone is going to have to figure out that
answer fairly soon. I'll put it on my list of things to do but if you want
to take charge of it, I won't complain!
As for the scalar bar error dialogue, I'm not getting it on my machine so
I'm not sure how it's coming up much less how to get rid of it. I'd be
more than happy to help you get rid of it though once I get more
information.
Another thing -- have you looked at CMake's FortranCInterface stuff for
automatically mangling the C++ functions to match up with Fortran? It
should make it such that you don't have to do the machine dependent
mangling yourself. An example is at
ParaView/CoProcessing/Adaptors/FortranAdaptors if you haven't checked it
out yet.
Andy
On Tue, Jan 10, 2012 at 6:59 AM, Biddiscombe, John A. <biddisco at cscs.ch>wrote:
> Andy****
>
> ** **
>
> Everything is working ok now. I’m glad that you are far away, because you
> may want to throw something heavy at me.****
>
> ** **
>
> I found that my main problem was that I passed an array of real(4) from
> fortran to use for the grid spacing and cast them to double* in my adaptor,
> this caused some ridiculous numbers to be used for the grid and the python
> script was basically aborting without doing anything – hence the lack of
> png output (and no error messages either). Of course all my print
> statements were in the fortran side to check that the values were correct
> so I didn’t catch it for ages.****
>
> ** **
>
> Anyway. All seems fine now.****
>
> ** **
>
> New Question : ****
>
> I am padding my imagedata pieces with one ghost cell on each side.
> Contouring etc works fine and pieces abut seamlessly, but for general
> safety, should I add a vtkGhostLevel array to my pointdata to ensure that
> other filters I might add later don’t make data in these regions visible?*
> ***
>
> (I didn’t look to see if there is an example anywhere that does this).****
>
> ** **
>
> thanks****
>
> ** **
>
> JB****
>
> ** **
>
> PS. When I add a scalar bar to the display, the script displays this error
> on the first timestep. Quite annoying – is there anything I can set to
> true/false to make it go away.****
>
> ** **
>
> ****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20120110/a525309e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 24820 bytes
Desc: not available
URL: <http://www.paraview.org/pipermail/paraview/attachments/20120110/a525309e/attachment-0001.png>
More information about the ParaView
mailing list