mesh distortion on reload (only quadratic elements)

[wmayer]

might be helpful too ...

For a unit test not really. What helped is

Code: Select all

newmesh.getElementNodes(1)

[ian.rees]

I have pushed a branch which works fine on Win64 and Ubuntu 14.04 64-bit. Please test also on other platforms.

I'm not sure I understand the problem I'm looking for, but it seems like I can create 2nd order meshes with netgen (edit:to clarify - using nglib via FreeCAD) and export/import them to/from unv without issue on both Werner's branch and master.

Opening the test file from https://forum.freecadweb.org/viewtopic. ... 49#p165602 I get a broken mesh on either branch - am I understanding correctly that this is expected, since the problem is due to a unv export bug?

OS: Mac OS X
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10699 (Git)
Build type: Debug
Branch: master
Hash: 8643f1cf1fc83314ee9ece9e92c972a1b577945a
Python version: 2.7.13
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.1.0

Ians-MacBook-Pro:src irees$ clang --version
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[wmayer]

I'm not sure I understand the problem I'm looking for, but it seems like I can create 2nd order meshes with netgen (edit:to clarify - using nglib via FreeCAD) and export/import them to/from unv without issue on both Werner's branch and master.

As far as I can see this is only an issue on Windows 64-bit. Somehow the unv export depends on the memory layout of the enums which seems to have always a size of 4 bytes on 32-bit and 64-bit applications while on 64-bit systems it should have 8 bytes. My branch fixes this by explicitly using the size_t type which is a typedef on the corresponding platform to have either 4 or 8 bytes.

What I don't understand is where in the unv export it uses the enum size (I am not familiar enough with the smesh code) nor why it works on Salome for Windows without this fix.

Opening the test file from https://forum.freecadweb.org/viewtopic. ... 49#p165602 I get a broken mesh on either branch - am I understanding correctly that this is expected, since the problem is due to a unv export bug?

The point is that the export is broken. So the created file is broken too and you will see the corrupted result on any kind of platform.

Yesterday I merged my branch and also added a unit test which checks the nodes order of a volume element after save & load with the original mesh.

[ian.rees]

Somehow the unv export depends on the memory layout of the enums which seems to have always a size of 4 bytes on 32-bit and 64-bit applications while on 64-bit systems it should have 8 bytes. My branch fixes this by explicitly using the size_t type which is a typedef on the corresponding platform to have either 4 or 8 bytes.

My understanding is that the standard more-or-less leaves the size of enumerations up to the compiler, as long as it's an integral type that can hold the number of items in the enumeration (not the maximum value of an item in the enumeration). There's a size/speed tradeoff involved, so I think it's normal for modern PC-type computers to use 4-byte enums unless you ask the compiler to save memory using something like -fshort-enums on clang or gcc.

I'd guess the issue is caused by a sloppy cast or memcopy between two classes/structs, where one uses enum and the other uses a long, to specify some field that is supposed to be the same. Your size_t approach seems like the safest bet (without finding the root cause) if the code works with 32 or 64 bit enums depending on what architecture it's compiled for.

[ulrich1a]

As far as I can see this is only an issue on Windows 64-bit.

I had the problem also on Windows 32-bit-system with a mesh made by Gmsh. It was on another computer, where I have no access over the weekend.

Ulrich

[bernd]

vejmarie wrote:
Salome is not supported on MacOS or Windows, or not tested as much as on Linux, which could explain why they didn't faced this issue.

Salome users can lay back.
Everything's alright.

saved and reloaded on Salome 8.2.0 Win64
Screenshot Salome 8.2.0 Win64.png

because we introduced the problem ourself with git commit 732bd85c and werner really made it work on all systems with git commit 1b7224cd