Modal / nodal tracking

[inducer]

Right now, it's possible to feed modal data to things that expect nodal data and vice versa. Everything is just a bunch of numbers in a DOFArray. Especially if @thomasgibson's entropy-stable work manages to stick, this will be a persistent source of user error. We should perhaps have the DOFArray remember the discretization_key for each group and check those on input to make sure they're as expected.

[alexfikl]

Would it work to introduce some subclassses NodalDOFArray and ModalDOFArray? Then each connection or whatnot can check if it got the right subclass. Some nice side effects

• the arithmetic in arraycontext checks other.__class__ is cls, so we wouldn't be able to do arithmetic on modal and nodal DOFArrays together by construction
• typing annotations?
• easy to inspect by printing the name vs going through the discretization keys.

[inducer]

I agree that using type annotations to check this statically would be appealing.

• The main difficulty I see with the approach you propose is that, technically, modal-vs-nodal is a per-group decision, and pretending otherwise is (IMO) going to lead to trouble. The first yuckiness I can foresee is having to check all element groups for modal-/nodal-ness... and then do you raise an error if it's not unanimous?
• Modal vs nodal is also not really the only DOF-changes-meaning problem we might have. Suppose we have two different element groups with identical node counts, but (say) different nodal locations. Right now, nothing prevents passing DOFArrays from one to the other, typically dropping to first order as a result. The `discretization-key tracking might stand a chance at catching these issues before they ruin someone's afternoon.

[alexfikl]

The main difficulty I see with the approach you propose is that, technically, modal-vs-nodal is a per-group decision, and pretending otherwise is (IMO) going to lead to trouble. The first yuckiness I can foresee is having to check all element groups for modal-/nodal-ness... and then do you raise an error if it's not unanimous?

What's the usecase for mixing modal and nodal values in the same DOFArray?

Also, if it's a per-group decision, what would passing a mixed DOFArray to a connection do? Would it only work on the groups it can or error out?

Suppose we have two different element groups with identical node counts, but (say) different nodal locations. Right now, nothing prevents passing DOFArrays from one to the other, typically dropping to first order as a result.

Oh yeah, that would be very cool to check somehow!

[inducer]

What's the usecase for mixing modal and nodal values in the same DOFArray?

There's no use case at all! :) I'm not arguing it's a good idea. I'm just saying that, right now, it's each group's decision to say what the DOFs mean. What I'm saying is that enforcing homogeneity in one specific characteristic (modal vs nodal) would require fairly awkward checking logic, and on top of that, it would fall short of quite a few other things that more general and less awkward logic could check. That's why I'm pushing for per-group/discr-key-based logic.

[alexfikl]

There's no use case at all! :) I'm not arguing it's a good idea. I'm just saying that, right now, it's each group's decision to say what the DOFs mean. What I'm saying is that enforcing homogeneity in one specific characteristic (modal vs nodal) would require fairly awkward checking logic, and on top of that, it would fall short of quite a few other things that more general and less awkward logic could check. That's why I'm pushing for per-group/discr-key-based logic.

Ah, got it now!

Would this be optional? What I'm thinking of is: e.g., pytential has that granularity stuff that doesn't correspond to the degrees of freedom of any existing group.

[inducer]

Would this be optional? What I'm thinking of is: e.g., pytential has that granularity stuff that doesn't correspond to the degrees of freedom of any existing group.

Oof, you're right. I mean, in principle it would be easy to make up some unique "discretization keys" for those cases, too. But given that concern, I think I agree that we would likely phase that in gradually, by deprecating the case where no discretization keys are supplied.