Windows support

[paulromano]

Now that OpenMC is solely C++ and Python, there's no fundamental reason why it shouldn't work on Windows. Supporting Windows would help encourage adoption in general. Some possible steps to help us get there:

• [ ] Try building/installing on Windows using Visual Studio
• [ ] Set up continuous integration to test on Windows (Azure Pipelines or AppVeyor)
• [ ] Distribute wheels on PyPI for Windows (see #1242)

[makeclean]

Building on Windows

1. Install Cmake for Windows
2. Install Git for Windows
3. Install Visual Studio15
4. Install HDF5 - now requires signup but there is native windows installer
5. open vstools native command prompt
6. cd to right place, for me I cloned in C:\Users\drand\openmc-test\openmc
7. mkdir bld
8. cmake -DCMAKE_INSTALL_PREFIX="C:\Users\drand\openmc-test\openmc" -Dopenmp=off C:\Users\drand\openmc-test\openmc note openmp I couldnt get to work right now
9. cmake --build . --config Release --target install *also doesnt quite work, errors from openmc::fatal_error and a bunch of complaints from the hdf5 interface, and about 748 other errors and some warnings.

Can I put the build log somewhere useful?

[paulromano]

@makeclean Absolutely, feel free to share the build log somewhere!

[pshriwise]

I was fussing around with this a bit today in Visual Studio '17 (couldn't get '19 to work at all).

I was able to successfully get hdf5 built and installed. Then got the following list of warnings/errors when attempting a build with OpenMC.

[makeclean]

I managed to get the number of errors down to about 115, which is two functions in the hdf5_interface. It seems like windows hdf5 doesn't like the hid_t datatype for some reason. Also the MS C++ compiler gives some weird errors, when the error is really upstream :(

[liangjg]

It seems one type of error that occurs many times and prevents MSVC from compiling openmc is due to the variable length array (VLA):

double evaluate_legendre(int n, const double data[], double x)
{
  double pnx[n + 1];
  ...
}

error C2131:  expression did not evaluate to a constant

• VLAs are only supported in C, and only from C99 on. They are not supported in C++.
• g++ supports VLAs as extensions to C90 and C++
• Visual Studio does not support VLAs at all in either C or C++. VS only supports up to the C89 standard To get around this, we can replace the VLAs with either dynamic arrays using new operator (must be deleted manually) or standard containers using std::vector. I guess the latter is more C++? But not sure if this will be less efficient than VLAs.

[paulromano]

@liangjg Ah-ha, good observation! Sounds like we ought to get rid of VLAs then since that is not standard C++. I'll create a separate issue for that.

[kingyue737]

I made some efforts to install openmc on Windows. I’m a newbie in c++, so the following speculation may not be correct.

Three options: 1、 compile with VC++:

• VC++ only supports OpenMP 2.0. Although I’ve built openmc successfully on windows, openmp is not available as @liangjg mentioned in #1249 .
• VC++ does not support C99. Cannot install OpenMC Python API because of C99 complex #1601 . To address this issue, replace C99 complex with C++ complex (like what @liangjg did to get rid of C99 VLAs) may be an idea.

2、 compile with GCC-MinGW:

• I failed to compile with mingw. Some dependent libraries like HDF5 on my Windows are compiled with VC++. Official site only provides pre-built binary distributions complied with VC++. To test this option, a mingw HDF5 should be installed.

3、 compile with Clang-cl:

• Clang-cl is compatible with VC++. I’ve built openmc successfully with Clang-cl and tested with a pwr assembly example. Although Clang-cl support OpenMP 4.5, CMake can not find OpenMP due to a bug (https://gitlab.kitware.com/cmake/cmake/-/issues/20999)
• Python doesn’t fully support compiling with clang-cl on Windows now (https://bugs.python.org/issue33351). It’s hard to install Python API with clang-cl at present.

[kingyue737]

I tried these three options in Visual Studio 2019 CMake Open Folder, using three different predefined configurations:

[lonnietc]

Hello All,

I have just downloaded OpenMc and want to try to compile it on Windows using Visual Studio 2019 or MinGW-x64 and was wondering if you had any luck since the last post was 2020, it seems.

Thanks

[paulromano]

I'm not aware of any recent efforts to directly compile on Windows. These days with WSL, most people opt to go that route for using OpenMC on Windows. If you do try compiling through Visual Studio, let us know how it goes!

[lonnietc]

@paulromano I was just experimenting with my MinGW-x64 and OpenMC.

Had to fix a few definitions but seemed to be able to get it to compile to create.

openmc.exe
libopenmc.dll

test_distribution.exe
test_file_utils.exe

The test_file_utils.exe yields:

$ ./test_file_utils.exe
Randomness seeded to: 4020036940

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test_file_utils.exe is a Catch2 v3.1.1 host application.
Run with -? for options

-------------------------------------------------------------------------------
Test get_file_extension
-------------------------------------------------------------------------------
D:/msys64/home/lonni/openmc/tests/cpp_unit_tests/test_file_utils.cpp:6
...............................................................................

D:/msys64/home/lonni/openmc/tests/cpp_unit_tests/test_file_utils.cpp:14: FAILED:
  REQUIRE( get_file_extension("lovely.dir/extensionless_file") == "" )
with expansion:
  "dir/extensionless_file" == ""

===============================================================================
test cases:  3 | 2 passed | 1 failed
assertions: 10 | 9 passed | 1 failed

The test_distribution.exe yields:

$ ./test_distribution.exe
Randomness seeded to: 690677050
===============================================================================
All tests passed (14 assertions in 2 test cases)

And, openmc.exe yields (without any input files)

$ ./openmc.exe
 ERROR: Could not find any XML input files! In order to run OpenMC, you first
        need a set of input files; at a minimum, this includes settings.xml,
        geometry.xml, and materials.xml or a single model XML file. Please
        consult the user's guide at https://docs.openmc.org for further
        information.

I'm just now still very new to openmc as I want to try to compare it against MCNP6 for photon transports (i.e. Co60 irradiator that I want to model with OpenMC) to see how close they are in the simulations.

Is there some simple example that I can get to test an basic input xml file for the openmc.exe binary?

Also, does openmc need additional supporting datafiles for nuclear data?

Thanks and have a good day.

[lonnietc]

@paulromano Just an update on things.

I just went and tried to use pip for the python portion of the openmc build with "pip install ." from the openmc root directory but that yielded a huge amount of errors and did not work out well, so far.

Will continue to work on it as well but right now, it seems that I only have the ability to use the C++ build part of OpenMC and need to read more in the docs to see how to proceed next and do more testing.

Cheers

[HunterBelanger]

I want to use OpenMC in the nuclear courses I will be teaching and have therefore spent a while trying to get it to compile natively on Windows. I now have a branch where I am able to compile the executable with both the MSVC and Intell compilers on Windows, with OpenMP support. In both cases, I am using the downloaded HDF5 binaries from their website. I have not yet started to look at making the Python API work.

When compiling with MSVC, the compiler does not like the seq_cst qualifier added to the omp pragmas in the SharedArray class. For now, when compiling on Windows, I have simply removed the seq_cst option. If my understanding is correct, this is only there for performance ? I am wondering how essential this is, and if it could be replaced by a flush ?

[paulromano]

@jtramm can probably comment more about seq_cst as I believe he added that in. In any event, it's easy enough to have an #ifdef that does something different on Windows. Sad to hear that OpenMP support still lags on Windows, but I'm not surprised.

[jtramm]

The seq_cst uses a stricter memory model that makes that operation sequentially consistent (i.e., that the operation happens in the place that you say it will in the code). I think the first one at least is required:

 int64_t thread_safe_append(const T& value)
  {
    // Atomically capture the index we want to write to
    int64_t idx;
    #pragma omp atomic capture seq_cst
    idx = size_++;

    // Check that we haven't written off the end of the array
    if (idx >= capacity_) {
      #pragma omp atomic write seq_cst
      size_ = capacity_;
      return -1;
    }

    // Copy element value to the array
    data_[idx] = value;

    return idx;
  }

The hypothetical problem is that, without it, the compiler might be optimizing for register pressure and decide that it doesn't want to actually have an idx variable. As such, it converts things to be basically:

 int64_t thread_safe_append(const T& value)
  {
    // Atomically capture the index we want to write to
    int64_t idx;
    #pragma omp atomic capture
    idx = size_++;

    // Check that we haven't written off the end of the array
    if (idx >= capacity_) {
      #pragma omp atomic write
      size_ = capacity_;
      return -1;
    }

    // Copy element value to the array
    data_[size_ - 1] = value; // Bad, as some other thread may also have incremented size_ in the interim!

    return idx;
  }

This would be valid by the C++ standard I think, as C++ programs give the compiler a lot of freedom in moving things around provided the same serial logic is preserved. The compilers generally don't account for what happens if another thread were to alter a variable at some point during the execution of a function, so it can replace a stack variable with several memory reads as it assumes memory is not changing in the background (which is not a good assumption with shared memory threading). Thus, the seq_cst qualifier forces the operations to happen as specified in the C++ source and removes some freedoms the compiler has. The Boehm paper has more info: https://www.usenix.org/legacy/event/hotpar11/tech/final_files/Boehm.pdf

Generally though, I'm not sure that I could actually find a use case where removing that qualifier could be demonstrated to break things, as it is going to be highly implementation dependent. It's also possible that use of the atomic qualifier maybe forces certain behavior in this case that means it will be ok for this usage, hard to say for sure.