Generating random particles and compute weights

[ezrayst]

Generating random particles and compute weights

Summary

The change would involve but not limited to mesh and cell where a new type of particle generator "random" would be implemented. As the title suggests, it would create random particles within the element. After we are able to generate random particles, we will compute the weights separately, depending on where the particles within the cell are. Thus there will be two separate PRs for this: (1) to generate random particles, (2) to compute the gauss weights.

Motivation

Currently, the current MPM explicit formulation does not pass a patch test. This provides another alternative to accurately integrate so we have the correct computed stress for each particle. Hopefully this can pass the patch test

Design Detail

Design of the random generator:

• Make a new class called QuadrilateralRandomQuadratures
• Update assign_quadrilateral in cell to include generator_type with default string value of "gauss"

Rationale and Alternatives

• The weights would need to be computed at each time step, and could be computed using the same function within a class.
• Generate random quadratures in geometry but the design of the code would be rather messy
• Make a separate quadrature_random function within QuadrilateralQuadratures for this purpose, which is templatized.

[ezrayst]

@kks32 commented:

Quadratures are not a reasonable way to generate random points within a cell:

• When we integrate FE solvers, these random quadratures would be incorrect / invalid in those situations.
• The weights associated for each random point would mean we will have each cell with its own weights and set of points, which defeats the purpose of having a generic quadrature class.

I suggest not to continue to on this path to generate material points randomly, please open an RFC issue and we can flush out the details of the implementation before writing any further code.

[ezrayst]

I don't quite get why the random quadratures would be incorrect, given that we always compute the weights in each time step.

Yes, each cell will has its own weights in each time step, but I see them as using the same way of computation which could be stored in the generic quadrature class.

Of course we can create namespace within elements or geometry to do this. Would that be better? Or maybe you have better ideas on this. Thanks!

[kks32]

A quadrature in a FE is fixed, we do not recompute its weights or coordinates. On the other hand, generating RandomQuadrature defeats the purpose of having a centralized class, at each coordinate, we would have to compute its weight and coordinates, so doing RandomQuadrature<2, 9> doesn't always give the same quadrature, so saving this coordinates and weights would mean for each cell we are going to have a new quadrature object. The existing quadrature design is for a fixed number of Gauss points, hence generic enough to warrant a class and multiple classes point to the same object. Also, what happens when the number of particles in the cell changes? How would the weights be computed?

Namespace itself doesn't help the issue, because we need a fundamentally different design.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.