Sparse GridFunction in MFEM

[eliasboegel]

Hi all,

As I alluded to during the MFEM tutorial today, I have a use-case that I am not quite sure how hard it is to adapt MFEM for. Let me also preface this with saying that I am at this point very unfamiliar with MFEM, but have read the paper and have gone through some examples.

I solve the Boltzmann equation, which has 1 to 3 velocity dimensions, 1 to 3 spatial dimensions and the time dimensions. For simplicity I'll assume no collisionality since it does not add anything to the context here and will use the 1D1V version of this equation as the example, together with the assumption of no acceleration being present, to really create a minimal example:
$$\frac{\partial f(x,v,t)}{\partial t} + v\frac{\partial f(x,v,t)}{\partial x} = 0$$

I discretize the velocity dimension(s) by expanding in velocity space with Hermite functions $\phi_i$:
$$f(x,v,t) = \sum_{i=0}^n c_i(x,t)\phi_i(v)$$

After some manipulation, we arrive at the following system:
$$\frac{\partial c_j(x,t)}{\partial t} + k_{j-1}\frac{\partial c_{j-1}(x,t) }{\partial x}+ k_{j+1}\frac{\partial c_{j+1}(x,t)}{\partial x} = 0$$

An essential part of the method is that the expansion order of the spectral discretization in velocity space is adaptive and can vary in physical space and time. That basically leaves me a standard advection equation of coefficients $c_j(x,t)$ with $j\in0, 1, ..., n$ where $n$ is integer and $n=n(x,t)$. I would like to discretize all remaining dimensions with MFEM. In computation of a term that involves " $j>n$ " so to speak, I want to use a "default value" of zero, equivalent to ignoring those Hermite terms. This, to me, looks like it requires something like GridFunction, but sparse. Instead of storing a huge amount of zeroes, I would like to store $n(x,t)$ to be able to keep track of the expansion order in space and time.

I already understood from the short conversation during the tutorial that there is currently no sparse GridFunction.

1. Is there any alternative to some form of sparse GridFunction that I may be able to use in this scenario?
2. What would you rate the effort and difficulty involved in implementing a sparse GridFunction?

[eliasboegel]

Hi @tzanio,
I would like to follow up on this - is there anyone that may be able to answer my question on this?

Thanks!

[tzanio]

Hi @eliasboegel,

Sorry for the delayed response.

I can't think of a simple approach to use existing MFEM classes instead of writing a new one. This is something we will like to do, but it is not on our short term plan. One of the difficulties is to come up with an interface that is both general, easy to use and performant 😁. If you want to work on it, we can schedule a telecon to brainstorm ideas.

Tzanio

[eliasboegel]

Hi @tzanio, is it possible to make something like the above work with within MFEM?

[jandrej]

If the problem on the element level is consistent you can "do whatever you want" on the quadrature point.

[eliasboegel]

If the problem on the element level is consistent you can "do whatever you want" on the quadrature point.

Hi Julian, thanks for the response. My question is more about whether MFEM's data structures support storing a different number of fields in each element. My current understanding of GridFunction is that I can only store a uniform number of fields across a domain unless I use submeshes. Is that correct?

[jandrej]

If you want inconsistencies on the element, yes that is correct.

[eliasboegel]

Could you elaborate briefly on "inconsistencies on the element"? I assume you mean variation of #fields within one element? I suspect that this would cause all kinds of problems. To get around that, I'm thinking of varying #fields only "between" elements, i.e. #fields is constant within any one element.