roystgnr

Sweet. That'll give me a good reason to `s/Block/Subdomain/g` and `s/block/subdomain/g` in all our docs and API names while I'm at it (though I'd leave the old APIs around for...

> This is related to the question I asked on slack on the other day. It's also made the most paranoid part of my answer look prophetic, I'm afraid: >...

> I don't worry too much about the cost, as initialization (projection) is only done when a dof gets "activated" This is a good point. If you used `GenericProjector` here...

Thanks for reporting this! Looks like the problem here isn't the libMesh version, it's the nlopt version. They just removed that enum 2 weeks ago, in https://github.com/stevengj/nlopt/commit/f4e74eb164d4ef650a339ef3eb4b34df177ee6e5#diff-7447dda2c1e8a9fd889796fb62786af1ca90c46ddc0cde8818e7eabd757c4e0e We'll get a...

When I looked into it, it looked like it only was triggering in cases where NetCDF is configured to define `NC_HAS_SZIP_WRITE` as `1`, which I guessed was probably something autodetected...

I like the idea, but it looks like we're interfering here with higher-level error handling in MOOSE CI.

We could probably add a try/catch there to be able to add compatibility with this with a smooth transition?

I could be talked into a warning. Not literally `libmesh_warning()`, but something informative to `libMesh::out`.

We don't use AD in libMesh itself, but Moose uses MetaPhysicL for AD, which is an optional libMesh dependency (because we use it for constructing projection operators as sparse matrices...

IIRC there's a ton of AD libraries around these days. The big advantages you'd get with MetaPhysicL are that it's already in contrib/ and that we've got facilities that ease...