MrHyDE Docker container

[dannys4]

As referenced in #1 , I've been trying to get MrHyDE working in a docker container (so that people who want to try it out don't have to fuss too much about getting all these random things installed just right, while littering in system paths, dealing with multiple installs of Trilinos, etc). This includes a new folder in the scripts directory which has a working Dockerfile as well as a README on how to use it.

NOTES:

• Admittedly, I link to an image I pushed onto Docker Hub under dgsharp/mrhyde:serial_dev (which is obviously under my name, not clearly associated under Sandia). If that's a problem please let me know. However, the only thing in that image is just some libraries that are all open source and nothing crazy.
• If you use the image to build MrHyDE, one of the tests fails. In particular, porous/Mixed_hybrid_highorder. I haven't checked why this happens, but I figure 120/121 regression tests passing is a good start.

Hopefully, with the public release of MrHyDE, this will make development and usage of MrHyDE from the public much more tractable (at least, it will for me). One simple further step would be to create an image that actually bundles MrHyDE prebuilt with the image. However, unless and until MrHyDE is a library, actually including it prebuilt in the image isn't particularly useful.

[GrahamBenHarper]

Hmm, I'd be careful about pushing images to Dockerhub and then referencing them in the repo itself. You're right, it's not directly associated under Sandia, but as soon as you reference it from the Sandia-owned repo, there's an implied closer connection. I think it would be better to remove the references to the binary from the repo, and just have a generic "if you docker pull a repository for MrHyDE, here's how you would proceed."

Additionally, the porous/Mixed_hybrid_highorder test is fine if it fails. I think it's one of a couple of problematic tests that sometimes pass or fail.

The only reason I bring up the warnings about linking the binary is I have this problem with MueLu because my understanding is I cannot push the MueLu docker container even though the Dockerfile repo itself has been reviewed.

[dannys4]

Understood, this is what I was worried about. Should I close this PR entirely and just open an informative issue instead? Or just remove the references to (and take down) the dockerhub image but leave the Dockerfile and README?

[GrahamBenHarper]

I think the PR is fine as long as you don't explicitly endorse a specific container from this main repo. The dockerfile clearly doesn't have any Sandia resources and uses all open codes, so anybody could conceivably put together that exact container. But take my words with a grain of salt because I'm not an expert point of reference for rules/policy, just somebody who vaguely understands the spirit of it.