add compatibility flag required to build PyNE against [email protected]+

[bam241]

deprecation in hdf5 1.12 change the interfaces.
this allows to use the old interface with hdf5 1.12+ on which PyNE relies.
see pyne/pyne#1220 for more details

[bam241]

@gonuke this should fix the [email protected] but again I am unsure this is the right way to do this.

[gonuke]

Thanks @bam241 - this does seem like a bandaid, but we'll have to take it for now

[gonuke]

This passed tests, but there was a failure on merge
https://app.circleci.com/pipelines/github/svalinn/DAGMC/271/workflows/52e99c23-b970-4a48-a8ec-ee60ee2d51b1/jobs/1060
Any ideas @bam241

[bam241]

this is very strange, this is one of the 4/5 tests we actually run on PR....

I restarted the one that failed...

[bam241]

the second run worked.

I don't like that I feel like we are experiencing those more and more...
I am not sure how to debug this, if this is a bug...

[pshriwise]

It is! I've noticed this too, but haven't had time to look into it. Seeing this thread reminded me to have another look. I'm fairly certain that this has to do with a threadsafe vulnerability in MOAB. I'll make an issue in MOAB's repo and drop the link here for the explanation.

[pshriwise]

Ok here's the relevant MOAB issue: https://bitbucket.org/fathomteam/moab/issues/135/thread-safety-issue-in-typesequencemanager

I'm not totally sure why we don't see this problem in our MC applications -- we're able to get the same result with 1 as with N threads. My only guess there is that there's enough time between the calls due to other operations. The calls in the overlap_check program are also extremely coherent in terms of the location and ray direction, making it more likely that they'll touch the same data in MOAB and expose these kinds of issues.