Store the mesh connectivity information for mesh based solvers about mui HOT 7 CLOSED

It's a good idea and one worth exploring, I guess the fixed position optimisation will deal with some overhead in terms of transferring the points each time, that's already there but the question is whether storing connectivity in the MUI interface is the best approach or if it should remain generic as a point cloud with the connectivity information remaining local to each solver. The big question is how far do you go in terms of storing mesh information, do you start to rely on proprietary formats, at which point are you introducing a dependancy for the library?

from mui.

Probably "mesh connectivity" is misleading. The main thing that seems useful to me is to store which points comprise the interpolation stencil rather than compute it each time (through the binning, etc.). It is a slow process to find which points within a cloud are "close" to a given point in 3D space, and for fixed meshed based simulations, this high-cost search should really only be done once.

from mui.

I did think that the next logical development of the fixed point solution was to stop the recreation of the bin structure, this is probably the next logical step for that, allow bin recreation for moving mesh problems but store the local region search, I guess the trade off is higher memory use for longer periods.

from mui.

True, there is a trade-off between memory use and CPU. But for most practical problems, recalculating the same expensive operation multiple times because it would take up some memory to store its result is a bad design choice.

from mui.

I suppose the more relevant question is how easy this issue is to address? Any feeling for this @SLongshaw ?

from mui.

Not at the moment, this should be linked to the "static points" mode of operation, it makes little sense otherwise as we can't assume a previous bin structure remains valid between frames.

Logically what needs to happen is that, rather than the created bin being destroyed (which happens for a timeframe when a "forget" command is issued), the bin object should be propagated forward after it is created for the first timeframe.

The bin object could then be extended to allow a record of the point associations, consuming more memory of course. The issue is that this is specific to the use of a certain spatial sampler, so if the associations are created for an exact sampler and then the same bin structure is queried using a Gaussian, the associations are no longer valid, so it will be necessary to make it so that each recorded set of connectivity (or associations) is specific to a sampler type in order to make the implementation general.

The first issue of storing and propagating the bin should be relatively trivial, the second issue is a larger development.

from mui.

Going to close this one as recent design decisions have really pointed to the fact that this is something MUI should avoid doing natively (that isn't to say the framework couldn't be used to push such connectivity information between solvers, just that it shouldn't be handled natively by extending the fundamental point cloud approach).

from mui.