FEM object types

[fandaL]

* click on the line number --> https://github.com/FreeCAD/FreeCAD/blob ... cx.py#L885
* manually add -L900 in your browser address line --> https://github.com/FreeCAD/FreeCAD/blob ... #L885-L900

In Firefox I can select block of code by using shift.

[bernd]

in the regard of export mixed meshes to inp file format: issue #3051

[bernd]

in the regard of displaying and creation of mixed meshes. https://forum.freecadweb.org/viewtopic. ... 93#p175893

[bernd]

I have been without my family at the weekend. thus so many posts ... I could not resist and gave the multiple mesh calculation a try. Lots of hacks but less work than I thought. But I got it working without inp file edition for a mix of beam and shell mesh elements. This can be seen as a proof of concept and yes it is doable https://github.com/berndhahnebach/FreeC ... ixedmeshes

screen.jpg (280.75 KiB) Viewed 1707 times

mixed_mesh_edge_face.fcstd

(43.46 KiB) Downloaded 39 times

@ulrich:
I did a small Python inp file writer to get the mesh writeing working. See (https://github.com/berndhahnebach/FreeC ... 3dc92ba83d), but it is more or less a hack. We need to tackle the inp writer down! How about your C++ implementation. Does it work for face beam meshes too?

Imagine this in conjunction with makkemals 3D result stuff

[bernd]

Edges are next, but this already reveals the next problem: If there are solids in the analysis, there is no shell-section written into the inp-file. Actually all elements are in the elements-set Eall. This contains then solid-elements and shell-elements. I think, there is a need to provide different names for each set. But it is actually not clear to me, what is the right way to do this.

My idea for a minimalistic working system:
Nall --> all Nodes
Evolumes --> element set for volume elements
Efaces --> element set for faces elements which do not belong to volumes
Eedges --> element set for edges elements which do not belong to faces and thus not belong to volumes

Sure there could be done much more with the input writer like groups and providing the names and and and. But the provided idea we could get something to work. I would do the changes in ccxwriter on the element sets (I started already see last post.)

bernd

[bernd]

So we need a user input, what sort of element should be used for the geometry, the user wants to analyze. This information needs to be accessible for the definition of the other parts of the analysis: mesh element type, writing of the geometry definition into the input file, constraints definitions and others. In order to give this a clean structure, an object defining 3D-geometry independent from material is helpful

Totally agree with that one. Another simple example is the use of 1D beam element or 1D truss element. Ccx provides both. For first thought I would say it is an independent parameter just for the mesh but as you stated in a former post this is not true. For different mesh element types the constraint parameter could be different too. An simple example are the rotational degrees. Solids do not have them shells and beam have them. Real trusses do not need them. This needs to be taken into account. I'm with you it has to be different from material definition just like it is with beam section and shell thickness.

May be we just do not care about it atm ?! We write some algorithm which goes around this. For example the rotational degrees. If the edge or face the boundary condition belong to a solid element we gone write no rotational degree if it belongs to a shell element we gone write the rotation degree. Mhh, no not good at all.

To be honest I think we need to tackle down the input writer and the element sets, then we can make models and write input data and we will see it much more clear where the problems of all the constraints are. Then we gone find a solution. Either if it is a new object in the analysis, a new object as a child for the mesh or just some attributes in the solver or some smart algorithm directly inside the constraints to get around the problem.

cheers bernd

[bernd]

Hi Ulrich I have been spending some time on this.

If we have multiple materials and multiple shells and multiple beams in one analysis I need to retrieve the element sets. For this I need the informations you gone have implemented in the Abaquswriter too. On the contrary if we would have this informations we could get around most constraint problems without special new objects (It does not mean we do not need it, but we do not need it to get started). Means what is needed.

We need to extract your code from Abaquswriter and extract it in two extra methods. Call this methods from inside the Abaquswriter to write the mesh. Than we will use the new methods to extend the python mesh API (if the methods are there I could extend the python mesh API) to add some new attributes to the mesh object. These will be:

- the mesh faces which do not belong to mesh volumes --> we may call them FacesNotRelatedToVolumes
- the mesh edges which do not belong to mesh faces and thus not to mesh volumes --> we may call them EdgesNotRelatedToFacdes

BTW, with this I could implement the mixed meshes analysis for Z88 as well (I do not know if it is supported by Z88 but I could FreeCAD FEM could do it.) Means any new solver could use the mixed mesh analysis if it done outside Abaquswriter.

Still the Abaquswriter should write the following ElementSets as stated earlier for a mixed mesh analysis mesh:

Nall --> Nodes of Evolumes, Efaces, Eedges or just all nodes
Evolumes --> element set for volume elements
Efaces --> element set for faces elements which do not belong to volumes
Eedges --> element set for edges elements which do not belong to faces and thus not belong to volumes

What is your opinion?

[bernd]

Might this exist in SMESH already ?

@ickby: Stefan if you may read this. Might it be SMESH has some methods to extract the following data from a mesh:

- the mesh faces which do not belong to mesh volumes
- the mesh edges which do not belong to mesh faces and thus not to mesh volumes

I did not see such when I did some development but I'm not good at all in reading C++ API ...

[ulrich1a]

- the mesh faces which do not belong to mesh volumes --> we may call them FacesNotRelatedToVolumes

This was my first approach. It is available here: https://github.com/ulrich1a/FreeCAD_sf_ ... and_Shells
I added filters to the Abaquswriter. At first I searched for all faces on the surface of a solid. Than I did compare these faces with all given faces in the mesh, to find the faces not belonging to a surface of a volume. This works already. But at the end it can not solve problems, where you want an additional shell on top of a surface, or beam elements at shell edges. (This was mentioned by fandal as a typical use case.) So I stopped working at this solution, I also needed to do some other stuff at this time.

To get fandals requirement to work, we need a different approach, where the user has to say, what he wants. The division of material and mesh-volumes into independent objects is the key to this. The user can than click on an shape-object and say it should be meshed as a volume. We give this information to the mesher (works already with gmesh) and than know what is needed to write into the input file. It allows the user to click on the same object again, asking for a shell. In this case both the volumes and the faces will be written into the input file.
Having independent objects for volume meshes and shell meshes, allows to give them a link to a material object. So the user has control over all aspects and there is no need to write complicated if-cascades for all cases of material and mesh combinations. There will be always a combination, that is not anticipated by an automatic algorithm, as we have now.

I know, that this will cause a heavy rewrite of the FEM-workbench. But I do not see, how to get the needed flexibility otherwise. In order to make this transition feasible, some planning and agreement, where the journey should go will be helpful.

Ulrich

[bernd]

I do not really understand your concerns ...

We just need to pass the shape to the mesher and will get the mesh we need. If we need beams on a shell we pass beams on a shell. If we would like to have beam on a volume we pass beams on a volume. If we would like to have shells on a volume we pass shells on a volume. We will get from the mesher what we pass.

The problem is we get faces from the meshed faces and faces from the meshed volumes and we get edges from the meshed edges and from the meshed faces. We need to split them. It is what you did for splitting faced from volumes and what I did by splitting edges from faces ( haaaackalarm ...https://github.com/berndhahnebach/FreeC ... #L296-L322 ) The problem with your implementation is is is inside writeAbaqus, but we need it outside too to get around lots of problems with constraints and multiple materials, and multiple shell and beam section. Thus my proposal to move it outside writeAbaqus.

BTW have you seen my working example for beams and shells ... https://forum.freecadweb.org/viewtopic. ... 66#p175958