search

inducer / grudge

Grand Unified Discontinuous Galerkin Environment? A DG code in training.
14 stars 17 forks source link

"project" is the wrong name for getting onto the quad grid #38

Open inducer opened 3 years ago

inducer commented 3 years ago

@MTCam pointed this out.

cc @lukeolson

inducer commented 3 years ago

In view of https://github.com/illinois-ceesd/mirgecom/pull/305, I got reminded of this issue. project is still occasionally inaccurate, just like interp was. The main example that comes to mind is interpolating from the nodal grid onto a quadrature-based evaluation grid. Maybe @thomasgibson can think through the operators required for entropy-stable and see if there are any other cases for which it would also be a misnomer.

I am wondering what, if anything, we should do about it. Or we could simply pronounce project to be accurate enough as terminology goes... as the coefficient finding is essentially always equivalent to projection. I'd welcome any thoughts here.

cc @thomasgibson @alexfikl

MTCam commented 3 years ago

This may be a pedestrian suggestion, but ...

What about just rolling a higher level interface to do transfer or transport and document that it interpolates when it can and projects when it needs to, etc?

inducer commented 3 years ago

@MTCam Thanks for the suggestion! I rather like the idea, and I think transfer is not a bad verb for this. (Math has so many of them for similar concepts: "restrict", "zero-extend", "project", "interpolate"... no way we're replicating that vocabulary, IMO.) I'll wait for @thomasgibson to chip in to see whether there's anything in entropy-stable that would make transfer seem like a bad word. One thing that would perhaps represent a problem if there is a choice of multiple valid ways of going between discretizations, with the user having to voice a preference.

Possibly related: while it's natural for transfer to lose information (e.g. for boundary restriction), should it also be allowed to silently lose accuracy? Or should we try to prevent that somehow?

thomasgibson commented 3 years ago

How about we support both interp and projection? Grudge already has a class hierarchy for doing this (it distinguishes between projection and interpolation operators). I think it makes perfect sense to have both, at least from a mathematical perspective.

This means, however, we will need to distinguish when to use one or the other. For moving back and forth between, say, quadrature grids (think over integration), this is clearly an interpolation because you're sampling your basis at a new set of nodes. This is also something that will be done for doing entropy stable DG (moving from polynomial representation to quadrature representation).

In other cases, say you're moving some arbitrary function into the polynomial space, this is, in general, a projection (involving the minimization of a residual via inverting a mass matrix system).

So what will likely need to be done is that we will need to do some error handling for project and interp functions. That is, if you're trying to perform interpolation and you call project, you raise an error and prompt the user to use interp instead, and vice versa.

Thoughts on this approach?

inducer commented 3 years ago

I think I'm coming around to that view. Quite possibly, what should happen is that DiscretizationWithBoundaries.connection_from_dds should be split into projection_from_dds and interpolation_from_dds.

I can see two questions:

thomasgibson commented 3 years ago
  • What would we do with operations that are equivalently interpolations and projections (e.g. restriction to the boundary). Would it be legal to obtain them both ways?

If there is a straightforward way to formalize this in the code, then I personally think allowing project and interp to work for both cases to be fine.

  • Should meshmode connections label themselves as projections or interpolations, to avoid confusion?

Personally, I think yes. Some connections are definitely projections (e.g. L2ProjectionInverseDiscretizationConnection) while several others can definitely be described as interpolations (e.g. certain applications of DirectDiscretizationConnection, ModalToNodalDiscretizationConnection? etc)

inducer commented 3 years ago

I agree with those points. Let's proceed with separate interp and project then and add metadata to meshmode as necessary.