CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Paraview & paraFoam (
-   -   paraview crashes, maybe I am doing something wrong (

mihaipruna April 9, 2012 09:11

paraview crashes, maybe I am doing something wrong
I'm trying to get out something like this:

Let's leave the streamlines out for now. I have a case with 4 million cells. I clip the internal mesh. Then I reopen another instance of the case further down in the pipeline and only display the STL surfaces. Anything beyond that causes it to crash. It's also very slow. I am using a Ubuntu VM with 6GB of RAM. I am currently expanding the disk size from 20gb to 40GB. Anything else I can do?

wyldckat April 9, 2012 09:31

Hi Mihai,

Is your Ubuntu i686 or x86_64? To confirm, run:

uname -m
If it's i686, it won't matter how much RAM you throw at it, because the maximum amount of RAM any process can use in 32bit is 2GiB.

Given that nowadays ParaView has an internal reader, you can copy the case folder to your real Windows or Mac machine and open any file with the extension "*.foam".

On Windows, open a command line window (run cmd), go into the folder where you have the case and run:

echo. > case.foam
The open this file "case.foam" in ParaView. This way you can use all of the RAM that your real machine has.
You can pre-create such a file on Ubuntu by running:

paraFoam -touch -builtin
Best regards,

lovecraft22 April 9, 2012 10:33

I'm using ubuntu on a virtual machine as well on a mac. What I usually do is to set the case directory as a shared folder between my host machine and the guest. This way I can look at the results using paraview on Mac Os X instead of looking at them within the virtual machine.

wyldckat April 9, 2012 10:43


Originally Posted by lovecraft22 (Post 353787)
What I usually do is to set the case directory as a shared folder between my host machine and the guest.

Be very careful when doing this on Windows + VirtualBox with Ubuntu VM, because it's been known to make the OpenFOAM solver's complain about files.
I'm not really sure in which way the folders were being shared, all I know is that crazy errors appeared. It'll take a while to look for the posts that mention this :(

edit: I searched for it and found the relevant thread and specific post confirming the issue with shared folders:

lovecraft22 April 9, 2012 10:52

Thank you Bruno, I noticed that indeed…

When you delete a file from the host machine then openFoam complains because some other file is missing or because it cannot write within a certain folder… The only way to solve this is to unmount you shared folder and then to mount it back. I created two aliases to perform these two tasks faster.

I'm on a Mac so that's not a Windows issue only (funny, isnt't it…)

mihaipruna April 9, 2012 15:05

thanks everyone, it works way better under windows. still crashed at some point in time, but farther along :)

lramutti April 25, 2014 20:27

Hey guys,

My ParaView 3.12 suddenly froze and I installed ParaView 4.0 to replace it. It seems like the new ParaView does not like one of the stl files I am trying to open. This is the error it keeps giving me:


ERROR: In /home/opencfd/OpenFOAM/ParaView-4.1.0/VTK/IO/Geometry/vtkSTLReader.cxx, line 378
vtkSTLReader (0x5c2f0a0): STLReader error reading file: /home/meisu/OpenFOAM/meisu-2.2.1/run/Research/HarranMesh/PostTurkey/priorityCases/priorityactualCase/constant/triSurface/dentro.stl Premature EOF while reading point.

Does somebody know how to solve this?


wyldckat April 26, 2014 07:41

Greetings Lucas,

It would be useful to know:
  1. What exactly happened to your ParaView 3.12.0, for example if you upgraded you're Linux Distribution or installed something else new.
  2. Also would be useful how exactly you installed ParaView 4.1.0.
  3. What command did you use to run ParaView 4.1.0?
My guess is that your Linux installation is using a non-English user interface. If you do not use the paraFoam script to launch ParaView, then you'll need to run this command before opening ParaView from the command line:

export LC_ALL=C
The other possibility is that ParaView is correct in stating that the STL file is incomplete, possibly due to a lack of disk space when you saved the STL file.

Best regards,

lramutti April 26, 2014 15:48

Hey Bruno,

Thanks for the response. So what happen was that suddenly my ParaView 3.12 stopped to work. With that I mean that I was not able to hit the apply key when I clicked a region of my mesh or a parameter. Same thing happened when trying to open a STL. So I thought I should simply restart the computer. It didn't workout. Another interesting thing that happened was with my clock on the top of the screen that disappeared. I figured it would just be simpler to re-install ParaView by installing the new version of OpenFOAM. Now regardless of the FOAM version I am running I just hit paraFoam in the command line and ParaView 4.0 opens. I personally don't think there is any problem with the STL because I was able to open it on ParaView 3.12 before it crashed. Seems like OpenFOAM has its own life :)

lramutti April 26, 2014 16:08

Sorry for the second message but just to clarify the previous one. My ParaView 3.12 did not crash because I was trying to open the STL file. I was able to open the STL but the apply key froze. Sorry for the misunderstanding.



wyldckat April 28, 2014 15:49

Hi Lucas,

The disappearance of the clock and other controls on the top right is one of those crazy bugs that easily occur in Ubuntu+Gnome. I have yet to understand why it happens.

The remaining description seems to be related to a possible update made to the system. This would easily happen if for example you had updated Ubuntu 13.10 to 14.04.
The other possibility is if the graphics card drivers had been updated.

As for the problem with the STL file, here are a few questions to try and figure out what might be the problem:
  1. If you run the following command, what does it give you?

    which paraview
  2. And what about this command:

    type paraFoam
  3. And if you run the following commands, are you able to open the STL file from within ParaView without any problems?

    export LC_ALL=C

Best regards,

PS: Forum members can edit their own posts within a period of 30 days of originally posting them ;)

lramutti April 28, 2014 17:16

Hey Bruno,

Thanks for letting me know about editing in the forum. I have followed your advice and this is what the terminal give me:


If you run the following command, what does it give you?

which paraview



And what about this command:

type paraFoam


paraFoam is hashed (/opt/openfoam230/bin/paraFoam)
**What is that supposed to mean?


And if you run the following commands, are you able to open the STL file from within ParaView without any problems?

export LC_ALL=C

It turns out that the code crash and the following is output (it is very long):

ERROR: In /home/opencfd/OpenFOAM/ParaView-4.1.0/VTK/IO/Geometry/vtkSTLReader.cxx, line 378
vtkSTLReader (0x517e520): STLReader error reading file: /home/meisu/OpenFOAM/meisu-2.2.1/run/Research/HarranMesh/PostTurkey/priorityCases/priorityactualCase/constant/triSurface/dentro.stl Premature EOF while reading point.

*** glibc detected *** /opt/paraviewopenfoam410/lib/paraview-4.1/paraview: double free or corruption (!prev): 0x0000000005525120 ***
======= Backtrace: =========
======= Memory map: ========
00400000-008bb000 r-xp 00000000 08:01 9115160                            /opt/paraviewopenfoam410/lib/paraview-4.1/paraview
00aba000-00abb000 r--p 004ba000 08:01 9115160                            /opt/paraviewopenfoam410/lib/paraview-4.1/paraview
00abb000-00abc000 rw-p 004bb000 08:01 9115160                            /opt/paraviewopenfoam410/lib/paraview-4.1/paraview
01c0b000-058f6000 rw-p 00000000 00:00 0                                  [heap]
7fc6c395c000-7fc6c395d000 rw-s 16f804000 00:05 1532                      /dev/dri/card0
7fc6c395d000-7fc6c395e000 rw-s 16f803000 00:05 1532                      /dev/dri/card0
7fc6c395f000-7fc6c3960000 rw-s 16f801000 00:05 1532                      /dev/dri/card0
7fc6c39d2000-7fc6c39e8000 r--p 00000000 08:01 6294626                    /usr/share/fonts/type1/gsfonts/n022024l.pfb
7fc6c39e8000-7fc6c39f0000 rw-s 16a127000 00:05 1532                      /dev/dri/card0
7fc6c39f8000-7fc6c39f9000 rw-s 16a147000 00:05 1532                      /dev/dri/card0
7fc6c3a01000-7fc6c3a09000 rw-s 154c85000 00:05 1532                      /dev/dri/card0
7fc6c3a09000-7fc6c3a11000 rw-s 154c7d000 00:05 1532                      /dev/dri/card0
7fc6c3a11000-7fc6c3a19000 rw-s 154c75000 00:05 1532                      /dev/dri/card0
7fc6c3a19000-7fc6c3a21000 rw-s 154c6d000 00:05 1532                      /dev/dri/card0
7fc6c3a21000-7fc6c3a29000 rw-s 154c65000 00:05 1532                      /dev/dri/card0
7fc6c3a29000-7fc6c3a31000 rw-s 154c5d000 00:05 1532                      /dev/dri/card0
7fc6c3a31000-7fc6c3a39000 rw-s 154c55000 00:05 1532                      /dev/dri/card0
7fc6c3a39000-7fc6c3a41000 rw-s 154c4d000 00:05 1532                      /dev/dri/card0
7fc6c3a41000-7fc6c3a49000 rw-s 154c45000 00:05 1532                      /dev/dri/card0
7fc6c3a49000-7fc6c3a51000 rw-s 154c3d000 00:05 1532                      /dev/dri/card0
7fc6c3a51000-7fc6c3a59000 rw-s 154c35000 00:05 1532                      /dev/dri/card0
7fc6c3a59000-7fc6c3a61000 rw-s 154c2d000 00:05 1532                      /dev/dri/card0
7fc6c3a61000-7fc6c3a69000 rw-s 154c25000 00:05 1532                      /dev/dri/card0
7fc6c3a69000-7fc6c3a71000 rw-s 154c1d000 00:05 1532                      /dev/dri/card0
7fc6c3a71000-7fc6c3a79000 rw-s 154c15000 00:05 1532                      /dev/dri/card0
7fc6c3a79000-7fc6c3a81000 rw-s 154c0d000 00:05 1532                      /dev/dri/card0
7fc6c3a81000-7fc6c3a89000 rw-s 154c05000 00:05 1532                      /dev/dri/card0
7fc6c3a89000-7fc6c3a91000 rw-s 154bfd000 00:05 1532                      /dev/dri/card0
7fc6c3a91000-7fc6c3a99000 rw-s 154bf5000 00:05 1532                      /dev/dri/card0
7fc6c3a99000-7fc6c3aa1000 rw-s 154bed000 00:05 1532                      /dev/dri/card0
7fc6c3aa1000-7fc6c3aa2000 rw-s 16a09e000 00:05 1532                      /dev/dri/card0
7fc6c3aa2000-7fc6c3aa3000 rw-s 16a09d000 00:05 1532                      /dev/dri/card0
7fc6c3aa3000-7fc6c3aa4000 rw-s 16a09c000 00:05 1532                      /dev/dri/card0
7fc6c3aa4000-7fc6c3aac000 rw-s 154be5000 00:05 1532                      /dev/dri/card0
7fc6c3aac000-7fc6c3ab4000 rw-s 154bdd000 00:05 1532                      /dev/dri/card0
7fc6c3ab4000-7fc6c3abc000 rw-s 154bd5000 00:05 1532                      /dev/dri/card0
7fc6c3abc000-7fc6c3ac4000 rw-s 154bcd000 00:05 1532                      /dev/dri/card0
7fc6c3ac4000-7fc6c3acc000 rw-s 154bc5000 00:05 1532                      /dev/dri/card0
7fc6c3acc000-7fc6c3ad4000 rw-s 154bbd000 00:05 1532                      /dev/dri/card0
7fc6c3ad4000-7fc6c3adc000 rw-s 154bb5000 00:05 1532                      /dev/dri/card0
7fc6c3adc000-7fc6c3ae4000 rw-s 154bad000 00:05 1532                      /dev/dri/card0
7fc6c3ae4000-7fc6c3aec000 rw-s 154ba5000 00:05 1532                      /dev/dri/card0
7fc6c3aec000-7fc6c3af4000 rw-s 154b9d000 00:05 1532                      /dev/dri/card0
7fc6c3af4000-7fc6c3afc000 rw-s 154b95000 00:05 1532                      /dev/dri/card0
7fc6c3afc000-7fc6c3b04000 rw-s 154b8d000 00:05 1532                      /dev/dri/card0
7fc6c3b04000-7fc6c3b0c000 rw-s 154b85000 00:05 1532                      /dev/dri/card0
7fc6c3b0c000-7fc6c3b14000 rw-s 154b7d000 00:05 1532                      /dev/dri/card0
7fc6c3b14000-7fc6c3b1c000 rw-s 154b75000 00:05 1532                      /dev/dri/card0
7fc6c3b1c000-7fc6c3b24000 rw-s 154b6d000 00:05 1532                      /dev/dri/card0
7fc6c3b24000-7fc6c3b2c000 rw-s 154b65000 00:05 1532                      /dev/dri/card0
7fc6c3b2c000-7fc6c3b34000 rw-s 154b5d000 00:05 1532                      /dev/dri/card0
7fc6c3b34000-7fc6c3b3c000 rw-s 154b55000 00:05 1532                      /dev/dri/card0
7fc6c3b3c000-7fc6c3b44000 rw-s 154b4d000 00:05 1532                      /dev/dri/card0
7fc6c3b44000-7fc6c3b4c000 rw-s 154b45000 00:05 1532                      /dev/dri/card0
7fc6c3b4c000-7fc6c3b55000 r-xp 00000000 08:01 5769387                    /usr/lib/x86_64-linux-gnu/qt4/plugins/iconengines/
7fc6c3b55000-7fc6c3d54000 ---p 00009000 08:01 5769387                    /usr/lib/x86_64-linux-gnu/qt4/plugins/iconengines/
7fc6c3d54000-7fc6c3d55000 r--p 00008000 08:01 5769387                    /usr/lib/x86_64-linux-gnu/qt4/plugins/iconengines/
7fc6c3d55000-7fc6c3d56000 rw-p 00009000 08:01 5769387                    /usr/lib/x86_64-linux-gnu/qt4/plugins/iconengines/
7fc6c3d59000-7fc6c3d61000 rw-s 154b3d000 00:05 1532                      /dev/dri/card0
7fc6c3d61000-7fc6c3d69000 rw-s 154b35000 00:05 1532                      /dev/dri/card0
7fc6c3d69000-7fc6c3d71000 rw-s 154b2d000 00:05 1532                      /dev/dri/card0
7fc6c3d71000-7fc6c43d0000 rw-s 00000000 00:04 398295044                  /SYSV00000000 (deleted)
7fc6c43d0000-7fc6c43d1000 rw-s 16d896000 00:05 1532                      /dev/dri/card0
7fc6c43d1000-7fc6c43d2000 rw-s 16dca6000 00:05 1532                      /dev/dri/card0
7fc6c43d2000-7fc6c43d3000 rw-s 16d895000 00:05 1532                      /dev/dri/card0
7fc6c43d3000-7fc6c4696000 rw-p 00000000 00:00 0
7fc6c4696000-7fc6c4697000 rw-s 13bbe4000 00:05 1532                      /dev/dri/card0
7fc6c4697000-7fc6c4698000 rw-s 13bbe3000 00:05 1532                      /dev/dri/card0
7fc6c4698000-7fc6c4699000 rw-s 16f988000 00:05 1532                      /dev/dri/card0Aborted (core dumped)



lramutti April 29, 2014 14:39


It seems that ParaView crashes whenever the ASCII STL file lacks a filenmane for the endsolid. For instance, I notice that in this particular case my STL file contained:


solid internal


The correct way is supposed to be:


solid internal

endsolid internal



wyldckat April 30, 2014 13:03

Hi Lucas,

Sorry, I didn't manage to look into this any sooner. And many thanks for sharing the solution you've found!

And your solution has now reminded me that Tobi had posted a nearly identical question several months ago: - although the issue back then was with older versions of ParaView... I guess the STL reader in ParaView/VTK is pretty sensitive...

Best regards,

Tobi May 12, 2014 05:43


Originally Posted by lramutti (Post 488981)

The correct way is supposed to be:


solid internal

endsolid internal




nice to know Lucas... just one question!
If you using region STLīs so you should define it as follow:


solid wallSurfaceHead
endsolid wallSurfaceHead
solid inletFront
endsolid inletFront

Is that correct or did you try it out?

lramutti May 14, 2014 16:28

Hey Tobi

That's correct. Make sure to add the mentioned commands to the regions of every STL before concatenating.



Tobi November 27, 2014 06:36

Hi Lucas,

my experience (interesting) is, that if you name your STL like *.STL you have to write that format:

solid myName
endsolid myName

If you rename the STL into *.stl, it is working without the myName after ensolid like:

solid myName

All times are GMT -4. The time now is 12:08.