Allow creating matrices based on hash tables

[lindsayad]

This is only supported by the PETSc backend

[roystgnr]

Those look like real failures - somehow in a bunch of use cases we're now trying to zero a matrix before it's initialized?

[lindsayad]

Yea, I'll get back to this particular PR soon

[moosebuild]

Job Coverage, step Generate coverage on b964294 wanted to post the following:

Coverage

	d6fe9d	#3983 b96429
	Total	Total	+/-	New
Rate	62.31%	62.31%	+0.00%	83.33%
Hits	72713	72728	+15	60
Misses	43991	43999	+8	12

Diff coverage report

Full coverage report

Warnings

• New new line coverage rate 83.33% is less than the suggested 90.0%

This comment will be updated on new commits.

[lindsayad]

this is ready for review

[roystgnr]

I take it there's no way via PETSc to get around the need for copy_from_hash()? I'd have thought the way to read hashed_matrix(i,j) would be to hash the pair (i,j) and read what you find (possibly after a close() in parallel), not to copy it into a CSR matrix or whatever and do all reads from that.

Other than that this is looking good now.

[lindsayad]

The thing is that there is no "hash table" matrix in PETSc. There is just a "hash table until you call MatAssemblyBegin/End and then you have your CSR" matrix. So the moment you call close on the "temporarily hash table" matrix you create your CSR matrix and your nonzero pattern is set. So this copy_from_hash is necessary to get intermediate snapshots of your matrix before its nonzero pattern has been completely filled. These intermediate snapshots are needed for things like kinematic contact. Maybe reading over this PETSc issue would give some more context

[lindsayad]

As the new example test is currently written, we will need https://gitlab.com/petsc/petsc/-/merge_requests/8063 to fix the failure. I'll probably just skip resetting the preallocation for the "non-hash-table" matrix in the mean time

[lindsayad]

I have no idea how this broke MetaPhysicL

[lindsayad]

Huzzah!

[roystgnr]

This looks ready to go to me, but it's a big enough changeset that I'd say let's let @jwpeterson also have a chance to agree or object before merging.