cross_rank_trace_pairs implicitly projects from the volume

[inducer]

That makes it impossible to communicate quantities that are already on the boundary. No good reason for that restriction.

cc @matthiasdiener @majosm @MTCam @thomasgibson

[MTCam]

I guess we should take care about changing this behavior on which MIRGECom depends (more-or-less). Less now since we almost exclusively use interior_trace_pairs to get data on the partition boundaries. I might argue for leaving the current behavior alone and adding a separate facility for communicating data that is already on the boundary, as that seems like a less-needed functionality (i.e. from the MIRGECom perspective).

[inducer]

I might argue for leaving the current behavior alone and adding a separate facility for communicating data that is already on the boundary, as that seems like a less-needed functionality (i.e. from the MIRGECom perspective).

I completely agree. I wasn't suggesting we break backward compatibility, and I wasn't sure of a use case. It just seemed odd that things were being done that way.