Meshfree discretization (e.g., Voronoi, or other method to generate a point cloud in a solid)

Coreform Cubit Version: 2022.4
Platform: Windows 10

Issue
This is not an issue but a general question for the research and development team at Coreform.

With meshfree technology (also called meshless, going by the names of RKPM, EFG, SPH, etc.) it is possible to perform simulations on a point cloud with no mesh needed. Surfaces are to be retained for traction (Neumann) type boundary conditions but can be represented/parameterized in a variety of ways that do or do not employ a mesh.

In any case, has Coreform considered adding a feature that leverages meshfree capabilities? For instance, Voronoi tessellation, sphere packing, Lizska’s GFD grid generation, etc., such that engineers can fully utilize the capabilities of these methods.

Meshfree capabilities are available in many codes now, for instance LS-DYNA, Sierra/SolidMechanics, and EPIC to name a few. All of the codes I’ve come across all use FEM meshers to generate the computational grid, but this is not necessary whatsoever for meshfree.

Hi @mhillman,

Welcome to the forum!

Coreform IGA (Isogeometric Analysis) is focused on a solution space that uses a CAD model directly as the solution space. No meshing required. This is somewhat of a different take on “meshfree” methods. The point cloud solution is not currently on our development schedule, but it is feasible to take as input an STL model containing the surfaces of the point cloud and use that as a starting point for the IGA analysis.

Take a look at Isogeometric Analysis is the next generation of FEA (coreform.com) for some examples. We are working on getting more case studies published soon.

Thanks,
Karl

In addition to what @karl said:

  1. Incidentally, in a former life I needed to create some Voronoi elements for an OpenFOAM simulation and accomplished this by writing my own Python module for extracting the dual of a tet-mesh (the dual mesh is the Voronoi tessellation of the nodes) and writing to OpenFOAM’s input format. So if you’re in dire need of something like this, that’s where I’d start.

  2. There is some functionality for meshing particles, such as for SPH or peridynamics. You can create a block and assign a sphere element type. The block needs to be assigned to vertices or nodes. From the Exodus documentation (see Table 4.1 in section 4.8.3 “Element Attributes”) the sphere element type does permit setting a uniform radius value for the block. Here’s an example:

reset
bri x 1
mesh vol 1
block 1 node in vol 1
block 1 element type sphere
block 1 attribute count 1
block 1 attribute index 1 0.05

In my former life I also came across the need for defining particles in a peridynamics simulation (in Sierra/SM) and just wrote a script that inserted vertices at hex and/or tet centroids, then utilized blocks to assign radii as needed.

1 Like

Hi @gvernon - there’s some issues with placing nodes at centroids of hexes for geometry representation and application of boundary conditions of course. We also need representative weights for the point cloud for say a Galerkin formulation. Passing the patch test requires that our nodal cells are conforming as well (any particle method, in fact all numerical methods need this).

The usual work-around for meshfree codes is to split the hexes into something like Voronoi diagrams, or generate Voronoi diagrams directly.

It seems a great path forward that would be convenient to those SPH and peridynamics users, and RKPM/EFG/etc. users alike would be to provide option to output the dual of the tet mesh. This would be a super super nice feature for the meshfree and particle community and a great contribution to the computational mechanics community as a whole to have it packaged in a preprocessor.

@karl I should have mentioned that there are many applications (e.g. extreme deformations, like blast and bullet penetration) where IGA and FEM will never replace the role of meshfree, so my inquiry could have been frame differently other than avoiding meshing.

Thanks,
Mike