FWW failing to read *.openFoam files

[Mr. Brendan Larcombe 0]

I'm looking for some help with some problems i'm having linking OpenFoam to FFW. Before going into detail I should mention that I've only been using OpenFoam (2.3 and 2.2.2) since the start of the week, which is also the length of time I've been using linux (ubuntu 14.04 LTS) so I'm pretty green regarding the use of both systems.

 

The simulation in question is one of the tutorial problems provided with OpenFoam, snappyMultiRegionHeater, which is a Heater Transfer problem using snappyHexMesh with multiple STL files representing solid regions and regions of air.

 

Now I've had no problem getting OpenFoam to run via FFW, the simulation itself runs perfectly and the outputted *.openFoam files open and can be post processed in paraview without any issue. My problem arises when FFW attempts to read the *.openFoam files and fails to read the data, an example of the output error is given below.

 

ERROR: In /home/qt/4.8.5/VTK/IO/Geometry/vtkOpenFOAMReader.cxx, line 6875
vtkOpenFOAMReaderPrivate (0x5080b40): boundaryField maxY not found in object T at time = 0

 

The error above is generated whether the computation connector loads the *.openFoam file, or whether i load it manually. It generates the error for each tracked variable (T, U, alphat, epsilon, K, p, p_rgh, rho) as well as one or (typically) more boundary fields.

 

I've attempted to convert the *.openFoam files to the ensight format as well, but the problem persists. I've run the simulation using two versions of OpenFoam as well, 2.3.0 and 2.2.2 to see if there was any difference. A dropbox link to the simulation files is as follows https://www.dropbox.com/s/xc82r76hfy9pqw0/OpenFoamToFFW.7z

 

Any advice you might have would be very helpful.

 

Edit: I've been running some other simple simulations and attempting to read thier *.openFoam files (damBreak (multiphase) and flange (snappyhexmesh)) and while FFW successfully loads them into the connector any attempt to post-process them causes a segmentation fault.

[Stefan Wunderlich 6]

Hi Brendan,

 

is it possible to attach a (maybe small) sample of this kind of OpenFOAM result?

I did not have this kind of problem yet.

 

Edit: have not seen the dropbox link, I will check the problem.

 

Cheers,

Stefan

[Stefan Wunderlich 6]

Hi again,

 

I can reproduce the behaviour. I tried opening the file(s) in Paraview but the same errors occured.

 

How did you open the file (and which file) in Paraview?

 

Cheers,

Stefan

[Mr. Brendan Larcombe 0]

Thanks for checking it out Stefan, I figured I'd get someone to check this one out as well https://www.dropbox.com/s/l1sfvnsep49ib72/damBreak.7z it's one of the ones that caused a segmentation fault. I suspect that may be related to my choice of ubuntu install, I hope it's not as I really don't want to have to reinstall a different version.

[Mr. Brendan Larcombe 0]

Hi Stefan,

 

When I opened the files in Paraview I opened all of them at once and selected all of the patches (except the internal mesh patch) on all of the 5 part files, I left the main fail unselected.

 

On another note, opening the damBreak file in windows FFW doesn't causes a segmentation fault when doing post processing (the snappyMultiRegionHeater files give the same error) so there is definitely an issue with my install, or my combination of OS, openfoam and ffw.

 

Thanks again

 

Edit: I've since rolled back to ubuntu 12.04 since it's one of the versions that is supported according to the download page, but I'm still suffering segmentation errors when I try and do any post processing on *.openFoam files. At this point I'm out of ideas, I tried to postprocess the old files, as well as new ones with both causes the crash. That said I've yet to try the snappyMultiRegionHeater simulation, I'll update again once I've tested that as well.

 

Edit: I've re-run snappyMultiRegionHeater, the result is the same, when it tries to read the *openFoam file it generates a series of VTK reader errors. The files load successfully in Paraview as well (files computation{stlfilename}.openFOAM.

[Stefan Wunderlich 6]

Hi Brendan,

 

I can postprocess damBreak without problems on my windows machine (check on Linux later and come back to you).

 

In general (not being an openfoam expert) my understanding is to open only the .foam / .openfoam file (also on paraview). This worked on all cases I had beside of the one you sent. You might consider to ask in an OpenFOAM forum why the first file gives errors in Paraview (when opening the .openfoam file).

 

As a sidenote: it probably won't help installing a different Linux flavour since the problem is most likely not os related.

 

Cheers,

Stefan

[Mr. Brendan Larcombe 0]

Hi Stefan,

 

Any news on post processing damBreak in Linux? That's the thing that's really got me confused, I can't imagine why it works in windows but not linux.

 

thanks for checking it out,

Brendan

[Mr. Brendan Larcombe 0]

Just a quick update. By using version 3.0.18 I've avoided the segmentation fault caused by attempting to post process *.OpenFOAM files, so there appears to be some problem in 3.0.19, or some compatibility issue between 3.0.19 and ubuntu/my setup. No updates on the multiRegionHeater error at this time.

 

Edit: Scratch that, I can post process the files successfully, but after saving and re-opening the mesh result has disappeared from computations & results, while the visulisation toolbox has remained (shown in the image below). This has resulted in none of the post processing being saved, or being at least viewable. So for the time being I can do post processing, but I can't save and review it at a later date.

 

 

Edit: Another update, post processing results produced in 3.0.18 can be opened and reviewed just fine in windows

[Mr. Brendan Larcombe 0]

Another update

 

I've resolved the issue with 3.0.18. I found out the reason the post processing was disappearing was due to saving the project as a new project AFTER completing the simulation didn't move the result as it should have. Saving as a new project before running the simulation, or just saving it normally avoids the problem of missing results data. That said 3.0.19 still crashes when attempting to post process a result. The VTK reader error has also not been resolved, but I'm still looking for other solutions to that problem.

[Karsten Wenzke 12]

Hey Brendan,

 

 

Hi Stefan,

 

Any news on post processing damBreak in Linux? That's the thing that's really got me confused, I can't imagine why it works in windows but not linux.

 

thanks for checking it out,

Brendan

I can reproduce the segmentation fault. This is fixed in the upcoming release 3.1. You can continue working with the 3.0.18 instead of 3.0.19 and update to 3.1 when released.

 

Another update

 

I've resolved the issue with 3.0.18. I found out the reason the post processing was disappearing was due to saving the project as a new project AFTER completing the simulation didn't move the result as it should have. Saving as a new project before running the simulation, or just saving it normally avoids the problem of missing results data. That said 3.0.19 still crashes when attempting to post process a result. The VTK reader error has also not been resolved, but I'm still looking for other solutions to that problem.

 

I can't reproduce that result files are not available after saving the a project to another folder. Have you seen this saving message

and you selected yes? If you select No? that might be the reason why you can't see the results anymore.

As a side note: It is a common practice to save a project before starting a computation.

 

Best Regards

 

Karsten

[Mr. Brendan Larcombe 0]

Hi Karsten

 

I definitely pressed the yes button, I'll double check tomorrow and try and reproduce it.

 

Regards,

Brendan

[Karsten Wenzke 12]

Hey Brendan,

 

I cannot reproduce this behavior. Sorry.

 

Maybe you don't have all rights for the .friendship/tmp folder.

 

Regards,

 

Karsten

[Mr. Sebastian Weickgenannt 1]

No updates on the multiRegionHeater error at this time.

 

Hi Brendan,

 

multiRegion postprocessing for OpenFOAM isn't really supported at this time.

 

Maybe there's some way to extract regions as single cases in OF, but generating VTKs or ensight files and importing those should do the trick as it is.

 

Cheers,

Sebastian