Strieded Element Restriction

[NamjaeChoi]

Hello,

I see that there are basically two ways of creating element restriction: the basic CeedElemRestrictionCreate and CeedElemRestrictionCreateStrided. If my understanding is correct, the former receives the offset for each node, and the latter only receives strides that can be applied globally. But we want to mix these two. We want to provide offset for each element, and use strides in each element, because we want to restrict a strided vector with some sparse element map. Is there a way to do this or can this functionality be added easily?

[jeremylt]

I don't understand the use case, can you say more?

With a standard restriction, the data for node i, component j, element k can be found in the L-vector at index offsets[i + k*elem_size] + j*comp_stride.

With a strided restriction, the data for node i, component j, element k in the E-vector is given by i*layout[0] + j*layout[1] + k*layout[2].

In practice, a strided restriction tends to only be for data that is regularly laid out discontinuously per node or quadrature point.

Are you looking for something where the data for node i, component j, element k can be found in the L-vector at index offsets[k] + i*node_stride + j*comp_stride? I'm not sure that would have much (or any?) of a performance benefit compared to a standard restriction?

[NamjaeChoi]

In MOOSE, each object can operate on a subset of elements, which we call block restriction. Re-computing quadrature values for every object is a waste, so we want to store quadrature values on a global vector and simply restrict it when computing each object.

[jeremylt]

I have no idea what to call it, but I could create a convenience function to take an array of element offsets and generate a standard restriction?

[NamjaeChoi]

Wouldn't that incur unnecessary memory usage? Basically we want to save memory by not providing trivially configurable offsets.

[jeremylt]

Generally, I recommend we try something that works and then tackle performance issues we observe when we see them

[jedbrown]

I think you'll find these indices are quite cheap compared to other quantities you're storing. I think what you're envisioning would complicate indexing when elements are interlaced, and thus may degrade vectorization and not "pay off". In any case, this is probably a 1% issue and could be investigated once you have a working approach.