Links with FEA

[virtuamechanica]

I was wondering about possibilities of this Amazing library to transfer data for structural analysis (homogenization, etc) with FE solver such as Abaqus or Open-source Calculix,..).

[LinKayser]

The biggest challenge is the meshing. We are currently focusing on interacting with quasi-meshless sim packages, like Intact solutions, etc. The good thing about a Computational Engineering Model is that it knows the purpose of the geometry it is generating, so it is possible to automatically "tag" the meshes in the right way.

But meshing is a bit of a dark art, so "someone" has to translate the rules into code. But PicoGK can output triangle meshes, and from there, it should be possible.

We will explore this further from LEAP 71 as we go along, but, again, we are more focused on meshless right now, because our voxel fields feed right into that method (Lattice-Boltzmann etc.).

@josefinelissner put up a few examples in this repo, so check it out.

Hope this helps!
Lin

[josefinelissner]

Hi @virtuamechanica !
I just set up a discussion for that: #32
An feel free to check out this initial example (although for fluid simulation): https://github.com/leap71/PicoGK_SimulationExample

[virtuamechanica]

Thank you Josefine!

[virtuamechanica]

Hello,

always related to the topic of link with simulation:
Could it be possible for you to build a dedicated tutorial (or at least indicate the main steps to follow) for doing this task: hollowing a volume starting from a stress field.
For example, i have a femoral implant volume geometry, and i want to build lattices inside with variable density. Of course the density should be dicted by stresses tensor values taken from a given FEA.
Is it possible to import a brep geometry in order to hollow it (since picoGk philosophy seems to build and assemble primitives from scratch , using external fields, if my understanding is correct).

As a final stage, i would need to compute the result with FEA again.
The best would be to automatically optimize the lattices design (beams diameter, field density,..) from engineering requirements, but I am not sure that picoGk handle such cases.
Thank you!

[thsmit]

Hi @virtuamechanica

Looks like you are referring to topology optimization. For that to work inside of PicoGK there should be an FEM module in PicoGK which is at this moment not the case/strategy, as far as I know.

Best, Thijs

[LinKayser]

Hello,

always related to the topic of link with simulation: Could it be possible for you to build a dedicated tutorial (or at least indicate the main steps to follow) for doing this task: hollowing a volume starting from a stress field. For example, i have a femoral implant volume geometry, and i want to build lattices inside with variable density. Of course the density should be dicted by stresses tensor values taken from a given FEA. Is it possible to import a brep geometry in order to hollow it (since picoGk philosophy seems to build and assemble primitives from scratch , using external fields, if my understanding is correct).

As a final stage, i would need to compute the result with FEA again. The best would be to automatically optimize the lattices design (beams diameter, field density,..) from engineering requirements, but I am not sure that picoGk handle such cases. Thank you!

While we don't have time to do a dedicated tutorial, here are the general steps.

1. Check out the LatticeLibrary and decide on a latticing strategy. For example, you may simply want to modulate the wall thickness of the lattice, based on the supplied field.
2. Read the 3D field from your simulation — if you store it in a ScalarField, you can look up the simulation value at the relevant point in space.
3. Use the value you read from the position to modulate the wall thickness (or whatever strategy you decide on)

It's not trivial but also not specifically hard. For a Gyroid, or other implicit lattice, it would be fairly straightforward, something like this (modified from Ex_ImplicitExample.cs:

          public float fSignedDistance(in Vector3 vecPt)
          {
              // Calculate the normalized coordinates within the gyroid space
              double nx = vecPt.X / m_fUnitSize;
              double ny = vecPt.Y / m_fUnitSize;
              double nz = vecPt.Z / m_fUnitSize;

              // Calculate the gyroid surface equation
              double fDist
                  =  Math.Sin(m_fScale * nx) * Math.Cos(m_fScale * ny) +
                     Math.Sin(m_fScale * ny) * Math.Cos(m_fScale * nz) +
                     Math.Sin(m_fScale * nz) * Math.Cos(m_fScale * nx);

              // you need to implement this function below, which queries the 
             // simulation scalar field, and returns an appropriate wall thickness
              float fThickness = fGetWallThicknessAtPosition(vecPt);
              // Apply thickness to the gyroid surface
              return (float)(Math.Abs(fDist) - 0.5f * fThickness);
          }

You can check out Ex_TestFields.cs for info on how to deal with fields.

Hope this helps getting you started.

Best,
Lin

[virtuamechanica]

Thank you very much @LinKayser

[thsmit]

Dear @LinKayser,

I am planning to do some work to 'link' PicoGK geometries to FEA/CFD simulations.

The approach that Josefine described (https://github.com/leap71/PicoGK_SimulationExample) is to put geometries and boundary conditions together and export as a .vdb file. This .vdb file should then be imported in a simulation software for processing. The problem is that open-source simulation software don't import .vdb files. I could solve this by a piece of code to output to formats that are readable by open-source software. Do you have any thoughts on this (usefull? anything that I am overlooking for this to work smoothly)?

Best, Thijs

[leap71]

Yes, there's a number of ways you can go about it, for example creating mesh patches that describe inlets or boundaries, so your approach of looking into typical simulation formats and writing information there, is a good one. The data formats can be quite different than the geometric representation, so be prepared to spend quite a bit of time on this. The advantage of having a computational model generate the geometry is of course that the model "knows" what the geometry does (this is a fluid, this is an inlet, the material is X, the expected temperature is such and such). So all the information you usually have to feed in by hand is already there. But formatting it into a way that conventional simulation packages can process is still a bit of a task. Lattice Boltzmann type simulation packages are good fit for our discretized signed distance field representation.

Best,
Lin

[yvanblanchard]

Independently of final FE solver format conversion, I think it also a question about How to model the lattices structure. If we consider that RVE approach (micro to macro/meso structure) is the best one (instead of using Shell or beam mesh elements), we would have to implement a kind of data mapping technique for applying equivalent materials properties , between SDF data and an ´external’ structural mesh (ex: gyroid cell in picoGk at xyz = homogenized mechanical properties = HEX8 structural mesh element with centroid xyz, ..).
What do you think @LinKayser ?

[thsmit]

Thanks for your replies. Herewith a few thoughts and I am welcoming any comments/feedback.

Different approaches:

Traditional, starting with focus on solids, a traditional body fitted mesh with tetrahedrals and output to (for example) .inp to be read in CalculiX, Abaqus, etc. Challenge is that a very complicated and high resolution mesh is resulting if you want to mesh, for example, a Gyroid.

Simplified "mesh-less", starting with focus on solids, map the geometry to high-resolution Hexahedral mesh (high-resolution so no need for homogenization) and solve in a voxel-based solver or CalculiX, Abaqus, etc. This can be extended to solve for fluid domains as well using OpenFoam.

Lattice-Bolzmann, the most elegant, but for Lattice-Bolzmann to work on solids more research needs to be done, as far as I know. If we would do this for fluids, can you recommend an open-source Lattice-Bolzmann solver?