All Projects FreeCAD  Addon Manager  Arch  Assembly  Draft  Expressions  FEM  File formats  GCS  OpenSCAD  Part  PartDesign  Path  Project Tools & Websites  Raytracing  Robot  Sketcher  Spreadsheet  TechDraw

View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002873FEMBugpublic2017-01-24 16:542019-01-20 18:12
Reporterberndhahnebach Assigned Toberndhahnebach  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionreopened 
Product Version0.17 
Target Version0.18Fixed in Version0.18 
Summary0002873: FEM, mesh, unv writer, do not renumbering on file writing
DescriptionIf 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
import Fem
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)
tetra4.Volumes

mesh_file = u"/tmp/femmesh.unv"
tetra4.write(mesh_file)
mesh = Fem.read(mesh_file)
mesh.Volumes


EDIT: Python code to reproduse ths node gap problem on a 2D analysis, tested on FreeCAD 0.18.15644:

# load 2D example file and set 3D output in solver
doc = FreeCAD.open(FreeCAD.ConfigGet("AppHomePath") + 'data/examples/FemCalculixCantilever2D.FCStd')
doc.FEMMeshGmsh.ViewObject.Visibility = False
doc.CalculiXccxTools.BeamShellResultOutput3D = True
doc.recompute()
# run the analysis
import FemGui
FemGui.setActiveAnalysis(doc.Analysis)
from femtools import ccxtools
fea = ccxtools.FemToolsCcx()
fea.update_objects()
fea.purge_results()
fea.run()

# node keys
doc.Result_mesh.FemMesh.Nodes.keys()  # starts with 178

# save and reload the file
save_name = u"/home/hugo/Desktop/nodegapstest.FCStd"
doc.saveAs(save_name)
FreeCAD.closeDocument(doc.Name)
doc2 = FreeCAD.open(save_name)

# node keys
doc2.Result_mesh.FemMesh.Nodes.keys()  # starts with 1
TagsMesh
FreeCAD Information

Relationships

related to 0003617 closedickby FEM, post processing, vtk mesh, it is not possible to create a vtk mesh with gaps 

Activities

berndhahnebach

2017-01-24 16:54

developer  

femmesh.unv (1,189 bytes)

berndhahnebach

2017-01-24 16:56

developer   ~0007964

confirmed on Version: 0.17.9783 (Git)

vejmarie

2017-02-26 15:26

developer   ~0008449

Hi Bernd,

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
  if (myMesh)
    myMesh->compactMesh();
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.

vejmarie

berndhahnebach

2017-02-26 16:15

developer   ~0008451

Last edited: 2017-02-26 16:15

 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.

bernd

vejmarie

2017-02-26 16:22

developer   ~0008452

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 ?

berndhahnebach

2017-02-26 18:33

developer   ~0008457

Do you have a specific example where renumbering is an issue ?

vejmarie
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.

Bernd

vejmarie

2017-02-26 18:58

developer   ~0008459

Hi Bernd,

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 ?

vejmarie

berndhahnebach

2017-02-26 19:38

developer   ~0008460

Last edited: 2017-02-26 19:43

Shall we still consider this behavior as a bug, or an implementation way of SMESH ?

vejmarie
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 ...

Bernd

EDIT: done

berndhahnebach

2018-09-25 21:09

developer   ~0011846

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

berndhahnebach

2018-09-25 21:11

developer   ~0011847

As long as this is open results from 2D and 1D analysis with 3D expansion could not be saved and reloaded.

berndhahnebach

2018-09-25 21:22

developer   ~0011848

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.

wmayer

2019-01-14 16:40

administrator   ~0012430

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
Branch: master
Hash: 0136445404fa1d45fff3d1254f938c147fc3834e
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)

berndhahnebach

2019-01-16 20:09

developer   ~0012445

Last edited: 2019-01-16 20:10

 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 ...

berndhahnebach

2019-01-17 18:24

developer   ~0012452

latest disscussions about this: https://forum.freecadweb.org/viewtopic.php?f=18&t=27105&start=70#p280775

wmayer

2019-01-17 20:08

administrator   ~0012453

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.

wmayer

2019-01-20 18:09

administrator   ~0012472

https://github.com/FreeCAD/FreeCAD/commit/82d92280af74223dfc2f0c190413df6725b4b62c

Issue History

Date Modified Username Field Change
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