View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002873||FEM||Bug||public||2017-01-24 16:54||2019-01-20 18:12|
|Target Version||0.18||Fixed in Version||0.18|
|Summary||0002873: FEM, mesh, unv writer, do not renumbering on file writing|
|Description||If an unv consists FEM elements with element numbering not starting with 1 the unv reader reads them and renumbers the starting with one. Since FreeCAD FEM uses unv to read and write FEM meshes inside the fcstd format the FEM mesh will be changed during save and load of a FreeCAD FEM mesh. The bug seams in smesh. See forum post http://forum.freecadweb.org/viewtopic.php?f=18&t=18982&start=10#p148711|
to reproduce use the following python code to create one tetra4 element with element number 88 and reload it. After reading it has element number 1. If the unv is opened in GMSH the element has number 88.
# 4 node tetrahedron --> tetra4
tetra4 = Fem.FemMesh()
tetra4.addNode( 6, 12, 18, 1)
tetra4.addNode( 0, 0, 18, 2)
tetra4.addNode(12, 0, 18, 3)
tetra4.addNode( 6, 6, 0, 4)
tetra4.addVolume([1, 2, 3, 4], 88)
mesh_file = u"/tmp/femmesh.unv"
mesh = Fem.read(mesh_file)
EDIT: Python code to reproduse ths node gap problem on a 2D analysis, tested on FreeCAD 0.18.15644:
||confirmed on Version: 0.17.9783 (Git)|
I looked at this issue, and I am not even yet sure this is a real issue, the UNV format specifies some labelling but for memory management and optimization SMESH is calling a Compactor function
at the end of the UNV reader. This function is renumbering nodes to get them contiguous within the Mesh structure. This is not breaking the interpretation of the UNV file format (ok if you resave your file on top of it this will break the numbering expressed in the file, but I am not convinced that we shall address Volumes elements directly by the absolute numbers), but can't we assume that a Volume mesh is based on node which shall be incrementally labelled ? Your mesh is still valide and you still can manipulate it. I agree that this is drastically reducing the interest to have a label.
I can easily suppress the call to the compactMesh (or put it as a parameter of the reader), but I think it will have some side effect our could have some side effect (need to check). If the call is not there your volume element will keep the right labelling. By the way compactMesh is called each time you recompute a Mesh.
Great you had the time to have look at this.Thanks for the informations. Got your point.
In this case we should leave it as it is vor the unv reader, or may be add the posibility to keep the numbers on import (But this is more a nice to have).
But still we need to solve the problem somhow for some other reason! The problem is FreeCAD uses unv to save and load the FEM mesh inside the FreeCAD fcstc file format. Thus if you save and load a FreeCAD file with a FEMMesh the node numbers are changed. This should not happen IMHO.
||Hi Bernd, I think this is a label violation if we define a node volume with label N if there is no nodes with label [0..N-1] defined into the mesh. Do you have a specific example where renumbering is an issue ?|
A Volume mesh with edges and faces. Normaly the volume numbers starts behind the faces and edges. If the edges and faces are removed manually for some reason (may be it is a huuuuuge mesh and one would like to save space and gain performance)the element numbering starts somewhere because the volumes numbering starts somewhere. If this file is saved by FreeCAD to disk and reloaded the mesh has been changed. From user point of view this could be an issue.
May be one has changed the mesh manually for some reason and did not finished his work in changing the mesh and saves the work on disk and reloads it the next day than all elements could be renumbered.
But to be honest this is all theortical. I really never had an issue except that I expected a FEM mesh which I save on disk will be the same mesh after reloading the FreeCAD file.
The mesh is the same after being saved. The element numbering is different I agree. We could perhaps expose the compactMesh function as to get the end user which is manually changing his mesh to compact by himself the results. Roughly Node numbering is an internal structure of SMESH and I believe we shouldn't allow end user to change it without cautious step by step approach including the compactMesh call function which tend to keep node numbering as low as possible.
Shall we still consider this behavior as a bug, or an implementation way of SMESH ?
The user could make his mesh completely manual by pyhton in FreeCAD including the mumbering, but he can not save his work. I try to make a feature request out of it and try to remove the assignment from you. This way we will fine the issue quite easily if some other people facing this issue. I'm curious if someone will in the future ...
We have got a use case where this is a real problem.
For beam and shell meshes the result mesh has node and element gaps. On FreeCAD file save and reload the result mesh is renumbered because of the gaps. Thus the result object node numbers do not fit with the result mesh node numbers anymore. Thus totally wrong results. See forum topic https://forum.freecadweb.org/viewtopic.php?f=18&t=27105&start=50#p223412
||As long as this is open results from 2D and 1D analysis with 3D expansion could not be saved and reloaded.|
steps to reproduce for a shell analysis:
- open FEM 2D example
- select solver
- change "Beam Shell Result Output 3D" to true
- rerun analysis
- check Abs displacement colors in standard result object, they look fine.
- save file on disk
- close file
- open file
- check Abs displacement colors in standard result object, they are broken.
This because of the renumbering unv on file save. See simple tet example from bug report.
With the version below a crash happens when checking the displacement of the reloaded file. This happens inside ViewProviderFemMesh::setDisplacementByNodeIdHelper where *it-startId gives an invalid index that doesn't exist in vNodeElementIdx.
OS: Windows 7
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.15576 (Git)
Build type: Release
Python version: 2.7.14
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.0.0
Locale: German/Germany (de_DE)
We could renumber the mesh on import from CalculiX frd result file. The Resuls_mesh would not have gaps in node ids and thus the unv driver would not compact the mesh on FreeCAD file writing. ...
BTW: added Python code on top of the issue to simpler test and reproduce ...
||latest disscussions about this: https://forum.freecadweb.org/viewtopic.php?f=18&t=27105&start=70#p280775|
Just to be clear: the function compactMesh() is not called when saving a file, it's called when restoring a file. For testing purposes go to DriverUNV_R_SMDS_Mesh::Perform() and comment out the lines
[code=c++] if (myMesh) myMesh->compactMesh(); [/code]
at the end.
|2017-01-24 16:54||berndhahnebach||New Issue|
|2017-01-24 16:54||berndhahnebach||Status||new => assigned|
|2017-01-24 16:54||berndhahnebach||Assigned To||=> vejmarie|
|2017-01-24 16:54||berndhahnebach||File Added: femmesh.unv|
|2017-01-24 16:56||berndhahnebach||Note Added: 0007964|
|2017-01-24 22:01||Kunda1||Tag Attached: Mesh|
|2017-02-26 15:26||vejmarie||Note Added: 0008449|
|2017-02-26 16:15||berndhahnebach||Note Added: 0008451|
|2017-02-26 16:15||berndhahnebach||Note Edited: 0008451|
|2017-02-26 16:22||vejmarie||Note Added: 0008452|
|2017-02-26 18:33||berndhahnebach||Note Added: 0008457|
|2017-02-26 18:58||vejmarie||Note Added: 0008459|
|2017-02-26 19:38||berndhahnebach||Note Added: 0008460|
|2017-02-26 19:38||berndhahnebach||Assigned To||vejmarie => berndhahnebach|
|2017-02-26 19:38||berndhahnebach||Assigned To||berndhahnebach =>|
|2017-02-26 19:39||berndhahnebach||Status||assigned => confirmed|
|2017-02-26 19:42||berndhahnebach||Priority||normal => low|
|2017-02-26 19:42||berndhahnebach||Category||Bug => Feature|
|2017-02-26 19:42||berndhahnebach||Target Version||0.17 =>|
|2017-02-26 19:43||berndhahnebach||Note Edited: 0008460|
|2017-02-26 19:44||berndhahnebach||Summary||read FEM meshes (unv) with elements numbers not starting with 1 is wrong => make it possible to read FEM meshes (unv) with elements numbers not starting with 1|
|2017-02-26 19:45||berndhahnebach||Summary||make it possible to read FEM meshes (unv) with elements numbers not starting with 1 => make it possible to read FEM meshes (*.unv / *.fcstd) with elements numbers not starting with 1|
|2017-03-05 20:39||berndhahnebach||Status||confirmed => closed|
|2018-09-25 21:09||berndhahnebach||Status||closed => feedback|
|2018-09-25 21:09||berndhahnebach||Resolution||open => reopened|
|2018-09-25 21:09||berndhahnebach||Note Added: 0011846|
|2018-09-25 21:10||berndhahnebach||Status||feedback => confirmed|
|2018-09-25 21:10||berndhahnebach||Priority||low => normal|
|2018-09-25 21:10||berndhahnebach||Severity||minor => major|
|2018-09-25 21:10||berndhahnebach||Category||Feature => Bug|
|2018-09-25 21:11||berndhahnebach||Note Added: 0011847|
|2018-09-25 21:12||berndhahnebach||Summary||make it possible to read FEM meshes (*.unv / *.fcstd) with elements numbers not starting with 1 => FEM, mesh, unv writer, do not renumbering on file writing|
|2018-09-25 21:22||berndhahnebach||Note Added: 0011848|
|2019-01-14 15:43||wmayer||Relationship added||related to 0003617|
|2019-01-14 16:40||wmayer||Note Added: 0012430|
|2019-01-16 20:05||berndhahnebach||Description Updated|
|2019-01-16 20:07||berndhahnebach||Description Updated|
|2019-01-16 20:09||berndhahnebach||Note Added: 0012445|
|2019-01-16 20:10||berndhahnebach||Note Edited: 0012445|
|2019-01-17 18:24||berndhahnebach||Note Added: 0012452|
|2019-01-17 20:08||wmayer||Note Added: 0012453|
|2019-01-20 18:09||wmayer||Assigned To||=> berndhahnebach|
|2019-01-20 18:09||wmayer||Status||confirmed => closed|
|2019-01-20 18:09||wmayer||Fixed in Version||=> 0.18|
|2019-01-20 18:09||wmayer||Note Added: 0012472|
|2019-01-20 18:12||wmayer||Target Version||=> 0.18|