Initial Windows Support

[HunterBelanger]

Description

This PR is an initial attempt to adding native Windows support to OpenMC. With these modifications, I have been able to compile vanilla OpenMC on Windows, using both MSVC (19.38) and the Intel compilers. I have made this a draft PR for the moment due to the following changes / restrictions.

• I found that the version of xtensor we are using in the submodules has a memory bug on Windows. For the time being, I have simply commented out loading the xtensor submodule directories, and currently get more recent versions with FetchContent. If we want to merge this, we will need update the submodule (or move to FetchContent ??) (see #2941).

• In general, I was able to get most of the Python API to work, with the exception of the cythonized bits like resonance reconstruction and fast ENDF floating point conversion. For now, I have simply disabled them on Windows. Otherwise, it seems to work just fine ? I was able to run the pin cell depletion example problem from Python.

• With Intel compilers, OpenMP parallelism works fine. With MSVC, an experimental flag needs to be added: /openmp:llvm. With this, MSVC builds it in parallel, and it seems to work. This experimental OMP support on Windows does not like the #pragma omp atomic write seq_cst we have in SharedArray, so I have added compilation guards to use a simple #pragma omp atomic write when using MSVC. In theory, this could open us up to a race condition here, but I haven't observed any problems with this yet (and in any case, using Intel avoid this problem).

• Many of the tests are failing on Windows. I have not been able to figure out why this is, however, as I can barely even get the tests to pass on my linux machine half the time. The results which I have obtained thus far seem to be in agreement with what I would expect. I am not sure to what extent some tests might be failing due to differences in Python dependencies on Windows ?

I am very open to suggestions on how to tackle the remaining problems ! I am definitely not a Windows developer, and have yet to find/understand good tools to properly examine this on Windows. For example, it will almost always crash in Debug mode because we apparently do some bad things with iterators in some spots. If you compile in Release mode, these do not pose a problem. Please feel free to test it out on a Windows machine and find all the bugs I have probably missed ! For now, I am not building HDF5 myself, but simply download and install the pre-built binaries from the HDF5 website.

Fixes #1243

Checklist

• [ ] I have performed a self-review of my own code
• [ ] I have run clang-format (version 15) on any C++ source files (if applicable)
• [ ] I have followed the style guidelines for Python source files (if applicable)
• [ ] I have made corresponding changes to the documentation (if applicable)
• [ ] I have added tests that prove my fix is effective or that my feature works (if applicable)

[gridley]

Nice! I always wondered why we couldn't do this. Pre-packing a binary for windows could be very nice for some users.

[paulromano]

@HunterBelanger Regarding the xtl/xtensor update, can you submit a separate PR just updating our submodules to the latest released version of each? That way we can consider separately (and later) whether we want to adopt FetchContent rather than lump it with the Windows-related changes here.

[HunterBelanger]

Yeah, I can make a separate PR to update the submodules and discuss FetchContent. For the time being though, I figure we probably want to keep the temporary work around that I have in this branch, just so it functions, and we can update this branch when we finally want to merge ? Otherwise, this won't work for anyone trying to test it.

[paulromano]

@HunterBelanger Yes, once the submodule update is merged separately, we can update this branch to remove the FetchContent changes (I can help with that if needed).