IsoGeometric Analysis testing in Moose

[roystgnr]

Reason

libMesh has had support added for IsoGeometric Analysis via custom-created or DynaIO-formatted meshes, but is now getting additional read support for new IGA extensions to the ExodusII format, the features of which make such meshes far more practical for users.

Design

Small example meshes and simulations employing them should be added to the Moose test suite, as demonstrations of capability, as tests for compatibility of various Moose features with IGA meshes, and as regression tests against any problems from future refactoring and upgrades of the IGA capabilities in libMesh.

Impact

The IGA extensions require a newer version of ExodusII to be enabled in libMesh, which requires HDF5 as a prerequisite, so to avoid foisting another compilation prerequisite on all Moose users we'll need TestHarness support for checking the libMesh ExodusII version and for skipping any tests which require a newer version.

Ideally no other changes will be needed, but part of the reason for adding IGA tests will be to uncover any Moose subsystems for which that isn't true. We can add new issues for any specific subsystem problems we uncover if/when we uncover some.

[roystgnr]

The IGA extensions require a newer version of ExodusII to be enabled in libMesh, which requires HDF5 as a prerequisite

And it turns out, (at least with current HDF5 versions? with libMesh's old NetCDF version?), the new ExodusII is using flock to request an exclusive lock when it opens a file ... which then fails, because Moose has already acquired a lock on the same file (in an attempt to prevent realtime viz programs from opening the file and then reading to the "end" before the end has been written, @permcody tells me).

I'm still trying to figure out what the right solution here is.

It would have been ideal to just turn off the flock call in the underlying (ExodusII->NetCDF->HDF5) library and let higher-level code continue to manage locking, but I can't see any way to set locking behavior at the NetCDF level, much less at the ExodusII level.

Cody suggests that we can just disable the higher-level locking in cases where we know the lower-level libraries are doing locking for us. I like this too (it appears to me that the libMesh Exodus objects will end up hanging on to a lock the whole time in between the first write attempt and an explicit close() or destructor, so we shouldn't have any race conditions), I'm just not sure how to accomplish the "we know" part. I had to dig through a dozen stack levels to find where the actual bug was occurring, and none of the higher-level or mid-level API docs seem to say anything about file locking, so I'm not sure where the behavior appeared and I can't see how we'll detect it if-and-when the locking behavior is removed in the future.

[roystgnr]

I can't see any way to set locking behavior at the NetCDF level, much less at the ExodusII level.

On the other hand, I do see a way to set locking behavior at the HDF5 level from arbitrary higher levels: with the environment variable $HDF5_USE_FILE_LOCKING set to FALSE my tests all start passing. Looks like this is tested by getenv at HDF5 subpackage initialization time ... and nothing gets initialized until our first ExodusII_IO_Helper::create() call, so we may be able to just putenv() right in there, in the cases where we detect that we're configured with HDF5.

What's astonishing is that this bug hadn't bit us before. I can reproduce it even with an old Exodus version, so long as I configure libMesh with HDF5 support.