GMSH is not well suited to large meshes one typically require for CFD, we are currently busy implementing cut-cell Cartesian meshing (using cfMeh and snappyHexMesh). This would provide an efficient solution to generate more realistic meshes. We are hoping to finish this in the next couple of weeks.wafi wrote: ... meshing ... mesh region, for bigger meshes this will not work, or ... with my model it did not work, but in general it us unclear what you mean with the relative size, should it be read as percentage?
Computational Fluid Dynamics (CFD) workbench using OpenFOAM
Moderator: oliveroxtoby
Forum rules
and Helpful information for the FEM forum
and Helpful information for the FEM forum
Re: Fork of CFD workbench
Re: Fork of CFD workbench
Hi Johann
I know, that`s why I tried to work with the region, idea behind, to create a boundary layer and mesh this with a fine mesh, but this did not work at all. A better meshing system would be highly appreciate, of cause RANS, possibility to work with waves .... etc I know a lot of things what I would like to have, but early spring is not chrismas
I know, that`s why I tried to work with the region, idea behind, to create a boundary layer and mesh this with a fine mesh, but this did not work at all. A better meshing system would be highly appreciate, of cause RANS, possibility to work with waves .... etc I know a lot of things what I would like to have, but early spring is not chrismas
Re: Fork of CFD workbench
regarding the crash reported yesterday:
after trying to understand where the failure during writing the case files ocures, I have got now an Ubuntu message, stating that openfoam crashed with the error message:
ideasUnvToFoam crashed with SIGABRT in Foam::error::abort
I have tried now to stop the crash by #raise in line 639 in utility.py to try to understand what happens. Please note what output in python window was shown in freecad. I think there is something wrong with the data structure and this data structure which is already on your computer, works fine, try to delete them and I am pretty sure, you will have same problem that the actual workbench do not check the necessary data structure and does not create them in advance ... that is my impression.
Here the errors shown in python window:
Start to write case to folder /tmp
Run pre-build check.
/home/peter/.FreeCAD/Mod/CfdFoam/data/defaults/simpleFoam
/tmp/case
Info: Initialise solver created fields (variables): set(['p', 'U'])
Writing GMSHExport FemMesh to UNV format file: /tmp/case/case.unv
Running ideasUnvToFoam "/tmp/case/case.unv"
bash: Zeile 1: 4108 Abgebrochen (Speicherabzug geschrieben) ideasUnvToFoam "/tmp/case/case.unv" > log.ideasUnvToFoam 2>&1
Traceback (most recent call last):
File "/home/peter/.FreeCAD/Mod/CfdFoam/CfdCaseWriterFoam.py", line 83, in run
success = self.write_case()
File "/home/peter/.FreeCAD/Mod/CfdFoam/CfdCaseWriterFoam.py", line 124, in write_case
self.write_mesh()
File "/home/peter/.FreeCAD/Mod/CfdFoam/CfdCaseWriterFoam.py", line 195, in write_mesh
self.builder.setupMesh(unvMeshFile, scale = 0.001)
File "/home/peter/.FreeCAD/Mod/CfdFoam/FoamCaseBuilder/BasicBuilder.py", line 134, in setupMesh
convertMesh(self._casePath, updated_mesh_path, scale)
File "/home/peter/.FreeCAD/Mod/CfdFoam/FoamCaseBuilder/utility.py", line 668, in convertMesh
setPatchType(case, 'defaultFaces', 'wall') # rename default boundary type to wall
File "/home/peter/.FreeCAD/Mod/CfdFoam/FoamCaseBuilder/utility.py", line 684, in setPatchType
f = BoundaryDict(case)
File "/usr/local/lib/python2.7/dist-packages/PyFoam/RunDictionary/BoundaryDict.py", line 36, in __init__
backup=backup)
File "/usr/local/lib/python2.7/dist-packages/PyFoam/RunDictionary/ParsedParameterFile.py", line 1292, in __init__
boundaryDict=True)
File "/usr/local/lib/python2.7/dist-packages/PyFoam/RunDictionary/ParsedParameterFile.py", line 85, in __init__
self.readFile()
File "/usr/local/lib/python2.7/dist-packages/PyFoam/RunDictionary/FileBasis.py", line 98, in readFile
self.openFile()
File "/usr/local/lib/python2.7/dist-packages/PyFoam/RunDictionary/FileBasis.py", line 84, in openFile
self.fh=gzip.open(self.name+".gz",mode)
File "/usr/lib/python2.7/gzip.py", line 34, in open
return GzipFile(filename, mode, compresslevel)
File "/usr/lib/python2.7/gzip.py", line 94, in __init__
fileobj = self.myfileobj = __builtin__.open(filename, mode or 'rb')
IOError: [Errno 2] Datei oder Verzeichnis nicht gefunden: u'/tmp/case/constant/polyMesh/boundary.gz'
after trying to understand where the failure during writing the case files ocures, I have got now an Ubuntu message, stating that openfoam crashed with the error message:
ideasUnvToFoam crashed with SIGABRT in Foam::error::abort
I have tried now to stop the crash by #raise in line 639 in utility.py to try to understand what happens. Please note what output in python window was shown in freecad. I think there is something wrong with the data structure and this data structure which is already on your computer, works fine, try to delete them and I am pretty sure, you will have same problem that the actual workbench do not check the necessary data structure and does not create them in advance ... that is my impression.
Here the errors shown in python window:
Start to write case to folder /tmp
Run pre-build check.
/home/peter/.FreeCAD/Mod/CfdFoam/data/defaults/simpleFoam
/tmp/case
Info: Initialise solver created fields (variables): set(['p', 'U'])
Writing GMSHExport FemMesh to UNV format file: /tmp/case/case.unv
Running ideasUnvToFoam "/tmp/case/case.unv"
bash: Zeile 1: 4108 Abgebrochen (Speicherabzug geschrieben) ideasUnvToFoam "/tmp/case/case.unv" > log.ideasUnvToFoam 2>&1
Traceback (most recent call last):
File "/home/peter/.FreeCAD/Mod/CfdFoam/CfdCaseWriterFoam.py", line 83, in run
success = self.write_case()
File "/home/peter/.FreeCAD/Mod/CfdFoam/CfdCaseWriterFoam.py", line 124, in write_case
self.write_mesh()
File "/home/peter/.FreeCAD/Mod/CfdFoam/CfdCaseWriterFoam.py", line 195, in write_mesh
self.builder.setupMesh(unvMeshFile, scale = 0.001)
File "/home/peter/.FreeCAD/Mod/CfdFoam/FoamCaseBuilder/BasicBuilder.py", line 134, in setupMesh
convertMesh(self._casePath, updated_mesh_path, scale)
File "/home/peter/.FreeCAD/Mod/CfdFoam/FoamCaseBuilder/utility.py", line 668, in convertMesh
setPatchType(case, 'defaultFaces', 'wall') # rename default boundary type to wall
File "/home/peter/.FreeCAD/Mod/CfdFoam/FoamCaseBuilder/utility.py", line 684, in setPatchType
f = BoundaryDict(case)
File "/usr/local/lib/python2.7/dist-packages/PyFoam/RunDictionary/BoundaryDict.py", line 36, in __init__
backup=backup)
File "/usr/local/lib/python2.7/dist-packages/PyFoam/RunDictionary/ParsedParameterFile.py", line 1292, in __init__
boundaryDict=True)
File "/usr/local/lib/python2.7/dist-packages/PyFoam/RunDictionary/ParsedParameterFile.py", line 85, in __init__
self.readFile()
File "/usr/local/lib/python2.7/dist-packages/PyFoam/RunDictionary/FileBasis.py", line 98, in readFile
self.openFile()
File "/usr/local/lib/python2.7/dist-packages/PyFoam/RunDictionary/FileBasis.py", line 84, in openFile
self.fh=gzip.open(self.name+".gz",mode)
File "/usr/lib/python2.7/gzip.py", line 34, in open
return GzipFile(filename, mode, compresslevel)
File "/usr/lib/python2.7/gzip.py", line 94, in __init__
fileobj = self.myfileobj = __builtin__.open(filename, mode or 'rb')
IOError: [Errno 2] Datei oder Verzeichnis nicht gefunden: u'/tmp/case/constant/polyMesh/boundary.gz'
Re: Fork of CFD workbench
one step ahead ...
after #raise in utility.py line 639 the program wrote the log file ideasUnvToFoam and in this file I could see, that boundary conditions failed and that this was the reason that openfoam stopped. Changing boundary conditions and everything was perfect.
So ... I think the main problem here is the error message, which should state, "OpenFoam stopped due to failures, please note log file". Second problem, this logfile has to be printed regardless if the solver crashes or not. I am not a programmer, but in my point of view, leave th raise command.
after #raise in utility.py line 639 the program wrote the log file ideasUnvToFoam and in this file I could see, that boundary conditions failed and that this was the reason that openfoam stopped. Changing boundary conditions and everything was perfect.
So ... I think the main problem here is the error message, which should state, "OpenFoam stopped due to failures, please note log file". Second problem, this logfile has to be printed regardless if the solver crashes or not. I am not a programmer, but in my point of view, leave th raise command.
Re: Fork of CFD workbench
Wafi, can you share the freecad file? I notice some problem in some constraints that I think they are not supported yet (as symmetry). I can check on it.wafi wrote:one step ahead ...
after #raise in utility.py line 639 the program wrote the log file ideasUnvToFoam and in this file I could see, that boundary conditions failed and that this was the reason that openfoam stopped. Changing boundary conditions and everything was perfect.
So ... I think the main problem here is the error message, which should state, "OpenFoam stopped due to failures, please note log file". Second problem, this logfile has to be printed regardless if the solver crashes or not. I am not a programmer, but in my point of view, leave th raise command.
@developers: have you any suggestion for my parallel computation problem?
Re: Fork of CFD workbench
General advice:Worufu wrote:wafi wrote:[..]@developers: have you any suggestion for my parallel computation problem?
1. Check how the solver should be started to use multiple threads (command line switch?)
2. Test manually outside of FreeCAD - does it work?
3. Check how the solver is started from FreeCAD - is the switch being used?
Re: Fork of CFD workbench
Ok, solved, thanks a lot. I needed a clean installation of MPI, because I had a no upgradable MPI version. So I uninstall MPI and then I have installed BlueCFD-core.PrzemoF wrote:General advice:Worufu wrote:wafi wrote:[..]@developers: have you any suggestion for my parallel computation problem?
1. Check how the solver should be started to use multiple threads (command line switch?)
2. Test manually outside of FreeCAD - does it work?
3. Check how the solver is started from FreeCAD - is the switch being used?
Re: Fork of CFD workbench
Submitted a PR to soup up the README a bit more
https://github.com/jaheyns/CfdFoam/pull/2
https://github.com/jaheyns/CfdFoam/pull/2
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
- oliveroxtoby
- Posts: 810
- Joined: Fri Dec 23, 2016 9:43 am
- Location: South Africa
Re: Fork of CFD workbench
Thanks for the feedback.
As Johan mentioned, this will hopefully work better when the cartesian meshing functionality is done.
* Enable Tools | Panels | Report view
* Right click in the report panel that appears, go to Options and check all the options to display all output.
* Try to run the case again and see what output appears.
Yes, relative size is a fraction of the maximum mesh spacing. This is new functionality and we should probably clarify.wafi wrote:
I have played a little bit today and I had several problems.
... meshing ... mesh region, for bigger meshes this will not work, or ... with my model it did not work, but in general it us unclear what you mean with the relative size, should it be read as percentage?
As Johan mentioned, this will hopefully work better when the cartesian meshing functionality is done.
This is a bit of an issue we have with formatting of dimensioned quantities in FreeCAD at present - fixed number of decimal places results in truncation of small quantities, athough the correct value is stored behind the scenes.... material constants ... I do not know why, but i.e. placing "sea water" in, next edit it`s stated "None" with totally different figures.
It is hard to know without more details. Viewing the exact output may give you a better idea:I had several crashs of the system when using a big model, underwater area of a 12m sailing boat incl. keel and rudder in a box of 20m length, 10m width and 5m draft. I do not know if these crashs were based on evt wrong material inputs, but in general the crashes were when gnuplot showed app. 50 iterations, than gnuplot stopped and shortly after gnuplot stopps solver also stopped. Due to the size of the unv file I did not looked into the materials, so maybe it is something with gnuplot constants or material, I do not know.
* Enable Tools | Panels | Report view
* Right click in the report panel that appears, go to Options and check all the options to display all output.
* Try to run the case again and see what output appears.
Please provide all the information requested in this post before reporting problems with CfdOF.
Re: Computational Fluid Dynamics (CFD) workbench using OpenFOAM
README says
Any OSXers willing to test and report?
Code: Select all
MacOSX:
Not tested, but a POSIX system. Possible to install and run OpenFOAM.
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs