Moderator: bernd
sure ...crobar wrote:... Correct me if I'm wrong, but doesn't the Mesh Design WB only create surface meshes, and not volume meshes?
That's interesting, are you implementing a way of creating a partition mesh to use multiple materials in the same mesh? This is the key thing missing from a mesh suitable for electromagnetic simulation. Generally I'd like to make a mesh of multiple parts, e.g. a magnet in a box of air where the box is one Part and the magnet another Part, but you end up with a single mesh, with different regions of the mesh given appropriate labels of some kind which you can use in your finite element package. For a mechanical example, the same idea might be a part of one metal welded to a part of another metal. You would want one mesh, but different regions of the mesh to have different materials.bernd wrote:Sure it would be possible, BUT ...crobar wrote:... Might it be possible to separate out the meshing component from the workbench? In the long run this would make life easier for those of us who want to do other types of finite element analysis using meshes generated in FreeCAD, e.g. heat flow, or electromagnetics, or fluid dynamics.
...
see Workbenches. The tools of the different workbenches are available in any other Workbench as well. I see no reason for separating FEM Mesh Generation from FEM Workbench. There are so many things to do. I'm on shell and beam analysis as well as multiple materials and of course the wiki. All not yet finished. If you would like to have it go for it and give it a try.
Code: Select all
App.ActiveDocument.getObject("cylinder_mag").FemMesh
========================== Dump contents of mesh ==========================
1) Total number of nodes: 868
2) Total number of edges: 122
3) Total number of faces: 1078
4) Total number of polygons: 0
5) Total number of volumes: 4332
6) Total number of polyhedrons: 0
7) Total number of linear edges: 122
8) Total number of linear faces: 1078
8.1) Number of linear triangles: 1078
8.2) Number of linear quadrangles: 0
9) Total number of linear volumes: 4332
9.1) Number of linear hexahedrons: 0
9.2) Number of linear tetrahedrons: 4332
9.3) Number of linear prisms: 0
9.4) Number of linear pyramids: 0
10) Total number of quadratic edges: 0
11) Total number of quadratic faces: 0
12) Total number of quadratic volumes: 0
===========================================================================
As you stated someone needs to implement it 
Of course if we have all these stuff it could make sense to make an own FEMMeshWB. ... No.crobar wrote: … That's interesting, are you implementing a way of creating a partition mesh to use multiple materials in the same mesh?
This is what I did. I used one big FemMesh and extracted the Elements belonging to the different materials. In CalculiX these Elements are written as different Elsets.crobar wrote: … You would want one mesh, but different regions of the mesh to have different materials.
ok, all I would say is that if you do plan to implement these features, it might be better to start out down the partition mesh/submesh route in the first place, as this might make life easier in the long run. It might mean users do not need to fuse their parts into one big part to do the calculations for instance, and the nodes in different regions would come pre-labelled for use in any FEA code when the mesh is exported.bernd wrote:Yeah, crobar we all are with you. These are great features. Making the mesh more fine where it is needed and mor coarse where it is not needed. Whould be very cool to have such features and Mesh checking and and and
No.crobar wrote: … That's interesting, are you implementing a way of creating a partition mesh to use multiple materials in the same mesh?
This is what I did. I used one big FemMesh and extracted the Elements belonging to the different materials. In CalculiX these Elements are written as different Elsets.crobar wrote: … You would want one mesh, but different regions of the mesh to have different materials.
See viewtopic.php?f=18&t=10640#p90166 But there is development going on. The guil will change again !
Sure, it would be better to go this way, even for performance reason. What I implemented in python is really slow on bigger fem volume meshes. But it is fast enought for fem shell meshes (the once I'm interested). Mhh and the main reason is I only know Python (at the moment).crobar wrote:... ok, all I would say is that if you do plan to implement these features, it might be better to start out down the partition mesh/submesh route in the first place, as this might make life easier in the long run. It might mean users do not need to fuse their parts into one big part to do the calculations for instance, and the nodes in different regions would come pre-labelled for use in any FEA code when the mesh is exported.
I can not say exactly whenn the inner are displayed and when not.