[Paraview] buggy xdmfreader
I am trying to read a huge hdf file (~2GB) using xdmf. However, the xdmfreader of paraview is showing this error: ERROR: In /home/pratik/Manually_Installed_Softwares/numerical/ParaView/ParaView-3.10.0/Utilities/Xdmf2/vtk/vtkXdmfReader.cxx, line 394 vtkXdmfReader (0xaef39b0): Failed to read data. ERROR: In /home/pratik/Manually_Installed_Softwares/numerical/ParaView/ParaView-3.10.0/VTK/Filtering/vtkExecutive.cxx, line 756 vtkPVCompositeDataPipeline (0xade0188): Algorithm vtkXdmfReader(0xaef39b0) returned failure for request: vtkInformation (0xb05eaa8) Debug: Off Modified Time: 4157222 Reference Count: 1 Registered Events: (none) Request: REQUEST_DATA FROM_OUTPUT_PORT: 0 FORWARD_DIRECTION: 0 ALGORITHM_AFTER_FORWARD: 1 ..many times. To figure out what was wrong, i reduced the xdmf so that it only reads the geometry (i.e XY grid), and even after using under *identical conditions *the same error persists. The only reason to explain this is the size of the h5 files being read: one of them contains only XY mesh point coordinates whereas the other one contains a lot of extra data that I am trying to visualize. Has anyone faced a similar problem? Can you please suggest which part of the Xdmf reader may be causing this problem? -- *Pratik Mallya* http://en.wikipedia.org/wiki/User:Pratik.mallya ___ 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] Structured grid, Reader, Metadata
Hi everybody, I'm just writting a reader that outputs a structured grid from a file. There already is some code to visualize data in the file as a mesh, but it uses openGL and some custom objects (that i would like to reuse of course!). Wanting to port it in Paraview, I'm just wondering if my reader instance is destroyed after requestInformation and requestData have been called. -If not, how can I get a handle on it with a new filter to access some objects in it. -If it is destroyed, can I use *vtkmodelMetadata* to pack objects on my * vtkStructuredGrid*? Regards PAPA ___ 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] CGNS Reader fails in 3.10.0 final release
David Partyka a écrit : Hi Richard, we fixed the issue with the 32bit Windows binary. It is actually a pretty serious bug in the VisIt code because it attempts to delete memory allocated in one library in another. Amazingly it only crashed on 32bit Windows. We are going to release a 3.10.1 that includes the fix as soon as we get feedback on several other fixes that we also will be including. Hi, Dave. I have just downloaded Paraview 3.10.1 Linux 64 bit and Windows 32 bit binaries. Now the CGNS reader is working fine both on Linux and Windows. Thank you for the good job. Richard. -- Richard GRENON ONERA Departement d'Aerodynamique Appliquee - DAAP/ACI 8 rue des Vertugadins 92190 MEUDON - FRANCE phone : +33 1 46 73 42 17 fax : +33 1 46 73 41 46 mailto:richard.gre...@onera.fr http://www.onera.fr ___ 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] CGNS Reader fails in 3.10.0 final release
Excellent, glad to hear! :-) On Fri, Apr 15, 2011 at 4:35 AM, Richard GRENON richard.gre...@onera.frwrote: David Partyka a écrit : Hi Richard, we fixed the issue with the 32bit Windows binary. It is actually a pretty serious bug in the VisIt code because it attempts to delete memory allocated in one library in another. Amazingly it only crashed on 32bit Windows. We are going to release a 3.10.1 that includes the fix as soon as we get feedback on several other fixes that we also will be including. Hi, Dave. I have just downloaded Paraview 3.10.1 Linux 64 bit and Windows 32 bit binaries. Now the CGNS reader is working fine both on Linux and Windows. Thank you for the good job. Richard. -- Richard GRENON ONERA Departement d'Aerodynamique Appliquee - DAAP/ACI 8 rue des Vertugadins 92190 MEUDON - FRANCE phone : +33 1 46 73 42 17 fax : +33 1 46 73 41 46 mailto:richard.gre...@onera.fr http://www.onera.fr ___ 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.10.0 filters contributing code
Regarding the contributing code, I applause! The work-flow you proposed is the simplest one. Do you think it would possible to use the submodule mechanism from git, so that the contributed plugins are directly built in the ParaView tree without interfering with the developers' branches ? Yes, they could, but I suppose it will be better to host that submodule repo at Kitware. Of course, ParaView will start including contributed plugins only after review and such. In any case, plugins should setup so that they can build externally without too much of an issue. 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] PV 3.10.0 filters contributing code
I just posted these set of instructions for contributing plugins to the Wiki http://www.paraview.org/Wiki/ParaView/Guidelines_for_Contributing_Plugins Utkarsh On Fri, Apr 15, 2011 at 8:23 AM, Utkarsh Ayachit utkarsh.ayac...@kitware.com wrote: Regarding the contributing code, I applause! The work-flow you proposed is the simplest one. Do you think it would possible to use the submodule mechanism from git, so that the contributed plugins are directly built in the ParaView tree without interfering with the developers' branches ? Yes, they could, but I suppose it will be better to host that submodule repo at Kitware. Of course, ParaView will start including contributed plugins only after review and such. In any case, plugins should setup so that they can build externally without too much of an issue. 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] PV 3.10.0 filters contributing code
I was thinking the same thing with respect to using Git submodules for plugins. If I have my own git repository and I want to build the plugin as part of ParaView it might start making sense to add some sort of CMake variable similar to the PARAVIEW_EXTERNAL_MODULES but that would specifically look in the Plugins folder of the ParaView source. I can always just add my plugin to the CMakeLists.txt file inside the Plugins folder and just keep lettings pulls from the ParaView git repo merge in but maybe an actual additional mechanism would be great. Just my 2 cents for the morning. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio On Apr 14, 2011, at 3:52 PM, Jérôme wrote: Hi Utkarsh and Natalie, Regarding the scalar name problem, I encountered this and solved it with the -apparently- same code snippet you sent. Yes, having the full code or the procedure to trigger the error would be helpful. Regarding the contributing code, I applause! The work-flow you proposed is the simplest one. Do you think it would possible to use the submodule mechanism from git, so that the contributed plugins are directly built in the ParaView tree without interfering with the developers' branches ? Looking forward to contributing, Jerome 2011/4/14 Utkarsh Ayachit utkarsh.ayac...@kitware.com: Natalie, Could you share the code/data and steps to reproduce so that I may be better able to judge what's the problem? Also as far your question about contributing code goes, I think that's definitely a great idea. I am a thinking of using a the following workflow to get contributed code in: * Commit your plugin (complete with CMake files and such) to a github or gitorious repository. * Add a Wiki page to the ParaView Wiki with details on building/using the plugin, and any other relevant information useful to the user. * Add a link for this Wiki page in the main page (I'll add a section for contributed plugins). If ParaView users find that plugin generally useable, we'd work with the developer to get the plugin into the ParaView repository itself. I want to keep this a separate step since many plugin developers may not consider all the configurations while writing their plugins e.g. it should work in client-server, parallel, render-server/data-server, remote-rendering etc. and it doesn't make sense to not share that plugin only because it doesn't handle some obscure configuration. How does that sound? Utkarsh On Thu, Apr 14, 2011 at 5:03 AM, Natalie Happenhofer natalieh...@hotmail.com wrote: Hi! I've recently downloaded PV 3.10.0 and extended it with my own filters I've already build in PV 3.6 and PV 3.8.0. However, executing them in PV3.10.0, I get the error Warning: In /home/happenhofer/svn/paraview/branches/ParaView-3.10.0/Servers/Filters/vtkTexturePainter.cxx, line 179 vtkTexturePainter (0x900c8d0): Failed to locate selected scalars. Will use image scalars by default. ERROR: In /home/happenhofer/svn/paraview/branches/ParaView-3.10.0/VTK/Rendering/vtkOpenGLTexture.cxx, line 196 vtkOpenGLTexture (0x9083d20): No scalar values found for texture input! I've googled those errors and one way to get rid of this seemed to be to name the arrays. Lamentably, the error persists after naming them. Here is a code fragment of setting the output (hor is a vtkDoubleArray): hor - SetName(name.c_str()); output - CopyStructure(input); output - GetPointData() - AddArray(hor); output - GetPointData() - SetActiveScalars(name.c_str()); output - Squeeze(); Do you have any ideas on this? As I said, in PV 3.6.x and PV 3.8.0 this code worked fine. Also, since I've been developing filters for ParaView quite a time now and some of my filters might be interesting to other users as well, so I thought about contributing code. I have coded a DataCalculator which operates on different data sets, for example if you have two datasets at different times and want to know the difference between the values, you could use this filter. Another filter of mine calculates the horizontal average of a dataset. Lastly, I wrote a wrapper-routine to the VTK-and the XDMF-Writer already included in Paraview, so that they do not just write one file, but write a time series of files. This might be interesting if you perform some operations on a time-series read in and want to save the output without having to call the writer for each time step separately. If you are interested, please let me know. Greetings, Natalie ___ 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:
[Paraview] plotting vectors
Hi All, I have a data set for which I need to plot the vector field. The vectors look great, however, I don't see the axis, so that one knows geometry scale..Is there a way to do in paraview. Regards, Vishwa ___ 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] plotting vectors
Hi , Thanks for getting back to me.. I was able to enable the axes. However, I still have a problem, which is when I zoom into the data, the labels on the axes are not longer visible. Is there a way to make this happen in paraview itself. Regards, Vishwa On 04/15/2011 09:35 AM, David E DeMarle wrote: On the display tab, turn on Show cube axes. David E DeMarle Kitware, Inc. RD Engineer 28 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-371-3971 x109 On Fri, Apr 15, 2011 at 10:27 AM, Vishwadagarsh...@gmail.com wrote: Hi All, I have a data set for which I need to plot the vector field. The vectors look great, however, I don't see the axis, so that one knows geometry scale..Is there a way to do in paraview. Regards, Vishwa ___ 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] plotting vectors
We are currently working on fixing that label scaling issue. It will be resolved in the next release. Utkarsh On Fri, Apr 15, 2011 at 11:17 AM, Vishwanath Somashekar dagarsh...@gmail.com wrote: Hi , Thanks for getting back to me.. I was able to enable the axes. However, I still have a problem, which is when I zoom into the data, the labels on the axes are not longer visible. Is there a way to make this happen in paraview itself. Regards, Vishwa On 04/15/2011 09:35 AM, David E DeMarle wrote: On the display tab, turn on Show cube axes. David E DeMarle Kitware, Inc. RD Engineer 28 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-371-3971 x109 On Fri, Apr 15, 2011 at 10:27 AM, Vishwadagarsh...@gmail.com wrote: Hi All, I have a data set for which I need to plot the vector field. The vectors look great, however, I don't see the axis, so that one knows geometry scale..Is there a way to do in paraview. Regards, Vishwa ___ 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] PV 3.10.0 filters contributing code
hi! Thanks for the guidelines, that's great. greetings, Natalie Am 15.04.2011 um 14:51 schrieb Utkarsh Ayachit utkarsh.ayac...@kitware.com: I just posted these set of instructions for contributing plugins to the Wiki http://www.paraview.org/Wiki/ParaView/Guidelines_for_Contributing_Plugins Utkarsh On Fri, Apr 15, 2011 at 8:23 AM, Utkarsh Ayachit utkarsh.ayac...@kitware.com wrote: Regarding the contributing code, I applause! The work-flow you proposed is the simplest one. Do you think it would possible to use the submodule mechanism from git, so that the contributed plugins are directly built in the ParaView tree without interfering with the developers' branches ? Yes, they could, but I suppose it will be better to host that submodule repo at Kitware. Of course, ParaView will start including contributed plugins only after review and such. In any case, plugins should setup so that they can build externally without too much of an issue. 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
[Paraview] ANN: IEEE Symposium on Large-Scale Data Analysis and Visualization
CALL FOR PARTICIPATION IEEE Symposium on Large-Scale Data Analysis and Visualization VisWeek 2011 in Providence, RI October 23-24, 2011 Website: http://www.ldav.org/ In many areas of science, simulations and experiments begin to generate many petabytes of data, with some sciences facing exabytes of data near term. Similarly, the collection of information about the Internet applications and users for a variety of purposes is generating only more data. Our ability to manage, mine, analyze, and visualize the data is fundamental to the knowledge discovery process. That is, the value of data at extreme scale can be fully realized only if we have an end-to-end solution, which demands a collective, inter-disciplinary effort to develop. This new symposium, held in conjunction with VisWeek 2011, aims at bringing together domain scientists, data analytics and visualization researchers, and users, and fostering the needed exchange to develop the next-generation data-intensive analysis and visualization technology. Attendees will be introduced to the latest and greatest research innovations in large data management, analysis, and visualization, learn how these innovations impact data intensive computing and knowledge discovery, and also learn about the critical issues in creating a complete solution through both invited and contributed talks, panel discussion, and a large data visualization contest that provides massive data and supercomputing time to contestants. Paper submissions are solicited for a long paper event that describes large data visualization techniques and systems, and a short paper event for practitioners to describe and present their large data visualization applications. Topic emphasis is on algorithms, languages, systems and hardware that supports the analysis and visualization of large data. There are a variety of ways to participate in LDAV 2011 -- papers, posters, and a vis contest. For details, please see http://www.ldav.org. We hope to see you there! Paper Submission Deadline: April 25, 2011 (Abstracts due April 18th) Poster Submission Deadline: August 15, 2011 Contest Submission Deadline: September 2, 2011 Organizing Committeee Symposium Chairs * James Ahrens, Los Alamos National Laboratory * Kwan-Liu Ma, University of California, Davis Program Chairs * David Rogers, Sandia National Laboratories * Claudio Silva, University of Utah Contest Chair * Sean Ahern, Oak Ridge National Laboratory Posters Chairs * Han-Wei Shen, Ohio State University * Venkatram Vishwanath, Argonne National Laboratory Publicity Chairs * Hank Childs, Lawrence Berkeley National Laboratory * Berk Geveci, Kitware Inc. Steering Committee * James Ahrens, Los Alamos National Laboratory * Chris Johnson, University of Utah * Kwan-Liu Ma, University of California, Davis * Michael Papka, Argonne National Laboratory ___ 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] Proposed changes to ParaView Git Workflow
Folks, It has been almost an year since ParaView and VTK migrated to git from CVS as the version control system. Now that everyone has become accustomed to using git, it's time to unleash some of its capabilities to streamline the maintenance, development and release process. This email summarizes the changes planned. Please feel free to voice any concerns or feedback that you may have. This proposal also changes the ParaView release cycle and versioning conventions. Currently ParaView uses two branches master and release. master is pretty much analogous to the CVS head. Developers made topic branches from master and merged them back to master when they were ready to commit (possibly using the stage). No dashboards would test your branch until it was merged into master. This meant that time and again the master would be unstable. This meant that come time to release, we have to spend extra man-hours cleaning up dashboards. This proposal ensures that the master can be maintained at a stable condition without inhibiting rapid development. The gory details will be covered in a separate Wiki page. The major bullets can be summarized as follows: Commits to ParaView --- * ParaView repository will have 3 branches: - release - master - next * Developers start topic branches from master (or release) and do their development. * Once they are ready to merge or ready to test the code on dashboards, they merge the topic branch to next using stage. * The ParaView continuous and nightly dashboards will test the next branch. Consequently every developer can get the testing results for his code. He can add more commits to his topic branch to address any issues that the dashboards exposed and merge those into next as well. * Once every week, members of the core ParaView development team will meet to identify topic branches in next that are stable and ready to be merged to master. This may involve communicating with the topic developer for clarifications etc. * No topic branch will be accepted for a merge to master unless all dashboard issues are addressed. This will ensure that master remains stable. One must note that developers always start their topic branches off master, hence they will always have a solid starting point. * Every time we cut a release, we can simply tag a commit on the master and fast-forward the release branch to that location. Minor patches can go into this branch for patch releases if needed. * Note that no topic branch should ever start from next or merge anything from next. Commits to VTK Submodule -- To isolate ParaView from constant changes to VTK, ParaView will use its own clone of VTK. This will be a nearly exact duplicate of the official VTK repository posted at a separate URL with some additional ParaView specific branches. The master in this clone will automatically track the official VTK-master. It will be a read-only mirror of the upstream i.e. the official VTK repository. This clone will have two new integration branches, pv-master and pv-next. ParaView's master can refer to commits in pv-master alone while next can refer to commits in pv-next alone. Also pv-master will always be merged into pv-next. In general pv-next can be considered a *less* stable staging ground for changes ParaView developers want to make to VTK when compared with VTK's master, while pv-master can be considered *more* stable than VTK-master because it will contain only the subset of topics that have been tested in ParaView. Of course, there are plans to clean up VTK's workflow in near future too. That will ensure a more stable VTK-master, in which case the pv-master will be fast-forwarded to the VTK-master on a more regular basis, but that's immaterial for this discussion. pv-master will always be merged into VTK master too ensuring that the two don't diverge. Thus it will be the ParaView developer's responsibility to get his code approved for VTK (possibly using gerrit). Server-side checks will ensure that you cannot bring in a topic into pv-master unless it's merged succesfully into VTK's master. This ensures that pv-master doesn't end up becoming a branch off VTK with 'hacks' for ParaView. Periodically, whenever VTK's master is deemed stable e.g. just before a release, it will be merged into pv-master. Thus bringing in any validated new changes and enchancements from VTK into ParaView. Versioning --- To help identify the development versions and released versions, our convention has been using odd minor numbers for development e.g. 3.9, 3.11, while even numbers for releases eg. 3.8, 3.10. This is no longer necessary. Instead the version of any development will be latest-stable-release-CommitCount-Commitid, where CommitCount is the number of commit since the lastest-stable-release tag and Commitid is a reduced SHA for the commit. (Look at the documentation for 'git describe' for additional
Re: [Paraview] vtkSocket bugs
Hmm, I had tested it on XP with PV 3.8.1 and didn't have any problems. sorry about that, I'll have to try again. Burlen On 04/14/2011 07:54 PM, David Partyka wrote: Hi Burlen, I had to revert your patch as it doesn't compile on Windows.. You will have to make sure it compiles there as well and resubmit your patch. If you need any help please let me know. Thanks. On Thu, Apr 14, 2011 at 3:51 PM, David Partyka david.part...@kitware.com mailto:david.part...@kitware.com wrote: Thanks Burlen, This is applied for 3.10.2. On Thu, Apr 14, 2011 at 2:11 PM, Burlen Loring blor...@lbl.gov mailto:blor...@lbl.gov wrote: Thanks Dave, Filed the bug report http://www.paraview.org/Bug/view.php?id=12087 I updated the patch for 3.10.0 as well (attached here and on the bug report). Burlen On 04/13/2011 11:24 AM, David Partyka wrote: Humm, I forgot all about this email. I'll stick it in right now for 3.10.2. If you don't mind please file a bug so that it isn't forgotten. On Wed, Apr 13, 2011 at 2:17 PM, Burlen Loring blor...@lbl.gov mailto:blor...@lbl.gov wrote: Hi Dave, What is the status on this? Burlen On 02/27/2011 02:53 PM, David Partyka wrote: Thanks Burlen, We'll take a look. On Sun, Feb 27, 2011 at 5:18 PM, Burlen Loring blor...@lbl.gov mailto:blor...@lbl.gov wrote: Hi, While installing ParaView on Nautilus, http://www.nics.tennessee.edu/computing-resources/nautilus, I hit a bug in vtkSocket that prevents ParaView from running on this machine. While tracking this down I uncovered a couple related issues. The main issue is that vtkSocket does not handle EINTR. EINTR occurs when a signal is caught by the application during a blocking socket call. While ParaView does not make use of signals they are used for asynchronous communication by some SGI specific libraries on Nautilus that are linked in with SGI MPI. Because Rank 0 pvserver spends quite a bit of its time blocked in socket calls it only takes a few 10s of seconds for EINTR to occur. When faced with EINTR ParaView silently exits leaving the user wondering what the heck happened. Which brings me to the second issue, a lack of error reporting in vtkSocket. To solve the first issue vtkSocket has to handle EINTR. How EINTR should be handled depends on the specific socket call. For all calls except connect the call can simply be restarted. For EINTR during connect one can't restart the call on all unix, so instead one must block in a select call when connect fails with EINTR. To be portable across Unix one should handle EINTR in all socket calls, even simple ones like set/getsockopt. The second issue of error reporting applies to all socket related errors in general, my feeling is that when a socket call fails vtkSocket should print a message using vtkErrorMacro, errno, and strerror(or windows equivalent) at the point of failure. I think this should be done inside vtkSocket because this is the only place one can safely assume errno has relevant information and vtkSocket has been implemented returning a single error code, -1, so that returning the real error code would change the API and break existing code, including ParaView. Not to mention that the values for error codes are apparently different on windows and unix. I took a stab at fixing these issues, patches attached. I tested them on my workstation, nautilus, and laptop running xp. I ran a dashboard on my linux workstation and didn't see any related issues. Would someone at KW mind taking a look at the changes and see if it could be made permanent? By the way after testing all socket calls for error returns I uncovered a third bug, vtkSocket::Close didn't set the descriptor ivar to -1 which resulted in vtkSocket::~vtkSocket calling close on a closed socket. Not a disasterous error, but this reinforces my opinion that the returns should be tested and error messages printed. Thanks Burlen
Re: [Paraview] vtkSocket bugs
Hey Burlen, David Gobbi just made some fixes to this and checked it into VTK moments ago. http://vtk.org/gitweb?p=VTK.git;a=commitdiff;h=d2a1fb9c5dd99830ad3cdfb753dcdd0e77268799 http://vtk.org/gitweb?p=VTK.git;a=commitdiff;h=d2a1fb9c5dd99830ad3cdfb753dcdd0e77268799 http://www.cdash.org/CDash/viewUpdate.php?buildid=976658 http://www.cdash.org/CDash/viewUpdate.php?buildid=976658If the dashboard turns out well you should be off the hook ;-) On Fri, Apr 15, 2011 at 2:42 PM, Burlen Loring blor...@lbl.gov wrote: Hmm, I had tested it on XP with PV 3.8.1 and didn't have any problems. sorry about that, I'll have to try again. Burlen On 04/14/2011 07:54 PM, David Partyka wrote: Hi Burlen, I had to revert your patch as it doesn't compile on Windows.. You will have to make sure it compiles there as well and resubmit your patch. If you need any help please let me know. Thanks. On Thu, Apr 14, 2011 at 3:51 PM, David Partyka david.part...@kitware.comwrote: Thanks Burlen, This is applied for 3.10.2. On Thu, Apr 14, 2011 at 2:11 PM, Burlen Loring blor...@lbl.gov wrote: Thanks Dave, Filed the bug report http://www.paraview.org/Bug/view.php?id=12087 I updated the patch for 3.10.0 as well (attached here and on the bug report). Burlen On 04/13/2011 11:24 AM, David Partyka wrote: Humm, I forgot all about this email. I'll stick it in right now for 3.10.2. If you don't mind please file a bug so that it isn't forgotten. On Wed, Apr 13, 2011 at 2:17 PM, Burlen Loring blor...@lbl.gov wrote: Hi Dave, What is the status on this? Burlen On 02/27/2011 02:53 PM, David Partyka wrote: Thanks Burlen, We'll take a look. On Sun, Feb 27, 2011 at 5:18 PM, Burlen Loring blor...@lbl.gov wrote: Hi, While installing ParaView on Nautilus, http://www.nics.tennessee.edu/computing-resources/nautilus, I hit a bug in vtkSocket that prevents ParaView from running on this machine. While tracking this down I uncovered a couple related issues. The main issue is that vtkSocket does not handle EINTR. EINTR occurs when a signal is caught by the application during a blocking socket call. While ParaView does not make use of signals they are used for asynchronous communication by some SGI specific libraries on Nautilus that are linked in with SGI MPI. Because Rank 0 pvserver spends quite a bit of its time blocked in socket calls it only takes a few 10s of seconds for EINTR to occur. When faced with EINTR ParaView silently exits leaving the user wondering what the heck happened. Which brings me to the second issue, a lack of error reporting in vtkSocket. To solve the first issue vtkSocket has to handle EINTR. How EINTR should be handled depends on the specific socket call. For all calls except connect the call can simply be restarted. For EINTR during connect one can't restart the call on all unix, so instead one must block in a select call when connect fails with EINTR. To be portable across Unix one should handle EINTR in all socket calls, even simple ones like set/getsockopt. The second issue of error reporting applies to all socket related errors in general, my feeling is that when a socket call fails vtkSocket should print a message using vtkErrorMacro, errno, and strerror(or windows equivalent) at the point of failure. I think this should be done inside vtkSocket because this is the only place one can safely assume errno has relevant information and vtkSocket has been implemented returning a single error code, -1, so that returning the real error code would change the API and break existing code, including ParaView. Not to mention that the values for error codes are apparently different on windows and unix. I took a stab at fixing these issues, patches attached. I tested them on my workstation, nautilus, and laptop running xp. I ran a dashboard on my linux workstation and didn't see any related issues. Would someone at KW mind taking a look at the changes and see if it could be made permanent? By the way after testing all socket calls for error returns I uncovered a third bug, vtkSocket::Close didn't set the descriptor ivar to -1 which resulted in vtkSocket::~vtkSocket calling close on a closed socket. Not a disasterous error, but this reinforces my opinion that the returns should be tested and error messages printed. 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 ___ 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
Re: [Paraview] vtkSocket bugs
That would be great! Thanks Daves. On 04/15/2011 11:46 AM, David Partyka wrote: Hey Burlen, David Gobbi just made some fixes to this and checked it into VTK moments ago. http://vtk.org/gitweb?p=VTK.git;a=commitdiff;h=d2a1fb9c5dd99830ad3cdfb753dcdd0e77268799 http://www.cdash.org/CDash/viewUpdate.php?buildid=976658 If the dashboard turns out well you should be off the hook ;-) On Fri, Apr 15, 2011 at 2:42 PM, Burlen Loring blor...@lbl.gov mailto:blor...@lbl.gov wrote: Hmm, I had tested it on XP with PV 3.8.1 and didn't have any problems. sorry about that, I'll have to try again. Burlen On 04/14/2011 07:54 PM, David Partyka wrote: Hi Burlen, I had to revert your patch as it doesn't compile on Windows.. You will have to make sure it compiles there as well and resubmit your patch. If you need any help please let me know. Thanks. On Thu, Apr 14, 2011 at 3:51 PM, David Partyka david.part...@kitware.com mailto:david.part...@kitware.com wrote: Thanks Burlen, This is applied for 3.10.2. On Thu, Apr 14, 2011 at 2:11 PM, Burlen Loring blor...@lbl.gov mailto:blor...@lbl.gov wrote: Thanks Dave, Filed the bug report http://www.paraview.org/Bug/view.php?id=12087 I updated the patch for 3.10.0 as well (attached here and on the bug report). Burlen On 04/13/2011 11:24 AM, David Partyka wrote: Humm, I forgot all about this email. I'll stick it in right now for 3.10.2. If you don't mind please file a bug so that it isn't forgotten. On Wed, Apr 13, 2011 at 2:17 PM, Burlen Loring blor...@lbl.gov mailto:blor...@lbl.gov wrote: Hi Dave, What is the status on this? Burlen On 02/27/2011 02:53 PM, David Partyka wrote: Thanks Burlen, We'll take a look. On Sun, Feb 27, 2011 at 5:18 PM, Burlen Loring blor...@lbl.gov mailto:blor...@lbl.gov wrote: Hi, While installing ParaView on Nautilus, http://www.nics.tennessee.edu/computing-resources/nautilus, I hit a bug in vtkSocket that prevents ParaView from running on this machine. While tracking this down I uncovered a couple related issues. The main issue is that vtkSocket does not handle EINTR. EINTR occurs when a signal is caught by the application during a blocking socket call. While ParaView does not make use of signals they are used for asynchronous communication by some SGI specific libraries on Nautilus that are linked in with SGI MPI. Because Rank 0 pvserver spends quite a bit of its time blocked in socket calls it only takes a few 10s of seconds for EINTR to occur. When faced with EINTR ParaView silently exits leaving the user wondering what the heck happened. Which brings me to the second issue, a lack of error reporting in vtkSocket. To solve the first issue vtkSocket has to handle EINTR. How EINTR should be handled depends on the specific socket call. For all calls except connect the call can simply be restarted. For EINTR during connect one can't restart the call on all unix, so instead one must block in a select call when connect fails with EINTR. To be portable across Unix one should handle EINTR in all socket calls, even simple ones like set/getsockopt. The second issue of error reporting applies to all socket related errors in general, my feeling is that when a socket call fails vtkSocket should print a message using vtkErrorMacro, errno, and strerror(or windows equivalent) at the point of failure. I think this should be done inside vtkSocket because this is the only place one can safely assume errno has relevant information and vtkSocket has been implemented returning a single error code, -1, so that returning the real error code would change the API and break existing code, including ParaView. Not to mention that the values for error codes are apparently different on windows and unix. I took a stab at fixing these
Re: [Paraview] vtkSocket bugs
Looks like David Gobbi's change did the trick. I'll merge that into release so it will be part of the next releases of ParaView/VTK. On Fri, Apr 15, 2011 at 2:56 PM, Burlen Loring blor...@lbl.gov wrote: That would be great! Thanks Daves. On 04/15/2011 11:46 AM, David Partyka wrote: Hey Burlen, David Gobbi just made some fixes to this and checked it into VTK moments ago. http://vtk.org/gitweb?p=VTK.git;a=commitdiff;h=d2a1fb9c5dd99830ad3cdfb753dcdd0e77268799 http://www.cdash.org/CDash/viewUpdate.php?buildid=976658 If the dashboard turns out well you should be off the hook ;-) On Fri, Apr 15, 2011 at 2:42 PM, Burlen Loring blor...@lbl.gov wrote: Hmm, I had tested it on XP with PV 3.8.1 and didn't have any problems. sorry about that, I'll have to try again. Burlen On 04/14/2011 07:54 PM, David Partyka wrote: Hi Burlen, I had to revert your patch as it doesn't compile on Windows.. You will have to make sure it compiles there as well and resubmit your patch. If you need any help please let me know. Thanks. On Thu, Apr 14, 2011 at 3:51 PM, David Partyka david.part...@kitware.com wrote: Thanks Burlen, This is applied for 3.10.2. On Thu, Apr 14, 2011 at 2:11 PM, Burlen Loring blor...@lbl.gov wrote: Thanks Dave, Filed the bug report http://www.paraview.org/Bug/view.php?id=12087 I updated the patch for 3.10.0 as well (attached here and on the bug report). Burlen On 04/13/2011 11:24 AM, David Partyka wrote: Humm, I forgot all about this email. I'll stick it in right now for 3.10.2. If you don't mind please file a bug so that it isn't forgotten. On Wed, Apr 13, 2011 at 2:17 PM, Burlen Loring blor...@lbl.gov wrote: Hi Dave, What is the status on this? Burlen On 02/27/2011 02:53 PM, David Partyka wrote: Thanks Burlen, We'll take a look. On Sun, Feb 27, 2011 at 5:18 PM, Burlen Loring blor...@lbl.govwrote: Hi, While installing ParaView on Nautilus, http://www.nics.tennessee.edu/computing-resources/nautilus, I hit a bug in vtkSocket that prevents ParaView from running on this machine. While tracking this down I uncovered a couple related issues. The main issue is that vtkSocket does not handle EINTR. EINTR occurs when a signal is caught by the application during a blocking socket call. While ParaView does not make use of signals they are used for asynchronous communication by some SGI specific libraries on Nautilus that are linked in with SGI MPI. Because Rank 0 pvserver spends quite a bit of its time blocked in socket calls it only takes a few 10s of seconds for EINTR to occur. When faced with EINTR ParaView silently exits leaving the user wondering what the heck happened. Which brings me to the second issue, a lack of error reporting in vtkSocket. To solve the first issue vtkSocket has to handle EINTR. How EINTR should be handled depends on the specific socket call. For all calls except connect the call can simply be restarted. For EINTR during connect one can't restart the call on all unix, so instead one must block in a select call when connect fails with EINTR. To be portable across Unix one should handle EINTR in all socket calls, even simple ones like set/getsockopt. The second issue of error reporting applies to all socket related errors in general, my feeling is that when a socket call fails vtkSocket should print a message using vtkErrorMacro, errno, and strerror(or windows equivalent) at the point of failure. I think this should be done inside vtkSocket because this is the only place one can safely assume errno has relevant information and vtkSocket has been implemented returning a single error code, -1, so that returning the real error code would change the API and break existing code, including ParaView. Not to mention that the values for error codes are apparently different on windows and unix. I took a stab at fixing these issues, patches attached. I tested them on my workstation, nautilus, and laptop running xp. I ran a dashboard on my linux workstation and didn't see any related issues. Would someone at KW mind taking a look at the changes and see if it could be made permanent? By the way after testing all socket calls for error returns I uncovered a third bug, vtkSocket::Close didn't set the descriptor ivar to -1 which resulted in vtkSocket::~vtkSocket calling close on a closed socket. Not a disasterous error, but this reinforces my opinion that the returns should be tested and error messages printed. 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 ___ Powered
