Hi everybody, I just downlo
I just downloaded the last version of paraview, i.e. 3.0.0
It looks like a nice update but I only succeed in using it with vtk files. I mean, translating with foamToVTK,then run paraview and open the vtk files of the desired case.
Is there a way to use it in the classical way:
paraFoam <root> <case>
When I do so, it return an error: "Got unknown argument: paraFoam.pvs"
Or will it possible in the future?
Thanks for any information.
Search for paraview3 on the bo
Search for paraview3 on the board and you will find stuff like
(and I think Mattijs answer in that thread answers you question)
Hello, Couple of months ago
Couple of months ago (The time around that post which Bernhard pointed to), I got the PVFoamReader partially working on ParaView 3.1.0.
It could (still can :-)!) display the internal mesh without any problems.... but when it came to displaying each individual patch, I was only able to to take it to a point where each patch was treated as a separate data-set.
So it works fine, but when you open the case using paraFoam, it gives you each patch as a different output. This does not look as elegant as the current way in which patches are handled using paraview 2.4.4.
The way to solve this would be to use the multiblock data sets available in the new VTK library, but I havent had the time to look into doing that yet. Anyway.... Mattijs is working on this issue... :-)! (Increases the laziness in me :-)!)
By the way... there already exists a plugin for OpenFOAM datasets in the ParaView 3 CVS. You need to enable it. For more information on that, check out.....
Have a nice evening!
Hello Philippose, Recently
Recently I'm slowly making progress on improving the paraview native reader (of which I posted an intermediate result here). Regarding that your words drew my attention: "I was only able to to take it to a point where each patch was treated as a separate data-set" since, the native reader also works exactly as you wrote following Terry's original implementation: the reader sets each patch as a separate dataset within one block (group) of vtkMultiBlockDataSet. However as of now it doesn't seem to make any problems to me. So, could you tell me what's the problem?
P.S. The native reader can also be turned on as a builtin reader on ParaView 3.0.2 (at least, I still haven't tried other ParaView3 versions) and I added how-to on the last part of the Tip_Build_A_Paraview3_Plugin page.
Hello Takuya, A Good day to
A Good day to you :-)!
I guess I created some confusion with my last post, and I apologise for that. I guess I used the wrong terms in describing what I had managed to achieve... so here is the next try :-)!
Since you work with Paraview at the coding level, I guess it will be enough to say... that I managed to get each patch as a separate output port. Not as separate data-sets... but as separate ports. I did not use the MultiBlockDataSet facilities... it was a super quick dirty modification to see if I could get a case loaded into ParaView 3.x.x.
So... in the paraview graphical interface... when I open a case... at the top left side where it shows the data-set currently opened... it gives a list of each patch in the form of a tree structure under the case opened. Then... I can switch on and off patches by controlling the visibility of each of those items in the list.
Let me see if I can send you a couple of screen shots of what I mean. I need to see if the code I wrote is still somewhere around on my hard disk :-)!
The problem however was... that I could not find a way of dynamically creating output ports (My last try was on Paraview 3.1.0.... I compiled Paraview 3.3.0 last evening... maybe something has changed) based on the number of patches in the case.
And also.... in this case... the custom graphical interface (the same one used by paraFoam now to select patches) does not effect the display of the patches.
Also :-) I could not load the different time instances in the case of a transient simulation.
Anyway.... I could sit with it again... and try a complete rewrite. Need to see if I am up to something like that now :-)!
Hope I cleared things up :-)!
I really want to switch to the ParaView 3 series... the interface is so much better (and cooler :-)!)
Have a nice day!
Hi Philippose, Thanks so mu
Thanks so much for an answer, all is clear to me now! I don't see any multiple output ports on the pipeline panel so that's probably a problem that I don't have to be afraid of.
With regard to interaction between the UI and the reader code I'm in a state not that different from you right now... no patch selection (I have even given up implementing that feature from the beggining), VCR controls don't work for timestepping (but the time slider in the reader panel works), etc, etc. I'm decided to be sticking with 3.0.2 for a while since the newer versions frequently don't compile, changes too quickly and most of all I would like to concentrate on the reader code itself rather than tracking the newest CVS head. I figure it won't be too hard to tailor the code later to suit the newest ParaView after completion of the code.
Hello again Takuya, Here ar
Hello again Takuya,
Here are some screenshots of the the things I spoke about.... I hope I can fit all of them into the post here :-)! Lets see....
I shall look into the whole issue again this weekend.... but this time I am looking more in the direction of doing it write.... probably with multi block datasets, and maybe with temporal datasets...
Have a nice weekend!
One thing I forgot to mention.
One thing I forgot to mention..... for me... the reader GUI works for selection of patches, if I allow multiple output ports as shown above. But again... there are many other problems that crop up.
The problem is... I cannot change the number of output ports in a dynamic manner.... which is why you see 10 output ports, even though I have only 5 patches + internal mesh.
Another thing is.... with the current plugin, paraview quits with a segmentation fault when I try to make a cross-section cut through the mesh :-)!
Basically.... as it is now... its a good "proof of concept"... but very very far from being too useful. On the other hand... if only the internal mesh needs to be displayed... without the need to switch on and off patches... then I think this plugin can be "simplified" to a working reader plugin with very few changes.
Hi Philippose, I was able to
I was able to confirm what you said from your screenshots (different ports for differnt patches etc.) and my understanging is right. Besides, your screenshots looks very interesting...! My motivation for working on the native reader is to get a reasonably working reader on Windows (where AFAIK the PVFoamReader-vtkFoam approach doesn't work) but if I could live with only Linux I would be just sitting until your work completes...
As to patch assignment problem I think Terry's native reader (ParaView3/VTK/IO/vtkOpenFOAMReader.cxx) might be able to offer you some help. According to RequestData() and CreateDataSet() of the code it seems that if you have each patch as a separate vtkUnstructuredGrid all patches can be simply added into group 0 of vtkMultiBlockDataSet.
And one question: where did you get ParaView 3.3 source code? For ParaView 3.2
cvs -d :pserver:firstname.lastname@example.org:/cvsroot/ParaView3 co -r ParaView-3-2 ParaView3
worked but not for 3.3.
Hello yet again :-)! Paravi
Hello yet again :-)!
Paraview 3.3.0 is the current base branch you get when you download ParaView from the CVS using (copy pasted from the paraview website :-)!):
cvs -d :pserver:email@example.com:/cvsroot/ParaView3 login
(respond with empty password)
Follow this command by checking out the source code:
cvs -d :pserver:firstname.lastname@example.org:/cvsroot/ParaView3 co ParaView3
Yes.... I have been looking at Terry's native reader (I assume you are working on extending the functionality of this native reader?) for ideas on using the multi-block data set capabilities.
It would be great to have an OpenFOAM paraview reader for the windows platform.... but so far, I found the current native reader (Terry's reader) to be extremely slow in loading the case... and when any modifications are made.
I guess the way the OpenFOAM source code handles the mesh data is highly optimised and streamlined... making things really fast! This is why I am still sticking to the OpenFOAM reader (PVFoamReader)... and hence the linux limitation.
So in that case I guess a reasonable deal would be for me to wait for you to come up with a blitzing Windows capable paraview plugin... while I work on a linux variant (Till yours beats mine on speed :-)! After which I can shift to yours for both platforms anyway....!)
And while we are fighting it out... Mattijs will slink in with an even faster plugin (I know he is working on this actively :-)!) putting both of us out of business :-)!
Have a nice weekend!
Hello again Phillipose, Yes,
Hello again Phillipose,
Yes, you are quite right, I'm extending the Terry's code and the performance problem is exactly where I'm intensively working on (besides gzipped file support). I reprogrammed the code almost from scratch, and managed to get roughly comparable performance (if not superior) with the OpenFOAM code. Of cource I looked around the OpenFOAM code here and there, and was surprised to see what functionality is how implemented. Especially the CellShape constructor is almost a beautiful art...
Said that, one of the inherent problems not easily solved within the native reader framework is boundary value handling. It is almost impractical to implement great variety of B.Cs in OpenFOAM thus the B.C.s the native reader can handle correctly will be limited to the ones that have value or gradient entries.
Feature-wise the code is mostly fixed and what remains is testing. It will take a while since I'm asking my collegue to also test it, but hopefully I will be able to post it not so distant future. Of course if you are interested I can send you the code.
Wow :-)! You have managed to g
Wow :-)! You have managed to get the same (better!?) performance as that of the OpenFOAM PVFoamReader !? Now I must say... that really is something :-)!
It would be a pleasure for me to test your code if you can make it available to me. My email ID is listed on my profile (which you can get by clicking on my name in the post.
I assume I would have to copy it into the same place where Terry's code resides in the ParaView sources... and recompile Paraview?
May I ask you what exactly your drive was... to more or less rewrite the code... and actually work out the implementation methods used in OpenFOAM? You must have spent a good number of hours I assume? It couldn't have been only to get it working in Windows...or :-)!?
Currently I am looking through the new VTK Pipeline concepts (I dont have any experience on the old pipeline... so not too bad :-)!), and also Terry's code.
Enjoy your day!
Hi, OK I sent you the code so
OK I sent you the code so it'd be nice if you could try it and give me any comments...
Regarding the motivation story it all attributes to a crappy educational PC cluster system in our university where using an OS other than Windows is not possible at all. Upon that PC system still I'm planning to use OpenFOAM/ParaView as course materials for my lecture on introductory computational engineering. With recent good performance PCs novice students are not accustomed to sit and wait for data processing to be done...!
|All times are GMT -4. The time now is 18:40.|