Re: [Paraview] Minor bug in OPENFOAM import filter
Hi David and Eugene,
From: David Lonie
Subject: Re: [Paraview] Minor bug in OPENFOAM import filter
Date: Fri, 24 Jun 2016 13:34:10 -0400
> Alternatively, I saw some discussion around skipping every entry in
> boundaryField specifications other than 'value'. This would likely
> be quite easy to implement. My only question is, would it break
> anything for the visualization?
It would be better if other entries like "gradient" (for Neumann-type
boundary conditions) can also be taken into account. However it needs
a lot of work (we need to add a logic to calculate the distance from
the adjacent cell center to the boundary face etc.). I think for now
we need to live with skipping every entry other than "value".
From: Eugene de Villiers
Subject: RE: [Paraview] Minor bug in OPENFOAM filter
Date: Wed, 22 Jun 2016 15:56:56 +
> I would say check for a "value" entry and if you don't find it
> assume zero gradient.
If I remember correctly, the reader already has a check for a "value"
entry and if not found it assumes zero gradient.
> It is important that only the first value entry on the base level of
> the boundary condition is actually identified as the face value
> correlated "value" entry.
I am sure that the reader already does this as well.
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: David Lonie
Subject: Re: [Paraview] Minor bug in OPENFOAM import filter
Date: Fri, 24 Jun 2016 13:34:10 -0400
> Hi Eugene,
>
> On Wed, Jun 22, 2016 at 11:45 AM, Eugene de Villiers > wrote:
>
>> Attached find a small case
>>
>
> Thanks -- I've loaded this up and can reproduce the error. The error occurs
> in vtkFoamEntryValue::ReadList, which contains the following comment:
>
> // general-purpose list reader - guess the type of the list and read
>
> // it. only supports ascii format and assumes the preceding '(' has
>
> // already been thrown away. the reader supports nested list with
>
> // variable lengths (e. g. `((token token) (token token token)).'
>
> // also *supports compound of tokens and lists (e. g. `((token token)*
>
> // *token)') only if a list comes as the first value.*
>
>
> So the list (1.1 (1 2 3)) is being parsed as a list, and our reader
> only supports lists
>
> containing mixed tokens / lists if the lists precede the tokens. And
> indeed, changing
>
> file to read ((1 2 3) 1.1) will eliminate the error. The current
> parser assumes that the
>
> remainder of the list will also be scalars and attempts to read them
> in -- then it
>
> chokes when it encounters a '(' instead of another scalar.
>
>
> Again, I'm not familiar with the openFOAM format, but would writing
> the list with the
>
> nested list first be feasible on your end? I'm not sure if this is a
> format restriction or
>
> an implementation detail of our reader.
>
>
> Alternatively, I saw some discussion around skipping every entry in
> boundaryField
>
> specifications other than 'value'. This would likely be quite easy to
> implement. My
>
> only question is, would it break anything for the visualization?
>
>
> Dave
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Search the list archives at: http://markmail.org/search/?q=ParaView
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview
Re: [Paraview] Minor bug in OPENFOAM filter
Hi Eugene and all, Sorry for not giving a concrete solution but just a comment. The current reader handles the complex OpenFOAM format without a priori knowledge of exact format of a specific dictionary entry. With further growing complexity and format extensions made over OpenFOAM versions, there can always be such a problem especially when reading entries required by certain types of boundary conditions. Either implementing such knowledge or skipping the entire dictionary entries other than the "value" entries in the boudaryFields could be an idea though. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: paraview-requ...@paraview.org Subject: ParaView Digest, Vol 146, Issue 25 Date: Tue, 21 Jun 2016 12:00:08 -0400 > Hi, > > We have come across a minor but annoying bug in the Paraview OPENFOAM reader. > > The component of the Paraview OPENFOAM parser that reads boundary conditions > has been set up to always expect another number where a scalar is encountered > in the following configuration: > > (1.111 ### > > when you follow a bracket-scalar with another bracket like this > > (1.111 ( > > an exception is thrown and the field is not loaded. However, if the leading > number is an integer, then it copes fine: > > (1 (### > > So it simply doesn't parse a scalar followed by a bracket. Most of such > instances are not relevant to the display of data as they concern table > inputs for time varying vector boundary conditions. The current workaround is > to always use integers in interpolation input tables, but obviously this is > not ideal. To reproduce the issue, simply add the following entry to any > boundary condition for any volumetric field: > > RandomEntry table (1.1 ( 1 2 3)); > > It will result in an "Error reading line XXX ... " output and the field that > the entry was added to will not be loaded. If you change it to: > > RandomEntry table (1 ( 1 2 3)); > > Then it works fine. I can provide a small case that reproduces the issue if > the above is not clear. > > Best regards, > > Eugene de Villiers > e.devilli...@engys.com<mailto:e.devilli...@engys.com> > Mob: +44 (0) 77 89748490 > Tel: +44 (0)20 32393041 (ext. 102) > Fax: +44 (0)20 33573123 > [logo_red-black_fonts_signature]<http://www.engys.com/> > > This message is intended only for the use of the addressee and may contain > information that is privileged, confidential and exempt from disclosure under > applicable law. If the reader of this message is not the intended recipient, > or the employee or agent responsible for delivering the message to the > intended recipient, you are hereby notified that any dissemination, > distribution or copying of this communication is strictly prohibited. If you > have received this e-mail in error, please notify us immediately by return > e-mail and delete this e-mail and all attachments from your system. > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
Re: [Paraview] Paraview 4.4 Openfoam native reader decomposed read issue
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 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 -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 > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
[Paraview] Japanese translation of the ParaView Tutorial version 4.2 is available
Hi, We are pleased to announce the availability of the Japanese translation of the ParaView Tutorial version 4.2 by Kenneth Moreland. Download from the Translations section of http://www.paraview.org/Wiki/The_ParaView_Tutorial . It is an update after more than four years since the last release for version 3.8. We would like to thank the original author for the excellent tutorial and for continuously providing the LaTeX source files on GitHub. Also, the translators are grateful to the Open CAE Society of Japan (http://www.opencae.jp/) for funding the translation project. Takuya ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
[Paraview] Problem loading a .pvd file in parallel into PV 4.3.1
Hi, I have a problem trying to load a .pvd file (containing a link to a time-series of .pvtp datasets) into a parallel configuration of PV 4.3.1. The steps to reproduce my problem are: Start multiple (say 4) pvservers in parallel Start the ParaView GUI, connect to the server Source - Sphere, Apply File - Save Data... Choose ParaView Data Files(*.pvd) as Files of type Name the file as sphere.pvd, OK, OK Delete Sphere1 File - Open... Choose sphere.pvd, OK, Apply With the above steps a sphere source is created, saved, loaded back and what I see should be a whole sphere. However, I only see a fragment of the sphere which has been saved as piece 0 of sphere.pvd (sphere/sphere_0_0.vtp). Moreover, when I load the underlying .pvtp file (sphere/sphere_0.pvtp), I can see the whole sphere as expected. I have the same problem with PV 4.2 as well, but not with 4.1. My problem looks similar to http://markmail.org/message/33hr6k45fgfd4w63 which reports a problem with .pvti files, but I am not sure if it is identical. Is this a bug or am I missing something? Thanks, Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
Re: [Paraview] Shapefiles?
Hi Mark, vtkGDALVectorReader has been in the ParaView source tree for quite a while. You however have to explicitly turn on the reader by CMake configuration (Module_vtkIOGDAL) and build ParaView with GDAL. Furthermore, you need to write a simple XML plugin and load it to expose the reader to the ParaView GUI. If it works, you can use GDALVectorReaderSM.xml in the vtkgis_vector_reader repository instead. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: "Vanmoer, Mark W" Subject: [Paraview] Shapefiles? Date: Thu, 30 Oct 2014 21:57:15 + > Hi ParaView, > > I found this thread: > www.paraview.org/pipermail/paraview/2012-December/027026.html<http://www.paraview.org/pipermail/paraview/2012-December/027026.html> > indicating vtkGDALVectorReader would be added to mainline ParaView, and I do > see an option load DEMs, but are ESRI ShapeFiles supported? I can't get any > .shp files to be recognized or load. > > There's an earlier thread from 2011 discussing vtkgis_vector_reader, is that > still the recommended ShapeFile loader? > > Thanks, > Mark ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
Re: [Paraview] parallel and transparency
I am not sure if exactly same, but had a very similar rendering problem with multiple overlapped opacity-mapped surfaces on 4.1.0. Turning on Use Immediate Mode Rendering in the Render View settings solved the problem on my Mac. Now, I checked on a Windows to make sure that it was a cross-platform workaround but it didn't work. Anyway, you might give it a try if you still have not. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Burlen Loring Subject: [Paraview] parallel and transparency Date: Fri, 02 May 2014 10:24:26 -0700 > Hi All, > > Transparency doesn't seem to be working correctly in parallel w/ > multiple actors(see attached image, bad.png). The check box to enable > depth peeling and slider to set the number of peels don't seem to be > working either. the slider shows 4 and is disabled. disabling depth > peeling doesn't change the image at all. I see similar problems with > volume rendering w/ multiple actors. With only one transparent actor > things look potentially OK. Is this a known issue? Are there other > settings? > > Thanks > Burlen > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] ANN: ParaView 4.0.0-RC2 now available for download
So not so many users were using the button - thanks for the clarification. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Utkarsh Ayachit Subject: Re: [Paraview] ANN: ParaView 4.0.0-RC2 now available for download Date: Thu, 30 May 2013 08:02:18 -0400 > That is intentional. When the moving of selection buttons to the > view-toolbar, there are now too many buttons. It isn't clear how often > these camera undo-buttons were used. If there's a strong sentiment one > way or the other, we can revisit this. > > Utkarsh > > On Wed, May 29, 2013 at 11:08 PM, Takuya OSHIMA > wrote: >> Hi, >> >> Is it intended that the Camera Undo button has been removed from the >> view toolbar? I know the Edit - Camera Undo menu is still there but >> the button was convenient. >> >> Takuya OSHIMA, Ph.D. >> Faculty of Engineering, Niigata University >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> >> >> From: Utkarsh Ayachit >> Subject: [Paraview] ANN: ParaView 4.0.0-RC2 now available for download >> Date: Tue, 28 May 2013 15:44:09 -0400 >> >>> Folks, >>> >>> In preparation of the next ParaView release, the ParaView 4.0.0, RC2 >>> (Release Candidate 2) is now available for download >>> (http://paraview.org/paraview/resources/software.php). Those looking >>> to check the source out from git, the git tag name is "v4.0.0-RC2". >>> >>> We will have a detailed summary for the new features and enhancements >>> in this release soon. In the mean time, a complete list of features >>> implemented and bugs fixed in this release can be found on the bug >>> tracker (http://paraview.org/Bug/changelog_page.php). >>> >>> The ParaView Team >>> >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the ParaView Wiki at: >> http://paraview.org/Wiki/ParaView >> >> Follow this link to subscribe/unsubscribe: >> http://www.paraview.org/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] ANN: ParaView 4.0.0-RC2 now available for download
Hi, Is it intended that the Camera Undo button has been removed from the view toolbar? I know the Edit - Camera Undo menu is still there but the button was convenient. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Utkarsh Ayachit Subject: [Paraview] ANN: ParaView 4.0.0-RC2 now available for download Date: Tue, 28 May 2013 15:44:09 -0400 > Folks, > > In preparation of the next ParaView release, the ParaView 4.0.0, RC2 > (Release Candidate 2) is now available for download > (http://paraview.org/paraview/resources/software.php). Those looking > to check the source out from git, the git tag name is "v4.0.0-RC2". > > We will have a detailed summary for the new features and enhancements > in this release soon. In the mean time, a complete list of features > implemented and bugs fixed in this release can be found on the bug > tracker (http://paraview.org/Bug/changelog_page.php). > > The ParaView Team > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Custom object panel deprecated?
Utkarsh, thanks for the info :) Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Utkarsh Ayachit Subject: Re: [Paraview] Custom object panel deprecated? Date: Mon, 29 Apr 2013 16:57:07 -0400 > I've updated the Plugin How with the new mechanisms for customizing > panels which will be available in the upcoming ParaView release. > > http://www.paraview.org/Wiki/ParaView/Plugin_HowTo#Adding_Customizations_for_Properties_Panel > http://www.paraview.org/Wiki/ParaView/Properties_Panel > > Utkarsh > > On Sat, Sep 1, 2012 at 9:02 AM, Takuya OSHIMA > wrote: >> Hi, >> >> I see from http://paraview.org/Wiki/Plugin_HowTo that the classic way >> of adding an object panel via a plugin has been deprecated. Do we have >> an alternative? >> >> Takuya OSHIMA, Ph.D. >> Faculty of Engineering, Niigata University >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the ParaView Wiki at: >> http://paraview.org/Wiki/ParaView >> >> Follow this link to subscribe/unsubscribe: >> http://www.paraview.org/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Paraview's "read-values" capability
Hi Vasilis Sassanis, Maybe too late answer: That is because the OpenFOAM reader always holds floating point attributes in single precision regardless of the original precision of the data. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: "Vasilis Sassanis" Subject: [Paraview] Paraview's "read-values" capability Date: Sun, 24 Feb 2013 02:43:05 +0200 (EET) > Hey lads, > > i have these values in one of my results files from OpenFoam for pressure : > > 8.29727559452 > 8.29727116377 > 8.29728432324 > 8.29726004707 > 8.29726903667 > 8.29726512189 > 8.2972572857 > 8.29729613037 > 8.29731830103 > 8.29732028065 and many more for all the points in the grid. > > As you can see, the difference starts from the ninth significant digit and > there is a difference in the values, but paraview plots only two values, > 8.306514 for max and 8.290024 for min, and not the intermediate > values. It just show two colours, blue for the min and red for the max. > > Why it doesn't plot the other values??? > > Thanks > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] [EXTERNAL] Visibility control error in comparative view?
Hi Alan, Thanks for the info. I tried today's git-master but the behavior didn't change. Is the fix in one of the stage branches or somewhere? Meanwhile, I noticed that the problem has already been reported and filed as a bug. http://paraview.org/Bug/view.php?id=13002 Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: "Scott, W Alan" Subject: RE: [EXTERNAL] [Paraview] Visibility control error in comparative view? Date: Thu, 17 Jan 2013 17:54:55 + > Takuya, > I believe that this behavior has been fixed in master, to be replaced by > other issues. I will write up bugs in the bug tracker. > > Bugs 13798, 13799 and 13800. > > Alan > > -Original Message- > From: paraview-boun...@paraview.org [mailto:paraview-boun...@paraview.org] On > Behalf Of Takuya OSHIMA > Sent: Thursday, January 17, 2013 7:00 AM > To: paraview@paraview.org > Subject: [EXTERNAL] [Paraview] Visibility control error in comparative view? > > Hi, > > With ParaView 3.98.0, try following: > 1. Start ParaView > 2. Sources - Wavelet. Apply. > 3. Right-click the top of the view to pop-up the menu, and choose >Convert To... - 3D View (Comparative) 4. View - Comparative View Inspector > 5. Choose Wavelet1 - Visibility from the combo boxes at the middle of >the comparative view inspector, and click the + button > > Then I get the following error messages. Is this how the feature is supposed > to work? > > Generic Warning: In > /Users/kitware/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/ParaViewCore/ServerManager/Core/vtkSMPropertyHelper.cxx, > line 484 Failed to locate property: Visibility > > > ERROR: In > /Users/kitware/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/ParaViewCore/ServerManager/Rendering/vtkPVComparativeAnimationCue.cxx, > line 599 vtkPVComparativeAnimationCue (0x1192a9630): Cue does not have > domain or property set! > > > ERROR: In > /Users/kitware/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/ParaViewCore/ServerManager/Rendering/vtkPVComparativeAnimationCue.cxx, > line 599 vtkPVComparativeAnimationCue (0x1192a9630): Cue does not have > domain or property set! > > > ERROR: In > /Users/kitware/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/ParaViewCore/ServerManager/Rendering/vtkPVComparativeAnimationCue.cxx, > line 599 vtkPVComparativeAnimationCue (0x1192a9630): Cue does not have > domain or property set! > > > ERROR: In > /Users/kitware/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/ParaViewCore/ServerManager/Rendering/vtkPVComparativeAnimationCue.cxx, > line 599 vtkPVComparativeAnimationCue (0x1192a9630): Cue does not have > domain or property set! > > Takuya OSHIMA, Ph.D. > Faculty of Engineering, Niigata University > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > > Follow this link to subscribe/unsubscribe: > http://www.paraview.org/mailman/listinfo/paraview > > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Visibility control error in comparative view?
Hi, With ParaView 3.98.0, try following: 1. Start ParaView 2. Sources - Wavelet. Apply. 3. Right-click the top of the view to pop-up the menu, and choose Convert To... - 3D View (Comparative) 4. View - Comparative View Inspector 5. Choose Wavelet1 - Visibility from the combo boxes at the middle of the comparative view inspector, and click the + button Then I get the following error messages. Is this how the feature is supposed to work? Generic Warning: In /Users/kitware/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/ParaViewCore/ServerManager/Core/vtkSMPropertyHelper.cxx, line 484 Failed to locate property: Visibility ERROR: In /Users/kitware/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/ParaViewCore/ServerManager/Rendering/vtkPVComparativeAnimationCue.cxx, line 599 vtkPVComparativeAnimationCue (0x1192a9630): Cue does not have domain or property set! ERROR: In /Users/kitware/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/ParaViewCore/ServerManager/Rendering/vtkPVComparativeAnimationCue.cxx, line 599 vtkPVComparativeAnimationCue (0x1192a9630): Cue does not have domain or property set! ERROR: In /Users/kitware/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/ParaViewCore/ServerManager/Rendering/vtkPVComparativeAnimationCue.cxx, line 599 vtkPVComparativeAnimationCue (0x1192a9630): Cue does not have domain or property set! ERROR: In /Users/kitware/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/ParaViewCore/ServerManager/Rendering/vtkPVComparativeAnimationCue.cxx, line 599 vtkPVComparativeAnimationCue (0x1192a9630): Cue does not have domain or property set! Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Paraview and Manta View
Hi, I also had a crash with a similar backtrace (which includes Manta::Mesh::~Mesh()) using PV 3.98.0 and Manta r2541 (the latest revision as of today) when I tried changing a display property of a Manta view (displaying a non-OpenFOAM dataset). The problem looks like that vtkMantaPolyDataMapper allocates a series of Manta objects as an array whereas Manta::Mesh::~Mesh() tries to delete them individually. Thus the attached patch fixed the problem for me. I filed a bug with the patch attached: http://paraview.org/Bug/view.php?id=13760 Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: David E DeMarle Subject: Re: [Paraview] Paraview and Manta View Date: Wed, 24 Oct 2012 09:56:54 -0400 > Can you send me the foam data off list? > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > > On Tue, Oct 23, 2012 at 3:47 PM, Jim Knopf wrote: >> Hi There! >> >> right now i'm playing around with paraview and manta ray tracer. I got Manta >> compile on my linux machine and got paraview compile with the manta plug-in. >> >> Now I'm trying to use the manta view in paraview with vtk data derived from >> an OpenFoam case. The result is a crash that I don't understand: >> >> 7f08fff2f000-7f090366b000 rw-p 00:00 0 >> 7f090366b000-7f090366c000 rw-s 122f42000 00:05 7478 >> /dev/dri/card0 >> 7f090366d000-7f090366e000 rw-s 122f4 00:05 7478 >> /dev/dri/card0 >> 7f090372f000-7f090373f000 rw-s 1150e2000 00:05 7478 >> /dev/dri/card0 >> 7f090388f000-7f09038a1000 rw-s 00:04 9044062 >> /SYSV (deleted) >> 7f0903981000-7f0903a81000 rw-s 11c594000 00:05 7478 >> /dev/dri/card0 >> 7f0903bc1000-7f0904343000 rw-s 00:04 8978494 >> /SYSV (deleted) >> 7f0904343000-7f0904344000 rw-s 1278e3000 00:05 7478 >> /dev/dri/card0 >> 7f0904344000-7f0904345000 rw-s 127e34000 00:05 7478 >> /dev/dri/card0 >> 7f09045ba000-7f09046b8000 rw-s 00:04 9568362 >> /SYSV (deleted) >> 7f09046b8000-7f09046dd000 rw-s 00:04 9470057 >> /SYSV (deleted) >> 7f09046dd000-7f0904708000 rw-s 00:04 9437288 >> /SYSV (deleted) >> 7f0904708000-7f0904709000 rw-s 11d082000 00:05 7478 >> /dev/dri/card0 >> 7f0904709000-7f090470a000 rw-s 11d081000 00:05 7478 >> /dev/dri/card0 >> 7f090470a000-7f090470b000 rw-s 11d08 00:05 7478 >> /dev/dri/card0Thread "RTRT Worker 0"(pid 23818 >> Backtrace: >> 1. /usr/local/lib/libManta_Core.so(+0x412d0) [0x7f08eb3272d0] >> 2. /lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7f092cb534a0] >> 3. /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f092cb53425] >> 4. /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7f092cb56b8b] >> 5. /lib/x86_64-linux-gnu/libc.so.6(+0x7439e) [0x7f092cb9139e] >> 6. /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96) [0x7f092cb9bb96] >> 7. /usr/local/lib/libManta_Model.so >> in Manta::Mesh::~Mesh() >> 8. /usr/local/lib/libManta_Model.so >> in Manta::Mesh::~Mesh() >> 9. /usr/local/lib/libManta_Model.so >> in Manta::Group::shrinkTo(unsigned long, bool) >> a. >> /home/otti/OpenFOAM/ThirdParty-2.1.1/platforms/linux64Gcc/paraview-3.12.0/lib/paraview-3.12/libvtkManta.so >> in vtkMantaActorThreadCache::FreeMantaResources() >> b. >> /home/otti/OpenFOAM/ThirdParty-2.1.1/platforms/linux64Gcc/paraview-3.12.0/lib/paraview-3.12/libvtkManta.so >> in Manta::CallbackTransaction::apply() >> c. /usr/local/lib/libManta_Engine.so >> in Manta::RTRT::postTransactions(bool&) >> d. /usr/local/lib/libManta_Engine.so >> in Manta::RTRT::internalRenderLoop(int, bool) >> e. /usr/local/lib/libManta_Core.so >> in Manta::Thread::run_body() >> f. /usr/local/lib/libManta_Core.so(+0x44728) [0x7f08eb32a728] >> 10. /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7f0929dd3e9a] >> 11. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f092cc10cbd] >> 139677424109440: main (state = blocking on semaphore, >> SyncDisplay::_frameready) >> 139676715988736: RTRT Worker 0 (state = running) >> >> Abort signalled by pid: 23818 >> Occured for thread: "RTRT Worker 0" >> >> >> Has anyone any idea? Running Manta standalone works >> >> Thanks and Greetings >> Jim >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/openso
Re: [Paraview] Reading DEM files
Nice to know there's still a good chance that the GDAL vector reader could go into ParaView proper. The reader has been working so great for me for more than a year that I really hope to see it fully integrated with ParaView/VTK. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Aashish Chaudhary Subject: Re: [Paraview] Reading DEM files Date: Wed, 19 Dec 2012 00:05:45 -0500 > Hi Deb, > > You can use this vector reader (uses GDAL) and ParaView plugin to load your > SRTM DEM. I will see if we can this reader and plugin into ParaView proper. > I have long desired it but we don't have any direct funding for it but > nonetheless I will have it in proper VTK / ParaView by the end of the year. > > https://gitorious.org/vtkgis_vector_reader > > Thanks, > > > On Tue, Dec 18, 2012 at 7:20 AM, deb wrote: > >> Data can be downloaded from http://centaurus.caf.dlr.de:8080/ >> After registering free account click on "SRTM Data download" text button >> (on web page toolbar) then link to ftp server will be provided for next 24 >> hours >> >> On вторник, 18 декември 2012 at 1:11 PM, "Utkarsh Ayachit" < >> utkarsh.ayac...@kitware.com> wrote: >> > >> >Can you share the data file to test? >> > >> > >> >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the ParaView Wiki at: >> http://paraview.org/Wiki/ParaView >> >> Follow this link to subscribe/unsubscribe: >> http://www.paraview.org/mailman/listinfo/paraview >> > > > > -- > | Aashish Chaudhary > | R&D Engineer > | Kitware Inc. > | www.kitware.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] pqPipelineSource::visibilityChanged() not fired when a downstream filter changes visibility
I filed a bug for the problem: http://paraview.org/Bug/view.php?id=13687 Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Takuya OSHIMA Subject: [Paraview] pqPipelineSource::visibilityChanged() not fired when a downstream filter changes visibility Date: Sun, 25 Nov 2012 12:34:04 +0900 (JST) > Hi, > > My custom reader panel (a pqAutoGeneratedObjectPanel) hooks the > pqPipelineSource::visibilityChanged() signal of the corresponding > reader proxy. I noticed that the signal used to be fired when a > downstream filter that changes the visibility of the input > (e.g. Slice) is added with PV 3.14.1 (+ earlier versions) and 3.98.0 > RC3 when I --use-old-panels, but does not with the new panels of the > RC3 (OS X 10.6.8, Qt 4.8.3, CMake 2.8.10). > > I attached a test plugin code to demonstrate the problem (a modified > Examples/Plugins/GUIObjectPanel). Try: > Build the plugin > Start ParaView from a command terminal (with/without --use-old-panels) > Load the plugin > Sources - Cone, Apply > Filters - Slice, Apply > > The expected behavior is a "Visibility changed" output on the terminal > when a slice is added because it turns off the visiblity of the cone > source. It works as expected when ParaView is started with > --use-old-panels but not without the option. > > Can anybody give me an insight? > > Takuya OSHIMA, Ph.D. > Faculty of Engineering, Niigata University > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Undefined symbols when building an example reader plugin
Hi, With today's git-master, building ParaView/Examples/Plugins/Reader on OS X 10.6.8, CMake 2.8.10, Qt 4.8.3 fails in the final linking stage stating: Undefined symbols: "vtkRenderingMatplotlib_AutoInit_Construct()", referenced from: __static_initialization_and_destruction_0(int, int)in MyPNGReader_Plugin.o __static_initialization_and_destruction_0(int, int)in moc_MyPNGReader_Plugin.o "vtkRenderingMatplotlib_AutoInit_Destruct()", referenced from: ___tcf_7 in MyPNGReader_Plugin.o ___tcf_5 in moc_MyPNGReader_Plugin.o ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [libMyPNGReader.dylib] Error 1 make[1]: *** [CMakeFiles/MyPNGReader.dir/all] Error 2 make: *** [all] Error 2 which is what I also have with my reader plugin. I know there is an easy workaround of adding vtkRenderingMatplotlib as one of TARGET_LINK_LIBRARIES but is this what I have to do? Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Example VisIt reader fails to configure
Hi, With the latest git-master, ParaView/Examples/Plugins/VisItReader fails to configure with cmake stating that cmake command "ADD_VISIT_PLUGIN_READER" is unknown. Is this a known problem? If anyone is curious, I am trying to update a Shapefile reader plugin which I have pulled from VisIt (https://gitorious.org/avtshapefilefileformat_plugin) to work with the latest master and having the same issue. (OS X 10.6.8, CMake 2.8.9, Qt 4.8.2) > cmake -DParaView_DIR=/opt/src/paraview/build > ../ParaView/Examples/Plugins/VisItReader -- The C compiler identification is GNU 4.2.1 -- The CXX compiler identification is GNU 4.2.1 -- Checking whether C compiler has -isysroot -- Checking whether C compiler has -isysroot - yes -- Checking whether C compiler supports OSX deployment target flag -- Checking whether C compiler supports OSX deployment target flag - yes -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Checking whether CXX compiler has -isysroot -- Checking whether CXX compiler has -isysroot - yes -- Checking whether CXX compiler supports OSX deployment target flag -- Checking whether CXX compiler supports OSX deployment target flag - yes -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - not found. -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - not found. -- Looking for Q_WS_QWS -- Looking for Q_WS_QWS - not found. -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - found -- Looking for QT_MAC_USE_COCOA -- Looking for QT_MAC_USE_COCOA - found -- Found Qt4: /opt/Qt-4.8.2/bin/qmake (found version "4.8.2") CMake Error at CMakeLists.txt:21 (ADD_VISIT_PLUGIN_READER): Unknown CMake command "ADD_VISIT_PLUGIN_READER". -- Configuring incomplete, errors occurred! Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Behavior of a plugin reader that shares the same proxy name as one of the internal readers?
I tested the fix and it did the trick. Thank you! Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Utkarsh Ayachit Subject: Re: [Paraview] Behavior of a plugin reader that shares the same proxy name as one of the internal readers? Date: Wed, 5 Sep 2012 14:19:21 -0400 > Thanks for the details. Helped me track down the issue in no time. Here the > bug: > http://paraview.org/Bug/view.php?id=13427 > > Utkarsh > > On Fri, Aug 24, 2012 at 11:15 AM, Takuya OSHIMA > wrote: >> Addendum: you have to put the representation plugin under >> PV_PLUGIN_PATH to auto-load. Strangely, if I check "Auto Load" in the >> Plugin Mnager to auto-load, the problem does not reproduce. >> >> Takuya OSHIMA, Ph.D. >> Faculty of Engineering, Niigata University >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> >> >> From: Takuya OSHIMA >> Subject: Re: [Paraview] Behavior of a plugin reader that shares the same >> proxy name as one of the internal readers? >> Date: Fri, 24 Aug 2012 23:51:55 +0900 (JST) >> >>> Hi Utkarsh, >>> >>> It looks like there is a problem in the order of loading internal >>> proxies (vtkPVInitializerPlugin?) and user plugins. I get the >>> aforementioned crash when I auto-load the plugin under (application >>> dir)/plugins but do not when I load manually from the Plugin Manager. >>> >>> The problem affects not only my tricky plugin but also user plugins >>> that inherit internal proxies by base_proxyname="..." or >> />. Try ParaView/Examples/Plugins/Representation of the git-master. It >>> works (I can choose the "Special Mapper" representation for a >>> polygonal dataset) if manually loaded, but if auto-loaded it complains >>> vtkSIProxyDefinitionManager (0x119f75690): Extension for (representations, >>> GeometryRepresentation) ignored since could not find core definition. >>> >>> If I am not mistaken there has been changes like the removal of >>> vtkParaViewIncludeModulesToSMApplication and the introduction of >>> vtkPVInitializerPlugin mechanism after 3.14.1 so I think my >>> observation could be consistent with the internal change. >>> >>> Takuya OSHIMA, Ph.D. >>> Faculty of Engineering, Niigata University >>> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >>> >>> From: Utkarsh Ayachit >>> Subject: Re: [Paraview] Behavior of a plugin reader that shares the same >>> proxy name as one of the internal readers? >>> Date: Mon, 20 Aug 2012 09:40:46 -0400 >>> >>> > Takuya, >>> > >>> > I am surprised it worked in 3.14. I don;t think there has been much >>> > change in the ServerManager since 3.14. I could track down what change >>> > caused it, but nonetheless, I think it's probably not a good idea to >>> > override default proxy. You should just create a new one with a new >>> > name and still assign to the same extensions. The user will be >>> > presented a dialog to pick which reader to create when he opens a >>> > matching extension file. That way state files/python scrips referring >>> > to one or the other will continue to work seamlessly without one >>> > accidentally creating the other one, etc. >>> > >>> > BTW, is there are newer version of the OpenFOAM reader that needs to >>> > go into ParaView for the upcoming release? >>> > >>> > Utkarsh >>> > >>> > On Sun, Aug 19, 2012 at 3:00 AM, Takuya OSHIMA >>> > wrote: >>> >> Hi, >>> >> >>> >> My reader plugin shares the same name as one of the builtin readers of >>> >> ParaView (OpenFOAMReader), as shown in the following server side XML. >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> If my memory serves me right I read in this list that a plugin has >>> >> precedence over an internal object in searching for a proxy. Indeed, >>> >> in the past released versions of ParaView (including 3.14.1), the >>> >> plugin reader has worked well in overriding the internal >>> >> reader. However, with the git-master of ParaView (as of today), when I >>> >> open an OpenFOAM case, the constructor of my reader panel (derived >>> >> from pqAutoGeneratedObjectPanel) ge
Re: [Paraview] Unlink a property from a GUI widget on a reader panel
I always hope to get all the updates into ParaView but the time constraint is too tight to work on this now. I'll ping you if I can prepare something. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Utkarsh Ayachit Subject: Re: [Paraview] Unlink a property from a GUI widget on a reader panel Date: Tue, 4 Sep 2012 11:25:38 -0400 > No, thank you! BTW, is there an update to the OpenFOAM reader what we > should be getting into ParaView? > > Utkarsh > > On Tue, Sep 4, 2012 at 11:23 AM, Takuya OSHIMA > wrote: >> Thanks Utkarsh. >> >> Takuya OSHIMA, Ph.D. >> Faculty of Engineering, Niigata University >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> >> - Original Message - >>>> From: Utkarsh Ayachit >>>> To: Takuya OSHIMA >>>> Cc: paraview@paraview.org >>>> Date: 2012-09-04 23:02:44 >>>> Subject: Re: [Paraview] Unlink a property from a GUI widget on a reader >>>> panel >>>> >>>> Looks good to me. I've pushed it to stage. It dashboards are >>>> unaffected, it will show up in master after next gatekeeper review. >>>> >>>> Utkarsh >>>> >>>> On Sat, Sep 1, 2012 at 11:40 AM, Takuya OSHIMA >>>> wrote: >>>> > I have pushed a proposed patch for the problem to gerrit. >>>> > http://review.source.kitware.com/#/c/7326/ >>>> > Can someone review please. >>>> > >>>> > Takuya OSHIMA, Ph.D. >>>> > Faculty of Engineering, Niigata University >>>> > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >>>> > >>>> > From: Takuya OSHIMA >>>> > Subject: [Paraview] Unlink a property from a GUI widget on a reader panel >>>> > Date: Mon, 27 Aug 2012 23:35:06 +0900 (東京 (標準時)) >>>> > >>>> >> Hi, >>>> >> >>>> >> I have a checkbox on my custom reader panel which is automatically >>>> >> generated in connection with an IntVector boolean domain property from >>>> >> the SM XML proxy definition, which is set to immediate_update. >>>> >> >>>> >> In order for checking/unchecking the checkbox to take effect in the >>>> >> server side immediately without turning the Apply button to green, In >>>> >> addition to setting the immediate_update attribute I unlink the >>>> >> default property link and setup/take care of an alternative link by >>>> >> >>>> >> pqNamedWidgets::unlinkObject(regionNames, pqSMProxy(this->proxy()), >>>> >> "ShowRegionNames", this->propertyManager()); >>>> >> this->Implementation->Links.addPropertyLink(regionNames, "checked", >>>> >> SIGNAL(toggled(bool)), this->proxy(), showRegionNames); >>>> >> this->Implementation->VTKConnect->Connect(showRegionNames, >>>> >> vtkCommand::ModifiedEvent, this, >>>> >> SLOT(onShowRegionNamesModified())); >>>> >> >>>> >> where regonNames is the QCheckBox and showRegionNames is the >>>> >> vtkSMIntVectorProperty. This has worked well with PV 3.14.1 and >>>> >> earlier versions, but with the git-master the Apply button turns to >>>> >> green when the checkbox is clicked. Is there a way to immediately push >>>> >> the property to the server without changing the Apply button state for >>>> >> the git-master? >>>> >> >>>> >> Just as a side note, I tested commit >>>> >> 3bb4f74eff3f0670df5bef12c1e29b77b394a963 (Fix auto-apply with the new >>>> >> properties panel) from the next branch but it did not help (unless >>>> >> turning on Auto Accept in the general setting). >>>> >> >>>> >> Takuya OSHIMA, Ph.D. >>>> >> Faculty of Engineering, Niigata University >>>> >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >>>> >> ___ >>>> >> Powered by www.kitware.com >>>> >> >>>> >> Visit other Kitware open-source projects at >>>> >> http://www.kitware.com/opensource/opensource.html >>>> >> >>>> >> Please keep messages on-topic and check the ParaView Wiki at: >>>> >> http://paraview.org/Wiki/ParaView >>>> >> >>>> >> Follow this link to subscribe/unsubscribe: >>>> >> http://www.paraview.org/mailman/listinfo/paraview >>>> > ___ >>>> > Powered by www.kitware.com >>>> > >>>> > Visit other Kitware open-source projects at >>>> > http://www.kitware.com/opensource/opensource.html >>>> > >>>> > Please keep messages on-topic and check the ParaView Wiki at: >>>> > http://paraview.org/Wiki/ParaView >>>> > >>>> > Follow this link to subscribe/unsubscribe: >>>> > http://www.paraview.org/mailman/listinfo/paraview >>>> ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Unlink a property from a GUI widget on a reader panel
Thanks Utkarsh. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN - Original Message - >> From: Utkarsh Ayachit >> To: Takuya OSHIMA >> Cc: paraview@paraview.org >> Date: 2012-09-04 23:02:44 >> Subject: Re: [Paraview] Unlink a property from a GUI widget on a reader panel >> >> Looks good to me. I've pushed it to stage. It dashboards are >> unaffected, it will show up in master after next gatekeeper review. >> >> Utkarsh >> >> On Sat, Sep 1, 2012 at 11:40 AM, Takuya OSHIMA >> wrote: >> > I have pushed a proposed patch for the problem to gerrit. >> > http://review.source.kitware.com/#/c/7326/ >> > Can someone review please. >> > >> > Takuya OSHIMA, Ph.D. >> > Faculty of Engineering, Niigata University >> > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> > >> > From: Takuya OSHIMA >> > Subject: [Paraview] Unlink a property from a GUI widget on a reader panel >> > Date: Mon, 27 Aug 2012 23:35:06 +0900 (東京 (標準時)) >> > >> >> Hi, >> >> >> >> I have a checkbox on my custom reader panel which is automatically >> >> generated in connection with an IntVector boolean domain property from >> >> the SM XML proxy definition, which is set to immediate_update. >> >> >> >> In order for checking/unchecking the checkbox to take effect in the >> >> server side immediately without turning the Apply button to green, In >> >> addition to setting the immediate_update attribute I unlink the >> >> default property link and setup/take care of an alternative link by >> >> >> >> pqNamedWidgets::unlinkObject(regionNames, pqSMProxy(this->proxy()), >> >> "ShowRegionNames", this->propertyManager()); >> >> this->Implementation->Links.addPropertyLink(regionNames, "checked", >> >> SIGNAL(toggled(bool)), this->proxy(), showRegionNames); >> >> this->Implementation->VTKConnect->Connect(showRegionNames, >> >> vtkCommand::ModifiedEvent, this, SLOT(onShowRegionNamesModified())); >> >> >> >> where regonNames is the QCheckBox and showRegionNames is the >> >> vtkSMIntVectorProperty. This has worked well with PV 3.14.1 and >> >> earlier versions, but with the git-master the Apply button turns to >> >> green when the checkbox is clicked. Is there a way to immediately push >> >> the property to the server without changing the Apply button state for >> >> the git-master? >> >> >> >> Just as a side note, I tested commit >> >> 3bb4f74eff3f0670df5bef12c1e29b77b394a963 (Fix auto-apply with the new >> >> properties panel) from the next branch but it did not help (unless >> >> turning on Auto Accept in the general setting). >> >> >> >> Takuya OSHIMA, Ph.D. >> >> Faculty of Engineering, Niigata University >> >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> >> ___ >> >> Powered by www.kitware.com >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Please keep messages on-topic and check the ParaView Wiki at: >> >> http://paraview.org/Wiki/ParaView >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://www.paraview.org/mailman/listinfo/paraview >> > ___ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Please keep messages on-topic and check the ParaView Wiki at: >> > http://paraview.org/Wiki/ParaView >> > >> > Follow this link to subscribe/unsubscribe: >> > http://www.paraview.org/mailman/listinfo/paraview >> ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Unlink a property from a GUI widget on a reader panel
I have pushed a proposed patch for the problem to gerrit. http://review.source.kitware.com/#/c/7326/ Can someone review please. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Takuya OSHIMA Subject: [Paraview] Unlink a property from a GUI widget on a reader panel Date: Mon, 27 Aug 2012 23:35:06 +0900 (東京 (標準時)) > Hi, > > I have a checkbox on my custom reader panel which is automatically > generated in connection with an IntVector boolean domain property from > the SM XML proxy definition, which is set to immediate_update. > > In order for checking/unchecking the checkbox to take effect in the > server side immediately without turning the Apply button to green, In > addition to setting the immediate_update attribute I unlink the > default property link and setup/take care of an alternative link by > > pqNamedWidgets::unlinkObject(regionNames, pqSMProxy(this->proxy()), > "ShowRegionNames", this->propertyManager()); > this->Implementation->Links.addPropertyLink(regionNames, "checked", > SIGNAL(toggled(bool)), this->proxy(), showRegionNames); > this->Implementation->VTKConnect->Connect(showRegionNames, > vtkCommand::ModifiedEvent, this, SLOT(onShowRegionNamesModified())); > > where regonNames is the QCheckBox and showRegionNames is the > vtkSMIntVectorProperty. This has worked well with PV 3.14.1 and > earlier versions, but with the git-master the Apply button turns to > green when the checkbox is clicked. Is there a way to immediately push > the property to the server without changing the Apply button state for > the git-master? > > Just as a side note, I tested commit > 3bb4f74eff3f0670df5bef12c1e29b77b394a963 (Fix auto-apply with the new > properties panel) from the next branch but it did not help (unless > turning on Auto Accept in the general setting). > > Takuya OSHIMA, Ph.D. > Faculty of Engineering, Niigata University > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > > Follow this link to subscribe/unsubscribe: > http://www.paraview.org/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Custom object panel deprecated?
Hi, I see from http://paraview.org/Wiki/Plugin_HowTo that the classic way of adding an object panel via a plugin has been deprecated. Do we have an alternative? Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Unlink a property from a GUI widget on a reader panel
Hi, I have a checkbox on my custom reader panel which is automatically generated in connection with an IntVector boolean domain property from the SM XML proxy definition, which is set to immediate_update. In order for checking/unchecking the checkbox to take effect in the server side immediately without turning the Apply button to green, In addition to setting the immediate_update attribute I unlink the default property link and setup/take care of an alternative link by pqNamedWidgets::unlinkObject(regionNames, pqSMProxy(this->proxy()), "ShowRegionNames", this->propertyManager()); this->Implementation->Links.addPropertyLink(regionNames, "checked", SIGNAL(toggled(bool)), this->proxy(), showRegionNames); this->Implementation->VTKConnect->Connect(showRegionNames, vtkCommand::ModifiedEvent, this, SLOT(onShowRegionNamesModified())); where regonNames is the QCheckBox and showRegionNames is the vtkSMIntVectorProperty. This has worked well with PV 3.14.1 and earlier versions, but with the git-master the Apply button turns to green when the checkbox is clicked. Is there a way to immediately push the property to the server without changing the Apply button state for the git-master? Just as a side note, I tested commit 3bb4f74eff3f0670df5bef12c1e29b77b394a963 (Fix auto-apply with the new properties panel) from the next branch but it did not help (unless turning on Auto Accept in the general setting). Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Behavior of a plugin reader that shares the same proxy name as one of the internal readers?
Addendum: you have to put the representation plugin under PV_PLUGIN_PATH to auto-load. Strangely, if I check "Auto Load" in the Plugin Mnager to auto-load, the problem does not reproduce. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Takuya OSHIMA Subject: Re: [Paraview] Behavior of a plugin reader that shares the same proxy name as one of the internal readers? Date: Fri, 24 Aug 2012 23:51:55 +0900 (JST) > Hi Utkarsh, > > It looks like there is a problem in the order of loading internal > proxies (vtkPVInitializerPlugin?) and user plugins. I get the > aforementioned crash when I auto-load the plugin under (application > dir)/plugins but do not when I load manually from the Plugin Manager. > > The problem affects not only my tricky plugin but also user plugins > that inherit internal proxies by base_proxyname="..." or />. Try ParaView/Examples/Plugins/Representation of the git-master. It > works (I can choose the "Special Mapper" representation for a > polygonal dataset) if manually loaded, but if auto-loaded it complains > vtkSIProxyDefinitionManager (0x119f75690): Extension for (representations, > GeometryRepresentation) ignored since could not find core definition. > > If I am not mistaken there has been changes like the removal of > vtkParaViewIncludeModulesToSMApplication and the introduction of > vtkPVInitializerPlugin mechanism after 3.14.1 so I think my > observation could be consistent with the internal change. > > Takuya OSHIMA, Ph.D. > Faculty of Engineering, Niigata University > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN > > From: Utkarsh Ayachit > Subject: Re: [Paraview] Behavior of a plugin reader that shares the same > proxy name as one of the internal readers? > Date: Mon, 20 Aug 2012 09:40:46 -0400 > > > Takuya, > > > > I am surprised it worked in 3.14. I don;t think there has been much > > change in the ServerManager since 3.14. I could track down what change > > caused it, but nonetheless, I think it's probably not a good idea to > > override default proxy. You should just create a new one with a new > > name and still assign to the same extensions. The user will be > > presented a dialog to pick which reader to create when he opens a > > matching extension file. That way state files/python scrips referring > > to one or the other will continue to work seamlessly without one > > accidentally creating the other one, etc. > > > > BTW, is there are newer version of the OpenFOAM reader that needs to > > go into ParaView for the upcoming release? > > > > Utkarsh > > > > On Sun, Aug 19, 2012 at 3:00 AM, Takuya OSHIMA > > wrote: > >> Hi, > >> > >> My reader plugin shares the same name as one of the builtin readers of > >> ParaView (OpenFOAMReader), as shown in the following server side XML. > >> > >> > >> > >> > >> > >> > >> If my memory serves me right I read in this list that a plugin has > >> precedence over an internal object in searching for a proxy. Indeed, > >> in the past released versions of ParaView (including 3.14.1), the > >> plugin reader has worked well in overriding the internal > >> reader. However, with the git-master of ParaView (as of today), when I > >> open an OpenFOAM case, the constructor of my reader panel (derived > >> from pqAutoGeneratedObjectPanel) gets executed but "this->proxy()" > >> picks up the proxy for the internal reader. I wonder if this is a > >> design change? > >> > >> Takuya OSHIMA, Ph.D. > >> Faculty of Engineering, Niigata University > >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN > >> ___ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Please keep messages on-topic and check the ParaView Wiki at: > >> http://paraview.org/Wiki/ParaView > >> > >> Follow this link to subscribe/unsubscribe: > >> http://www.paraview.org/mailman/listinfo/paraview > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > > Follow this link to subscribe/unsubscribe: > http://www.paraview.org/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Behavior of a plugin reader that shares the same proxy name as one of the internal readers?
Hi Utkarsh, It looks like there is a problem in the order of loading internal proxies (vtkPVInitializerPlugin?) and user plugins. I get the aforementioned crash when I auto-load the plugin under (application dir)/plugins but do not when I load manually from the Plugin Manager. The problem affects not only my tricky plugin but also user plugins that inherit internal proxies by base_proxyname="..." or . Try ParaView/Examples/Plugins/Representation of the git-master. It works (I can choose the "Special Mapper" representation for a polygonal dataset) if manually loaded, but if auto-loaded it complains vtkSIProxyDefinitionManager (0x119f75690): Extension for (representations, GeometryRepresentation) ignored since could not find core definition. If I am not mistaken there has been changes like the removal of vtkParaViewIncludeModulesToSMApplication and the introduction of vtkPVInitializerPlugin mechanism after 3.14.1 so I think my observation could be consistent with the internal change. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Utkarsh Ayachit Subject: Re: [Paraview] Behavior of a plugin reader that shares the same proxy name as one of the internal readers? Date: Mon, 20 Aug 2012 09:40:46 -0400 > Takuya, > > I am surprised it worked in 3.14. I don;t think there has been much > change in the ServerManager since 3.14. I could track down what change > caused it, but nonetheless, I think it's probably not a good idea to > override default proxy. You should just create a new one with a new > name and still assign to the same extensions. The user will be > presented a dialog to pick which reader to create when he opens a > matching extension file. That way state files/python scrips referring > to one or the other will continue to work seamlessly without one > accidentally creating the other one, etc. > > BTW, is there are newer version of the OpenFOAM reader that needs to > go into ParaView for the upcoming release? > > Utkarsh > > On Sun, Aug 19, 2012 at 3:00 AM, Takuya OSHIMA > wrote: >> Hi, >> >> My reader plugin shares the same name as one of the builtin readers of >> ParaView (OpenFOAMReader), as shown in the following server side XML. >> >> >> >> >> >> >> If my memory serves me right I read in this list that a plugin has >> precedence over an internal object in searching for a proxy. Indeed, >> in the past released versions of ParaView (including 3.14.1), the >> plugin reader has worked well in overriding the internal >> reader. However, with the git-master of ParaView (as of today), when I >> open an OpenFOAM case, the constructor of my reader panel (derived >> from pqAutoGeneratedObjectPanel) gets executed but "this->proxy()" >> picks up the proxy for the internal reader. I wonder if this is a >> design change? >> >> Takuya OSHIMA, Ph.D. >> Faculty of Engineering, Niigata University >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the ParaView Wiki at: >> http://paraview.org/Wiki/ParaView >> >> Follow this link to subscribe/unsubscribe: >> http://www.paraview.org/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Behavior of a plugin reader that shares the same proxy name as one of the internal readers?
Hi, My reader plugin shares the same name as one of the builtin readers of ParaView (OpenFOAMReader), as shown in the following server side XML. If my memory serves me right I read in this list that a plugin has precedence over an internal object in searching for a proxy. Indeed, in the past released versions of ParaView (including 3.14.1), the plugin reader has worked well in overriding the internal reader. However, with the git-master of ParaView (as of today), when I open an OpenFOAM case, the constructor of my reader panel (derived from pqAutoGeneratedObjectPanel) gets executed but "this->proxy()" picks up the proxy for the internal reader. I wonder if this is a design change? Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] OpenFoam reader native built-in or plugin version differences
The SVN version supports 3.14.1 (the wiki page is outdated) and loads slightly newer OpenFOAM meshes. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Ian Curington Subject: [Paraview] OpenFoam reader native built-in or plugin version differences Date: Wed, 18 Jul 2012 13:45:03 +0100 > Dear ParaView & OpenFoam users: > > http://openfoamwiki.net/index.php/Contrib_Parallelized_Native_OpenFOAM_Reader_for_ParaView > > current SVN source is configured as a plugin, has extra buttons (Watch, > Rescale), > however only mentions working with ParaView 3.10/11. > > Meanwhile, ParaView 3.14.1 (& current GIT) has built-in OpenFoam reader > (without Watch, Rescale). > > So, which one is most up to date? Which one loads the most recent OpenFoam > meshes? > Is the plugin ported to 3.14.1? ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Internationalization of Paraview
Hi Karl, I am aware that there once was a developer who started creating a Japanese version of ParaView and have seen someone mention the existence of a Chinese version but don't know their current statuses. Technically, modifying ParaView to handle menus and message texts in foreign languages should not be difficult thanks to the internationalization framework of Qt. However I don't think translating all menus and message texts and (more importantly) keeping the translated resources up-to-date will be an easy task for an active project like ParaView (it depends on what amount of available human resources you have though). Meanwhile, our group have translated Kenneth Moreland's The ParaView Tutorial to Japanese (http://www.paraview.org/Wiki/The_ParaView_Tutorial). The translation was last updated for PV 3.8 thus looks a bit outdated regarding the version number but most of the contents are still applicable to the current version, becuase the tutorial is more or less focused on the background philosophy and knowledge of ParaView while dealing with practical exercises on its operation in rather version independent way. It would be great if someone creates a Japanese version of ParaView, but we find it more realistic to translate such textbook materials than to create and maintain a translated version of PV if available resources are limited. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Karl Merkley Subject: [Paraview] Internationalization of Paraview Date: Thu, 7 Jun 2012 10:03:11 -0600 > Has anybody looked at language support in Paraview? Specifically, has > anybody done a Russian or Japanese version of Paraview? Is it doable and how > much work is it? > >Thanks, > Karl ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] PV 3.14.1 little endian client / big endian server?
Thanks Utkarsh. The bug: http://paraview.org/Bug/view.php?id=13113 Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Utkarsh Ayachit Subject: Re: [Paraview] PV 3.14.1 little endian client / big endian server? Date: Fri, 20 Apr 2012 08:13:48 -0400 > I'm pretty sure it won't work since we started using protobuf > (ParaView 3.12). Mind reporting a bug? I would like to figure out if > there's an easy way to bring the support back. > > Utkarsh > > On Fri, Apr 20, 2012 at 7:40 AM, Takuya OSHIMA > wrote: >> Hi, >> >> I wonder if anyone has got PV 3.14.1 working with a little endian >> client / big endian server setup? I am trying to run PV with the >> client-server setup >> >> Client: >> Mac OS X 10.6.8 (Intel) >> PV 3.14.1 OS X 64-bit binary downloaded from Kitware >> >> Server: >> Fujitsu FX10 (SPARC IXfx) >> PV 3.14.1 cross-compiled on x86-64 Linux with CMake 2.8.7, FCCpx compiler >> >> and am getting crashes both on the server and the client as >> follows. There are other possible causes e.g. a bit tricky network >> connection (using portfwd) but I am curious if PV is supposed to work >> with this type of setup in the first place. >> >> Server error messages: >> mpiexec ~/fx/20120415/bin/pvserver --use-offscreen-rendering >> Waiting for client... >> Connection URL: cs://x:1 >> Accepting connection(s): x:1 >> Client connected. >> [x:12678] *** Process received signal *** >> [x:12678] Signal: Bus error (10) >> [x:12678] Signal code: Invalid address alignment (1) >> [x:12678] Failing at address: 0x214037b1 >> [x:12678] [ 0] >> /opt/FJSVxosmmm/lib64/libmpgpthread.so.1(_IO_funlockfile+0x5c) >> [0x20809974] >> [x:12678] [ 1] >> /x/fx/20120415/lib/paraview-3.14/libvtkParallel.so.pv3.14(_ZN21vtkMultiProcessStream12vtkInternals9SwapBytesEv+0x1e4) >> [0x06783b64] >> [x:12678] [ 2] >> /x/fx/20120415/lib/paraview-3.14/libvtkParallel.so.pv3.14(_ZN21vtkMultiProcessStream10SetRawDataEPKhj+0x440) >> [0x06778b80] >> [x:12678] [ 3] >> /x/fx/20120415/lib/paraview-3.14/libvtkPVServerImplementation.so(_ZN18vtkPVSessionServer24OnClientServerMessageRMIEPvi+0x18) >> [0x008aec98] >> [x:12678] [ 4] >> /x/fx/20120415/lib/paraview-3.14/libvtkPVServerImplementation.so(_ZN46_GLOBAL__N__22_vtkPVSessionServer_cxx_cc8ff48111RMICallbackEPvS0_ii+0xc) >> [0x008ac5cc] >> [x:12678] [ 5] >> /x/fx/20120415/lib/paraview-3.14/libvtkParallel.so.pv3.14(_ZN25vtkMultiProcessController10ProcessRMIEiPvii+0x3f0) >> [0x0676c8b0] >> [x:12678] [ 6] >> /x/fx/20120415/lib/paraview-3.14/libvtkParallel.so.pv3.14(_ZN25vtkMultiProcessController11ProcessRMIsEii+0x210) >> [0x0676bfd0] >> [x:12678] [ 7] >> /x/fx/20120415/lib/paraview-3.14/libvtkPVClientServerCore.so(_ZN26vtkTCPNetworkAccessManager21ProcessEventsInternalEmb+0x3c4) >> [0x01116f44] >> [x:12678] [ 8] >> /x/fx/20120415/lib/paraview-3.14/libvtkPVClientServerCore.so(_ZN26vtkTCPNetworkAccessManager13ProcessEventsEm+0xc) >> [0x01116b4c] >> [x:12678] [ 9] /x/fx/20120415/lib/paraview-3.14/pvserver [0x102440] >> [x:12678] [10] /x/fx/20120415/lib/paraview-3.14/pvserver(main+0xc) >> [0x10250c] >> [x:12678] [11] /lib64/libc.so.6(__libc_start_main+0x194) >> [0x2118b81c] >> [x:12678] [12] >> /x/fx/20120415/lib/paraview-3.14/pvserver(_start+0x2c) [0x10206c] >> [x:12678] *** End of error message *** >> [ERR.] PLE 0017 plexec The process terminated with the >> signal.(rank=0)(nid=0x01040006)(sig=10) >> >> Client error messages: >>> /Applications/ParaView\ 3.14.1.app/Contents/MacOS/paraview >> ERROR: In >> /Source/ParaView/release/ParaView/VTK/Parallel/vtkSocketCommunicator.cxx, >> line 812 >> vtkSocketCommunicator (0x10d88b820): Could not receive tag. 55627 >> >> >> ERROR: In >> /Source/ParaView/release/ParaView/ParaViewCore/ServerManager/vtkSMSessionClient.cxx, >> line 774 >> vtkSMSessionClient (0x10c6bc1f0): Server failed to gather information. >> >> >> ERROR: In >> /Source/ParaView/release/ParaView/VTK/Parallel/vtkSocketCommunicator.cxx, >> line 812 >> vtkSocketCommunicator (0x10d88b820): Could not receive tag. 55627 >> >> >> ERROR: In >> /Source/ParaView/release/ParaView/ParaViewCore/ServerManager/vtkSMSessionClient
[Paraview] PV 3.14.1 little endian client / big endian server?
aView/VTK/Parallel/vtkSocketCommunicator.cxx, line 812 vtkSocketCommunicator (0x10d88b820): Could not receive tag. 55628 libprotobuf ERROR /Source/ParaView/release/ParaView/Utilities/protobuf/src/google/protobuf/message_lite.cc:123] Can't parse message of type "paraview_protobuf.Message" because it is missing required fields: global_id, location ERROR: In /Source/ParaView/release/ParaView/VTK/Parallel/vtkSocketCommunicator.cxx, line 812 vtkSocketCommunicator (0x10d88b820): Could not receive tag. 55627 ERROR: In /Source/ParaView/release/ParaView/ParaViewCore/ServerManager/vtkSMSessionClient.cxx, line 774 vtkSMSessionClient (0x10c6bc1f0): Server failed to gather information. Thanks, Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Unreclaimed memory in coprocessing? (PV 3.12.0 and git-master)
Hi John,
What I observed on a Mac and a Linux box with 8 processor parallel
runs (around 400MB per process) were quite similar to your memory
profiling but with a bit larger growth rate of 1-2% and 2-3% per
coprocessing execution respectively (somehow it was bigger on Linux).
I'll see if I can do similar profiling.
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: "Biddiscombe, John A."
Subject: RE: [Paraview] Unreclaimed memory in coprocessing? (PV 3.12.0 and
git-master)
Date: Tue, 10 Jan 2012 14:51:41 +
> Takuya
>
> Running a test of coprocessing on a very small simulation using just 2 cores
> on the desktop, I am seeing what looks like a very small leak. Over about 30
> iterations, it’s of the order of 30MB, so might not be real (need to test on a
> bigger domain to see if it grows faster), but the trend looks credible. I’ll
> see if I can pinpoint where the loss is occurring.
>
> JB
>
> [cid]
>
>
>
> -Original Message-
> From: paraview-boun...@paraview.org [mailto:paraview-boun...@paraview.org] On
> Behalf Of Takuya OSHIMA
> Sent: 10 January 2012 15:11
> To: paraview@paraview.org
> Subject: Re: [Paraview] Unreclaimed memory in coprocessing? (PV 3.12.0 and
> git-master)
>
> Attached in the previous mail is a sample Python coprocessing script that
> exhibits the problem (written by the coprocessing script generator of
> git-master as of today).
>
> Takuya
>
> Takuya OSHIMA, Ph.D.
>
> Faculty of Engineering, Niigata University
>
> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
>
> From: Takuya OSHIMA
>
> Subject: Unreclaimed memory in coprocessing? (PV 3.12.0 and git-master)
>
> Date: Tue, 10 Jan 2012 23:08:21 +0900 (JST)
>
> > Hi,
>
> >
>
> > I am having a problem where the memory usage of my simulation program
>
> > which links with the PV coprocessing library grows until it gets
>
> > killed by the operating system.
>
> >
>
> > I have the following piece of code for triggering coprocessing and if
>
> > I watch the memory usage with the ps/top commands it grows only at the
>
> > timestep where this->Processor->CoProcess() is called. My simulation
>
> > program uses vtkImageData as underlying data structure so no data
>
> > format adaptation (that may involve allocating extra memory for data
>
> > copy) is performed.
>
> >
>
> > this->DataDescription->SetTimeData(this->TimeInfo->GetTimeValue(),
>
> > this->TimeInfo->GetTIter());
>
> > if (this->Processor->RequestDataDescription(this->DataDescription))
>
> > {
>
> > vtkCPInputDataDescription *idd
>
> > = this->DataDescription->GetInputDescriptionByName("input");
>
> > // obtain vtkImageData to coprocess from my simulation program
>
> > vtkImageData *grid = this->TimeInfo->GetGrid();
>
> > idd->SetWholeExtent(grid->GetWholeExtent());
>
> > idd->SetGrid(grid);
>
> > // now call the coprocessing library
>
> > this->Processor->CoProcess(this->DataDescription);
>
> > }
>
> >
>
> > Besides, the Apple's "leaks" tool shows no meaningful leaks which
>
> > makes me wonder if e.g. there are un-unregistered proxies than simply
>
> > unmatched New()/Delete() or new/delete pairs.
>
> >
>
> > The problem is same for PV 3.12.0 and the git master as of today.
>
> > Is anybody else having the problem? Any ideas?
>
> >
>
> > Thanks,
>
> > Takuya
>
> >
>
> > Takuya OSHIMA, Ph.D.
>
> > Faculty of Engineering, Niigata University
>
> > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
>
> ___
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/
> opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at: http://
> paraview.org/Wiki/ParaView
>
> Follow this link to subscribe/unsubscribe:
>
> http://www.paraview.org/mailman/listinfo/paraview
>
> *
>
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Unreclaimed memory in coprocessing? (PV 3.12.0 and git-master)
Attached in the previous mail is a sample Python coprocessing script
that exhibits the problem (written by the coprocessing script
generator of git-master as of today).
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Takuya OSHIMA
Subject: Unreclaimed memory in coprocessing? (PV 3.12.0 and git-master)
Date: Tue, 10 Jan 2012 23:08:21 +0900 (JST)
> Hi,
>
> I am having a problem where the memory usage of my simulation program
> which links with the PV coprocessing library grows until it gets
> killed by the operating system.
>
> I have the following piece of code for triggering coprocessing and if
> I watch the memory usage with the ps/top commands it grows only at the
> timestep where this->Processor->CoProcess() is called. My simulation
> program uses vtkImageData as underlying data structure so no data
> format adaptation (that may involve allocating extra memory for data
> copy) is performed.
>
> this->DataDescription->SetTimeData(this->TimeInfo->GetTimeValue(),
> this->TimeInfo->GetTIter());
> if (this->Processor->RequestDataDescription(this->DataDescription))
> {
> vtkCPInputDataDescription *idd
> = this->DataDescription->GetInputDescriptionByName("input");
> // obtain vtkImageData to coprocess from my simulation program
> vtkImageData *grid = this->TimeInfo->GetGrid();
> idd->SetWholeExtent(grid->GetWholeExtent());
> idd->SetGrid(grid);
> // now call the coprocessing library
> this->Processor->CoProcess(this->DataDescription);
> }
>
> Besides, the Apple's "leaks" tool shows no meaningful leaks which
> makes me wonder if e.g. there are un-unregistered proxies than simply
> unmatched New()/Delete() or new/delete pairs.
>
> The problem is same for PV 3.12.0 and the git master as of today.
> Is anybody else having the problem? Any ideas?
>
> Thanks,
> Takuya
>
> Takuya OSHIMA, Ph.D.
> Faculty of Engineering, Niigata University
> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Unreclaimed memory in coprocessing? (PV 3.12.0 and git-master)
Hi,
I am having a problem where the memory usage of my simulation program
which links with the PV coprocessing library grows until it gets
killed by the operating system.
I have the following piece of code for triggering coprocessing and if
I watch the memory usage with the ps/top commands it grows only at the
timestep where this->Processor->CoProcess() is called. My simulation
program uses vtkImageData as underlying data structure so no data
format adaptation (that may involve allocating extra memory for data
copy) is performed.
this->DataDescription->SetTimeData(this->TimeInfo->GetTimeValue(),
this->TimeInfo->GetTIter());
if (this->Processor->RequestDataDescription(this->DataDescription))
{
vtkCPInputDataDescription *idd
= this->DataDescription->GetInputDescriptionByName("input");
// obtain vtkImageData to coprocess from my simulation program
vtkImageData *grid = this->TimeInfo->GetGrid();
idd->SetWholeExtent(grid->GetWholeExtent());
idd->SetGrid(grid);
// now call the coprocessing library
this->Processor->CoProcess(this->DataDescription);
}
Besides, the Apple's "leaks" tool shows no meaningful leaks which
makes me wonder if e.g. there are un-unregistered proxies than simply
unmatched New()/Delete() or new/delete pairs.
The problem is same for PV 3.12.0 and the git master as of today.
Is anybody else having the problem? Any ideas?
Thanks,
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
surfaceRep.py
Description: Binary data
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] PV 3.12.0 coprocessing problem when using multiple filters
Thanks for the fix Andy. I'll test as soon as I can.
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Andy Bauer
Subject: Re: [Paraview] PV 3.12.0 coprocessing problem when using multiple
filters
Date: Tue, 20 Dec 2011 15:45:10 -0500
> Hi Takuya,
>
> This issue has been fixed. We did a slightly different fix than yours so
> that we could avoid the MPI communication. The commit SHA is
> 135ed11151e547ff54fbb373d686898e40cc3dec.
>
> Thanks for the bug report.
>
> Andy
>
> On Tue, Dec 6, 2011 at 4:05 PM, Andy Bauer wrote:
>
>> Hi Takuya,
>>
>> Sorry for the slow response but I finally did verify this problem. Your
>> change also fixes it. I'm not that familiar with vtkPVSessionCore so I'll
>> need to talk to some other people to make sure that it's the proper fix and
>> if not, what is the proper fix. I'll email again when it's been fixed.
>>
>> Thanks,
>> Andy
>>
>>
>> On Mon, Nov 14, 2011 at 9:32 AM, Takuya OSHIMA > > wrote:
>>
>>> Hi Andy,
>>>
>>> I may be wrong but I have a feeling that the collected data
>>> information in process 0 should be redistributed to other processes
>>> since adding a print statement for
>>> Slice1.GetDataInformation().GetNumberOfPoints() prints for each
>>> process the number of points expected from the hierarchical collection
>>> mechanism of vtkPVSessionCore::CollectInformation().
>>>
>>> I am not sure if this is the right place and thing but if I add the
>>> following code to vtkPVSessionCore::CollectInformation() the slice
>>> filter works exactly as you stated ("it just needs to go through one
>>> of the process's grid domain such that the global number of points and
>>> cells is greater than 0").
>>>
>>> Takuya OSHIMA, Ph.D.
>>> Faculty of Engineering, Niigata University
>>> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
>>>
>>> ---
>>> ParaView-3.12.0/ParaViewCore/ServerImplementation/vtkPVSessionCore.cxx
>>> 2011-11-09 05:56:18.0 +0900
>>> +++
>>> ParaView-3.12.0.new/ParaViewCore/ServerImplementation/vtkPVSessionCore.cxx
>>> 2011-11-14 23:17:32.0 +0900
>>> @@ -825,6 +825,33 @@
>>> controller->Send(&len, 1, parent, ROOT_SATELLITE_INFO_TAG);
>>> }
>>> }
>>> +
>>> + if (this->SymmetricMPIMode)
>>> +{
>>> +if (myid == 0)
>>> + {
>>> + vtkClientServerStream css;
>>> + info->CopyToStream(&css);
>>> + const unsigned char* data;
>>> + size_t length;
>>> + css.GetData(&data, &length);
>>> + int len = static_cast(length);
>>> + controller->Broadcast(&len, 1, 0);
>>> + controller->Broadcast(const_cast(data), len, 0);
>>> + }
>>> +else
>>> + {
>>> + int len;
>>> + controller->Broadcast(&len, 1, 0);
>>> + unsigned char *data = new unsigned char[len];
>>> + controller->Broadcast(data, len, 0);
>>> + vtkClientServerStream stream;
>>> + stream.SetData(data, len);
>>> + info->CopyFromStream(&stream);
>>> + delete [] data;
>>> + }
>>> +}
>>> +
>>> return true;
>>> }
>>>
>>>
>>> //
>>>
>>> From: Andy Bauer
>>> Subject: Re: [Paraview] PV 3.12.0 coprocessing problem when using
>>> multiple filters
>>> Date: Sun, 13 Nov 2011 14:18:14 -0500
>>>
>>> > I hope that's not the case that the slice has to go through each
>>> process's
>>> > grid domain. I think it just needs to go through one of the process's
>>> grid
>>> > domain such that the global number of points and cells is greater than
>>> 0.
>>> > I will check on this though.
>>> >
>>> > Andy
>>> >
>>> > On Sat, Nov 12, 2011 at 3:57 AM, Takuya OSHIMA
>>> > wrote:
>>> >
>>> >> Thanks for all the input guys. Indeed Pat's tip did the trick, in my
>>> case:
>>> >>
>>> >>if Slice1.GetDataInformation().GetNumberOfPoints():
>>> >>DataRepresentation2.ColorArr
Re: [Paraview] PV 3.12.0 coprocessing problem when using multiple filters
Thanks Andy.
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Andy Bauer
Subject: Re: [Paraview] PV 3.12.0 coprocessing problem when using multiple
filters
Date: Tue, 6 Dec 2011 16:05:57 -0500
> * Hi Takuya,
>
> Sorry for the slow response but I finally did verify this problem. Your
> change also fixes it. I'm not that familiar with vtkPVSessionCore so I'll
> need to talk to some other people to make sure that it's the proper fix and if
> not, what is the proper fix. I'll email again when it's been fixed.
>
> Thanks,
> Andy
>
> On Mon, Nov 14, 2011 at 9:32 AM, Takuya OSHIMA
> wrote:
>
> Hi Andy,
>
> I may be wrong but I have a feeling that the collected data
> information in process 0 should be redistributed to other processes
> since adding a print statement for
> Slice1.GetDataInformation().GetNumberOfPoints() prints for each
> process the number of points expected from the hierarchical collection
> mechanism of vtkPVSessionCore::CollectInformation().
>
> I am not sure if this is the right place and thing but if I add the
> following code to vtkPVSessionCore::CollectInformation() the slice
> filter works exactly as you stated ("it just needs to go through one
> of the process's grid domain such that the global number of points and
> cells is greater than 0").
>
> Takuya OSHIMA, Ph.D.
> Faculty of Engineering, Niigata University
> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
>
> --- ParaView-3.12.0/ParaViewCore/ServerImplementation/vtkPVSessionCore.cxx
> 2011-11-09 05:56:18.0 +0900
> +++ ParaView-3.12.0.new/ParaViewCore/ServerImplementation/
> vtkPVSessionCore.cxx 2011-11-14 23:17:32.0 +0900
> @@ -825,6 +825,33 @@
> controller->Send(&len, 1, parent, ROOT_SATELLITE_INFO_TAG);
> }
> }
> +
> + if (this->SymmetricMPIMode)
> + {
> + if (myid == 0)
> + {
> + vtkClientServerStream css;
> + info->CopyToStream(&css);
> + const unsigned char* data;
> + size_t length;
> + css.GetData(&data, &length);
> + int len = static_cast(length);
> + controller->Broadcast(&len, 1, 0);
> + controller->Broadcast(const_cast(data), len, 0);
> + }
> + else
> + {
> + int len;
> + controller->Broadcast(&len, 1, 0);
> + unsigned char *data = new unsigned char[len];
> + controller->Broadcast(data, len, 0);
> + vtkClientServerStream stream;
> + stream.SetData(data, len);
> + info->CopyFromStream(&stream);
> + delete [] data;
> + }
> + }
> +
> return true;
> }
> //
>
>
>
> From: Andy Bauer
> Subject: Re: [Paraview] PV 3.12.0 coprocessing problem when using multiple
> filters
> Date: Sun, 13 Nov 2011 14:18:14 -0500
>
> > I hope that's not the case that the slice has to go through each
> process's
> > grid domain. I think it just needs to go through one of the process's
> grid
> > domain such that the global number of points and cells is greater than
> 0.
> > I will check on this though.
> >
> > Andy
> >
> > On Sat, Nov 12, 2011 at 3:57 AM, Takuya OSHIMA
> > wrote:
> >
> >> Thanks for all the input guys. Indeed Pat's tip did the trick, in my
> case:
> >>
> >> if Slice1.GetDataInformation().GetNumberOfPoints():
> >> DataRepresentation2.ColorArrayName = 'p'
> >>
> >> I am still new to coprocessing so I am not getting things right but
> >> here is my deduction: I am running my simulation code in parallel with
> >> 8 processes with one cell thickness of ghost layers. Slice1 does
> >> intersect the domain, but not all of parallel decomposed
> >> subdomains. Hence the error is issued for the processes that have no
> >> slice data.
> >>
> >> Meanwhile I noticed that the slice in oneSlice.py just have happened
> >> to locate exactly on interprocessor boundaries and intersected all of
> >> parallel decomposed subdomains at the ghost layers. That explains why
> >> the
Re: [Paraview] import paraview.vtk.geovis imports the common kit?
No one stated it is intended so is now filed. http://paraview.org/Bug/view.php?id=12739 Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Takuya OSHIMA Subject: [Paraview] import paraview.vtk.geovis imports the common kit? Date: Thu, 10 Nov 2011 19:11:46 +0900 (JST) > Hi, > > Playing with pvpython 3.12.0 I just noticed that "import > paraview.vtk.geovis" imports the vtkCommon kit. Is this intended? > > Generator> pvpython > Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) > [GCC 4.2.1 (Apple Inc. build 5646)] on darwin > Type "help", "copyright", "credits" or "license" for more information. >>>> import paraview.vtk.geovis >>>> dir(paraview.vtk.geovis) > ['VTK_ARIAL', 'VTK_ARRAY_DATA', 'VTK_BACKGROUND_LOCATION', 'VTK_BIT', > 'VTK_BIT_MAX', 'VTK_BIT_MIN', 'VTK_BUILD_SHARED_LIBS', 'VTK_BUILD_VERSION', > 'VTK_CHAR', 'V > . > ..... > iLi2EE', 'vtkVector_IiLi3EE', 'vtkVector_IiLi4EE', 'vtkVersion', > 'vtkVoidArray', 'vtkWarpTransform', 'vtkWindow', 'vtkWindowLevelLookupTable', > 'vtkXMLDataElement', 'vtkXMLFileOutputWindow'] > > Takuya OSHIMA, Ph.D. > Faculty of Engineering, Niigata University > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] PV 3.12.0 coprocessing problem when using multiple filters
Hi Andy,
I may be wrong but I have a feeling that the collected data
information in process 0 should be redistributed to other processes
since adding a print statement for
Slice1.GetDataInformation().GetNumberOfPoints() prints for each
process the number of points expected from the hierarchical collection
mechanism of vtkPVSessionCore::CollectInformation().
I am not sure if this is the right place and thing but if I add the
following code to vtkPVSessionCore::CollectInformation() the slice
filter works exactly as you stated ("it just needs to go through one
of the process's grid domain such that the global number of points and
cells is greater than 0").
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
--- ParaView-3.12.0/ParaViewCore/ServerImplementation/vtkPVSessionCore.cxx
2011-11-09 05:56:18.0 +0900
+++ ParaView-3.12.0.new/ParaViewCore/ServerImplementation/vtkPVSessionCore.cxx
2011-11-14 23:17:32.0 +0900
@@ -825,6 +825,33 @@
controller->Send(&len, 1, parent, ROOT_SATELLITE_INFO_TAG);
}
}
+
+ if (this->SymmetricMPIMode)
+{
+if (myid == 0)
+ {
+ vtkClientServerStream css;
+ info->CopyToStream(&css);
+ const unsigned char* data;
+ size_t length;
+ css.GetData(&data, &length);
+ int len = static_cast(length);
+ controller->Broadcast(&len, 1, 0);
+ controller->Broadcast(const_cast(data), len, 0);
+ }
+else
+ {
+ int len;
+ controller->Broadcast(&len, 1, 0);
+ unsigned char *data = new unsigned char[len];
+ controller->Broadcast(data, len, 0);
+ vtkClientServerStream stream;
+ stream.SetData(data, len);
+ info->CopyFromStream(&stream);
+ delete [] data;
+ }
+}
+
return true;
}
//
From: Andy Bauer
Subject: Re: [Paraview] PV 3.12.0 coprocessing problem when using multiple
filters
Date: Sun, 13 Nov 2011 14:18:14 -0500
> I hope that's not the case that the slice has to go through each process's
> grid domain. I think it just needs to go through one of the process's grid
> domain such that the global number of points and cells is greater than 0.
> I will check on this though.
>
> Andy
>
> On Sat, Nov 12, 2011 at 3:57 AM, Takuya OSHIMA
> wrote:
>
>> Thanks for all the input guys. Indeed Pat's tip did the trick, in my case:
>>
>>if Slice1.GetDataInformation().GetNumberOfPoints():
>>DataRepresentation2.ColorArrayName = 'p'
>>
>> I am still new to coprocessing so I am not getting things right but
>> here is my deduction: I am running my simulation code in parallel with
>> 8 processes with one cell thickness of ghost layers. Slice1 does
>> intersect the domain, but not all of parallel decomposed
>> subdomains. Hence the error is issued for the processes that have no
>> slice data.
>>
>> Meanwhile I noticed that the slice in oneSlice.py just have happened
>> to locate exactly on interprocessor boundaries and intersected all of
>> parallel decomposed subdomains at the ghost layers. That explains why
>> the script worked without error.
>>
>> Takuya OSHIMA, Ph.D.
>> Faculty of Engineering, Niigata University
>> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
>>
>> From: pat marion
>> Subject: Re: [Paraview] PV 3.12.0 coprocessing problem when using multiple
>> filters
>> Date: Fri, 11 Nov 2011 20:08:54 -0500
>>
>> > That's right, if the output has no point or cell data, then assigning the
>> > ColorArrayName property will throw an exception. It's kind of an
>> annoying
>> > behavior. So I'll work around this by writing code such as:
>> >
>> > if mySlice.GetDataInformation().GetNumberOfPoints():
>> > rep.ColorArrayName='p'
>> >
>> >
>> > Pat
>> >
>> > On Fri, Nov 11, 2011 at 12:39 PM, Andy Bauer
>> wrote:
>> >
>> >> Another thing to check is if there are any cells in the output from the
>> >> second slice filter. In the ParaView GUI, i started with the mandelbrot
>> >> source and then created a slice filter that didn't intersect the domain.
>> >> After that there wasn't any point or cell data in the output.
>> >>
>> >> Andy
>> >>
>> >>
>> >> 2011/11/11 Takuya OSHIMA
>> >>
>> >>> I'm not in a place where I can test the line 323 modification right
>> >>> now but the cell array p i
Re: [Paraview] PV 3.12.0 coprocessing problem when using multiple filters
Thanks for all the input guys. Indeed Pat's tip did the trick, in my case:
if Slice1.GetDataInformation().GetNumberOfPoints():
DataRepresentation2.ColorArrayName = 'p'
I am still new to coprocessing so I am not getting things right but
here is my deduction: I am running my simulation code in parallel with
8 processes with one cell thickness of ghost layers. Slice1 does
intersect the domain, but not all of parallel decomposed
subdomains. Hence the error is issued for the processes that have no
slice data.
Meanwhile I noticed that the slice in oneSlice.py just have happened
to locate exactly on interprocessor boundaries and intersected all of
parallel decomposed subdomains at the ghost layers. That explains why
the script worked without error.
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: pat marion
Subject: Re: [Paraview] PV 3.12.0 coprocessing problem when using multiple
filters
Date: Fri, 11 Nov 2011 20:08:54 -0500
> That's right, if the output has no point or cell data, then assigning the
> ColorArrayName property will throw an exception. It's kind of an annoying
> behavior. So I'll work around this by writing code such as:
>
> if mySlice.GetDataInformation().GetNumberOfPoints():
> rep.ColorArrayName='p'
>
>
> Pat
>
> On Fri, Nov 11, 2011 at 12:39 PM, Andy Bauer wrote:
>
>> Another thing to check is if there are any cells in the output from the
>> second slice filter. In the ParaView GUI, i started with the mandelbrot
>> source and then created a slice filter that didn't intersect the domain.
>> After that there wasn't any point or cell data in the output.
>>
>> Andy
>>
>>
>> 2011/11/11 Takuya OSHIMA
>>
>>> I'm not in a place where I can test the line 323 modification right
>>> now but the cell array p is present. Please note that oneSlice.py
>>> which also colors by cell p works.
>>>
>>> Takuya OSHIMA, Ph.D.
>>> Faculty of Engineering, Niigata University
>>> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
>>>
>>> From: Utkarsh Ayachit
>>> Subject: Re: [Paraview] PV 3.12.0 coprocessing problem when using
>>> multiple filters
>>> Date: Fri, 11 Nov 2011 09:16:18 -0500
>>>
>>> > Is the array "p" not present when you're coprocessnig? Try taking out
>>> > line 323 which sets the array "p" as the array to color with.
>>> >
>>> > Utkarsh
>>> >
>>> > On Fri, Nov 11, 2011 at 9:08 AM, Takuya OSHIMA
>>> > wrote:
>>> > > Hi,
>>> > >
>>> > > I am trying to explore the coprocessing capability of PV 3.12.0. When
>>> > > I create a pipeline with a single slice filter within the PV GUI,
>>> > > export the Python state file by the coprocessing plugin and run the
>>> > > script as the coprocessing pipleline in my simulation code, it works
>>> > > fine.
>>> > >
>>> > > However if I create a pipeline with two or more filters my simulation
>>> > > code issues an error from the coprocessing library (the error message
>>> > > is for the case of two slice filters):
>>> > >
>>> > > Traceback (most recent call last):
>>> > > File "", line 2, in
>>> > > File "/Users/ohshima/shindoriTest/twoSlices.py", line 323, in
>>> DoCoProcessing
>>> > >DataRepresentation2.ColorArrayName = 'p'
>>> > > File
>>> "/Volumes/RAID0data/paraview/3.12/build/Utilities/VTKPythonWrapping/site-packages/paraview/servermanager.py",
>>> line 212, in __setattr__
>>> > >setter(self, value)
>>> > > File
>>> "/Volumes/RAID0data/paraview/3.12/build/Utilities/VTKPythonWrapping/site-packages/paraview/servermanager.py",
>>> line 2276, in setProperty
>>> > >return self.SetPropertyWithName(propName, value)
>>> > > File
>>> "/Volumes/RAID0data/paraview/3.12/build/Utilities/VTKPythonWrapping/site-packages/paraview/servermanager.py",
>>> line 267, in SetPropertyWithName
>>> > >prop.SetData(arg)
>>> > > File
>>> "/Volumes/RAID0data/paraview/3.12/build/Utilities/VTKPythonWrapping/site-packages/paraview/servermanager.py",
>>> line 695, in SetData
>>> > >raise ValueError("Could not locate array %s in the input." % arr)
Re: [Paraview] PV 3.12.0 coprocessing problem when using multiple filters
I'm not in a place where I can test the line 323 modification right
now but the cell array p is present. Please note that oneSlice.py
which also colors by cell p works.
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Utkarsh Ayachit
Subject: Re: [Paraview] PV 3.12.0 coprocessing problem when using multiple
filters
Date: Fri, 11 Nov 2011 09:16:18 -0500
> Is the array "p" not present when you're coprocessnig? Try taking out
> line 323 which sets the array "p" as the array to color with.
>
> Utkarsh
>
> On Fri, Nov 11, 2011 at 9:08 AM, Takuya OSHIMA
> wrote:
> > Hi,
> >
> > I am trying to explore the coprocessing capability of PV 3.12.0. When
> > I create a pipeline with a single slice filter within the PV GUI,
> > export the Python state file by the coprocessing plugin and run the
> > script as the coprocessing pipleline in my simulation code, it works
> > fine.
> >
> > However if I create a pipeline with two or more filters my simulation
> > code issues an error from the coprocessing library (the error message
> > is for the case of two slice filters):
> >
> > Traceback (most recent call last):
> > File "", line 2, in
> > File "/Users/ohshima/shindoriTest/twoSlices.py", line 323, in
> > DoCoProcessing
> > DataRepresentation2.ColorArrayName = 'p'
> > File
> > "/Volumes/RAID0data/paraview/3.12/build/Utilities/VTKPythonWrapping/site-packages/paraview/servermanager.py",
> > line 212, in __setattr__
> > setter(self, value)
> > File
> > "/Volumes/RAID0data/paraview/3.12/build/Utilities/VTKPythonWrapping/site-packages/paraview/servermanager.py",
> > line 2276, in setProperty
> > return self.SetPropertyWithName(propName, value)
> > File
> > "/Volumes/RAID0data/paraview/3.12/build/Utilities/VTKPythonWrapping/site-packages/paraview/servermanager.py",
> > line 267, in SetPropertyWithName
> > prop.SetData(arg)
> > File
> > "/Volumes/RAID0data/paraview/3.12/build/Utilities/VTKPythonWrapping/site-packages/paraview/servermanager.py",
> > line 695, in SetData
> > raise ValueError("Could not locate array %s in the input." % arr)
> > ValueError: Could not locate array p in the input.
> >
> > The problem is same for Mac OS X 10.6 and RHEL 5.1 64bit. I attach the
> > scripts oneSlice.py (which works) and twoSlices.py (which does not
> > work). Can anybody shed light on the problem?
> >
> > Takuya
> >
> > Takuya OSHIMA, Ph.D.
> > Faculty of Engineering, Niigata University
> > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
> >
> > ___
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the ParaView Wiki at:
> > http://paraview.org/Wiki/ParaView
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.paraview.org/mailman/listinfo/paraview
> >
> >
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
[Paraview] import paraview.vtk.geovis imports the common kit?
Hi, Playing with pvpython 3.12.0 I just noticed that "import paraview.vtk.geovis" imports the vtkCommon kit. Is this intended? Generator> pvpython Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import paraview.vtk.geovis >>> dir(paraview.vtk.geovis) ['VTK_ARIAL', 'VTK_ARRAY_DATA', 'VTK_BACKGROUND_LOCATION', 'VTK_BIT', 'VTK_BIT_MAX', 'VTK_BIT_MIN', 'VTK_BUILD_SHARED_LIBS', 'VTK_BUILD_VERSION', 'VTK_CHAR', 'V . . iLi2EE', 'vtkVector_IiLi3EE', 'vtkVector_IiLi4EE', 'vtkVersion', 'vtkVoidArray', 'vtkWarpTransform', 'vtkWindow', 'vtkWindowLevelLookupTable', 'vtkXMLDataElement', 'vtkXMLFileOutputWindow'] Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] ANN: ParaView 3.12.0 RC-2 available for download
Thanks! Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: David Partyka Subject: Re: [Paraview] ANN: ParaView 3.12.0 RC-2 available for download Date: Mon, 7 Nov 2011 08:16:33 -0500 > Merged. > > 2011/11/5 Takuya OSHIMA > >> Any chance this gets fixed in the final release of 3.12? >> >> Just to make sure I've filed as a bug with the proposed fix (which you >> can find in this mail too): >> http://paraview.org/Bug/view.php?id=12710 >> >> Takuya >> >> Takuya OSHIMA, Ph.D. >> Faculty of Engineering, Niigata University >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> >> From: David Partyka >> Subject: Re: [Paraview] ANN: ParaView 3.12.0 RC-2 available for download >> Date: Sun, 9 Oct 2011 11:37:16 -0400 >> >> > Will take a look. for 3.12. >> > >> > 2011/10/9 Takuya OSHIMA >> > >> >> With Paul's comment I was able to reproduce the problem and did find >> >> what were wrong. One is a trivial bug that forced the filter to try to >> >> calculate normals for all cell types and another is lack of skipping >> >> everything when input array to process is not found (e.g. when a >> >> partial array in a multiblock dataset is specified). >> >> >> >> Please find the attachment for the fix. Like Paul and Fabian I'd like >> >> to see this fixed in the 3.12 release. >> >> >> >> Takuya >> >> >> >> Takuya OSHIMA, Ph.D. >> >> Faculty of Engineering, Niigata University >> >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> >> >> >> From: Takuya OSHIMA >> >> Subject: Re: [Paraview] ANN: ParaView 3.12.0 RC-2 available for download >> >> Date: Sun, 09 Oct 2011 02:30:10 +0900 (東京 (標準時)) >> >> >> >> > Hi Fabian, >> >> > >> >> > Paul probably meant lines created by slicing patches (in OpenFOAM >> >> > term). Sounds like a bug in Surface Vectors than one in the OpenFOAM >> >> > reader anyway... >> >> > >> >> > Takuya >> >> > >> >> > Takuya OSHIMA, Ph.D. >> >> > Faculty of Engineering, Niigata University >> >> > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> >> > >> >> > From: Fabian Braennstroem >> >> > Subject: Re: ANN: ParaView 3.12.0 RC-2 available for download >> >> > Date: Sat, 08 Oct 2011 13:35:50 +0200 >> >> > >> >> >> Hello to you both, >> >> >> >> >> >> I am not sure, what you mean with lines in my input, but yes I did >> cut >> >> >> (slice) through a openfoam domain... now I am not able to reproduce >> it; >> >> >> though as Paul mentioned, this error was there earlier as well. I >> check >> >> >> again. >> >> >> >> >> >> Best Regards >> >> >> Fabian >> >> >> >> >> >> On 10/07/2011 11:49 AM, Paul Edwards wrote: >> >> >> > Hi, >> >> >> > >> >> >> > I noticed a bug with "Surface Vectors" before - if you have any >> lines >> >> in >> >> >> > your input (i.e. you cut through a volume and surfaces) then it >> will >> >> >> > crash. Is this the problem you are having Fabian? >> >> >> > >> >> >> > Regards, >> >> >> > Paul >> >> >> > >> >> >> > On 7 October 2011 07:14, Takuya OSHIMA > >> >> > <mailto:osh...@eng.niigata-u.ac.jp>> wrote: >> >> >> > >> >> >> > Hi Fabian, I cannot reproduce (OS X 64bit / Ubuntu 10.04 >> 64bit). >> >> Can >> >> >> > you isolate whether it is specific to OpeFOAM data or not? If >> it >> >> is, >> >> >> > can you share a test case? >> >> >> > >> >> >> > Takuya >> >> >> > >> >> >> > Takuya OSHIMA, Ph.D. >> >> >> > Faculty of Engineering, Niigata University >> >> >> > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> >> >> > >> >> >> > From: Fabian Bra
Re: [Paraview] 3.12.0-RC3: could not open source file "GL/gl.h" compiling vtkIceTSynchronizedRenderers.cxx
Yes /nfs/v14/v14006/opt/Mesa-7.11/include/GL contains gl.h:
ls -al /nfs/v14/v14006/opt/Mesa-7.11/include/GL
total 1088
drwxr-xr-x 2 v14006 v14 4096 Oct 25 20:33 .
drwxr-xr-x 3 v14006 v14 4096 Oct 25 17:15 ..
-rw-r--r-- 1 v14006 v14 639607 Oct 25 20:33 glext.h
-rw-r--r-- 1 v14006 v14 4376 Oct 25 20:33 glfbdev.h
-rw-r--r-- 1 v14006 v14 84670 Oct 25 20:33 gl.h
-rw-r--r-- 1 v14006 v14 128943 Oct 25 20:33 gl_mangle.h
-rw-r--r-- 1 v14006 v14 17255 Oct 25 20:33 glu.h
-rw-r--r-- 1 v14006 v14 3315 Oct 25 20:33 glu_mangle.h
-rw-r--r-- 1 v14006 v14 43887 Oct 25 20:33 glxext.h
-rw-r--r-- 1 v14006 v14 17170 Oct 25 20:33 glx.h
-rw-r--r-- 1 v14006 v14 3463 Oct 25 20:33 glx_mangle.h
-rw-r--r-- 1 v14006 v14 4770 Oct 25 20:33 mesa_wgl.h
-rw-r--r-- 1 v14006 v14 8595 Oct 25 20:33 osmesa.h
-rw-r--r-- 1 v14006 v14 51274 Oct 25 20:33 vms_x_fix.h
-rw-r--r-- 1 v14006 v14 41377 Oct 25 20:33 wglext.h
-rw-r--r-- 1 v14006 v14 4468 Oct 25 20:33 wmesa.h
Indeed, if I copy lines from PV 3.10.1 CMakeLists.txt
IF(APPLE)
IF(VTK_USE_X OR VTK_OPENGL_HAS_OSMESA)
INCLUDE_DIRECTORIES(${OPENGL_INCLUDE_DIR})
ENDIF(VTK_USE_X OR VTK_OPENGL_HAS_OSMESA)
ELSE(APPLE)
INCLUDE_DIRECTORIES(${OPENGL_INCLUDE_DIR})
ENDIF(APPLE)
and paste it to inside IF (PARAVIEW_USE_ICE_T AND VTK_USE_MPI)... of
ParaViewCore/ClientServerCore/CMakeLists.txt the error is fixed and
the produced pvserver runs fine (but I am unsure about
IF(APPLE)... since I only tested on Linux).
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: David Partyka
Subject: Re: [Paraview] 3.12.0-RC3: could not open source file "GL/gl.h"
compiling vtkIceTSynchronizedRenderers.cxx
Date: Mon, 7 Nov 2011 07:10:49 -0500
> Can you verify /nfs/v14/v14006/opt/Mesa-7.11/include contains "GL/gl.h"? It
> should if mesa built and installed correctly.
>
> On Mon, Nov 7, 2011 at 6:22 AM, Takuya OSHIMA
> wrote:
>
>> Hi Kevin,
>>
>> Thaks for your comment. Here is my full CMake configuration. On thing
>> that may be noticed is that our cluster does not have GL/gl.h under
>> /usr/include (unlike some of modern Linux systems).
>>
>> cmake ../ParaView-3.12.0-RC3 \
>>-DCMAKE_CXX_COMPILER=/opt/intel/Compiler/11.0/074/bin/intel64/icpc \
>>-DCMAKE_C_COMPILER=/opt/intel/Compiler/11.0/074/bin/intel64/icc \
>>-DCMAKE_INSTALL_PREFIX=/nfs/v14/v14006/opt/ParaView-3.12.0-RC3 \
>>-DCMAKE_BUILD_TYPE=Release \
>>-DBUILD_SHARED_LIBS=ON \
>>-DBUILD_TESTING=OFF \
>>-DPARAVIEW_BUILD_QT_GUI=OFF \
>>-DPARAVIEW_ENABLE_PYTHON=ON \
>>-DPARAVIEW_USE_MPI=ON \
>>-DMPI_CXX_INCLUDE_PATH=/opt/itc/mpi/mpich-mx-intel11-shared/include \
>>-DENABLE_MPI4PY=OFF \
>>-DPARAVIEW_ENABLE_COPROCESSING=ON \
>>-DVTK_OPENGL_HAS_OSMESA=ON \
>>-DVTK_USE_X=OFF \
>>-DOPENGL_gl_LIBRARY= \
>>-DOPENGL_glu_LIBRARY=/nfs/v14/v14006/opt/Mesa-7.11/lib/libGLU.so \
>>-DOPENGL_INCLUDE_DIR=/nfs/v14/v14006/opt/Mesa-7.11/include \
>>-DOSMESA_INCLUDE_DIR=/nfs/v14/v14006/opt/Mesa-7.11/include \
>>-DOSMESA_LIBRARY=/nfs/v14/v14006/opt/Mesa-7.11/lib/libOSMesa32.so \
>>-DVTK_USE_OFFSCREEN=ON
>>
>> Takuya OSHIMA, Ph.D.
>> Faculty of Engineering, Niigata University
>> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
>>
>> From: "Kevin H. Hobbs"
>> Subject: Re: [Paraview] 3.12.0-RC3: could not open source file "GL/gl.h"
>> compiling vtkIceTSynchronizedRenderers.cxx
>> Date: Mon, 07 Nov 2011 05:36:07 -0500
>>
>> > On 11/05/2011 06:13 AM, Takuya OSHIMA wrote:
>> >> Hi,
>> >>
>> >> I tried to build the 3.12.0 RC3 with MesaLib-7.11 (OSMesa) on a RHEL
>> >> 5.1 headless cluster and got an error:
>> >>
>> >>
>> /nfs/work2/v14/v14006/src/ParaView-3.12.0-RC3/VTK/Rendering/vtkOpenGL.h(26):
>> catastrophic error: could not open source file "GL/gl.h"
>> >> # include // Include OpenGL API.
>> >> ^
>> >>
>> >> compilation aborted for
>> /nfs/work2/v14/v14006/src/ParaView-3.12.0-RC3/ParaViewCore/ClientServerCore/vtkIceTSynchronizedRenderers.cxx
>> (code 4)
>> >> make[2]: ***
>> [ParaViewCore/ClientServerCore/CMakeFiles/vtkPVClientServerCore.dir/vtkIceTSynchronizedRenderers.cxx.o]
>> Error 4
>> >>
>> >> Looking into ParaViewCore/ClientServerCore/CMakeLists.txt I found
>> >> nothing that specifies ${OPENGL_INCLUDE_DIR} as opposed to the old
>> >> ParaView-3.10.1/Servers/Filters/CMakeLists.txt (where
>> >> vtkIceTSynchronizedRenderers.
Re: [Paraview] 3.12.0-RC3: could not open source file "GL/gl.h" compiling vtkIceTSynchronizedRenderers.cxx
Hi Kevin,
Thaks for your comment. Here is my full CMake configuration. On thing
that may be noticed is that our cluster does not have GL/gl.h under
/usr/include (unlike some of modern Linux systems).
cmake ../ParaView-3.12.0-RC3 \
-DCMAKE_CXX_COMPILER=/opt/intel/Compiler/11.0/074/bin/intel64/icpc \
-DCMAKE_C_COMPILER=/opt/intel/Compiler/11.0/074/bin/intel64/icc \
-DCMAKE_INSTALL_PREFIX=/nfs/v14/v14006/opt/ParaView-3.12.0-RC3 \
-DCMAKE_BUILD_TYPE=Release \
-DBUILD_SHARED_LIBS=ON \
-DBUILD_TESTING=OFF \
-DPARAVIEW_BUILD_QT_GUI=OFF \
-DPARAVIEW_ENABLE_PYTHON=ON \
-DPARAVIEW_USE_MPI=ON \
-DMPI_CXX_INCLUDE_PATH=/opt/itc/mpi/mpich-mx-intel11-shared/include \
-DENABLE_MPI4PY=OFF \
-DPARAVIEW_ENABLE_COPROCESSING=ON \
-DVTK_OPENGL_HAS_OSMESA=ON \
-DVTK_USE_X=OFF \
-DOPENGL_gl_LIBRARY= \
-DOPENGL_glu_LIBRARY=/nfs/v14/v14006/opt/Mesa-7.11/lib/libGLU.so \
-DOPENGL_INCLUDE_DIR=/nfs/v14/v14006/opt/Mesa-7.11/include \
-DOSMESA_INCLUDE_DIR=/nfs/v14/v14006/opt/Mesa-7.11/include \
-DOSMESA_LIBRARY=/nfs/v14/v14006/opt/Mesa-7.11/lib/libOSMesa32.so \
-DVTK_USE_OFFSCREEN=ON
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: "Kevin H. Hobbs"
Subject: Re: [Paraview] 3.12.0-RC3: could not open source file "GL/gl.h"
compiling vtkIceTSynchronizedRenderers.cxx
Date: Mon, 07 Nov 2011 05:36:07 -0500
> On 11/05/2011 06:13 AM, Takuya OSHIMA wrote:
>> Hi,
>>
>> I tried to build the 3.12.0 RC3 with MesaLib-7.11 (OSMesa) on a RHEL
>> 5.1 headless cluster and got an error:
>>
>> /nfs/work2/v14/v14006/src/ParaView-3.12.0-RC3/VTK/Rendering/vtkOpenGL.h(26):
>> catastrophic error: could not open source file "GL/gl.h"
>> # include // Include OpenGL API.
>> ^
>>
>> compilation aborted for
>> /nfs/work2/v14/v14006/src/ParaView-3.12.0-RC3/ParaViewCore/ClientServerCore/vtkIceTSynchronizedRenderers.cxx
>> (code 4)
>> make[2]: ***
>> [ParaViewCore/ClientServerCore/CMakeFiles/vtkPVClientServerCore.dir/vtkIceTSynchronizedRenderers.cxx.o]
>> Error 4
>>
>> Looking into ParaViewCore/ClientServerCore/CMakeLists.txt I found
>> nothing that specifies ${OPENGL_INCLUDE_DIR} as opposed to the old
>> ParaView-3.10.1/Servers/Filters/CMakeLists.txt (where
>> vtkIceTSynchronizedRenderers.cxx had been in) having
>>
>
>
> I build PareView with OSMesa from their git repositories every
> night.
>
> Could you please post your CMakeCache.txt to a public server or
> tell us the CMake variables you set?
>
> The OSMesa related variables I set are :
>
> OPENGL_INCLUDE_DIR:PATH=/home/kevin/mesa_osmesa/include
> OPENGL_gl_LIBRARY:FILEPATH=
> OPENGL_glu_LIBRARY:FILEPATH=/home/kevin/mesa_osmesa/lib/libGLU.so
> VTK_OPENGL_HAS_OSMESA:BOOL=ON
> OSMESA_INCLUDE_DIR:PATH=/home/kevin/mesa_osmesa/include
> OSMESA_LIBRARY:FILEPATH=/home/kevin/mesa_osmesa/lib/libOSMesa.so
> VTK_USE_OFFSCREEN:BOOL=ON
> VTK_USE_X:BOOL=OFF
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] 3.12.0-RC3: could not open source file "GL/gl.h" compiling vtkIceTSynchronizedRenderers.cxx
I filed this as a bug:
http://paraview.org/Bug/view.php?id=12711
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Takuya OSHIMA
Subject: [Paraview] 3.12.0-RC3: could not open source file "GL/gl.h" compiling
vtkIceTSynchronizedRenderers.cxx
Date: Sat, 05 Nov 2011 19:13:42 +0900 (JST)
> Hi,
>
> I tried to build the 3.12.0 RC3 with MesaLib-7.11 (OSMesa) on a RHEL
> 5.1 headless cluster and got an error:
>
> /nfs/work2/v14/v14006/src/ParaView-3.12.0-RC3/VTK/Rendering/vtkOpenGL.h(26):
> catastrophic error: could not open source file "GL/gl.h"
> # include // Include OpenGL API.
> ^
>
> compilation aborted for
> /nfs/work2/v14/v14006/src/ParaView-3.12.0-RC3/ParaViewCore/ClientServerCore/vtkIceTSynchronizedRenderers.cxx
> (code 4)
> make[2]: ***
> [ParaViewCore/ClientServerCore/CMakeFiles/vtkPVClientServerCore.dir/vtkIceTSynchronizedRenderers.cxx.o]
> Error 4
>
> Looking into ParaViewCore/ClientServerCore/CMakeLists.txt I found
> nothing that specifies ${OPENGL_INCLUDE_DIR} as opposed to the old
> ParaView-3.10.1/Servers/Filters/CMakeLists.txt (where
> vtkIceTSynchronizedRenderers.cxx had been in) having
>
> # The following was copy/paste from vtkIncludeDirectories.cmake
> # OpenGL include directories.
> IF(APPLE)
> IF(VTK_USE_X OR VTK_OPENGL_HAS_OSMESA)
> INCLUDE_DIRECTORIES(${OPENGL_INCLUDE_DIR})
> ENDIF(VTK_USE_X OR VTK_OPENGL_HAS_OSMESA)
> ELSE(APPLE)
> INCLUDE_DIRECTORIES(${OPENGL_INCLUDE_DIR})
> ENDIF(APPLE)
>
> so perhaps we need something similar around (line 116)
>
> IF (PARAVIEW_USE_ICE_T AND VTK_USE_MPI)
>SET (Kit_SRCS
> ${Kit_SRCS}
> vtkIceTSynchronizedRenderers.cxx)
> .
> ENDIF (PARAVIEW_USE_ICE_T AND VTK_USE_MPI)
>
> of ParaViewCore/ClientServerCore/CMakeLists.txt ?
>
> Takuya OSHIMA, Ph.D.
> Faculty of Engineering, Niigata University
> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://www.paraview.org/mailman/listinfo/paraview
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] ANN: ParaView 3.12.0 RC-2 available for download
Any chance this gets fixed in the final release of 3.12? Just to make sure I've filed as a bug with the proposed fix (which you can find in this mail too): http://paraview.org/Bug/view.php?id=12710 Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: David Partyka Subject: Re: [Paraview] ANN: ParaView 3.12.0 RC-2 available for download Date: Sun, 9 Oct 2011 11:37:16 -0400 > Will take a look. for 3.12. > > 2011/10/9 Takuya OSHIMA > >> With Paul's comment I was able to reproduce the problem and did find >> what were wrong. One is a trivial bug that forced the filter to try to >> calculate normals for all cell types and another is lack of skipping >> everything when input array to process is not found (e.g. when a >> partial array in a multiblock dataset is specified). >> >> Please find the attachment for the fix. Like Paul and Fabian I'd like >> to see this fixed in the 3.12 release. >> >> Takuya >> >> Takuya OSHIMA, Ph.D. >> Faculty of Engineering, Niigata University >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> >> From: Takuya OSHIMA >> Subject: Re: [Paraview] ANN: ParaView 3.12.0 RC-2 available for download >> Date: Sun, 09 Oct 2011 02:30:10 +0900 (東京 (標準時)) >> >> > Hi Fabian, >> > >> > Paul probably meant lines created by slicing patches (in OpenFOAM >> > term). Sounds like a bug in Surface Vectors than one in the OpenFOAM >> > reader anyway... >> > >> > Takuya >> > >> > Takuya OSHIMA, Ph.D. >> > Faculty of Engineering, Niigata University >> > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> > >> > From: Fabian Braennstroem >> > Subject: Re: ANN: ParaView 3.12.0 RC-2 available for download >> > Date: Sat, 08 Oct 2011 13:35:50 +0200 >> > >> >> Hello to you both, >> >> >> >> I am not sure, what you mean with lines in my input, but yes I did cut >> >> (slice) through a openfoam domain... now I am not able to reproduce it; >> >> though as Paul mentioned, this error was there earlier as well. I check >> >> again. >> >> >> >> Best Regards >> >> Fabian >> >> >> >> On 10/07/2011 11:49 AM, Paul Edwards wrote: >> >> > Hi, >> >> > >> >> > I noticed a bug with "Surface Vectors" before - if you have any lines >> in >> >> > your input (i.e. you cut through a volume and surfaces) then it will >> >> > crash. Is this the problem you are having Fabian? >> >> > >> >> > Regards, >> >> > Paul >> >> > >> >> > On 7 October 2011 07:14, Takuya OSHIMA > >> > <mailto:osh...@eng.niigata-u.ac.jp>> wrote: >> >> > >> >> > Hi Fabian, I cannot reproduce (OS X 64bit / Ubuntu 10.04 64bit). >> Can >> >> > you isolate whether it is specific to OpeFOAM data or not? If it >> is, >> >> > can you share a test case? >> >> > >> >> > Takuya >> >> > >> >> > Takuya OSHIMA, Ph.D. >> >> > Faculty of Engineering, Niigata University >> >> > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> >> > >> >> > From: Fabian Braennstroem > >> > <mailto:f.braennstr...@gmx.de>> >> >> > Subject: Re: [Paraview] ANN: ParaView 3.12.0 RC-2 available for >> download >> >> > Date: Thu, 06 Oct 2011 19:13:39 +0200 >> >> > >> >> > > Hello, >> >> > > >> >> > > just tested it on linux 64bit with openfoam decomposed data. >> >> > > Making a slice and applying "Surface Vectors" results in a >> >> > > Segmentation fault. >> >> > > >> >> > > It would be great to fix this in the 3.12. >> >> > > >> >> > > Best Regards >> >> > > Fabian >> >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the ParaView Wiki at: >> http://paraview.org/Wiki/ParaView >> >> Follow this lin
[Paraview] 3.12.0-RC3: could not open source file "GL/gl.h" compiling vtkIceTSynchronizedRenderers.cxx
Hi,
I tried to build the 3.12.0 RC3 with MesaLib-7.11 (OSMesa) on a RHEL
5.1 headless cluster and got an error:
/nfs/work2/v14/v14006/src/ParaView-3.12.0-RC3/VTK/Rendering/vtkOpenGL.h(26):
catastrophic error: could not open source file "GL/gl.h"
# include // Include OpenGL API.
^
compilation aborted for
/nfs/work2/v14/v14006/src/ParaView-3.12.0-RC3/ParaViewCore/ClientServerCore/vtkIceTSynchronizedRenderers.cxx
(code 4)
make[2]: ***
[ParaViewCore/ClientServerCore/CMakeFiles/vtkPVClientServerCore.dir/vtkIceTSynchronizedRenderers.cxx.o]
Error 4
Looking into ParaViewCore/ClientServerCore/CMakeLists.txt I found
nothing that specifies ${OPENGL_INCLUDE_DIR} as opposed to the old
ParaView-3.10.1/Servers/Filters/CMakeLists.txt (where
vtkIceTSynchronizedRenderers.cxx had been in) having
# The following was copy/paste from vtkIncludeDirectories.cmake
# OpenGL include directories.
IF(APPLE)
IF(VTK_USE_X OR VTK_OPENGL_HAS_OSMESA)
INCLUDE_DIRECTORIES(${OPENGL_INCLUDE_DIR})
ENDIF(VTK_USE_X OR VTK_OPENGL_HAS_OSMESA)
ELSE(APPLE)
INCLUDE_DIRECTORIES(${OPENGL_INCLUDE_DIR})
ENDIF(APPLE)
so perhaps we need something similar around (line 116)
IF (PARAVIEW_USE_ICE_T AND VTK_USE_MPI)
SET (Kit_SRCS
${Kit_SRCS}
vtkIceTSynchronizedRenderers.cxx)
.
ENDIF (PARAVIEW_USE_ICE_T AND VTK_USE_MPI)
of ParaViewCore/ClientServerCore/CMakeLists.txt ?
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Paraview will not build
Hi Ken, I am happy to try your patch too if turnaround of several days is acceptable because we have to throw the whole cmake/make process in a batch queue. Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: "Moreland, Kenneth" Subject: Re: [Paraview] Paraview will not build Date: Wed, 26 Oct 2011 19:37:15 + > Gar. I guess I should have been paying attention to this email thread. I'll > take a look at this. > > I don't think I can easily replicate the compile problem. Could someone > (Rich?) please volunteer to accept a patch and attempt to compile it rather > than have me spin my wheels trying to install an old version of MPI on > something? > > -Ken ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Paraview will not build
The problem I think is that MPI_IN_PLACE is supported only by MPI-2 whereas your MPI library probably implements MPI 1.x. MPI_IN_PLACE was not in IceT until PV 3.10.1. I had given up trying to install PV 3.12 series on a supercluster that only has MPI 1.2 support so would really appreciate if the MPI-2 dependence is removed by any chance... Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: David Partyka Subject: Re: [Paraview] Paraview will not build Date: Tue, 25 Oct 2011 21:44:13 -0400 > You shouldn't be tweaking the Cache! :-P It should work with openmpi, > mpich2, msmpi intel mpi etc. > > On Tue, Oct 25, 2011 at 9:04 PM, Cook, Rich wrote: > >> Ah, thanks, >> perhaps this only works with OpenMPI... I'll investigate whether I can use >> that. >> Paraview is hard as hell to build. >> -- Rich >> >> On Oct 25, 2011, at 5:59 PM, Scott, W Alan wrote: >> >> > Works for me! Here is a snippet from our python script. >> > >> > Alan >> > >> >mpiDir = >> '/apps/x86_64/mpi/openmpi/intel-11.1-f064-c064/openmpi-1.4.2_oobpr >> > >> > cMakeVars = cMakeVars +\ >> >'-DMPI_LIBRARY:FILEPATH="'+mpiDir+'/lib/libmpi.so;'+\ >> > mpiDir+'/lib/libopen-rte.so;'+\ >> > mpiDir+'/lib/libopen-pal.so;'+\ >> > mpiDir+'/lib/libmpi_cxx.so" '+\ >> >'-DCMAKE_EXE_LINKER_FLAGS:STRING=-Bdynamic ' >> > >> >cMakeVars = cMakeVars +\ >> >'-DVTK_USE_MPI:BOOL=ON '+\ >> >'-DPARAVIEW_USE_MPI:BOOL=ON '+\ >> >'-DMPI_INCLUDE_PATH:PATH='+mpiDir+'/include/ '+\ >> >'-DCMAKE_C_FLAGS:STRING="-w -fPIC -I'+mpiDir+'/include/openmpi" >> '+\ >> >'-DCMAKE_CXX_FLAGS:STRING="-w -fPIC -I'+mpiDir+'/include/openmpi" >> '+\ >> >'-DCMAKE_CXX_FLAGS_RELEASE:STRING="-O2 -fPIC" '+\ >> >'-DCMAKE_C_FLAGS_RELEASE:STRING="-O2 -fPIC" '+\ >> >'-DPARAVIEW_PLUS_BUILD:BOOL=OFF ' >> > >> > cMakeVars = cMakeVars +\ >> >'-DPARAVIEW_USE_MPI_SSEND:BOOL=ON ' >> > >> > >> > >> > -Original Message- >> > From: paraview-boun...@paraview.org [mailto: >> paraview-boun...@paraview.org] On Behalf Of Cook, Rich >> > Sent: Tuesday, October 25, 2011 6:44 PM >> > To: paraview@paraview.org >> > Subject: [Paraview] Paraview will not build >> > >> > Help? >> > >> > [ 44%] Building C object >> Utilities/IceT/src/communication/CMakeFiles/IceTMPI.dir/mpi.c.o >> > cd >> /nfs/tmp2/rcook/ParaView/3.12/ParaView-3.12.0-RC2-build/Utilities/IceT/src/communication >> && /usr/local/bin/mpicc -DIceTMPI_EXPORTS -DVTK_PYTHON_BUILD >> -I/usr/global/tools/Kitware/Paraview/3.11/chaos_4_x86_64_ib/include >> -I/usr/gapps/visit/mili/1.10.0/linux-x86_64_gcc-4.1/include >> -I/usr/gapps/visit/hdf5/1.8.4/linux-x86_64_gcc-4.1/include -g -fPIC >> -I/nfs/tmp2/rcook/ParaView/3.12/ParaView-3.12.0-RC2-build >> -I/nfs/tmp2/rcook/ParaView/3.12/ParaView-3.12.0-RC2-build/VTK/Utilities >> -I/usr/local/include/python2.6 -I/usr/local/tools/mvapich-gnu/include >> -I/nfs/tmp2/rcook/ParaView/3.12/ParaView-3.12.0-RC2/Utilities/IceT/src/include >> -I/nfs/tmp2/rcook/ParaView/3.12/ParaView-3.12.0-RC2-build/Utilities/IceT/src/include >> -ansi -Wall -Wno-long-long -Wcast-align -Wextra -Wformat-security -Wshadow >> -Wunused -Wreturn-type -Wpointer-arith -Wdeclaration-after-statement -o >> CMakeFiles/IceTMPI.dir/mpi.c.o -c >> /nfs/tmp2/rcook/ParaView/3.12/ParaView-3.12.0-RC2/Utilities/IceT/src/communication/mpi.c >> > >> /nfs/tmp2/rcook/ParaView/3.12/ParaView-3.12.0-RC2/Utilities/IceT/src/communication/mpi.c: >> In function 'Gather': >> > >> /nfs/tmp2/rcook/ParaView/3.12/ParaView-3.12.0-RC2/Utilities/IceT/src/communication/mpi.c:327: >> error: 'MPI_IN_PLACE' undeclared (first use in this function) >> > >> /nfs/tmp2/rcook/ParaView/3.12/ParaView-3.12.0-RC2/Utilities/IceT/src/communication/mpi.c:327: >> error: (Each undeclared identifier is reported only once >> > >> /nfs/tmp2/rcook/ParaView/3.12/ParaView-3.12.0-RC2/Utilities/IceT/src/communication/mpi.c:327: >> error: for each function it appears in.) >> > >> /nfs/tmp2/rcook/ParaView
Re: [Paraview] ANN: ParaView 3.12.0 RC-2 available for download
With Paul's comment I was able to reproduce the problem and did find
what were wrong. One is a trivial bug that forced the filter to try to
calculate normals for all cell types and another is lack of skipping
everything when input array to process is not found (e.g. when a
partial array in a multiblock dataset is specified).
Please find the attachment for the fix. Like Paul and Fabian I'd like
to see this fixed in the 3.12 release.
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Takuya OSHIMA
Subject: Re: [Paraview] ANN: ParaView 3.12.0 RC-2 available for download
Date: Sun, 09 Oct 2011 02:30:10 +0900 (東京 (標準時))
> Hi Fabian,
>
> Paul probably meant lines created by slicing patches (in OpenFOAM
> term). Sounds like a bug in Surface Vectors than one in the OpenFOAM
> reader anyway...
>
> Takuya
>
> Takuya OSHIMA, Ph.D.
> Faculty of Engineering, Niigata University
> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
>
> From: Fabian Braennstroem
> Subject: Re: ANN: ParaView 3.12.0 RC-2 available for download
> Date: Sat, 08 Oct 2011 13:35:50 +0200
>
>> Hello to you both,
>>
>> I am not sure, what you mean with lines in my input, but yes I did cut
>> (slice) through a openfoam domain... now I am not able to reproduce it;
>> though as Paul mentioned, this error was there earlier as well. I check
>> again.
>>
>> Best Regards
>> Fabian
>>
>> On 10/07/2011 11:49 AM, Paul Edwards wrote:
>> > Hi,
>> >
>> > I noticed a bug with "Surface Vectors" before - if you have any lines in
>> > your input (i.e. you cut through a volume and surfaces) then it will
>> > crash. Is this the problem you are having Fabian?
>> >
>> > Regards,
>> > Paul
>> >
>> > On 7 October 2011 07:14, Takuya OSHIMA > > <mailto:osh...@eng.niigata-u.ac.jp>> wrote:
>> >
>> > Hi Fabian, I cannot reproduce (OS X 64bit / Ubuntu 10.04 64bit). Can
>> > you isolate whether it is specific to OpeFOAM data or not? If it is,
>> > can you share a test case?
>> >
>> > Takuya
>> >
>> > Takuya OSHIMA, Ph.D.
>> > Faculty of Engineering, Niigata University
>> > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
>> >
>> > From: Fabian Braennstroem > > <mailto:f.braennstr...@gmx.de>>
>> > Subject: Re: [Paraview] ANN: ParaView 3.12.0 RC-2 available for
>> > download
>> > Date: Thu, 06 Oct 2011 19:13:39 +0200
>> >
>> > > Hello,
>> > >
>> > > just tested it on linux 64bit with openfoam decomposed data.
>> > > Making a slice and applying "Surface Vectors" results in a
>> > > Segmentation fault.
>> > >
>> > > It would be great to fix this in the 3.12.
>> > >
>> > > Best Regards
>> > > Fabian
diff --cc VTK
index 9aa84ed,9b133f7..000
--- a/VTK
+++ b/VTK
diff --git a/ParaViewCore/VTKExtensions/vtkSurfaceVectors.cxx b/ParaViewCore/VTKExtensions/vtkSurfaceVectors.cxx
index 9b83aae..f462c2e 100644
--- a/ParaViewCore/VTKExtensions/vtkSurfaceVectors.cxx
+++ b/ParaViewCore/VTKExtensions/vtkSurfaceVectors.cxx
@@ -82,6 +82,13 @@ int vtkSurfaceVectors::RequestData(vtkInformation *vtkNotUsed(request),
vtkIdType numPoints, pointId, i, cellId;
numPoints = input->GetNumberOfPoints();
vtkDataArray *inVectors = this->GetInputArrayToProcess(0,inputVector);
+
+ if(!inVectors)
+{
+output->ShallowCopy(input);
+return 1;
+}
+
vtkDataArray* newVectors = 0;
vtkDoubleArray* newScalars = 0;
vtkIdList* cellIds = vtkIdList::New();
@@ -125,7 +132,7 @@ int vtkSurfaceVectors::RequestData(vtkInformation *vtkNotUsed(request),
cellId = cellIds->GetId(i);
cellType = input->GetCellType(cellId);
if (cellType == VTK_VOXEL || cellType == VTK_POLYGON ||
- cellType == VTK_TRIANGLE || VTK_QUAD)
+ cellType == VTK_TRIANGLE || cellType == VTK_QUAD)
{
input->GetCellPoints(cellId, ptIds);
input->GetPoint(ptIds->GetId(0), p1);
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] ANN: ParaView 3.12.0 RC-2 available for download
Hi Fabian, Paul probably meant lines created by slicing patches (in OpenFOAM term). Sounds like a bug in Surface Vectors than one in the OpenFOAM reader anyway... Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Fabian Braennstroem Subject: Re: ANN: ParaView 3.12.0 RC-2 available for download Date: Sat, 08 Oct 2011 13:35:50 +0200 > Hello to you both, > > I am not sure, what you mean with lines in my input, but yes I did cut > (slice) through a openfoam domain... now I am not able to reproduce it; > though as Paul mentioned, this error was there earlier as well. I check > again. > > Best Regards > Fabian > > On 10/07/2011 11:49 AM, Paul Edwards wrote: > > Hi, > > > > I noticed a bug with "Surface Vectors" before - if you have any lines in > > your input (i.e. you cut through a volume and surfaces) then it will > > crash. Is this the problem you are having Fabian? > > > > Regards, > > Paul > > > > On 7 October 2011 07:14, Takuya OSHIMA > <mailto:osh...@eng.niigata-u.ac.jp>> wrote: > > > > Hi Fabian, I cannot reproduce (OS X 64bit / Ubuntu 10.04 64bit). Can > > you isolate whether it is specific to OpeFOAM data or not? If it is, > > can you share a test case? > > > > Takuya > > > > Takuya OSHIMA, Ph.D. > > Faculty of Engineering, Niigata University > > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN > > > > From: Fabian Braennstroem > <mailto:f.braennstr...@gmx.de>> > > Subject: Re: [Paraview] ANN: ParaView 3.12.0 RC-2 available for download > > Date: Thu, 06 Oct 2011 19:13:39 +0200 > > > > > Hello, > > > > > > just tested it on linux 64bit with openfoam decomposed data. > > > Making a slice and applying "Surface Vectors" results in a > > > Segmentation fault. > > > > > > It would be great to fix this in the 3.12. > > > > > > Best Regards > > > Fabian > > > > > > On 10/04/2011 11:24 PM, David Partyka wrote: > > >> I Joe, can you redownload the tarball. I forgot to include the > > version > > >> file in the tarball which the version calculation code uses when > > there > > >> isn't a git repository. If it still doesn't work let me know. > > Thanks! > > >> > > >> On Tue, Oct 4, 2011 at 5:22 PM, joseph insley > > mailto:ins...@mcs.anl.gov> > > >> <mailto:ins...@mcs.anl.gov <mailto:ins...@mcs.anl.gov>>> wrote: > > >> > > >> Hello, > > >> > > >> I have a question about the source distribution of 3.12.0 > > RC-2. I > > >> understand from a message from Utkarsh back in August that > > the way > > >> that version numbers are determined has changed, and now > > requires a > > >> call to "git describe". After downloading the source > > tarball from > > >> http://paraview.org/files/v3.12/ParaView-3.12.0-RC2.tar.gz, my > > >> attempt to build failed, apparently while attempting to call git > > >> describe. So, my question is, will git now become a > > dependency for > > >> building release versions of ParaView? Or is this call > > currently > > >> still in there because this is still just a release > > candidate, and > > >> not yet an official release? > > >> > > >> Thanks, > > >> joe. > > >> > > >> On Sep 29, 2011, at 2:39 PM, David Partyka wrote: > > >> > > >>> The ParaView team is pleased to announce the availability > > of the > > >>> ParaView 3.12.0 Release Candidate 2 binaries for download > > on the > > >>> ParaView > > (http://paraview.org/paraview/resources/software.html). > > >>> ParaView 3.12 can be considered as a bug-fix release with over > > >>> 180 issues resolved. The detailed list can be found at > > >>> http://www.paraview.org/Bug/changelog_page.php. > > >>> > > >>> With Python being one of the preferred means of interacting > &g
Re: [Paraview] ANN: ParaView 3.12.0 RC-2 available for download
Hi Fabian, I cannot reproduce (OS X 64bit / Ubuntu 10.04 64bit). Can you isolate whether it is specific to OpeFOAM data or not? If it is, can you share a test case? Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Fabian Braennstroem Subject: Re: [Paraview] ANN: ParaView 3.12.0 RC-2 available for download Date: Thu, 06 Oct 2011 19:13:39 +0200 > Hello, > > just tested it on linux 64bit with openfoam decomposed data. > Making a slice and applying "Surface Vectors" results in a > Segmentation fault. > > It would be great to fix this in the 3.12. > > Best Regards > Fabian > > On 10/04/2011 11:24 PM, David Partyka wrote: >> I Joe, can you redownload the tarball. I forgot to include the version >> file in the tarball which the version calculation code uses when there >> isn't a git repository. If it still doesn't work let me know. Thanks! >> >> On Tue, Oct 4, 2011 at 5:22 PM, joseph insley > <mailto:ins...@mcs.anl.gov>> wrote: >> >> Hello, >> >> I have a question about the source distribution of 3.12.0 RC-2. I >> understand from a message from Utkarsh back in August that the way >> that version numbers are determined has changed, and now requires a >> call to "git describe". After downloading the source tarball from >> http://paraview.org/files/v3.12/ParaView-3.12.0-RC2.tar.gz, my >> attempt to build failed, apparently while attempting to call git >> describe. So, my question is, will git now become a dependency for >> building release versions of ParaView? Or is this call currently >> still in there because this is still just a release candidate, and >> not yet an official release? >> >> Thanks, >> joe. >> >> On Sep 29, 2011, at 2:39 PM, David Partyka wrote: >> >>> The ParaView team is pleased to announce the availability of the >>> ParaView 3.12.0 Release Candidate 2 binaries for download on the >>> ParaView (http://paraview.org/paraview/resources/software.html). >>> ParaView 3.12 can be considered as a bug-fix release with over >>> 180 issues resolved. The detailed list can be found at >>> http://www.paraview.org/Bug/changelog_page.php. >>> >>> With Python being one of the preferred means of interacting with >>> ParaView, we've added support to create animation tracks that use >>> Python scripts to build highly customized animations. >>> >>> Plugins support is one of the strong points of ParaView and with >>> this release, we've made it easier to load deployed plugins on the >>> server processes as well. All distributed plugins are now listed >>> on the client as well as the server side. >>> >>> The release includes updates to LANL's streaming framework. >>> The multiresolution streaming view now automatically adjusts >>> resolution to match the projected image size. Also, VTK filters >>> are now able to modify meta-information which means they can >>> modify the data while still allowing the streaming framework to >>> cull and prioritize pieces. An example is a new spherical warp >>> filter that projects flat data onto the globe while correctly >>> tracking piece bounding boxes. >>> >>> Also, there are updates to support users of the cosmology >>> and windblade formats. For example the MaskPoints filter (used to >>> place glyphs and in other places) was updated with new options >>> that improve random sampling in parallel. Likewise VTK's Gaussian >>> Splatter filter is now exposed in ParaView which makes it easy to >>> visualize point set data with imaging filters. The cosmo and >>> windblade readers have also been revised. >>> >>> This version includes some major changes under the >>> covers. ParaView 3.12 includes improvements to the underpinnings >>> of ParaView ServerManager. The communication layer under the >>> ParaView ServerManager was upgraded to minimize communication as >>> well as making it easier to debug and trace messages being >>> exchanged between client and server. We now use Google Protocol >>> Buffers, for example, to exchange messages between client and server. >>> >>> In addition, there are several small but notable improvements >>> included in this release for example,
Re: [Paraview] [vtk-developers] [VTK 0012629]: Incorrect polyhedron insertion in vtkAppendFilter
Hi, There is an incorrect insertion of polyhedral cell in vtkAppendFilter that causes ParaView to crash, which I filed as a VTK bug with a proposed patch (attached in this mail as well) as follows. I hope the fix is included in the PV 3.12 release. Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Mantis Bug Tracker Subject: [vtk-developers] [VTK 0012629]: Incorrect polyhedron insertion in vtkAppendFilter Date: Wed, 5 Oct 2011 09:35:23 -0400 > > The following issue has been SUBMITTED. > == > http://paraview.org/Bug/view.php?id=12629 > == > Reported By: Takuya OSHIMA > Assigned To: > == > Project:VTK > Issue ID: 12629 > Category: (No Category) > Reproducibility:have not tried > Severity: minor > Priority: high > Status: backlog > Project:Kitware > Type: crash > == > Date Submitted: 2011-10-05 09:35 EDT > Last Modified: 2011-10-05 09:35 EDT > == > Summary:Incorrect polyhedron insertion in vtkAppendFilter > Description: > There is an incorrect insertion of polyhedral cell in vtkAppendFilter which > causes crash. > > I attached patch to fix the problem. I'll attach a test case later if > permission > is granted by the original reporter. > > == > > Issue History > Date ModifiedUsername FieldChange > ====== > 2011-10-05 09:35 Takuya OSHIMA New Issue > 2011-10-05 09:35 Takuya OSHIMA File Added: > 0001-Fix-polyhedron-handling-in-vtkAppendFilter.patch > == > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://www.vtk.org/mailman/listinfo/vtk-developers > 0001-Fix-polyhedron-handling-in-vtkAppendFilter.patch Description: Binary data ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] attach filebrowser to box in properties panel and does RequestData() block dialogs
Hi kate, Perhaps you can try adding to the string vector property that holds file name. Several examples are in readers.xml in the source distribution of PV. Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: fiss...@pitt.edu Subject: [Paraview] attach filebrowser to box in properties panel and does RequestData() block dialogs Date: Mon, 19 Sep 2011 15:38:29 -0400 > Hi, > > Is there a way to attach a filebrowser to a textbox or dropdown list in > the properties panel in a custom filter via the XML spec ? > > Since I didn't see the way to do that I added a pqFileDialog dialog() call > in my filter RequestData() method. It came up ok but did not respond to > any mouse/keyboard input. I tried moving the dialog() call to my filter > constructor, just to see if it worked there, and it worked fine. > Is mouse/keyboard interaction blocked during execute of RequestData() ? > For the server/parent parameters to dialog() I used > pqApplicationCore::instance()->getServerManagerModel()->getItemAtIndex(0); > pqCoreUtilities::mainWidget() > > > (I know its gross to try to put a dialog() in RequestData(), but we at least > temporarily need a little junk file from the user, not worth writing a reader > for, would prefer to add filebrowser to properties panel if I can do that > easily). > > thanks > kate ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Get name of object in Pipeline Browser
Hi Lars,
> But where and when do I have to call that code? Because at the moment my
> plugin is executed by clicking on "File / Export" in ParaView, so I don't
> have any GUI related code. Everything is on the VTK side.
Just a faint idea that happened to come to me is to create an
autostart plugin and hook any one of ***Created() signals of
pqOjbectBuilder
http://www.paraview.org/ParaView3/Doc/Nightly/html/classpqObjectBuilder.html
that is considered suitable to detect creation of your exporter and
if detected send the strings to the server-side exporter object.
I have never tried myself so am totally unsure if it at all works, may
be totally wrong.
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Lars Bilke
Subject: Re: [Paraview] Get name of object in Pipeline Browser
Date: Thu, 18 Aug 2011 12:52:48 +0200
> Dear John,
>
> thanks for your explanations. I roughly got an idea but I have a few
> questions:
>>
>> class vtkMyExporter . {
>>
>> the usual vtkSetGetStuff and all the write, update, etc
>>
>> void SetMyNameString(const char *) // for a single dataset/actor
>> void SetMyNameStringList(const char **) // for a list of items
>> };
>>
>>
>>
>
> This is clear.
>> this gets wrapped by client server etc etc
>>
>> In the GUI, you could query the name from the pqXXX stuff, I have a similar
>> snippet that does this
>>
>> pqPipelineSource *source = *it;
>>
>>
>>
>>
>
> I assume I can get *it like this:
>
> QList sources_and_filters =
> pqApplicationCore::instance()->getServerManagerModel()->findItems();
>
>
> But where and when do I have to call that code? Because at the moment my
> plugin is executed by clicking on "File / Export" in ParaView, so I don't
> have any GUI related code. Everything is on the VTK side.
>>
>>
>>
>>
>> std::string xmlName = source->getProxy()->GetXMLName();
>>
>> now you want the name, not the XML name, so use that
>> but now you can
>>
>> vtkSMPropertyHelper modified(source->getProxy(), "MyNameString");
>>
>>
>> modified.Set(xmlName.c_str()); // or something like that
>>
>>
>>
>>
>
> This sets the name on the proxy.
>>
>>
>>
>>
>> then you need to push your string into the VTK class using something like
>>
>>
>> source->getProxy()->UpdateVTKObjects()
>>
>>
>> or UpdatePipeline (I forget the correct calls)
>>
>>
>>
>>
>
> But what is that doing?
>>
>>
>>
>> and because your custom SetMyNameString doesn’t trigger a modified in the
>> pipeline, you can carry on with doing the write, but the exporter has the
>> string passed in from he GUI just before it writes. You can pass a string
>> list if you want and make sure the order matches the order of writes so the
>> names match.
>>
>>
>>
>
> I dont understand how the name actually gets to my exporter. And because a
> list of names is more general I would only pass this list to my exporter and
> not a single name.
>
>
> See vtkOpenSGExporter.h / .cxx on Github:
> https://github.com/bilke/pv_opensg_plugin
>
>
> Thank you very much for your help!!
> Lars.
>> From: Lars Bilke [mailto:lars.bi...@ufz.de]
>> Sent: 18 August 2011 09:14
>> To: Biddiscombe, John A.
>> Cc: Utkarsh Ayachit; ParaView Mailliste
>> Subject: Re: [Paraview] Get name of object in Pipeline Browser
>>
>> Thanks for your answers!
>>
>>
>>
>> John,
>>
>> where on the gui-side do I need to pass that string? Do I need to modify the
>> ParaView sources? Because I only want to write a plugin which should be
>> redistributable to colleagues which have only the ParaView binaries
>> installed.
>>
>> And your suggestion assumes that I only want to export one actor right? What
>> I want is to export all actors in one step.
>>
>>
>>
>> Lars
>>
>>
>> Am Mittwoch, 17. August 2011 um 15:45 schrieb Biddiscombe, John A.:
>> > It'd probably be easier to add a method to the vtk-exporter class which
>> > accepts a string, and from the gui, pass the string in just before export
>> > - because you can get it the proxy name from the gui end. Make sure the
>> > SetProxyName(char*...) method doesn't ca
Re: [Paraview] Shapefiles to Paraview (or VTK) format
Hi, I may be a bit persistent about this and may be complicating things more, but went on to port VisIt Shapefile database reader as a ParaView plugin via VisItBridge https://gitorious.org/avtshapefilefileformat_plugin because I wanted to examine as much options as possible. So now we have three options: ParaViewGeo (LGPL), vtkGDALVectorReader (MIT License), and the VisIt reader (BSD License). Each of the three turned out to have its strengths, to illustrate I took a screenshot: http://dl.dropbox.com/u/7352393/ShapefileReadersScreenshot.png where the two above are represented in Surface and the two below are in Surface With Edges. Observations are * ParaViewGeo and vtkGDALVectorReader represent polygons in lines, whereas the VisIt reader in polygons, propably due to difference in philosophy in handling polygons with holes, which is not supported natively in VTK. VisIt reader is characteristic in this point because it offers an option to tessellate polygons using the OpenGL tessellator. * The VisIt reader with tessellation and vtkGDALVectorReader allows field values to be loaded as well. For our own particular purpose vtkGDALVectorReader turned out to be best suited, but for others other readers might be better. Either way, I am really looking forward to seeing one (or more) of them included in ParaView/VTK. Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Aashish Chaudhary Subject: Re: [Paraview] Shapefiles to Paraview (or VTK) format Date: Wed, 8 Jun 2011 21:25:42 -0400 > Sure. I might be able make this reader as part of VTK and if you are > willing to share your plugin then probably we could make that as part > of Paraview source code. > > Looking forward to your feedback. > > Thanks > > > On Wed, Jun 8, 2011 at 8:23 PM, Takuya OSHIMA > wrote: >> Hi Aashish, >> >> Great! My big thanks for sharing your reader. I will check and >> hopefully I should be able to wrap the reader as a ParaView plugin. >> >> Takuya >> >> Takuya OSHIMA, Ph.D. >> Faculty of Engineering, Niigata University >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> >> From: Aashish Chaudhary >> Subject: Re: [Paraview] Shapefiles to Paraview (or VTK) format >> Date: Wed, 8 Jun 2011 09:20:05 -0400 >> >>> Hi Takuya, >>> >>> Instead of sending it over the email I decided to put it over >>> gitorious so that it could be maintained. >>> >>> Checkout source code from here: >>> >>> https://gitorious.org/vtkgis_vector_reader >>> >>> The repository has a test program as well that could be used to view a >>> shape file or write shape file gdal layers as vtk files. This test >>> program won't work when you don't have a projection information in the >>> shape file but you can still look at the test code to get an idea on >>> how to convert the data into vtk files. >>> >>> If you have any questions or if you find any bugs please let me know. >>> >>> Thanks >>> >>> >>> On Tue, Jun 7, 2011 at 12:12 PM, Aashish Chaudhary >>> wrote: >>>> Sure. I will attach the reader header and source in my next email (by >>>> the end of the day). >>>> >>>> Thanks, >>>> >>>> >>>> On Tue, Jun 7, 2011 at 4:27 AM, Takuya OSHIMA >>>> wrote: >>>>> Hi Aashish, >>>>> >>>>> Would be great for me too if your reader may be shared (thus we have >>>>> more options for importing Shapefiles)! >>>>> >>>>> Takuya >>>>> >>>>> Takuya OSHIMA, Ph.D. >>>>> Faculty of Engineering, Niigata University >>>>> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >>>>> >>>>> From: Aashish Chaudhary >>>>> Subject: Re: [Paraview] Shapefiles to Paraview (or VTK) format >>>>> Date: Mon, 6 Jun 2011 10:29:22 -0400 >>>>> >>>>>> Hi Lester, >>>>>> >>>>>> I have a Shapefile reader (actually a vector format reader) for VTK. >>>>>> You would have to write a program to use it (I can send a sample app >>>>>> too). It will require VTK and GDAL. >>>>>> >>>>>> I can send you the code in my next email if you are interested. >>>>>> >>>>>> Regards, >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Jun 5, 2011 at 11:16 AM
[Paraview] OpenFOAM reader parser error
Hi, A user reported a parser error in OpenFOAM reader http://www.cfd-online.com/Forums/openfoam/89890-openfoam-2-0-opensuse-11-4-a.html#post313489 for which I filed a bug with a testcase and a proposed fix http://paraview.org/Bug/view.php?id=12318 . Thanks, Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] OpenFOAM reader incompatibility with temporal intermpolator
Really? Particle tracer never works for me without temporal interpolator (I only get a polygonal mesh with 0 cells/points). How do you make the interpolation work and how do you specify the timestep interval? Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Berk Geveci Subject: Re: [Paraview] OpenFOAM reader incompatibility with temporal intermpolator Date: Thu, 23 Jun 2011 09:24:44 -0400 > Hi Takuya, > > Out of curiosity, why would the lack of temporal interpolator make > path lines impractical? The particle tracer does its own interpolation > between timesteps. > > -berk > > On Thu, Jun 23, 2011 at 5:42 AM, Takuya OSHIMA > wrote: > > Hi, > > > > I just came across Dave DeMarle's ParaView course slides presented > > at the 6th OpenFOAM Workshop. > > http://www.openfoamworkshop.org/6th_OpenFOAM_Workshop_2011/Program/Training/deMarle_slides.pdf > > > > In the 11th slide (Temporal Processing) I see that the "Interpolation > > between time steps" is grayed out, which I suspect was done so because > > the temporal interpolator did not interpolate the OpenFOAM dataset > > (which made path lines unpractical as well). This is a known > > problem that has fixes involving both the OpenFOAM reader and the > > temporal interpolator. The fix to the former (which I backported from > > my own development version) is attached in this mail and the latter > > has already been filed as a bug with a patch: > > http://vtk.org/Bug/view.php?id=12151 > > > > Thanks, > > Takuya > > > > Takuya OSHIMA, Ph.D. > > Faculty of Engineering, Niigata University > > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN > > > > ___ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Please keep messages on-topic and check the ParaView Wiki at: > > http://paraview.org/Wiki/ParaView > > > > Follow this link to subscribe/unsubscribe: > > http://www.paraview.org/mailman/listinfo/paraview > > > > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] OpenFOAM reader incompatibility with temporal intermpolator
Hi,
I just came across Dave DeMarle's ParaView course slides presented
at the 6th OpenFOAM Workshop.
http://www.openfoamworkshop.org/6th_OpenFOAM_Workshop_2011/Program/Training/deMarle_slides.pdf
In the 11th slide (Temporal Processing) I see that the "Interpolation
between time steps" is grayed out, which I suspect was done so because
the temporal interpolator did not interpolate the OpenFOAM dataset
(which made path lines unpractical as well). This is a known
problem that has fixes involving both the OpenFOAM reader and the
temporal interpolator. The fix to the former (which I backported from
my own development version) is attached in this mail and the latter
has already been filed as a bug with a patch:
http://vtk.org/Bug/view.php?id=12151
Thanks,
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
diff --git a/IO/vtkOpenFOAMReader.cxx b/IO/vtkOpenFOAMReader.cxx
index 7445c6f..423124f 100644
--- a/IO/vtkOpenFOAMReader.cxx
+++ b/IO/vtkOpenFOAMReader.cxx
@@ -337,6 +337,8 @@ private:
vtkPoints *);
bool GetCellZoneMesh(vtkMultiBlockDataSet *, const vtkFoamIntVectorVector *,
const vtkFoamIntVectorVector *, vtkPoints *);
+ void SetShallowCopies(vtkMultiBlockDataSet *, vtkMultiBlockDataSet *,
+ const char *);
};
vtkStandardNewMacro(vtkOpenFOAMReaderPrivate);
@@ -7682,6 +7684,30 @@ void vtkOpenFOAMReaderPrivate::AddArrayToFieldData(
}
//-
+// Set shallow copies of the input datasets to output
+void vtkOpenFOAMReaderPrivate::SetShallowCopies(vtkMultiBlockDataSet *output,
+vtkMultiBlockDataSet *input, const char *blockName)
+{
+ // Set shallow copies of the member datasets as the final output so
+ // as not to get overridden in the input temporal dataset during the
+ // execution of temporal pipeline executive.
+ vtkMultiBlockDataSet *mbds = vtkMultiBlockDataSet::New();
+ for (unsigned int blockI = 0; blockI < input->GetNumberOfBlocks(); blockI++)
+{
+vtkDataObject *ds = input->GetBlock(blockI)->NewInstance();
+ds->ShallowCopy(input->GetBlock(blockI));
+mbds->SetBlock(blockI, ds);
+ds->FastDelete();
+mbds->GetMetaData(blockI)->CopyEntry(input->GetMetaData(blockI),
+vtkCompositeDataSet::NAME());
+}
+ const unsigned int groupTypeI = output->GetNumberOfBlocks();
+ output->SetBlock(groupTypeI, mbds);
+ mbds->FastDelete();
+ this->SetBlockName(output, groupTypeI, blockName);
+}
+
+//-
// return 0 if there's any error, 1 if success
int vtkOpenFOAMReaderPrivate::RequestData(vtkMultiBlockDataSet *output,
bool recreateInternalMesh, bool recreateBoundaryMesh, bool updateVariables)
@@ -8004,16 +8030,21 @@ int vtkOpenFOAMReaderPrivate::RequestData(vtkMultiBlockDataSet *output,
// Add Internal Mesh to final output only if selected for display
if (this->InternalMesh != NULL)
{
-output->SetBlock(0, this->InternalMesh);
+// Set shallow copy of the unstructured grid as the final output
+// so as not to get overridden when it is used as the input of
+// temporal filters during the execution of the temporal pipeline
+// executive.
+vtkUnstructuredGrid *ug = vtkUnstructuredGrid::New();
+ug->ShallowCopy(this->InternalMesh);
+output->SetBlock(0, ug);
+ug->FastDelete();
this->SetBlockName(output, 0, "internalMesh");
}
// set boundary meshes/data as output
if (this->BoundaryMesh != NULL && this->BoundaryMesh->GetNumberOfBlocks() > 0)
{
-const unsigned int groupTypeI = output->GetNumberOfBlocks();
-output->SetBlock(groupTypeI, this->BoundaryMesh);
-this->SetBlockName(output, groupTypeI, "Patches");
+this->SetShallowCopies(output, this->BoundaryMesh, "Patches");
}
// set lagrangian mesh as output
@@ -8021,50 +8052,37 @@ int vtkOpenFOAMReaderPrivate::RequestData(vtkMultiBlockDataSet *output,
{
if (lagrangianMesh->GetNumberOfBlocks() > 0)
{
- const unsigned int groupTypeI = output->GetNumberOfBlocks();
- output->SetBlock(groupTypeI, lagrangianMesh);
- this->SetBlockName(output, groupTypeI, "Lagrangian Particles");
+ this->SetShallowCopies(output, lagrangianMesh, "Lagrangian Particles");
}
lagrangianMesh->Delete();
}
if (this->Parent->GetReadZones())
{
-vtkMultiBlockDataSet *zones = NULL;
+vtkMultiBlockDataSet *zones
+= (this->PointZoneMesh || this->FaceZoneMesh || this->CellZoneMesh
+? vtkMultiBlockDataSet::New() : 0);
+
// set Zone Meshes as output
if (this->PointZoneMesh != NULL)
{
- zones = vtkMu
Re: [Paraview] Shapefiles to Paraview (or VTK) format
Hi Aashish, Great! My big thanks for sharing your reader. I will check and hopefully I should be able to wrap the reader as a ParaView plugin. Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Aashish Chaudhary Subject: Re: [Paraview] Shapefiles to Paraview (or VTK) format Date: Wed, 8 Jun 2011 09:20:05 -0400 > Hi Takuya, > > Instead of sending it over the email I decided to put it over > gitorious so that it could be maintained. > > Checkout source code from here: > > https://gitorious.org/vtkgis_vector_reader > > The repository has a test program as well that could be used to view a > shape file or write shape file gdal layers as vtk files. This test > program won't work when you don't have a projection information in the > shape file but you can still look at the test code to get an idea on > how to convert the data into vtk files. > > If you have any questions or if you find any bugs please let me know. > > Thanks > > > On Tue, Jun 7, 2011 at 12:12 PM, Aashish Chaudhary > wrote: >> Sure. I will attach the reader header and source in my next email (by >> the end of the day). >> >> Thanks, >> >> >> On Tue, Jun 7, 2011 at 4:27 AM, Takuya OSHIMA >> wrote: >>> Hi Aashish, >>> >>> Would be great for me too if your reader may be shared (thus we have >>> more options for importing Shapefiles)! >>> >>> Takuya >>> >>> Takuya OSHIMA, Ph.D. >>> Faculty of Engineering, Niigata University >>> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >>> >>> From: Aashish Chaudhary >>> Subject: Re: [Paraview] Shapefiles to Paraview (or VTK) format >>> Date: Mon, 6 Jun 2011 10:29:22 -0400 >>> >>>> Hi Lester, >>>> >>>> I have a Shapefile reader (actually a vector format reader) for VTK. >>>> You would have to write a program to use it (I can send a sample app >>>> too). It will require VTK and GDAL. >>>> >>>> I can send you the code in my next email if you are interested. >>>> >>>> Regards, >>>> >>>> >>>> >>>> On Sun, Jun 5, 2011 at 11:16 AM, Robert Maynard >>>> wrote: >>>>> It should be noted that the implementation in ParaViewGeo is LGPL not BSD. >>>>> >>>>> On Sun, Jun 5, 2011 at 6:33 AM, Takuya OSHIMA >>>>> wrote: >>>>>> >>>>>> Just to share my finding, ParaViewGeo has a Shapefile reader plugin. >>>>>> http://paraviewgeo.mirarco.org/index.php/Main_Page >>>>>> >>>>>> Several warnings are issued when I tried to compile the plugin in >>>>>> conjunction with the latest git master of PV. Besides I don't know if >>>>>> it is supposed to be a complete implementation, but as far as I tested >>>>>> importing geometry worked. >>>>>> >>>>>> Takuya >>>>>> >>>>>> Takuya OSHIMA, Ph.D. >>>>>> Faculty of Engineering, Niigata University >>>>>> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >>>>>> >>>>>> >>>>>> From: Lester Anderson >>>>>> Subject: [Paraview] Shapefiles to Paraview (or VTK) format >>>>>> Date: Wed, 16 Mar 2011 09:19:24 + >>>>>> >>>>>> > >>>>>> > Hello >>>>>> > >>>>>> > Is there an easy way to get Shapefile data from ArcGIS into Paraview? >>>>>> > It >>>>>> > is an important file format and one which is widely used so it would be >>>>>> > great if there was a method of importing this. As I see it, one has to >>>>>> > somehow convert the format to a VTK structure (vector-based), not sure >>>>>> > of >>>>>> > the easiest solution. >>>>>> > >>>>>> > Any suggestions? >>>>>> > >>>>>> > Thanks >>>>>> > >>>>>> > Lester >>>>>> > >>>>>> ___ >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Visit other Kitware open-source projects at >>>>>> http://www.kitware.com/opensource/opensource
Re: [Paraview] Shapefiles to Paraview (or VTK) format
Hi Aashish, Would be great for me too if your reader may be shared (thus we have more options for importing Shapefiles)! Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Aashish Chaudhary Subject: Re: [Paraview] Shapefiles to Paraview (or VTK) format Date: Mon, 6 Jun 2011 10:29:22 -0400 > Hi Lester, > > I have a Shapefile reader (actually a vector format reader) for VTK. > You would have to write a program to use it (I can send a sample app > too). It will require VTK and GDAL. > > I can send you the code in my next email if you are interested. > > Regards, > > > > On Sun, Jun 5, 2011 at 11:16 AM, Robert Maynard > wrote: >> It should be noted that the implementation in ParaViewGeo is LGPL not BSD. >> >> On Sun, Jun 5, 2011 at 6:33 AM, Takuya OSHIMA >> wrote: >>> >>> Just to share my finding, ParaViewGeo has a Shapefile reader plugin. >>> http://paraviewgeo.mirarco.org/index.php/Main_Page >>> >>> Several warnings are issued when I tried to compile the plugin in >>> conjunction with the latest git master of PV. Besides I don't know if >>> it is supposed to be a complete implementation, but as far as I tested >>> importing geometry worked. >>> >>> Takuya >>> >>> Takuya OSHIMA, Ph.D. >>> Faculty of Engineering, Niigata University >>> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >>> >>> >>> From: Lester Anderson >>> Subject: [Paraview] Shapefiles to Paraview (or VTK) format >>> Date: Wed, 16 Mar 2011 09:19:24 + >>> >>> > >>> > Hello >>> > >>> > Is there an easy way to get Shapefile data from ArcGIS into Paraview? It >>> > is an important file format and one which is widely used so it would be >>> > great if there was a method of importing this. As I see it, one has to >>> > somehow convert the format to a VTK structure (vector-based), not sure of >>> > the easiest solution. >>> > >>> > Any suggestions? >>> > >>> > Thanks >>> > >>> > Lester >>> > >>> ___ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Please keep messages on-topic and check the ParaView Wiki at: >>> http://paraview.org/Wiki/ParaView >>> >>> Follow this link to subscribe/unsubscribe: >>> http://www.paraview.org/mailman/listinfo/paraview >> >> >> >> -- >> Robert Maynard >> >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the ParaView Wiki at: >> http://paraview.org/Wiki/ParaView >> >> Follow this link to subscribe/unsubscribe: >> http://www.paraview.org/mailman/listinfo/paraview >> >> > > > > -- > | Aashish Chaudhary > | R&D Engineer > | Kitware Inc. > | www.kitware.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Shapefiles to Paraview (or VTK) format
Just to share my finding, ParaViewGeo has a Shapefile reader plugin. http://paraviewgeo.mirarco.org/index.php/Main_Page Several warnings are issued when I tried to compile the plugin in conjunction with the latest git master of PV. Besides I don't know if it is supposed to be a complete implementation, but as far as I tested importing geometry worked. Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Lester Anderson Subject: [Paraview] Shapefiles to Paraview (or VTK) format Date: Wed, 16 Mar 2011 09:19:24 + > > Hello > > Is there an easy way to get Shapefile data from ArcGIS into Paraview? It is > an important file format and one which is widely used so it would be great if > there was a method of importing this. As I see it, one has to somehow convert > the format to a VTK structure (vector-based), not sure of the easiest > solution. > > Any suggestions? > > Thanks > > Lester > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Connecting/Disconnecting to pvservers multiple times doesn't work
Tested the latest git master and it's working now. Thanks Utkarsh. Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Utkarsh Ayachit Subject: Re: [Paraview] Connecting/Disconnecting to pvservers multiple times doesn't work Date: Fri, 3 Jun 2011 10:05:06 -0400 > I've committed a fix for this. Feel free to give it a try. > > Utkarsh > > On Fri, Jun 3, 2011 at 9:17 AM, Utkarsh Ayachit > wrote: >> I was able to reproduce it. I'll track it down, thanks. >> >> Utkarsh >> >> 2011/5/31 Takuya OSHIMA : >>> Yes I am starting pvservers from the server config as attached. >>> >>> And now I noticed that I don't have the problem if I start pvservers >>> manually from the command line and let the client connect to the >>> pvservers. >>> >>> Takuya >>> >>> Takuya OSHIMA, Ph.D. >>> Faculty of Engineering, Niigata University >>> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >>> >>> From: Utkarsh Ayachit >>> Subject: Re: [Paraview] Connecting/Disconnecting to pvservers multiple >>> times doesn't work >>> Date: Tue, 31 May 2011 08:53:14 -0400 >>> >>>> Interesting, I could not reproduce the problem. Are the server-configs >>>> that you are trying to connect also staring the pvserver process? Can >>>> you post the server config you're trying to use? Maybe I can try to >>>> reproduce the problem with that server config. >>>> >>>> Utkarsh >>> >>> >>> >> ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Connecting/Disconnecting to pvservers multiple times doesn't work
Yes I am starting pvservers from the server config as attached. And now I noticed that I don't have the problem if I start pvservers manually from the command line and let the client connect to the pvservers. Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Utkarsh Ayachit Subject: Re: [Paraview] Connecting/Disconnecting to pvservers multiple times doesn't work Date: Tue, 31 May 2011 08:53:14 -0400 > Interesting, I could not reproduce the problem. Are the server-configs > that you are trying to connect also staring the pvserver process? Can > you post the server config you're trying to use? Maybe I can try to > reproduce the problem with that server config. > > Utkarsh servers.pvsc Description: Binary data ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Connecting/Disconnecting to pvservers multiple times doesn't work
Hi,
I've got another problem with the client server mode when trying to
connecting/disconnecting to pvservers multiple times. Try this:
1. File->Connect...
2. Choose a properly configured entry from the "Choose a servrer:" list
3. File->Disconnect
4. File->Connect...
5. Choose a properly configured entry from the "Choose a servrer:" list
Then pvserver doesn't start. Both the
12240_cleanup_proxy_definition_manager branch and the git master has
the problem but the console logs are different.
(12240_cleanup_proxy_definition_manager)
Unknown server type: ""
(git master)
Multiple server connections not supported yet.
Requesting to remove a non-added server.
ERROR: In
/Volumes/RAID0data/paraview/ParaView/ParaViewCore/ServerImplementation/vtkPVSessionCore.cxx,
line 317
vtkPVSessionCore (0x12003eea0): Attempt to assign existing ID 1.
while processing
Message 0 = Assign
Argument 0 = id_value {1}
Argument 1 = vtk_object_pointer {vtkPVSessionCoreInterpreterHelper
(0x120031220)}
ERROR: In
/Volumes/RAID0data/paraview/ParaView/ParaViewCore/ServerImplementation/vtkPVSessionCore.cxx,
line 318
vtkPVSessionCore (0x12003eea0): Aborting execution for debugging purposes.
Here's the bug report:
http://paraview.org/Bug/view.php?id=12241
Thanks,
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Calling GetProperty() of server manager proxy object from plugin object panel
So I pulled the stage branch 12240_cleanup_proxy_definition_manager
mentioned in another post, rebuilt ParaView and the plugin is working
again. Thanks!
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Utkarsh Ayachit
Subject: Re: [Paraview] Calling GetProperty() of server manager proxy object
from plugin object panel
Date: Mon, 30 May 2011 16:45:14 -0400
> Takuya,
>
> Your problem may be related to an issue recently posted on the list by
> John Biddiscombe, titled "custom filters missing from menus". I am
> looking into the issue.
>
> Utkarsh
>
> On Mon, May 30, 2011 at 9:47 AM, Utkarsh Ayachit
> wrote:
>> Get the XMLName and XMLGroup for the proxy you are accessing. Is it
>> what you expect?
>>
>> Utkarsh
>>
>> 2011/5/30 Takuya OSHIMA :
>>> Yes. I can see that the server side plugin (which is not a pure-XML
>>> plugin but a dylib) is loaded in the plugin manager screen.
>>>
>>> Takuya
>>>
>>> Takuya OSHIMA, Ph.D.
>>> Faculty of Engineering, Niigata University
>>> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
>>>
>>> From: Utkarsh Ayachit
>>> Subject: Re: [Paraview] Calling GetProperty() of server manager proxy
>>> object from plugin object panel
>>> Date: Mon, 30 May 2011 09:30:32 -0400
>>>
>>>> Is the plugin being loaded on the server-side as well? XML's are now
>>>> fetched from the server-side in ParaView so pure-XML plugins should
>>>> be loaded on server-side as well.
>>>>
>>>> Utkarsh
>>>>
>>>> On Sun, May 29, 2011 at 5:37 AM, Takuya OSHIMA
>>>> wrote:
>>>> > Hi,
>>>> >
>>>> > In the GUI panel (a subclass of pqAutoGeneratedObjectPanel) of my
>>>> > reader plugin I have lines getting property of its corresponding
>>>> > server manager proxy object, like
>>>> > vtkSMIntVectorProperty *uiRescale
>>>> > =
>>>> > vtkSMIntVectorProperty::SafeDownCast(this->proxy()->GetProperty("UiRescale"));
>>>> >
>>>> > This works fine with PV 3.10.1 in both builtin and client server modes,
>>>> > and in builtin mode of PV git master. However in client server mode of
>>>> > PV git master as of today, the call
>>>> > this->proxy()->GetProperty("UiRescale")
>>>> > returns a null pointer. Did anything in this regard change with the
>>>> > git master?
>>>> >
>>>> > The tested platform is OS X 10.6.7, Qt 4.7.2, CMake 2.8.4.
>>>> >
>>>> > Thanks,
>>>> > Takuya
>>>> >
>>>> > Takuya OSHIMA, Ph.D.
>>>> > Faculty of Engineering, Niigata University
>>>> > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
>>>> > ___
>>>> > Powered by www.kitware.com
>>>> >
>>>> > Visit other Kitware open-source projects at
>>>> > http://www.kitware.com/opensource/opensource.html
>>>> >
>>>> > Please keep messages on-topic and check the ParaView Wiki at:
>>>> > http://paraview.org/Wiki/ParaView
>>>> >
>>>> > Follow this link to subscribe/unsubscribe:
>>>> > http://www.paraview.org/mailman/listinfo/paraview
>>>> >
>>>
>>
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Calling GetProperty() of server manager proxy object from plugin object panel
Yes. I can see that the server side plugin (which is not a pure-XML
plugin but a dylib) is loaded in the plugin manager screen.
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Utkarsh Ayachit
Subject: Re: [Paraview] Calling GetProperty() of server manager proxy object
from plugin object panel
Date: Mon, 30 May 2011 09:30:32 -0400
> Is the plugin being loaded on the server-side as well? XML's are now
> fetched from the server-side in ParaView so pure-XML plugins should
> be loaded on server-side as well.
>
> Utkarsh
>
> On Sun, May 29, 2011 at 5:37 AM, Takuya OSHIMA
> wrote:
> > Hi,
> >
> > In the GUI panel (a subclass of pqAutoGeneratedObjectPanel) of my
> > reader plugin I have lines getting property of its corresponding
> > server manager proxy object, like
> > vtkSMIntVectorProperty *uiRescale
> > =
> > vtkSMIntVectorProperty::SafeDownCast(this->proxy()->GetProperty("UiRescale"));
> >
> > This works fine with PV 3.10.1 in both builtin and client server modes,
> > and in builtin mode of PV git master. However in client server mode of
> > PV git master as of today, the call
> > this->proxy()->GetProperty("UiRescale")
> > returns a null pointer. Did anything in this regard change with the
> > git master?
> >
> > The tested platform is OS X 10.6.7, Qt 4.7.2, CMake 2.8.4.
> >
> > Thanks,
> > Takuya
> >
> > Takuya OSHIMA, Ph.D.
> > Faculty of Engineering, Niigata University
> > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
> > ___
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the ParaView Wiki at:
> > http://paraview.org/Wiki/ParaView
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.paraview.org/mailman/listinfo/paraview
> >
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Calling GetProperty() of server manager proxy object from plugin object panel
Hi,
In the GUI panel (a subclass of pqAutoGeneratedObjectPanel) of my
reader plugin I have lines getting property of its corresponding
server manager proxy object, like
vtkSMIntVectorProperty *uiRescale
=
vtkSMIntVectorProperty::SafeDownCast(this->proxy()->GetProperty("UiRescale"));
This works fine with PV 3.10.1 in both builtin and client server modes,
and in builtin mode of PV git master. However in client server mode of
PV git master as of today, the call
this->proxy()->GetProperty("UiRescale")
returns a null pointer. Did anything in this regard change with the
git master?
The tested platform is OS X 10.6.7, Qt 4.7.2, CMake 2.8.4.
Thanks,
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] origin of arc_length after application of "plot on intersection line" filter
waku2005, * Make the intersection line visible in the 3D view by clicking the eye-icon * Open Selection Inspector * Choose the PlotOnIntersectionCurve object from Current Object * Click Create Selection * Choose POINT from Field Type * Click New Value * Enter Composite ID of your interst DataSet from the Data Hierarchy list on the left * Enter 0 in the Index field And you should be able to see the origin point is highlighted in the 3D view and the 2D plot view. Additionaly, you can see which points in 3D view corresponds to which part of the plot by clicking Select Points On in the menu bar and selecting the points by mouse, with point ID labels if you further do * Click Point Label in the selection inspector * Check Visible * Label Mode: Point IDs. Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: waku2005 Subject: [Paraview] origin of arc_length after application of "plot on intersection line" filter Date: Tue, 24 May 2011 16:50:53 +0900 > Dear all; > > I have been calculated a flow around a car in a duct. > I hope to know the distribution of pressure coefficient on the body > surface, particularly on the typical intersection lines > in order to compare experimental results. > > Please let me know about the "plot on intersection line" > After plotting the surface pressure, I had applied the " plot on > intersection line" filter to the surface plot. > I choose a y-normal intersection (y = 0, center of the body) and the > plot will be done to the X-Z surface intersection line. > I can see the 2-D plot of pressure (Vert. axis) vs arc_length (Hori.axis). > > Then, my first question is where is the point of the arc_length == 0, > i.e., what are values of x and z at the arc_length == 0 ? > Second one is the calculation direction of the arc_length, because the > arc_length calculation can be defined CW or CCW to the y-normal axis. > > Best regards. > waku2...@gmail.com > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > > Follow this link to subscribe/unsubscribe: > http://www.paraview.org/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Problem with self-made VTK Unstructured Grid file in xml format
Hi Mathias, The content of "offsets" DataArray should be 8, not 1. Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: "win...@gmx.net" Subject: [Paraview] Problem with self-made VTK Unstructured Grid file in xml format Date: Mon, 23 May 2011 11:51:53 +0200 > Hello, > > I am currently writing my visualization data to vtk-xml files in > unstructured grid format. As long as I do not add any cell > information, this works fine. However, as soon as I have a single cell > inside my data, Paraview 3.10.1 (32 bit precompiled binary on SUSE > Linux) crashes when I press "Apply" after loading the data. > > In the attachment, there is a very small example of my files - can > anybody see a mistake therein? > > Thank you in advance, > > Mathias > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] openfoam reader for decomposed case
It is possible only with the development version of the reader hosted at SourceForge: svn co https://of-interfaces.svn.sourceforge.net/svnroot/of-interfaces/trunk/vtkPOFFReader Switch to decomposed case, hit Rescan, set timestep and hit Apply. Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Jacques Papper Subject: Re: [Paraview] openfoam reader for decomposed case Date: Thu, 21 Apr 2011 10:52:51 +0100 > This would indeed be a neet addition. > I don't believe there is a way of doing that at the moment though. > J. > > 2011/4/20 Fabian Braennstroem > >> Hi, >> >> I am frequently using the openfoam reader for a decomposed case. >> Is there a way to set the time before one needs to load the first "zero" >> time step? Using a reconstructed case type, it is possible to set the wanted >> time step. >> >> Thanks in advance! >> Fabian >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the ParaView Wiki at: >> http://paraview.org/Wiki/ParaView >> >> Follow this link to subscribe/unsubscribe: >> http://www.paraview.org/mailman/listinfo/paraview >> ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] ANN: Upcoming changes to ParaView Server Manager
Thanks again for the clarification!
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Sebastien Jourdain
Subject: Re: [Paraview] ANN: Upcoming changes to ParaView Server Manager
Date: Tue, 29 Mar 2011 09:34:09 -0400
> Hi Takuya,
>
> >> NEW2: pxy->ExecuteStream(stream)
> >
> > In fact, this is not possible because vtkSMProxy::ExecuteStream() is
> > protected (is this a bug or intended?).
>
> It is intended, specially if your are not inside the vtkSMProxy class
> implementation.
> It is more a helper method that use the proxy session and location to
> send and execute the stream that may not be related in any other way
> to that proxy.
>
> thanks,
>
> Seb
>
> >
> > Takuya
> >
> > Takuya OSHIMA, Ph.D.
> > Faculty of Engineering, Niigata University
> > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
> >
> >
> > From: Sebastien Jourdain
> > Subject: Re: [Paraview] ANN: Upcoming changes to ParaView Server Manager
> > Date: Tue, 29 Mar 2011 08:37:14 -0400
> >
> >> Hi Takuya,
> >>
> >> I'm glad that you gave a try and you managed to make your plugin work.
> >> Moreover, thanks for that "cheat sheet".
> >>
> >> Here is my feedback about it:
> >>
> >>> OLD: pxy->Set/GetServers() (where pxy is a vtkSMProxy)
> >>> NEW: pxy->Set/GetLocation()
> >>
> >> Yes
> >>
> >>> OLD: pxy->Set/GetConnectionID()
> >>> NEW: pxy->Set/GetSession()
> >>
> >> Yes, but those lines should simply be removed as the session is set on
> >> the Proxy at its creation, therefore there is no point in doing it
> >> twice.
> >>
> >>> OLD: pxy->GetID()
> >>> NEW: VTKOBJECT(pxy) (a stream operator in client-server stream)
> >>
> >> Yes
> >>
> >>> OLD: pm->SendSteram(this->GetConnectionID(), this->GetServers(), stream)
> >>> NEW: this->ExecuteStream(stream) (where this is a vtkSMProxy)
> >>
> >> Yes
> >>
> >>> OLD: pm->SendStream(pxy->GetConnectionID(), pxy->GetServers(), stream)
> >>> NEW: pxy->GetSession()->ExecuteStream(pxy->GetLocation(), stream)
> >>> (where pm is a vtkProcessModule)
> >>
> >> Yes, but as you did it previously you can also do that
> >> NEW2: pxy->ExecuteStream(stream)
> >>
> >>> Also, what I noticed so far are
> >>> * CoProcessing module does not build due to some missing headers.
> >>
> >> I'm going to look into that and fix it. Thanks to have notice it.
> >>
> >>> * ParaViewCore/ServerManager/vtkSMDataSourceProxy.{cxx,h} are orphaned
> >>> (have no reference from other sources or CMakeLists).
> >>
> >> Yes, I was planning to remove it. Are you using it ?
> >>
> >> Thanks again for those valuable comments,
> >>
> >> Seb
> >
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] ANN: Upcoming changes to ParaView Server Manager
Sorry I hit send too early:
>> * ParaViewCore/ServerManager/vtkSMDataSourceProxy.{cxx,h} are orphaned
>> (have no reference from other sources or CMakeLists).
>
> Yes, I was planning to remove it. Are you using it ?
No.
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Sebastien Jourdain
Subject: Re: [Paraview] ANN: Upcoming changes to ParaView Server Manager
Date: Tue, 29 Mar 2011 08:37:14 -0400
> Hi Takuya,
>
> I'm glad that you gave a try and you managed to make your plugin work.
> Moreover, thanks for that "cheat sheet".
>
> Here is my feedback about it:
>
>> OLD: pxy->Set/GetServers() (where pxy is a vtkSMProxy)
>> NEW: pxy->Set/GetLocation()
>
> Yes
>
>> OLD: pxy->Set/GetConnectionID()
>> NEW: pxy->Set/GetSession()
>
> Yes, but those lines should simply be removed as the session is set on
> the Proxy at its creation, therefore there is no point in doing it
> twice.
>
>> OLD: pxy->GetID()
>> NEW: VTKOBJECT(pxy) (a stream operator in client-server stream)
>
> Yes
>
>> OLD: pm->SendSteram(this->GetConnectionID(), this->GetServers(), stream)
>> NEW: this->ExecuteStream(stream) (where this is a vtkSMProxy)
>
> Yes
>
>> OLD: pm->SendStream(pxy->GetConnectionID(), pxy->GetServers(), stream)
>> NEW: pxy->GetSession()->ExecuteStream(pxy->GetLocation(), stream)
>> (where pm is a vtkProcessModule)
>
> Yes, but as you did it previously you can also do that
> NEW2: pxy->ExecuteStream(stream)
>
>> Also, what I noticed so far are
>> * CoProcessing module does not build due to some missing headers.
>
> I'm going to look into that and fix it. Thanks to have notice it.
>
>> * ParaViewCore/ServerManager/vtkSMDataSourceProxy.{cxx,h} are orphaned
>> (have no reference from other sources or CMakeLists).
>
> Yes, I was planning to remove it. Are you using it ?
>
> Thanks again for those valuable comments,
>
> Seb
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] ANN: Upcoming changes to ParaView Server Manager
Seb, thanks for the clarifications, especially pointing out
that Set/GetSession() are redundant.
>> OLD: pm->SendStream(pxy->GetConnectionID(), pxy->GetServers(), stream)
>> NEW: pxy->GetSession()->ExecuteStream(pxy->GetLocation(), stream)
>> (where pm is a vtkProcessModule)
>
> Yes, but as you did it previously you can also do that
> NEW2: pxy->ExecuteStream(stream)
In fact, this is not possible because vtkSMProxy::ExecuteStream() is
protected (is this a bug or intended?).
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Sebastien Jourdain
Subject: Re: [Paraview] ANN: Upcoming changes to ParaView Server Manager
Date: Tue, 29 Mar 2011 08:37:14 -0400
> Hi Takuya,
>
> I'm glad that you gave a try and you managed to make your plugin work.
> Moreover, thanks for that "cheat sheet".
>
> Here is my feedback about it:
>
>> OLD: pxy->Set/GetServers() (where pxy is a vtkSMProxy)
>> NEW: pxy->Set/GetLocation()
>
> Yes
>
>> OLD: pxy->Set/GetConnectionID()
>> NEW: pxy->Set/GetSession()
>
> Yes, but those lines should simply be removed as the session is set on
> the Proxy at its creation, therefore there is no point in doing it
> twice.
>
>> OLD: pxy->GetID()
>> NEW: VTKOBJECT(pxy) (a stream operator in client-server stream)
>
> Yes
>
>> OLD: pm->SendSteram(this->GetConnectionID(), this->GetServers(), stream)
>> NEW: this->ExecuteStream(stream) (where this is a vtkSMProxy)
>
> Yes
>
>> OLD: pm->SendStream(pxy->GetConnectionID(), pxy->GetServers(), stream)
>> NEW: pxy->GetSession()->ExecuteStream(pxy->GetLocation(), stream)
>> (where pm is a vtkProcessModule)
>
> Yes, but as you did it previously you can also do that
> NEW2: pxy->ExecuteStream(stream)
>
>> Also, what I noticed so far are
>> * CoProcessing module does not build due to some missing headers.
>
> I'm going to look into that and fix it. Thanks to have notice it.
>
>> * ParaViewCore/ServerManager/vtkSMDataSourceProxy.{cxx,h} are orphaned
>> (have no reference from other sources or CMakeLists).
>
> Yes, I was planning to remove it. Are you using it ?
>
> Thanks again for those valuable comments,
>
> Seb
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] ANN: Upcoming changes to ParaView Server Manager
Hi,
I think it would be helpful if there is a quick guidance about what
changes to what in typical cases, for example what I have figured out
for my plugin are (am I correct about all these?):
OLD: pxy->Set/GetServers() (where pxy is a vtkSMProxy)
NEW: pxy->Set/GetLocation()
OLD: pxy->Set/GetConnectionID()
NEW: pxy->Set/GetSession()
OLD: pxy->GetID()
NEW: VTKOBJECT(pxy) (a stream operator in client-server stream)
OLD: pm->SendSteram(this->GetConnectionID(), this->GetServers(), stream)
NEW: this->ExecuteStream(stream) (where this is a vtkSMProxy)
OLD: pm->SendStream(pxy->GetConnectionID(), pxy->GetServers(), stream)
NEW: pxy->GetSession()->ExecuteStream(pxy->GetLocation(), stream)
(where pm is a vtkProcessModule)
Also, what I noticed so far are
* CoProcessing module does not build due to some missing headers.
* ParaViewCore/ServerManager/vtkSMDataSourceProxy.{cxx,h} are orphaned
(have no reference from other sources or CMakeLists).
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Sebastien Jourdain
Subject: [Paraview] ANN: Upcoming changes to ParaView Server Manager
Date: Mon, 28 Mar 2011 15:29:14 -0400
> Folks,
>
> For those of you who haven't follow the topic in the
> paraview-developers mailing list here is a quick summary on what's
> going on in the coming weeks.
> We've been working for a while now on restructuring the Server Manager
> of ParaView to make it more efficient as well as allowing it to
> support collaborative workflows.
> The API has undergone major changes and may cause some minor rewrite
> of your own code. Before we merge these changes to master, please try
> out the Collaboration branch with your code and let us know if you
> experience any issue.
> Please see below for the details on how to checkout the Collaboration branch.
>
> Thanks for your support,
>
> Seb
>
> = From the ParaView-developer list ===
>
> Following up the mail from Utkarsh on the changes to ParaView Server Manager :
>
> http://public.kitware.com/pipermail/paraview-developers/2011-February/000951.html
>
> We finally push our branch to the stage. That branch will only be
> merged to master in the coming month.
> But if you have developed a plugin or any code based on ParaView and
> you want to test it against
> that major update, please follow the coming instructions and don't
> hesitate to send us your feed back.
>
> In order to fetch our ParaView branch from stage, you will need to
> execute the following command line:
>
> $ git clone --recursive git://paraview.org/stage/ParaView.git -b Collaboration
>
> Then, as any regular ParaView source directory, you should be able to
> configure and build it.
> As some directory and kit renaming occurred, you may need to update
> the name of the ParaView library that you are linking against. Now the
> ParaViewCore package which used to be called "Servers" contains the
> following kits:
> vtkPVCommon, vtkPVClientServerCore, vtkPVServerImplementation,
> vtkPVServerManager, vtkPVVTKExtensions.
>
> Please remember, these do not affect 3.10 or even 3.10.1. These will
> make into the
> official ParaView 4.0 release, nothing sooner.
>
> Seb
>
> PS: Additional informations on those changes are available here
> http://paraview.org/ParaView3/images/2/24/ParaViewCollaborationChanges.pdf
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://www.paraview.org/mailman/listinfo/paraview
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] paraview 3.10 + OpenFOAM
Yes the cavity tutorial. AFAIK there's no OpenFOAM dataset being used for testing ( http://paraview.org/Bug/view.php?id=10247 ), so I attached Mark's cavity dataset (with addition of a .foam stub). Dave, open cavity.foam in the archive and Apply. Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: "OLESEN Mark" Subject: RE: [Paraview] paraview 3.10 + OpenFOAM Date: Thu, 17 Mar 2011 13:06:10 +0100 > Is there currently any particular OpenFOAM dataset being used for testing? If > so, I could convert it into the compact-face format. > > Otherwise the dataset from Takuya (cavity tutorial I think) should be okay - > there are no license issues. > >> I have a dataset contributed by Mark but am not sure about its >> license. Mark, do you have any? cavity.tar.bz2 Description: Binary data ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] paraview 3.10 + OpenFOAM
I have a dataset contributed by Mark but am not sure about its license. Mark, do you have any? Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: David Partyka Subject: Re: [Paraview] paraview 3.10 + OpenFOAM Date: Thu, 17 Mar 2011 07:47:06 -0400 > Hey Takuya and Mark, > > Do either of you have a dataset that could be included in ParaViewData to > make a simple regression test that exercises this functionality? > > Thanks! > > On Thu, Mar 17, 2011 at 7:18 AM, Takuya OSHIMA > wrote: > >> Mark, looking forward to hearing your test results, that's where you >> can definitely contribute ;-) >> >> Takuya >> >> Takuya OSHIMA, Ph.D. >> Faculty of Engineering, Niigata University >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> >> >> This has been applied to release and master. >> > >> > Perfect! Thanks David and Takuya. >> > Sorry I still didn't have time to compile and test it myself. >> > >> > /mark >> ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] paraview 3.10 + OpenFOAM
Mark, looking forward to hearing your test results, that's where you can definitely contribute ;-) Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> This has been applied to release and master. > > Perfect! Thanks David and Takuya. > Sorry I still didn't have time to compile and test it myself. > > /mark ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] paraview 3.10 + OpenFOAM
Thanks, David! Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: David Partyka Subject: Re: [Paraview] paraview 3.10 + OpenFOAM Date: Wed, 16 Mar 2011 11:52:52 -0400 > This has been applied to release and master. > > http://vtk.org/gitweb?p=VTK.git;a=commit;h=9fda3e707034e45adc261f66089de5d7711d870e > > On Wed, Mar 16, 2011 at 8:33 AM, Takuya OSHIMA > wrote: > >> I filed a bug for this: >> http://www.paraview.org/Bug/view.php?id=11974 >> The patch is also attached to this mail. >> >> As Mark says it would be very important, so we really hope to see this >> included in the upcoming 3.10.1 release. >> >> Thanks! >> Takuya >> >> Takuya OSHIMA, Ph.D. >> Faculty of Engineering, Niigata University >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> >> From: David Partyka >> Subject: Re: [Paraview] paraview 3.10 + OpenFOAM >> Date: Fri, 11 Mar 2011 05:32:05 -0500 >> >> > It was released two days ago ;-). Your patch most certainly could be >> > included for the next release. If you want, submit a bug on >> > paraview.org/Bugwith your patch, and possibly a dataset and >> > instructions to recreate the >> > original issue. >> > >> > Thanks! >> > >> > On Fri, Mar 11, 2011 at 3:21 AM, OLESEN Mark > >wrote: >> > >> >> When is 3.10 slated for release? >> >> I have a patch from Takuya OSHIMA for handling a compact face format in >> >> OpenFOAM. It would be very important to get this in before the next >> release. >> >> What tests are needed and what is the time-frame to squeezing in this >> type >> >> of change before the 3.10 release? >> >> >> >> /mark >> >> >> >> >> >> DISCLAIMER: >> >> This electronic transmission (and any attachments thereto) is intended >> >> solely for the use of the addressee(s). It may contain confidential or >> >> legally privileged information. If you are not the intended recipient of >> >> this message, you must delete it immediately and notify the sender. Any >> >> unauthorized use or disclosure of this message is strictly prohibited. >> >> Faurecia does not guarantee the integrity of this transmission and shall >> >> therefore never be liable if the message is altered or falsified nor for >> any >> >> virus, interception or damage to your system. >> >> >> >> ___ >> >> Powered by www.kitware.com >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Please keep messages on-topic and check the ParaView Wiki at: >> >> http://paraview.org/Wiki/ParaView >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://www.paraview.org/mailman/listinfo/paraview >> >> >> ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] paraview 3.10 + OpenFOAM
I filed a bug for this:
http://www.paraview.org/Bug/view.php?id=11974
The patch is also attached to this mail.
As Mark says it would be very important, so we really hope to see this
included in the upcoming 3.10.1 release.
Thanks!
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: David Partyka
Subject: Re: [Paraview] paraview 3.10 + OpenFOAM
Date: Fri, 11 Mar 2011 05:32:05 -0500
> It was released two days ago ;-). Your patch most certainly could be
> included for the next release. If you want, submit a bug on
> paraview.org/Bugwith your patch, and possibly a dataset and
> instructions to recreate the
> original issue.
>
> Thanks!
>
> On Fri, Mar 11, 2011 at 3:21 AM, OLESEN Mark wrote:
>
>> When is 3.10 slated for release?
>> I have a patch from Takuya OSHIMA for handling a compact face format in
>> OpenFOAM. It would be very important to get this in before the next release.
>> What tests are needed and what is the time-frame to squeezing in this type
>> of change before the 3.10 release?
>>
>> /mark
>>
>>
>> DISCLAIMER:
>> This electronic transmission (and any attachments thereto) is intended
>> solely for the use of the addressee(s). It may contain confidential or
>> legally privileged information. If you are not the intended recipient of
>> this message, you must delete it immediately and notify the sender. Any
>> unauthorized use or disclosure of this message is strictly prohibited.
>> Faurecia does not guarantee the integrity of this transmission and shall
>> therefore never be liable if the message is altered or falsified nor for any
>> virus, interception or damage to your system.
>>
>> ___
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ParaView Wiki at:
>> http://paraview.org/Wiki/ParaView
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.paraview.org/mailman/listinfo/paraview
>>
diff --git a/IO/vtkOpenFOAMReader.cxx b/IO/vtkOpenFOAMReader.cxx
index e9870cb..7445c6f 100644
--- a/IO/vtkOpenFOAMReader.cxx
+++ b/IO/vtkOpenFOAMReader.cxx
@@ -348,8 +348,6 @@ struct vtkFoamIntVectorVector
private:
vtkIntArray *Indices, *Body;
- vtkFoamIntVectorVector();
-
public:
~vtkFoamIntVectorVector()
{
@@ -363,6 +361,10 @@ public:
this->Indices->Register(0); // vtkDataArrays do not have ShallowCopy
this->Body->Register(0);
}
+ vtkFoamIntVectorVector() :
+Indices(vtkIntArray::New()), Body(vtkIntArray::New())
+ {
+ }
vtkFoamIntVectorVector(const int nElements, const int bodyLength) :
Indices(vtkIntArray::New()), Body(vtkIntArray::New())
{
@@ -2406,6 +2408,51 @@ public:
}
}
+ // reads compact list of labels.
+ void ReadCompactIOLabelList(vtkFoamIOobject& io)
+ {
+if (io.GetFormat() != vtkFoamIOobject::BINARY)
+ {
+ this->ReadLabelListList(io);
+ return;
+ }
+
+this->Superclass::LabelListListPtr = new vtkFoamIntVectorVector;
+this->Superclass::Type = LABELLISTLIST;
+for(int arrayI = 0; arrayI < 2; arrayI++)
+ {
+ vtkFoamToken currToken;
+ if (!io.Read(currToken))
+{
+throw vtkFoamError() << "Unexpected EOF";
+}
+ if (currToken.GetType() == vtkFoamToken::LABEL)
+{
+const int sizeI = currToken.To();
+if (sizeI < 0)
+ {
+ throw vtkFoamError() << "List size must not be negative: size = "
+ << sizeI;
+ }
+if (sizeI > 0) // avoid invalid reference
+ {
+ vtkIntArray *array = (arrayI == 0
+ ? this->Superclass::LabelListListPtr->GetIndices()
+ : this->Superclass::LabelListListPtr->GetBody());
+ array->SetNumberOfValues(sizeI);
+ io.ReadExpecting('(');
+ io.Read(reinterpret_cast(array->GetPointer(0)),
+ sizeI * sizeof(int));
+ io.ReadExpecting(')');
+ }
+}
+ else
+{
+throw vtkFoamError() << "Expected integer, found " << currToken;
+}
+ }
+ }
+
bool ReadField(vtkFoamIOobject& io)
{
try
@@ -4580,7 +4627,14 @@ vtkFoamIntVectorVector * vtkOpenFOAMReaderPrivate::ReadFacesFile(
vtkFoamEntryValue dict(NULL);
try
{
-dict.ReadLabelListList(io);
+if (io.GetClassName() == "faceCompactList")
+ {
+ dict.ReadCompactIOLabelList(io);
+ }
+else
+ {
+ dict.ReadLabelListList(io);
+ }
}
catc
Re: [Paraview] mysterious linker error for custom library in custom PV Plugin
I guess 'extern "C"' is missing in the declaration of fioOpen?
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Christine Corbett Moran
Subject: [Paraview] mysterious linker error for custom library in custom PV
Plugin
Date: Thu, 3 Mar 2011 16:57:48 +0100
> I have a problem with building/linking to an external library I've called
> libfio. The library builds, and I can link programs against it from the
> command line. However my final plugin always comes up with a "ld: symbol(s)
> not found". I have several other libraries which are linked against just
> fine in my plugin, it is only this one which creates a problem.
>
> I'm on OS X 10.6, using gcc version 4.2.1 (Apple Inc. build 5664). I have
> tried building it both as a shared and static library, from both CMake and
> externally (then linking from within CMake). I have several other libraries
> I rely on which function perfectly well under any of the previous setups:
> {shared,static} x {built within plugin cmake, built externally} x {c,cxx}.
> However with this set of .c files I always get a linking error, and it's
> the same for any of the previous permutations. Under any configuration I'm
> able to link against it from the command line. That is to say for the
> example for a shared library built within the PV plugin CMake: libfio.dylib
> is created within my build directory ParaViz_build, and doing e.g. gcc
> grafic2csv.c -lfio
> -L/Users/corbett/Documents/Projects/pvaddons/ParaViz/ParaViz_build/ -o
> grafic2csv has no linking errors, where grafic2csv contains the identical
> code which later offends the linker within my plugin (see below for sample).
>
> Example make output for a shared library built within the PV Plugin CMake:
> ...
> [ 11%] Built target TipsyHelpers
> [ 13%] Building C object CMakeFiles/fio.dir/fio/fio.c.o
> [ 14%] Building C object CMakeFiles/fio.dir/fio/romberg.c.o
> Linking C shared library libfio.dylib
> [ 14%] Built target fio
> [ 16%] Building C object CMakeFiles/SQLitelib.dir/sqlitelib/sqlite3.c.o
> Linking C static library libSQLitelib.a
> [ 16%] Built target SQLitelib
> ..
> [ 98%] Building CXX object
> CMakeFiles/AstroVizPlugin.dir/AstroVizPlugin_Plugin.cxx.o
> [100%] Building CXX object
> CMakeFiles/AstroVizPlugin.dir/moc_AstroVizPlugin_Plugin.cxx.o
> Linking CXX shared library libAstroVizPlugin.dylib
> Undefined symbols:
> "fioOpen(char const*, double, double)", referenced from:
> vtkGraficReader::RequestData(vtkInformation*, vtkInformationVector**,
> vtkInformationVector*)in vtkGraficReader.cxx.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[2]: *** [libAstroVizPlugin.dylib] Error 1
> make[1]: *** [CMakeFiles/AstroVizPlugin.dir/all] Error 2
> make: *** [all] Error 2
>
>
>
> Example CMake for building a static library with the PV Plugin CMake:
>
> ADD_LIBRARY(
> fio
> STATIC
> fio/fio.c
> fio/romberg.c
> )
> SET_TARGET_PROPERTIES(fio PROPERTIES LINKER_LANGUAGE C)
> SET_TARGET_PROPERTIES(fio PROPERTIES COMPILE_FLAGS "-fPIC")
>
> TARGET_LINK_LIBRARIES(
> AstroVizPlugin
> fio
> TipsyHelpers
> SQLitelib
> )
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Paraview/pvserver running very slow
Florian, Is there any reason you prefer to load such a big case with reconstructed? The OpenFOAM reader (and subsequent filters) runs in parallel only for decomposed cases. For reconstructed cases the reader loads everything in process 0. Also, are you sure you built ParaView with compiler optimizations (CMAKE_BUILD_TYPE = Release)? Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Florian Lindner Subject: [Paraview] Paraview/pvserver running very slow Date: Mon, 28 Feb 2011 13:15:15 +0100 > > Hello, > > I’m running paraview 3.8.1 under linux using 8 cpus loading a > reconstructed openfoam case with about 13GB per timestep (we have just > two time steps, start 0 and result 1). The machine on which pvserver > runs has 16 cpus and 70GB RAM, but pvserver uses just a small fraction > of the ram. > > Loading the case takes about 5 minutes (which would be fine, if > subsequent operations were running more smoothly). > Adding a slice takes another couple of minutes. Rotating (using the > mouse) takes about 10sec for one frame to be rendered (the slice is > constant colored). Computing 100 streamlines from a line source takes > about 10 minutes, moving the view is fluent. As soon as the slice is > displayed moving the view becomes extremely slow again. > > I have also tried to convert the mesh to VTK which does not really > change something. (Resulting VTK is of 37GB size). > > At this state interactive work is not possible. Since the dataset is > not extraordinary large (I think), I suspect a problem with our MPI > configuration. > > Offscreen rendering works (I think), we have 8 windows "Visualization > Toolkit – OpenGL" that opens on the client (though the windows remain > black). > > MPI implementation is SGI MPI. I have also tried to compile openmpi > 1.4.3 and pvserver from source, yet it’s still very slow. The client > used is the x64 build from the paraview homepage. > > MPI setup is for local use only. > > I am grateful for any help… > > Florian > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > > Follow this link to subscribe/unsubscribe: > http://www.paraview.org/mailman/listinfo/paraview ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] CoProcessing
Hi Pat, Sorry for this late reply. Good to hear there is a concrete plan to merge the live data source to the mainline. Until then, if possible rebasing onto one of the upcoming releases (say 3.10) would be appreciated. That way we can explore the feature on top of a stable basis. p.s. I thought I could write and post a brief guide to build/setup the live data source but time still has not yet allowed me... Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: pat marion Subject: Re: [Paraview] CoProcessing Date: Thu, 13 Jan 2011 12:20:28 -0500 > Hi Takuya, > > I'm really happy to hear that the live data source works with your > simulation code! And I'm very impressed you were able to make it work > without any documentation! Let me know if you have any further questions. > > I cannot give you an expected timeline for merging with the mainline, but > there is another option- I can rebase the branch onto the HEAD version of > paraview. The code still won't be ready for merging with the mainline, but > at least it would work with today's paraview. One of the reasons I want to > delay integration (and even a rebase) is because there is active work on the > paraview connection management code (called collaboration.) When that work > is complete, it might change the way I do the connection handling for the > live data source. > > Pat > > On Thu, Jan 13, 2011 at 9:41 AM, Takuya OSHIMA > wrote: > >> After some trials I managed to get the live data source to work with >> my simulation code... I must say it's fantastic!! >> >> Now, is there any expected timeline when it will be merged to the >> mainline? >> >> Takuya >> >> Takuya OSHIMA, Ph.D. >> Faculty of Engineering, Niigata University >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> >> From: pat marion >> Subject: Re: [Paraview] CoProcessing >> Date: Wed, 12 Jan 2011 14:24:03 -0500 >> >> > Hi Andrey, >> > >> > When I wrote those slides, the code for the Live Data Source had not yet >> > received approval for public release. The code is now available but has >> yet >> > to be merged with the paraview main release. You'll have to compile >> > paraview yourself in order to use the Live Data Source. The code can be >> > found in the live-data branch of the git repository git:// >> > github.com/patmarion/ParaView.git >> > >> > Pat >> > >> > On Wed, Jan 12, 2011 at 1:07 PM, Andrey Lomtev > >wrote: >> > >> >> Hello everyone, >> >> >> >> I'm going to use CoProcessing library. I'm moving step by step as >> described >> >> in SC10_tutorial. I don't understand slide 99. I can't create Live Data >> >> Source. It isn't presented in my PV version (3.8.1). How can I add it? >> >> >> >> Thanks, >> >> Andrey. >> >> ___ >> >> Powered by www.kitware.com >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Please keep messages on-topic and check the ParaView Wiki at: >> >> http://paraview.org/Wiki/ParaView >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://www.paraview.org/mailman/listinfo/paraview >> >> >> ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] CoProcessing
After some trials I managed to get the live data source to work with my simulation code... I must say it's fantastic!! Now, is there any expected timeline when it will be merged to the mainline? Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: pat marion Subject: Re: [Paraview] CoProcessing Date: Wed, 12 Jan 2011 14:24:03 -0500 > Hi Andrey, > > When I wrote those slides, the code for the Live Data Source had not yet > received approval for public release. The code is now available but has yet > to be merged with the paraview main release. You'll have to compile > paraview yourself in order to use the Live Data Source. The code can be > found in the live-data branch of the git repository git:// > github.com/patmarion/ParaView.git > > Pat > > On Wed, Jan 12, 2011 at 1:07 PM, Andrey Lomtev wrote: > >> Hello everyone, >> >> I'm going to use CoProcessing library. I'm moving step by step as described >> in SC10_tutorial. I don't understand slide 99. I can't create Live Data >> Source. It isn't presented in my PV version (3.8.1). How can I add it? >> >> Thanks, >> Andrey. >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the ParaView Wiki at: >> http://paraview.org/Wiki/ParaView >> >> Follow this link to subscribe/unsubscribe: >> http://www.paraview.org/mailman/listinfo/paraview >> ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Error when reading large XMLUnstructuredData file
Hi Guenter, just for confirmation, did you build both VTK that your
converter uses and ParaView with VTK_USE_64BIT_IDS ON?
By the way I'm working with OS X 10.6, if it makes difference...
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Guenter Bartsch
Subject: Re: [Paraview] Error when reading large XMLUnstructuredData file
Date: Tue, 4 Jan 2011 12:10:27 +0100
> Takuya,
>
> thanks for your quick reply. however, we do have set
>
> VTK_USE_64BIT_IDSON
>
> and this is a 64bit linux platform (CentOS/RHEL x86_64) in case that
> matters - so unfortunately that isn't the solution here.
>
> thanks anyway and kind regards,
>
>guenter
>
> On Tue, Jan 4, 2011 at 12:06 PM, Takuya OSHIMA
> wrote:
>> Hi Guenter and all,
>>
>> I also had the same issue with .vti (XML vtkImageData) files of
>> roughly the same sizes of around 3 GBytes. Currently I'm working
>> around the issue by building VTK and ParaView with VTK_USE_64BIT_IDS
>> set to ON, which will allow you to load up to 4 GBytes as compared to
>> 2 GBytes when VTK_USE_64BIT_IDS is OFF.
>>
>> However I'd be interested if there's more fundamental way of resolving
>> the issue because I'll be handling larger cases soon. Is there a
>> format (other than series of legacy VTK format files) that is
>> time-aware, parallelizable and allows more than 4 GBytes of
>> vtkImageData per partition?
>>
>> Takuya
>>
>> Takuya OSHIMA, Ph.D.
>> Faculty of Engineering, Niigata University
>> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
>>
>> From: Guenter Bartsch
>> Subject: [Paraview] Error when reading large XMLUnstructuredData file
>> Date: Tue, 4 Jan 2011 11:45:18 +0100
>>
>>> hi all,
>>>
>>> we have run into a problem reading a pretty large (3.6 GB) .vtu file.
>>> the file was produced by a fortran program that writes vtk data in the
>>> old ascii format which results in a 17G ascii file which takes very
>>> long to load in paraview (and results in an error message). so, we
>>> have written a converter program that reads the ascii file and outputs
>>> xml:
>>>
>>>
>>> int main(int argc, char *argp[])
>>> {
>>> if (argc != 2) {
>>> cerr << "usage: " << argp[0] << " \n\n";
>>> return 1;
>>> }
>>>
>>> char *filename = argp[1];
>>>
>>> cout << "Input filename: " << filename << "\n";
>>>
>>> vtkSmartPointer reader =
>>> vtkSmartPointer::New();
>>> reader->SetFileName(filename);
>>>
>>> char *ofilename = "foo.vtu";
>>> cout << "Output filename: " << ofilename << "\n";
>>> vtkSmartPointer writer =
>>> vtkSmartPointer::New();
>>> writer->SetFileName(ofilename);
>>> writer->SetInputConnection(reader->GetOutputPort());
>>> writer->Write();
>>>
>>> return EXIT_SUCCESS;
>>> }
>>>
>>> this program runs fine. now, if i open the resulting file in paraview,
>>> i run into this error as soon as i hit apply:
>>>
>>> ERROR: In
>>> /opt/paraview-3.8.1/src/ParaView-3.8.1/VTK/IO/vtkXMLUnstructuredDataReader.cxx,
>>> line 652
>>> vtkXMLUnstructuredGridReader (0x143f0c40): Cannot read cell
>>> connectivity from Cells in piece 0 because the "connectivity" array is
>>> not long enough.
>>>
>>> the converter did work on a smaller test data set and paraview could
>>> open it - only now with the large data set paraview fails. here is the
>>> header of the failing file:
>>>
>>>
>>> >> byte_order="LittleEndian" compressor="vtkZLibDataCompressor">
>>>
>>> >> NumberOfCells="105122745" >
>>>
>>> >> NumberOfComponents="3" format="appended" RangeMin="0.0021820231521"
>>> RangeMax="24.459394872" offset="0" />
>>>
>>>
>>>
>>>
>>> >> format="appended" RangeMin="0"
>>> RangeMax="5007.1818403" offset="1580185620" />
>>>
>>>
>>>
Re: [Paraview] Error when reading large XMLUnstructuredData file
Hi Guenter and all,
I also had the same issue with .vti (XML vtkImageData) files of
roughly the same sizes of around 3 GBytes. Currently I'm working
around the issue by building VTK and ParaView with VTK_USE_64BIT_IDS
set to ON, which will allow you to load up to 4 GBytes as compared to
2 GBytes when VTK_USE_64BIT_IDS is OFF.
However I'd be interested if there's more fundamental way of resolving
the issue because I'll be handling larger cases soon. Is there a
format (other than series of legacy VTK format files) that is
time-aware, parallelizable and allows more than 4 GBytes of
vtkImageData per partition?
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Guenter Bartsch
Subject: [Paraview] Error when reading large XMLUnstructuredData file
Date: Tue, 4 Jan 2011 11:45:18 +0100
> hi all,
>
> we have run into a problem reading a pretty large (3.6 GB) .vtu file.
> the file was produced by a fortran program that writes vtk data in the
> old ascii format which results in a 17G ascii file which takes very
> long to load in paraview (and results in an error message). so, we
> have written a converter program that reads the ascii file and outputs
> xml:
>
>
> int main(int argc, char *argp[])
> {
> if (argc != 2) {
> cerr << "usage: " << argp[0] << " \n\n";
> return 1;
> }
>
> char *filename = argp[1];
>
> cout << "Input filename: " << filename << "\n";
>
> vtkSmartPointer reader =
> vtkSmartPointer::New();
> reader->SetFileName(filename);
>
> char *ofilename = "foo.vtu";
> cout << "Output filename: " << ofilename << "\n";
> vtkSmartPointer writer =
> vtkSmartPointer::New();
> writer->SetFileName(ofilename);
> writer->SetInputConnection(reader->GetOutputPort());
> writer->Write();
>
> return EXIT_SUCCESS;
> }
>
> this program runs fine. now, if i open the resulting file in paraview,
> i run into this error as soon as i hit apply:
>
> ERROR: In
> /opt/paraview-3.8.1/src/ParaView-3.8.1/VTK/IO/vtkXMLUnstructuredDataReader.cxx,
> line 652
> vtkXMLUnstructuredGridReader (0x143f0c40): Cannot read cell
> connectivity from Cells in piece 0 because the "connectivity" array is
> not long enough.
>
> the converter did work on a smaller test data set and paraview could
> open it - only now with the large data set paraview fails. here is the
> header of the failing file:
>
>
> byte_order="LittleEndian" compressor="vtkZLibDataCompressor">
>
> NumberOfCells="105122745" >
>
> NumberOfComponents="3" format="appended" RangeMin="0.0021820231521"
> RangeMax="24.459394872" offset="0" />
>
>
>
>
> format="appended" RangeMin="0"
> RangeMax="5007.1818403" offset="1580185620" />
>
>
> RangeMin="" RangeMax=""
> offset="2045521660" />
> RangeMin="" RangeMax=""
> offset="3504937336" />
> RangeMin="" RangeMax=""
> offset="3671971228" />
>
>
>
>
>_WJgAAACAvXYAALF2AADJdgAAUHcAA...
>
> does anyone know what could be going on here? do we need to configure
> paraview to handle larger files? is this a bug? could the original
> ascii data set have been corrupt and the error reflects now in the xml
> file?
>
> thanks in advance and best regards,
>
>guenter
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://www.paraview.org/mailman/listinfo/paraview
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] ParaView 3.8.1 hangs on select points/cells for plugin-generated multiblock data set
Hi Utkarsh, Correct, as far as I tested, the problem is no longer present in 3.9. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Utkarsh Ayachit Subject: Re: [Paraview] ParaView 3.8.1 hangs on select points/cells for plugin-generated multiblock data set Date: Mon, 6 Dec 2010 08:55:04 -0500 > Takuya, > > Following the email threads you posted on the bug report, it seems > that issue is no longer a problem, with 3.9. Am I reading that > correctly? > > Utkarsh > > On Sun, Dec 5, 2010 at 9:26 PM, Takuya OSHIMA > wrote: > > Ouch. It's already been filed by another user as a OpenFOAM reader bug. > > http://paraview.org/Bug/view.php?id=11516 > > > > Takuya OSHIMA, Ph.D. > > Faculty of Engineering, Niigata University > > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN > > > > From: Takuya OSHIMA > > Subject: Re: [Paraview] ParaView 3.8.1 hangs on select points/cells for > > plugin-generated multiblock data set > > Date: Mon, 06 Dec 2010 10:06:20 +0900 (JST) > > > >> Hi Karl, > >> > >> A user has reported the problem on the CFD-Online forum recently which > >> I also was able to reproduce on OS X. > >> http://www.cfd-online.com/Forums/openfoam/74355-issue-involving-paraview.html#post281435 > >> (the discussion starts from Oct. 30) > >> I didn't file the problem as a bug because as written in my post I see > >> the problem only with 3.8.1 but not with 3.8.0 or 3.9-Development. > >> > >> p.s.: > >>> * File - Open - "bcOscilating/system/controlDict.foam" - Ok > >>> * Ignore the warning about missing time dependent data. Irrelevant here. > >>> * Change File Name to "bcOscilating\system\fvSchemes" - Apply > >> > >> You should be able to open bcOscilating/system/controlDict :) > >> > >> Takuya OSHIMA, Ph.D. > >> Faculty of Engineering, Niigata University > >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN > >> > >> > >> From: Karl König > >> Subject: Re: [Paraview] ParaView 3.8.1 hangs on select points/cells for > >> plugin-generated multiblock data set > >> Date: Sun, 05 Dec 2010 23:59:46 +0100 > >> > >>> Hi, > >>> > >>> Actually, the very same behavior can be observed with a completely > >>> different plugin, developed independently - Takuya Oshima's Parallelized > >>> Native OpenFOAM Reader Plugin: No point/cell selection problems when the > >>> plugin is compiled for 32-bit or 64-bit Linux against the official PV > >>> Development release 3.8.1, but ParaView 3.8.1 hangs (both 32-bit and > >>> 64-bit) if the plugin is compiled with Visual Studio 2008 SP1 against > >>> the official PV Development Installation for Windows. > >>> > >>> Recipe: > >>> * Get the plugin source > >>> (see > >>> http://openfoamwiki.net/index.php/Contrib_Parallelized_Native_OpenFOAM_Reader_for_ParaView) > >>> svn co > >>> https://of-interfaces.svn.sourceforge.net/svnroot/of-interfaces/trunk/vtkPOFFReader > >>> * CMake, then compile the plugin with Visual Studio 2008 SP1 (32-bit or > >>> 64-bit) > >>> * Start ParaView 3.8.1 (Win32 or Win64) > >>> (downloaded from > >>> http://www.paraview.org/files/v3.8/ParaView-3.8.1-Win*-x86.exe) > >>> * Tools - Manage Plugins - Load New... - > >>> "Release/POFFDevReaderPanelPlugin.dll" + > >>> "Release/POFFDevReaderPlugin.dll" - Close > >>> > >>> Download a sample OpenFOAM data set, e.g. > >>> http://openfoamwiki.net/images/e/e1/BcOscilating.tar.gz. Untar. > >>> > >>> * File - Open - "bcOscilating/system/controlDict.foam" - Ok > >>> * Ignore the warning about missing time dependent data. Irrelevant here. > >>> * Change File Name to "bcOscilating\system\fvSchemes" - Apply > >>> * (optional:) Color by cell data array named "p". > >>> * (optional:) Representation "Surface with Edges" > >>> * Lasso select with either SelectPoints or SelectCells > >>> => PV 3.8.1 hangs > >>> (no such problem with SelectPointsThrough or SelectCellsThrough, > >>> though, as with the minimal reader posted previously) > >>> > >>> Does anyone else notice such strange behavior with his multiblock reader > &
[Paraview] Please close bug #11211
By the way, can somebody close bug #11211 please? http://paraview.org/Bug/view.php?id=11211 0011211: ParaView-3.9.0 gives wrong contour (iso-surface) on OpenFOAM-datasets Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] ParaView 3.8.1 hangs on select points/cells for plugin-generated multiblock data set
Ouch. It's already been filed by another user as a OpenFOAM reader bug. http://paraview.org/Bug/view.php?id=11516 Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Takuya OSHIMA Subject: Re: [Paraview] ParaView 3.8.1 hangs on select points/cells for plugin-generated multiblock data set Date: Mon, 06 Dec 2010 10:06:20 +0900 (JST) > Hi Karl, > > A user has reported the problem on the CFD-Online forum recently which > I also was able to reproduce on OS X. > http://www.cfd-online.com/Forums/openfoam/74355-issue-involving-paraview.html#post281435 > (the discussion starts from Oct. 30) > I didn't file the problem as a bug because as written in my post I see > the problem only with 3.8.1 but not with 3.8.0 or 3.9-Development. > > p.s.: >> * File - Open - "bcOscilating/system/controlDict.foam" - Ok >> * Ignore the warning about missing time dependent data. Irrelevant here. >> * Change File Name to "bcOscilating\system\fvSchemes" - Apply > > You should be able to open bcOscilating/system/controlDict :) > > Takuya OSHIMA, Ph.D. > Faculty of Engineering, Niigata University > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN > > > From: Karl König > Subject: Re: [Paraview] ParaView 3.8.1 hangs on select points/cells for > plugin-generated multiblock data set > Date: Sun, 05 Dec 2010 23:59:46 +0100 > >> Hi, >> >> Actually, the very same behavior can be observed with a completely >> different plugin, developed independently - Takuya Oshima's Parallelized >> Native OpenFOAM Reader Plugin: No point/cell selection problems when the >> plugin is compiled for 32-bit or 64-bit Linux against the official PV >> Development release 3.8.1, but ParaView 3.8.1 hangs (both 32-bit and >> 64-bit) if the plugin is compiled with Visual Studio 2008 SP1 against >> the official PV Development Installation for Windows. >> >> Recipe: >> * Get the plugin source >> (see >> http://openfoamwiki.net/index.php/Contrib_Parallelized_Native_OpenFOAM_Reader_for_ParaView) >> svn co >> https://of-interfaces.svn.sourceforge.net/svnroot/of-interfaces/trunk/vtkPOFFReader >> * CMake, then compile the plugin with Visual Studio 2008 SP1 (32-bit or >> 64-bit) >> * Start ParaView 3.8.1 (Win32 or Win64) >> (downloaded from >> http://www.paraview.org/files/v3.8/ParaView-3.8.1-Win*-x86.exe) >> * Tools - Manage Plugins - Load New... - >> "Release/POFFDevReaderPanelPlugin.dll" + >> "Release/POFFDevReaderPlugin.dll" - Close >> >> Download a sample OpenFOAM data set, e.g. >> http://openfoamwiki.net/images/e/e1/BcOscilating.tar.gz. Untar. >> >> * File - Open - "bcOscilating/system/controlDict.foam" - Ok >> * Ignore the warning about missing time dependent data. Irrelevant here. >> * Change File Name to "bcOscilating\system\fvSchemes" - Apply >> * (optional:) Color by cell data array named "p". >> * (optional:) Representation "Surface with Edges" >> * Lasso select with either SelectPoints or SelectCells >> => PV 3.8.1 hangs >>(no such problem with SelectPointsThrough or SelectCellsThrough, >> though, as with the minimal reader posted previously) >> >> Does anyone else notice such strange behavior with his multiblock reader >> plugins on Windows? >> >> Thanks in advance for any feedback, >> Karl >> >> >> >> Karl König wrote, On 24.11.2010 09:04: >>> Hi all, >>> >>> I've a multiblock reader plugin which behaves nicely in Unix >>> environments (Linux and Solaris, 32 and 64bit), but seems to cause >>> problems under Windows (XP and 7, 32 and 64bit, compiled with Visual >>> Studio 2008 SP1 against official PV Development release): >>> Importing the data, viewing the data and exporting the data to different >>> file formats (e.g. as *.vtm) and importing that data again into ParaView >>> works without any problem, but whenever I use SelectCells or >>> SelectPoints from the selection toolbar and lasso select an area from an >>> object imported by this reader, ParaView hangs - under Windows, not in a >>> Unix environment. If, however, one applies a MergeBlocks filter first >>> and then lasso selects an area, there is no problem. >>> >>> I boiled down the reader to a minimal test case, it's more or less a >>> mere source now (but still implemented as a reader) and am attaching the >>> source code. Once compiled, it will integrate into p
Re: [Paraview] ParaView 3.8.1 hangs on select points/cells for plugin-generated multiblock data set
Hi Karl,
A user has reported the problem on the CFD-Online forum recently which
I also was able to reproduce on OS X.
http://www.cfd-online.com/Forums/openfoam/74355-issue-involving-paraview.html#post281435
(the discussion starts from Oct. 30)
I didn't file the problem as a bug because as written in my post I see
the problem only with 3.8.1 but not with 3.8.0 or 3.9-Development.
p.s.:
> * File - Open - "bcOscilating/system/controlDict.foam" - Ok
> * Ignore the warning about missing time dependent data. Irrelevant here.
> * Change File Name to "bcOscilating\system\fvSchemes" - Apply
You should be able to open bcOscilating/system/controlDict :)
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Karl König
Subject: Re: [Paraview] ParaView 3.8.1 hangs on select points/cells for
plugin-generated multiblock data set
Date: Sun, 05 Dec 2010 23:59:46 +0100
> Hi,
>
> Actually, the very same behavior can be observed with a completely
> different plugin, developed independently - Takuya Oshima's Parallelized
> Native OpenFOAM Reader Plugin: No point/cell selection problems when the
> plugin is compiled for 32-bit or 64-bit Linux against the official PV
> Development release 3.8.1, but ParaView 3.8.1 hangs (both 32-bit and
> 64-bit) if the plugin is compiled with Visual Studio 2008 SP1 against
> the official PV Development Installation for Windows.
>
> Recipe:
> * Get the plugin source
> (see
> http://openfoamwiki.net/index.php/Contrib_Parallelized_Native_OpenFOAM_Reader_for_ParaView)
> svn co
> https://of-interfaces.svn.sourceforge.net/svnroot/of-interfaces/trunk/vtkPOFFReader
> * CMake, then compile the plugin with Visual Studio 2008 SP1 (32-bit or
> 64-bit)
> * Start ParaView 3.8.1 (Win32 or Win64)
> (downloaded from
> http://www.paraview.org/files/v3.8/ParaView-3.8.1-Win*-x86.exe)
> * Tools - Manage Plugins - Load New... -
> "Release/POFFDevReaderPanelPlugin.dll" +
> "Release/POFFDevReaderPlugin.dll" - Close
>
> Download a sample OpenFOAM data set, e.g.
> http://openfoamwiki.net/images/e/e1/BcOscilating.tar.gz. Untar.
>
> * File - Open - "bcOscilating/system/controlDict.foam" - Ok
> * Ignore the warning about missing time dependent data. Irrelevant here.
> * Change File Name to "bcOscilating\system\fvSchemes" - Apply
> * (optional:) Color by cell data array named "p".
> * (optional:) Representation "Surface with Edges"
> * Lasso select with either SelectPoints or SelectCells
> => PV 3.8.1 hangs
>(no such problem with SelectPointsThrough or SelectCellsThrough,
> though, as with the minimal reader posted previously)
>
> Does anyone else notice such strange behavior with his multiblock reader
> plugins on Windows?
>
> Thanks in advance for any feedback,
> Karl
>
>
>
> Karl König wrote, On 24.11.2010 09:04:
>> Hi all,
>>
>> I've a multiblock reader plugin which behaves nicely in Unix
>> environments (Linux and Solaris, 32 and 64bit), but seems to cause
>> problems under Windows (XP and 7, 32 and 64bit, compiled with Visual
>> Studio 2008 SP1 against official PV Development release):
>> Importing the data, viewing the data and exporting the data to different
>> file formats (e.g. as *.vtm) and importing that data again into ParaView
>> works without any problem, but whenever I use SelectCells or
>> SelectPoints from the selection toolbar and lasso select an area from an
>> object imported by this reader, ParaView hangs - under Windows, not in a
>> Unix environment. If, however, one applies a MergeBlocks filter first
>> and then lasso selects an area, there is no problem.
>>
>> I boiled down the reader to a minimal test case, it's more or less a
>> mere source now (but still implemented as a reader) and am attaching the
>> source code. Once compiled, it will integrate into paraview and offer to
>> open any file named *.mini (there is one in subdirectory sample-input).
>> The content of the file is completely ignored, instead a multiblock
>> containing one unstructured grid with exactly one cube is created. This
>> is enough to trigger the problem.
>>
>> I'd like to know whether this is a problem with the ParaView Windows
>> builds or whether I am misconstructing a multiblock data set which
>> somehow confuses only Windows builds. I tend to believe the latter (as a
>> data object generator source using the program "MB { UG1 }" does not
>> cause ParaView to hang when trying to select something), but have no
>> idea what I might be doing wro
Re: [Paraview] Fwd: Interpolation problem
Hi Shinya, If I am not mistaken Gouraud is an interpolation for shading than for field values. Try crating a Sphere source and changing the Interpolation selection between Gouraud and Flat, hopefully you'll see the difference in shading. Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Andy Bauer Subject: Re: [Paraview] Fwd: Interpolation problem Date: Thu, 14 Oct 2010 11:06:36 -0400 > 2010/10/14 小縣信也 > >> Hi Andy, >> >> Thank you for replying. >> Do you mean that the rendering image doesn't reflect the result of >> interpolation ? >> > > Yes. > > >> If so, what is the most common usage? >> In what situation is the interpolation used ? >> > > If your grid uses triangles then the image should match the interpolation > for the typical node/point based interpolation. > > > >> Shinya >> >> >> 2010/10/13 Andy Bauer : >> > I think this is a rendering issue and not an interpolation issue. From >> the >> > 2d plot you can see that it's properly interpolating the values. I think >> > the quadrilateral is getting rendered as 2 triangles in which case the >> > diagonal values appear to be constant since the 2 end points are at the >> same >> > value. >> > >> > 2010/10/12 小縣信也 >> >> >> >> Hello >> >> >> >> I'm sending the following e-mail again ,because nobody answered it. >> >> Does anyone have information on my problem? >> >> >> >> Shinya >> >> >> >> >> >> -- Forwarded message -- >> >> From: 小縣信也 >> >> Date: 2010/10/7 >> >> Subject: Interpolation problem >> >> To: paraview@paraview.org >> >> >> >> >> >> Hello, paraview users >> >> >> >> I draw the file “Sample_inter.vtk” on ParaView. (ref:attached file) >> >> I chose “Gouraud” in Interpolation option. >> >> The contor picture doesn’t seem to be interpolated by 4 points. >> >> However,the graph which is made by PlotOverLine shows the gradation of >> >> 4 points scalar. >> >> Why are they different? >> >> Does anyone know this problem? >> >> How can I make contour picture interpolated by Gouraud ? >> >> >> >> I look forward to your reply to my inquiry >> >> >> >> Shinya Ogata >> >> >> >> ___ >> >> Powered by www.kitware.com >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Please keep messages on-topic and check the ParaView Wiki at: >> >> http://paraview.org/Wiki/ParaView >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://www.paraview.org/mailman/listinfo/paraview >> >> >> > >> > >> ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Japanese translation of The ParaView Tutorial Version 3.8 is available
Hi, I wanted to drop a note to Japanese subscribers that a Japanese translation of The ParaView Tutorial Version 3.8 is now available. http://paraview.org/Wiki/The_ParaView_Tutorial As always, many thanks to Kenneth Moreland for providing the excellent tutorial and its LaTeX source. Takuya ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] Showing FileName property on the GUI
Hi,
Before a commit on yesterday
commit 35f842cbf94964f567158fa5ebfde62249c354f0
Author: Utkarsh Ayachit
Date: Tue Sep 7 09:41:35 2010 -0400
Adding support for a hint to specify the default "FileName" property.
the show hint to FileName property had been respected, i.e. if I write
in the SM-XML
the property appeared on the GUI reader panel even if it was the first
file property (and I could see that there had been an explicit logic
to check propertiesToShow). However after the commit it is no longer
effective. Can the previous behavior be retrieved, by e. g. the
following modification?
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
diff --git a/Qt/Components/pqNamedWidgets.cxx b/Qt/Components/pqNamedWidgets.cxx
index 12c53d1..7fb0f6c 100644
--- a/Qt/Components/pqNamedWidgets.cxx
+++ b/Qt/Components/pqNamedWidgets.cxx
@@ -699,13 +699,6 @@ static void processHints(QGridLayout* panelLayout,
propertiesToHide.push_back(pname);
}
- // Skip the filename property.
- QString filenameProperty = pqObjectBuilder::getFileNamePropertyName(smProxy);
- if (!filenameProperty.isEmpty())
-{
-propertiesToHide.push_back(filenameProperty);
-}
-
// Get the hints for this proxy.
// The hints may contain stuff about property groupping/layout
// etc etc.
@@ -855,6 +848,14 @@ void pqNamedWidgets::createWidgets(QGridLayout*
panelLayout, vtkSMProxy* pxy)
QStringList propertiesToHide;
QStringList propertiesToShow;
processHints(panelLayout, pxy, propertiesToHide, propertiesToShow);
+
+ // Skip the filename property if it is not a property to show.
+ QString filenameProperty = pqObjectBuilder::getFileNamePropertyName(pxy);
+ if (!filenameProperty.isEmpty() &&
!propertiesToShow.contains(filenameProperty))
+{
+propertiesToHide.push_back(filenameProperty);
+}
+
rowCount = panelLayout->rowCount();
for(iter->Begin(); !iter->IsAtEnd(); iter->Next())
{
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] List of tested compilers?
Thanks! Just as a comment there are old gcc-2.96 (dash8) and gcc-3.3.2 (dash5/6) listed but as far as I can see from the dashboards they are not used for VTK/ParaView. Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Dave Partyka Subject: Re: [Paraview] List of tested compilers? Date: Mon, 30 Aug 2010 13:07:44 -0400 > I have some of this information on an internal Kitware wiki. It's not > complete but should give you an idea. > > krondor gcc-3.3 > midworld gcc-3.3 > dashmacmini1 gcc-4.0.1 > dashmacmini2 gcc-4.0.1 > dashmacmini3 gcc-4.0.1 > dashmacmini4 gcc > beleriand > dashsun1 Sun C 5.6 > destiny aCC > dash1win98 VS > trinsic ? > hythloth gcc 4.3.3 > valhalla ? > dash1vista32 VS8 > dash1win64 VS71 VS8 VS9 > dash2win64 VS9 > morva VS8 > dagobah > faraway gcc-4.1.3 > dash1 VS71 > dash2 VS70 > dash3 VS6 VS9 > dash4 bcc-5.8 > dash5 gcc-3.3.2 > dash6 gcc-3.3.2 > dash8 gcc-2.96 > dash11 VS71 > dash12 VS9 VS10 > dash13 VS6 > dash14 mingw cygwin > dash15 > dash16 gcc-4.3.2 > dash17 gcc-4.0.3 > dash18 > dash19 bcc-5.5 VS8 > dash20 VS > dash21 gcc-4.3.2 > dash22 cygwin mingw watcom VS71 VS8 VS9 > dash23 > amber1 gcc-4.1 > amber2 gcc-4.1 > amber3 gcc-4.1 > amber4 gcc-4.1 > amber5 gcc-4.1 > amber6 gcc-4.1 > amber7 gcc-4.1 > amber8 gcc-4.1 > amber9 VS9 > > 2010/8/30 Takuya OSHIMA > >> Hi, >> >> Is there a comprehensive list of compilers of the VTK and ParaView >> dashboard platforms? In particular, which is the oldest version of GCC >> that should be supported by VTK and ParaView? I skimmed through the >> dashboards and found the Linux kernel version of each platform but >> the compiler version is always unavailable. >> >> My intention of the question is that it would be useful for a >> (potential) contributor to have such a list so that he/she can test >> the code with the compilers before submitting it. >> >> Takuya >> >> Takuya OSHIMA, Ph.D. >> Faculty of Engineering, Niigata University >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the ParaView Wiki at: >> http://paraview.org/Wiki/ParaView >> >> Follow this link to subscribe/unsubscribe: >> http://www.paraview.org/mailman/listinfo/paraview >> ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] List of tested compilers?
Hi, Is there a comprehensive list of compilers of the VTK and ParaView dashboard platforms? In particular, which is the oldest version of GCC that should be supported by VTK and ParaView? I skimmed through the dashboards and found the Linux kernel version of each platform but the compiler version is always unavailable. My intention of the question is that it would be useful for a (potential) contributor to have such a list so that he/she can test the code with the compilers before submitting it. Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] CoProcessing
Hi Jacques,
I can share what I did with my own C++ simulation code. The caveats
are that I only did a quick test so far and that my code is
serial. But it's working. Take a look at the attached cxx file.
Initializations are in
fdmCoProcessing(fdmTimeInfo *tInfo) and
fdmCoProcessing::Parse(vtkXMLDataElement *coproc).
Replace source->GetCharacterData() in Parse() with the file name of
your Python script created by the ParaView coprocessing script
generator plugin.
Per-time step processings are in
fdmCoProcessing::Exec().
Replace this->TimeInfo->GetGrid() with the output of your
adaptor. Perhaps this is where you have to elaborate.
Finalizations are in
fdmCoProcessing::~fdmCoProcessing().
If your project is CMake-based, add
FIND_PACKAGE(ParaView REQUIRED)
INCLUDE(${PARAVIEW_USE_FILE})
to your CMakeLists.txt and vtkCoProcessor to your TARGET_LINK_LIBRARIES.
If my example is not enough you can also take a look at
ParaView/CoProcessing/CoProcessor/Testing/TestDriver
but I'm afraid it might be a bit too overwhelming as a starting point.
Hope this helps,
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Jacques Papper
Subject: Re: [Paraview] CoProcessing
Date: Wed, 4 Aug 2010 13:02:36 +0100
> * Hi All,
>
> Sorry for my last post, I figured out that I had wrongly set my PYTHONPATH..
> All the tests work ok now. Still interested in CoProcessing adaptors examples
> though :)
>
> Thanks
> Jacques
>
> 2010/8/4 Jacques Papper
>
> Hi All,
>
> I'm starting to look into the ParaView CoProcessing libraries.
> I just pulled from git today, and compiled it all up following the
> guidelines in :
> http://www.paraview.org/Wiki/CoProcessing
> I didn't find :
> BUILD_PYTHON_COPROCESSING_ADAPTOR
> but instead :
> PARAVIEW_BUILD_PLUGIN_CoProcessingScriptGenerator
> anyway the compilation went through without any issues.
> I then tried :
>
> ctest -R CoProcessing
> Test project /users/boreas01/jacques/PARAVIEW/ParaView-bin
> Start 491: CoProcessingTestPythonScript
> 1/3 Test #491: CoProcessingTestPythonScript ... Passed 0.45
> sec
> Start 492: CoProcessingPythonScriptGridPlot
> 2/3 Test #492: CoProcessingPythonScriptGridPlot ...***Failed 0.09
> sec
> Start 493: CoProcessingPythonScriptPressurePlot
> 3/3 Test #493: CoProcessingPythonScriptPressurePlot ...***Failed 0.09
> sec
>
> 33% tests passed, 2 tests failed out of 3
>
> Total Test time (real) = 0.68 sec
>
> The following tests FAILED:
> 492 - CoProcessingPythonScriptGridPlot (Failed)
> 493 - CoProcessingPythonScriptPressurePlot (Failed)
> Errors while running CTest
>
> Is this a problem in my current installation or on the master branch ?
>
> Finally, I would like to start writing an adaptor to a C++ parallelised
> code. Can you tell me what is the closest code I can inspire myself from ?
>
> Thank you,
> Jacques
>
> PS sorry mixed up the subjects..
>
fdmCoProcessing.cxx
Description: Binary data
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] CoProcessing
I try to resend my mail as there seems to be a heavy delivery delay or
the mail was lost... Sorry if this is going to be a double post.
Takuya
--
Hi Jacques,
I can share what I did with my own C++ simulation code. The caveats
are that I only did a quick test so far and that my code is
serial. But it's working. Take a look at the attached cxx file.
Initializations are in
fdmCoProcessing(fdmTimeInfo *tInfo) and
fdmCoProcessing::Parse(vtkXMLDataElement *coproc).
Replace source->GetCharacterData() in Parse() with the file name of
your Python script created by the ParaView coprocessing script
generator plugin.
Per-time step processings are in
fdmCoProcessing::Exec().
Replace this->TimeInfo->GetGrid() with the output of your
adaptor. Perhaps this is where you have to elaborate.
Finalizations are in
fdmCoProcessing::~fdmCoProcessing().
If your project is CMake-based, add
FIND_PACKAGE(ParaView REQUIRED)
INCLUDE(${PARAVIEW_USE_FILE})
to your CMakeLists.txt and vtkCoProcessor to your TARGET_LINK_LIBRARIES.
If my example is not enough you can also take a look at
ParaView/CoProcessing/CoProcessor/Testing/TestDriver
but I'm afraid it might be a bit too overwhelming as a starting point.
Hope this helps,
Takuya
Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
From: Jacques Papper
Subject: Re: [Paraview] CoProcessing
Date: Wed, 4 Aug 2010 13:02:36 +0100
> * Hi All,
>
> Sorry for my last post, I figured out that I had wrongly set my PYTHONPATH..
> All the tests work ok now. Still interested in CoProcessing adaptors examples
> though :)
>
> Thanks
> Jacques
>
> 2010/8/4 Jacques Papper
>
> Hi All,
>
> I'm starting to look into the ParaView CoProcessing libraries.
> I just pulled from git today, and compiled it all up following the
> guidelines in :
> http://www.paraview.org/Wiki/CoProcessing
> I didn't find :
> BUILD_PYTHON_COPROCESSING_ADAPTOR
> but instead :
> PARAVIEW_BUILD_PLUGIN_CoProcessingScriptGenerator
> anyway the compilation went through without any issues.
> I then tried :
>
> ctest -R CoProcessing
> Test project /users/boreas01/jacques/PARAVIEW/ParaView-bin
> □□□ Start 491: CoProcessingTestPythonScript
> 1/3 Test #491: CoProcessingTestPythonScript ...□□ Passed□□□ 0.45
> sec
> □□□ Start 492: CoProcessingPythonScriptGridPlot
> 2/3 Test #492: CoProcessingPythonScriptGridPlot ...***Failed□□□ 0.09
> sec
> □□□ Start 493: CoProcessingPythonScriptPressurePlot
> 3/3 Test #493: CoProcessingPythonScriptPressurePlot ...***Failed□□□ 0.09
> sec
>
> 33% tests passed, 2 tests failed out of 3
>
> Total Test time (real) =□□ 0.68 sec
>
> The following tests FAILED:
> □□□ 492 - CoProcessingPythonScriptGridPlot (Failed)
> □□□ 493 - CoProcessingPythonScriptPressurePlot (Failed)
> Errors while running CTest
>
> Is this a problem in my current installation or on the master branch ?
>
> Finally, I would like to start writing an adaptor to a C++ parallelised
> code. Can you tell me what is the closest code I can inspire myself from ?
>
> Thank you,
> Jacques
>
> PS sorry mixed up the subjects..
>
fdmCoProcessing.cxx
Description: Binary data
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] CoProcessing
Hi again, This time I have a question: the demonstration of a live data visualization at the bottom of the CoProcessing wiki page is definitely awesome. When is the feature expected to be merged to the git master of ParaView? Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: Takuya OSHIMA Subject: Re: [Paraview] CoProcessing Date: Wed, 04 Aug 2010 22:40:30 +0900 (東京 (標準時)) > Hi Jacques, > > I can share what I did with my own C++ simulation code. The caveats > are that I only did a quick test so far and that my code is > serial. But it's working. Take a look at the attached cxx file. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
[Paraview] unresponsive Pause?
Hi, One thing that's been annoying me a bit about recent ParaView (3.8 and git head) on OS X 10.6.4, Qt-4.6.3 (x86-64) is that when I'm playing animations with somewhat heavy datasets (around > 1 million cells in structured / unstructured grids), it overruns 5 - 6 steps until it stops playing when the Pause button on the VCR toolbar was hit. I vaguely remember this annoyance started with transition of Qt version to either 4.5 or 4.6 (I believe it was fine at least until Qt 4.3 / PV 3.6). Also, if I add 5 - 6 processEvents() calls in pqVCRController::onTick() as attached below (kind of silly though), the GUI becomes back responsive. Is it only me who is having this problem? Any thoughts? Thanks, Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN diff --git a/Qt/Components/pqVCRController.cxx b/Qt/Components/pqVCRController.cxx index 362d322..17c747e 100644 --- a/Qt/Components/pqVCRController.cxx +++ b/Qt/Components/pqVCRController.cxx @@ -127,6 +127,11 @@ void pqVCRController::onTick() // process the events so that the GUI remains responsive. QApplication::processEvents(); + QApplication::processEvents(); + QApplication::processEvents(); + QApplication::processEvents(); + QApplication::processEvents(); + QApplication::processEvents(); emit this->timestepChanged(); } ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Write and read a vtk file (in python)
It did work for the OpenFOAM reader on the Python console as well under es_AR.UTF-8 (which I know had been affected by the problem) on Ubuntu 10.04. Thanks for the fast fix! Takuya Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: pat marion Subject: Re: [Paraview] Write and read a vtk file (in python) Date: Fri, 4 Jun 2010 11:16:04 -0400 > * Any idea if python will respect that call too? > > Pat > > On Fri, Jun 4, 2010 at 10:15 AM, Utkarsh Ayachit > wrote: > > I've committed a fix. Attached is the patch for the same. > > commit 3f4904f94224ef3a6c03989a012c4484a759a607 > Author: Utkarsh Ayachit > Date: Fri Jun 4 10:14:30 2010 -0400 > > setlocale to avoid locale related numeric issues. > > Refer to http://www.paraview.org/pipermail/paraview/2009-August/ > 013278.html > thread for details. > > Utkarsh > > On Fri, Jun 4, 2010 at 9:50 AM, Berk Geveci > wrote: > > Thanks Takuya. We'll take care of it. > > > > 2010/6/4 Takuya OSHIMA : > >> Hi, > >> > >>> This seems to be related to the way the LOCALE is set on your system. > It is > >>> probably set to French in one case and English in the other. Does > anybody know > >>> if we can force LOCALE to English in the ParaView application or the > reader? > >> > >> Indeed, forcing the locale where the PV application runs under to C > >> was what I proposed a while ago, which failed to draw attention: > >> http://www.paraview.org/pipermail/paraview/2009-August/013278.html > >> > >> I'd really appreciate if the PV developers reconsider this. > >> > >> Takuya > >> > >> Takuya OSHIMA, Ph.D. > >> Faculty of Engineering, Niigata University > >> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN > >> > >> > >> From: Berk Geveci > >> Subject: Re: [Paraview] Write and read a vtk file (in python) > >> Date: Fri, 4 Jun 2010 09:25:02 -0400 > >> > >>> > 1) reading : > >>> > > >>> > > >>> > from a vtkStructuredGrid object, I use a vtkStructuredGridWriter to > create a > >>> > vtk file, and I have the following problem : > >>> > when I launch the script in Paraview, the format of floating points > is not > >>> > good (I obtain for example 33,1632 instead of 33.1632). So, the file > created > >>> > is not readable by Paraview. If I launch the script directly in a > terminal, > >>> > it works fine. Perhaps because the version of vtk module is not the > same ? > >>> > If I use the binary format I have not this problem. > >>> > >>> This seems to be related to the way the LOCALE is set on your system. > It is > >>> probably set to French in one case and English in the other. Does > anybody know > >>> if we can force LOCALE to English in the ParaView application or the > reader? > >>> > >>> > 2) writing : > >>> > > >>> > > >>> > I would like to read my vtk files from the python shell, with > >>> > OpenDataFile(), but It didn't succeed and I have the following > message (with > >>> > a file which can be read in paraview using menu open of course :-) : > >>> > >>> Unless I am mistaken, you give the filename directly to OpenDataFile > (), > >>> without FileName=. > >>> > >>> -berk > >>> > >>> > > >>> > > >>> > /home/plumecoq/tmp/ParaView/flow_1_0075.vtk > >>> > Traceback (most recent call last): > >>> > File "", line 1, in > >>> > File "/home/plumecoq/EHPOC/plugins/ElsaMenu/elsa.py", line 91, in > > >>> > main() > >>> > File "/home/plumecoq/EHPOC/plugins/ElsaMenu/elsa.py", line 73, in > main > >>> > reader_vtk = OpenDataFile(file_name_vtk) > >>> > File > >>> > "/home/plumecoq/Paraview/ParaView-3.8.0-bin/Utilities/ > VTKPythonWrapping/pa
