My first design instinct here wouldn't have been "DofMap, and also SCDofMap that might be null", it would have been "DofMapBase, which might be a plain DofMap or might be a SCCapableDofMap". I'm not saying your way isn't better or asking you to change it, but I'm curious as to what you think the pros+cons are.

The StaticCondensation matrix, if being used, will be the system matrix that users add into. The dof indices that users use for adding into this are the global dofs, hence its conceptual reliance on the full DofMap. However, internally the StaticCondensation class will need to map global system matrix data to statically condensed matrix data for which it must rely on the statically condensed dof map (StaticCondensationDofMap).

Having the full system hold both full and condensed dof maps makes StaticCondensation class construction easy. Additionally, construction of sparsity patterns for the condensed matrices currently routes through the full dof map because it implements methods that the SparsityPattern::Build class calls like find_connected_dofs that the StaticCondensationDofMap doesn't currently have implementations for. But the SparsityPattern::Build does also query the StaticCondensationDofMap for things like dont_condense_vars. So this is another instance where we require both the DofMap and the StaticCondensationDofMap at the same time. I think sometime in the future StaticCondensationDofMap could be more full featured such that it can handle sparsity pattern construction for the statically condensed system all by itself, but I'm not there yet

That isn't a pro-con list. It's perhaps a "current necessity due to a degree of laziness" list? I have not yet made a serious attempt to see if I can make SparsityPattern::Build use only the statically condensed dof map. I think that one of the logical outcomes of such an attempt would be to change the current constructor in this PR

Build::Build (const DofMap & dof_map_in,
              const CouplingMatrix * dof_coupling_in,
              const std::set<GhostingFunctor *> & coupling_functors_in,
              const bool implicit_neighbor_dofs_in,
              const bool need_full_sparsity_pattern_in,
              const bool calculate_constrained_in,
              const StaticCondensationDofMap * const sc_in)

to

Build::Build (const DofMapBase & dof_map_in,
              const CouplingMatrix * dof_coupling_in,
              const std::set<GhostingFunctor *> & coupling_functors_in,
              const bool implicit_neighbor_dofs_in,
              const bool need_full_sparsity_pattern_in,
              const bool calculate_constrained_in)

which would in turn mean enhancing DofMapBase/StaticCondensationDofMap.

I can attempt a serious run at this if you would like me to

Oh, definitely don't attempt a serious run at this yet. I'm still just spitballing here. Trying to understand the design, not to criticize it.

Even in my idea, we'd still have two DofMapBase subclasses, it's just that one of them would own the other, to make the APIs cleaner. An Elem is-a DofObject, which at times has-a second DofObject accessible via old_dof_object(), which is non-nullptr in cases where we need to track both an old and a current numbering at once. The analogous thing to do here would be a DofMap which has-a StaticCondensationDofMap, non-null when we're doing static condensation; but perhaps the better solution in this case would be to have a StaticCondensationDofMap for the advanced cases, which then always has-a plain DofMap that doesn't itself know about static condensation.

Even that might not be an improvement. If you're 99% sure it wouldn't be an improvement, I'm fine with us not trying. If you're 90% sure it wouldn't be an improvement, I'd like to get something in the new code paths marked libmesh_experimental() but I'm still fine with us not trying yet.

So you're thinking that the DofMap, not the System, should own StaticCondensationDofMap?

This old idiom should still work, right? Could we leave it around, either in one example or in a unit test, to cover that?

What do you mean? get_static_condensation() now returns a DofMapBase instead of the SparseMatrix derived class. So the options are either (what is currently used in that example)

sc_sys.get_static_condensation_system_matrix().get_condensed_mat().m()

or

sc_sys.get_static_condensation().n_dofs()

Ugh. I misunderstood part of the API change here.

Is there anything we can do to preserve backwards compatibility here? Maybe make get_static_condensation() do what get_static_condensation_system_matrix() now does, and make get_static_condensation_map() the new API that returns the DofMapBase subclass? If we've got what's effectively a new API then we can give it a new name, and then we've still got the old name left over to try to preserve compatibility.

The old API made it into the 1.8.0 branch, and wasn't marked libmesh_experimental(), and I just don't like yanking users around. I like to be one of the people who ameliorates others' API consistency problems, despite the ugliness of #if VERSION > foo #elif VERSION > bar #etc code; I don't like to be the one of the ones creating the problems.