Problem with UNV-Mesh-reading
Moderator: bernd
Forum rules
and Helpful information for the FEM forum
and Helpful information for the FEM forum
Problem with UNV-Mesh-reading
I am having a problem with FEM-meshes made with Gmsh. It did work well for quite some time, but now I am getting this mesh for a cube.
I could not find the commit that cause this.
The mesh is created fine with Gmsh, but shows up this wrong way in FreeCAD.
It does work with: 70049dac4b6b5c416694f64182452e69565246b5 I just picked this commit for a test.
It failed with: 72d2349429cdba6beeaec93658ccd2315baa1d14
Any ideas?
Edit: It seems to be this commit, that causes the problem: 6c2a7b479fc8cbd821e1d10df94dee2057f0ca92
issue #0002891: Sketching impossible, Type.Error Exception
Ulrich
I could not find the commit that cause this.
The mesh is created fine with Gmsh, but shows up this wrong way in FreeCAD.
It does work with: 70049dac4b6b5c416694f64182452e69565246b5 I just picked this commit for a test.
It failed with: 72d2349429cdba6beeaec93658ccd2315baa1d14
Any ideas?
Edit: It seems to be this commit, that causes the problem: 6c2a7b479fc8cbd821e1d10df94dee2057f0ca92
issue #0002891: Sketching impossible, Type.Error Exception
Ulrich
- Attachments
-
- failed_mesh_import.png (56.36 KiB) Viewed 2000 times
Re: Problem with UNV-Mesh-reading
for reference
- 70049dac4b6b5c416694f64182452e69565246b5 --> git commit 70049da
- 72d2349429cdba6beeaec93658ccd2315baa1d14 --> git commit 72d2349
- 6c2a7b479fc8cbd821e1d10df94dee2057f0ca92 --> git commit 6c2a7b4
- 70049dac4b6b5c416694f64182452e69565246b5 --> git commit 70049da
- 72d2349429cdba6beeaec93658ccd2315baa1d14 --> git commit 72d2349
- 6c2a7b479fc8cbd821e1d10df94dee2057f0ca92 --> git commit 6c2a7b4
Re: Problem with UNV-Mesh-reading
works for me with:
OS: Debian GNU/Linux 8.7 (jessie)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10064 (Git)
Build type: Unknown
Branch: master
Hash: d7ed8c4383f394f64dd9314eefa00efae02fb32f
Python version: 2.7.9
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 7.0.0
does the GMSH mesh object of FreeCAD works for you? This uses unv too. Would you post a file to test with.
OS: Debian GNU/Linux 8.7 (jessie)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10064 (Git)
Build type: Unknown
Branch: master
Hash: d7ed8c4383f394f64dd9314eefa00efae02fb32f
Python version: 2.7.9
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 7.0.0
does the GMSH mesh object of FreeCAD works for you? This uses unv too. Would you post a file to test with.
Re: Problem with UNV-Mesh-reading
The problem shows up at making the mesh with the Gmsh-button. Here is an example. Importing a mesh does work!
Ulrich
OS: Debian GNU/Linux 8.6 (jessie)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10065 (Git)
Build type: Release
Branch: Rueck6
Hash: 1cec205531828b44156dff7b655d72ee10119529
Python version: 2.7.9
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 7.1.0
Ulrich
OS: Debian GNU/Linux 8.6 (jessie)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10065 (Git)
Build type: Release
Branch: Rueck6
Hash: 1cec205531828b44156dff7b655d72ee10119529
Python version: 2.7.9
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 7.1.0
- Attachments
-
- Box_failed_mesh.fcstd
- (66.61 KiB) Downloaded 28 times
Re: Problem with UNV-Mesh-reading
GMSH mesh button works for me too as well as meshing your box. If you use the GMSH mesh button in FreeCAD and watch the report console there are some informations printed about the files involved. You can see the brep, the geo and the unvfile which where involved in the process. Try to use them manually. Run GMSH manually, with the provided geo, import the created unv manually ...
BTW: you where not using master branch. you are one commit ahead master
BTW: you where not using master branch. you are one commit ahead master
Re: Problem with UNV-Mesh-reading
I had to add a few VTK-modules in order to compile FreeCAD on my system. So I am always one commit ahead.bernd wrote:BTW: you where not using master branch. you are one commit ahead master
I made a test regarding locale. It gives the following output on my system
Code: Select all
ulrich@Pauline:~/Sourcen/FreeCAD/FreeCAD_0.16/bin$ locale
LANG=de_DE.utf8
LANGUAGE=
LC_CTYPE="de_DE.utf8"
LC_NUMERIC="de_DE.utf8"
LC_TIME="de_DE.utf8"
LC_COLLATE="de_DE.utf8"
LC_MONETARY="de_DE.utf8"
LC_MESSAGES="de_DE.utf8"
LC_PAPER="de_DE.utf8"
LC_NAME="de_DE.utf8"
LC_ADDRESS="de_DE.utf8"
LC_TELEPHONE="de_DE.utf8"
LC_MEASUREMENT="de_DE.utf8"
LC_IDENTIFICATION="de_DE.utf8"
LC_ALL=
Code: Select all
ulrich@Pauline:~/Sourcen/FreeCAD/Build_0.17/bin$ locale
LANG=de_DE.utf8
LANGUAGE=
LC_CTYPE="de_DE.utf8"
LC_NUMERIC=C
LC_TIME="de_DE.utf8"
LC_COLLATE="de_DE.utf8"
LC_MONETARY="de_DE.utf8"
LC_MESSAGES="de_DE.utf8"
LC_PAPER="de_DE.utf8"
LC_NAME="de_DE.utf8"
LC_ADDRESS="de_DE.utf8"
LC_TELEPHONE="de_DE.utf8"
LC_MEASUREMENT="de_DE.utf8"
LC_IDENTIFICATION="de_DE.utf8"
LC_ALL=
Ulrich
Re: Problem with UNV-Mesh-reading
I face the same problem with freshly build master (using bernd's script, deleted everything before).
I also noticed that usually the solid which is meshed is automatically hidden and the mesh is shown instead but it does not happen.
Is it maybe related to gmsh? I use the one provided in the repository of Ubuntu 16.04.1
OS: Ubuntu 16.04.1 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10064 (Git)
Build type: Unknown
Branch: master
Hash: d7ed8c4383f394f64dd9314eefa00efae02fb32f
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.0.0
Code: Select all
$ locale
LANG=de_AT.UTF-8
LANGUAGE=de_AT:de
LC_CTYPE="de_AT.UTF-8"
LC_NUMERIC=de_AT.UTF-8
LC_TIME=de_AT.UTF-8
LC_COLLATE="de_AT.UTF-8"
LC_MONETARY=de_AT.UTF-8
LC_MESSAGES="de_AT.UTF-8"
LC_PAPER=de_AT.UTF-8
LC_NAME=de_AT.UTF-8
LC_ADDRESS=de_AT.UTF-8
LC_TELEPHONE=de_AT.UTF-8
LC_MEASUREMENT=de_AT.UTF-8
LC_IDENTIFICATION=de_AT.UTF-8
LC_ALL=
Is it maybe related to gmsh? I use the one provided in the repository of Ubuntu 16.04.1
Code: Select all
$ gmsh -version
2.10.1
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10064 (Git)
Build type: Unknown
Branch: master
Hash: d7ed8c4383f394f64dd9314eefa00efae02fb32f
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.0.0
Re: Problem with UNV-Mesh-reading
No, it is related to commit - 6c2a7b479fc8cbd821e1d10df94dee2057f0ca92 --> http://github.com/FreeCAD/FreeCAD/commit/6c2a7b4HoWil wrote:Is it maybe related to gmsh?
This changes internal setting of LC_NUMERIC. Try to type into the console
Code: Select all
export LC_NUMERIC="C"
Ulrich
Re: Problem with UNV-Mesh-reading
Yeap Ulrich,
it did the trick
HoWil
it did the trick
Thx,ulrich1a wrote:Code: Select all
export LC_NUMERIC="C"
HoWil
Re: Problem with UNV-Mesh-reading
See also this thread: https://forum.freecadweb.org/viewtopic. ... 37#p158962
The note in the Qt docssays that from the main() to the runApplication() after the QApplication is created.
The effect is that now the decimal separator again is a point (i.e. C locale) and not eventually a comma (e.g. for de_DE.UTF-8) which is the desired behaviour.
Now what is the problem with gmsh? Does it fail while loading existing files? If yes can you check if there is comma as decimal separator in floating numbers?
The note in the Qt docssays that
And all what I did is to move the callOn Unix/Linux Qt is configured to use the system locale settings by default. This can cause a conflict when using POSIX functions, for instance, when converting between data types such as floats and strings, since the notation may differ between locales. To get around this problem, call the POSIX function setlocale(LC_NUMERIC,"C") right after initializing QApplication, QGuiApplication or QCoreApplication to reset the locale that is used for number formatting to "C"-locale.
Code: Select all
setlocale(LC_NUMERIC,"C")
The effect is that now the decimal separator again is a point (i.e. C locale) and not eventually a comma (e.g. for de_DE.UTF-8) which is the desired behaviour.
Now what is the problem with gmsh? Does it fail while loading existing files? If yes can you check if there is comma as decimal separator in floating numbers?