QTAG_XXX is misnamed

[inducer]

With the introduction of QTAG_MODAL in #77, it's apparent that the QTAG_ prefixes (for "quadrature tag") are misnamed. "Modal" just isn't a form of quadrature, unless you twist your head in a very special way. "Discretization tag" would make sense, but the DTAG_ is taken ("domain tag"). DISCR_TAG_XXX?

cc @thomasgibson @majosm @alexfikl

[majosm]

Would something like STAG_ (“space tag”) make sense?

[thomasgibson]

DISCR_TAG_ is growing on me.

[alexfikl]

I always assumed that QTAG_NONE was supposed to be the only one of its kind, as other quadrature tags get named by the user, so definitely agree that it's weird.

I'm also on board with DISCR_TAG_QUAD and DISCR_TAG_MODAL (if I understood @thomasgibson correctly?).

[thomasgibson]

What about DISCR_TAG_BASE (for basic discretizations, with explicitly defined bases; not quadrature grids) and DISCR_TAG_MODAL for modal discretizations? Right now, quadrature discretizations are basically treated as "anything other than those", as shown here.

@alexfikl Do we want to take this opportunity to drop in a special DISCR_TAG_QUAD specifically for quadrature discretizations? At the moment, Mirgecom uses strings to denote the quadrature grid (like "quad"), but it's not widely used at the moment, so we have a window of opportunity before breaking tons of compatibility. @majosm What do you think?

[alexfikl]

What about DISCR_TAG_BASE (for basic discretizations, with explicitly defined bases; not quadrature grids) and DISCR_TAG_MODAL for modal discretizations? Right now, quadrature discretizations are basically treated as "anything other than those", as shown here.

Yeah, that sounds good!

Do we want to take this opportunity to drop in a special DISCR_TAG_QUAD specifically for quadrature discretizations?

How would that work if there are multiple quadrature discretizations? I'm mostly thinking of surface PDEs here, where there are all sorts of nasty nonlinear terms that you could treat differently.

[thomasgibson]

How would that work if there are multiple quadrature discretizations? I'm mostly thinking of surface PDEs here, where there are all sorts of nasty nonlinear terms that you could treat differently.

That's a good question. I guess that's why str are acceptable input (for basically letting the user decide what to do with it). Alternatively, we could make DISCR_TAG_QUAD take additional parameters (for example, a domain_tag?) Sort of like how DTAG_BOUNDARY can take a tag to help specialize for specific types of boundaries.

[alexfikl]

That's a good question. I guess that's why str are acceptable input (for basically letting the user decide what to do with it). Alternatively, we could make DISCR_TAG_QUAD take additional parameters (for example, a domain_tag?) Sort of like how DTAG_BOUNDARY can take a tag to help specialize for specific types of boundaries.

Or just let the user inherit from DISCR_TAG_QUAD for problem specific stuff? That doesn't sound too bad.

[inducer]

I don't know how realistic it is, but the intent of user-defined quadrature tags was to define multiple "levels" of overintegration. I don't know if anyone would really want that, but it seemed easy to do. Maybe that's worth keeping. I like the proposal of making user-defined tags by inheriting rather than by strings.

[inducer]

I also think DISCR_TAG_xxx is OK.