For a unit test not really. What helped ismight be helpful too ...
Code: Select all
newmesh.getElementNodes(1)
Moderator: bernd
For a unit test not really. What helped ismight be helpful too ...
Code: Select all
newmesh.getElementNodes(1)
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.wmayer wrote:I have pushed a branch which works fine on Win64 and Ubuntu 14.04 64-bit. Please test also on other platforms.
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.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.
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.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?
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.wmayer wrote: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.
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.wmayer wrote:As far as I can see this is only an issue on Windows 64-bit.
because we introduced the problem ourself with git commit 732bd85c and werner really made it work on all systems with git commit 1b7224cdUR_ wrote: ↑Mon Apr 03, 2017 7:12 pmSalome users can lay back.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.
Everything's alright.
saved and reloaded on Salome 8.2.0 Win64
Screenshot Salome 8.2.0 Win64.png