How to Compile GridDyn: MSYS2

This post contains instructions for compiling GridDyn on a Windows OS computer using MSYS2 as the compiler. Topics covered include downloading the GridDyn source file, installing the SUNDIALS solver library, building GridDyn, and running an example on GridDyn.

The alternative to Visual Studio for compiling GridDyn on Windows is to use MSYS2. I do this on a regular basis to test different compilers and ensure that everything compiles correctly.

The MYSYS2 software is an independent rewrite of MSYS, based on Cygwin (POSIX compatibility layer) and MinGW-w64, with the goal of better interoperability with native Windows software. MSYS2 provides a Unix-like environment to build Windows applications. It uses Arch Linux’s pacman package manager. The SourceForge MSYS2 web page contains the installation instructions for both the 32-bit and 64-bit versions.

I use the 64-bit version and typically install it directly on the drive (in this case C:/msys64). Administrative privileges are not required to perform the installation.

Once pacman is installed, you should be able to open a command window from the installed start-menu shortcut.
The following is the first command:

$pacman -Syuu.

If you have a new version of the software, updates are not required; if not, there may be some updates required, in which case follow the on-screen instructions.

Compiler Tools
Next you need to install the tools that will be used to compile GridDyn. Type the following command:
$ pacman –S mingw64/mingw-w64-x86_64-gcc

There are several options for compilers. The latest version is gcc 6.2; any compiler that is version 4.9 or newer should work.

Other packages to install include the following:


Getting the GridDyn Repository
The last part of the following command can be whatever you want it to be; it is the directory from which to download the source file.
$git clone gridDyn-public

Installing SUNDIALS
Before you build GridDyn you will need to download SUNDIALS.

          1. Create a SUNDIALS directory and enter it using the following commands:
            $ mkdir sundials

            $ cd sundials
          2. Use the following command to download SUNDIALS:
            $ wget
          3. Extract the file.
            $tar xvfz sundials-2.6.2.tar.gz
          4. Create the following install and build directories and enter the build directory:
            $ mkdir sundials-2.6.2-build

            $ mkdir sundials-2.6.2-install
            $ cd sundials-2.6.2-build
          5. As in the previous blog post, this version of SUNDIALS has some problems finding KLU on a Windows system, be it for Visual Studio or for MSYS2. You will need to help it by using the following findKLU command from GridDyn.  The experimental branch of the public repo fixes some of this but more improvements are expected in the future.
            $ cp ~/gridDyn-public/config/FindKLU.cmake ../sundials-2.6.2/config/FindKLU.cmake
          6. Start up CMake.
            $cmake-gui ../sundials-2.6.2
            The following window is displayed.sshot1
          7. Select the “Configure” button. A dialog box is displayed (see the following screenshot). Scroll down the list of generators to “MSYS Makefiles”, then select the “Finish” button.sshot2
          8. After selecting “Finish”, some variables will show up; a few need to be changed. Deselect BUILD_SHARED_LIBS.
          9. Change the CMAKE_INSTALL_PREFIX to the created install directory.
          10. Set CMAKE_BUILD_TYPE to Release otherwise it may default to debug though you are free to set it to whatever you so choose (Release, Debug, RelWithDebInfo, MinSizeRel).
          11. Deselect EXAMPLES_ENABLE and EXAMPLES_INSTALL.
          12. Select KLU_ENABLE.
          13. Select OPENMP_ENABLE (optional). If everything worked properly and there were no errors, a “Configuring done” message is displayed.
          14. Select “Generate.”
          15. Close the window.
          16. In the command prompt, type $make, followed by $make install. This will copy the appropriate file to the Install directory.

Building GridDyn

        1. Enter the GridDyn Directory:$ cd ~/gridDyn-public
        2. Create a build directory by typing the following: $mkdir build, 
$ cd build, and 
$cmake-gui ...
        3. The following are recommended modifications to the CMake build.
          • Select LOAD_ARKODE and LOAD_CVODE.
          • Select OPENMP_ENABLE.
          • Specify the SUNDIALS_INSTALL_DIR to the install directory specified in the previous step.
          • Change CMAKE_BUILD_TYPE to Release.
        4. The final options screen for GridDyn (shown in the following screenshot) is displayed. Note: If any options are changed a final configure must be run.
        5. Select the “Generate” button.
        6. Exit the CMake GUI.
        7. At the command line type $ make -j 8. The -j 8 character specifies the number of jobs to run in parallel. Select some number appropriate for your computer.
        8. If an install directory was specified, type $ make install in the command line. To copy the files to the installation directory (for example gridDyn-public/bin), enter $ cd ../bin.


In the directory created by typing the following lines, the main executables are gridDynMain and test.

$ ./griddynMain ../examples/two_bus_example.xml -o res.txt
area count =0 buses=2 links= 1 gens= 1
(PRESTART)[sim]::GridDyn version 0.5.0 2016-08-20
Simulation gridDynSim_103 executed in 0.0099999 seconds
simulation final Power flow statesize= 4, 10 non zero elements in Jacobian

$ less res.txt
gridDynSim_103 basepower=100.000000
Simulation 2 buses 1 lines

This prints out a formatted file of the results of a simple two-bus case.


Congratulations! You have now compiled and run an Example on GridDyn.


How to Compile GridDyn: Visual Studio

This post contains instructions for compiling GridDyn on a Windows OS computer using Visual Studio as the compiler. Topics covered include Installing Visual Studio, CMake, and Boost C++ Libraries; building SuiteSparse; installing Sundials; and building GridDyn itself.

Welcome to the first informational post on the GridDyn Blog! This blog site will serve a variety of purposes:

— As a repository for examples of how to use GridDyn;
— Highlighting new features and functionalities;
— Providing troubleshooting tips and support; and
— Acting as a supplement to the available documentation.

Preliminary Set-Up

To kick things off, let’s begin with instructions for compiling on a Windows OS computer using Visual Studio as the compiler. (I’ll show you how to do this using MSYS2 in a subsequent post.)  As a note this process is continually evolving and will likely change (hopefully for the better) as time goes on.  

Before we begin, I am going to make some basic assumptions:

— You are familiar with installing software.
— You have administrator privileges to install the necessary software.
— You have some experience compiling software.

For starters, it is necessary to have the Git version control system (and a suitable Git client) installed on your PC. I personally use TortoiseGit.

Visual Studio Install

Next you’ll need to install Visual Studio on your PC if you do not have it already. The Community edition works fine since this is an open-source project, but if you already have other editions, they should work as well. Visual Studio 2015 or newer is required due to GridDyn’s use of C++11/14 features.

CMake Install

Next you will need CMake, an open-source, cross-platform family of tools designed to build, test, and package software, and to create project files. The installation is self-explanatory.

Boost C++ Libraries

GridDyn makes use of the Boost C++ libraries for many of the components and libraries. These are free C++ libraries available from SourceForge. You can use version 1.61. Not all features of GridDyn will work with versions older than 1.61; progressively fewer features will function as we go forward and more parts of GridDyn are updated and enhanced.

I typically extract the compressed archive to a folder on the root directory, such as C:\boost_1_62_0. Boost has its own build system that can use the Visual Studio compiler. For some additional instructions on building Boost, check out this post on Studio Freya: How to build Boost 1.62 with Visual Studio 2015. Only the 64-bit editions are needed for this application. I would advise using the default installation location instead of the one used on the website. The following screenshots show the build instructions.


The build process will probably take awhile.

SuiteSparse Build

Before building SUNDIALS and GridDyn, you must download and build SuiteSparse, another dependency of which you’ll principally use KLU, the sparse-matrix solver.  The GitHub repository contains the instructions for building SuiteSparse on Windows. It can be downloaded on whatever Git interface you’re running.  If you are using TortoiseGit, see the following screenshot.


Once SuiteSparse is downloaded, start CMake-gui from the start menu,  point it to the folder where the repository was created, and create a suitable build directory (I usually just create a build directory in the SuiteSparse folder). Click “Configure.”  A pop-up window similar to the following should appear.


Select the “Visual Studio 14 2015 Win64” option on the drop-down menu. You can choose the 32-bit version, but then Boost and all other dependencies would need to be built similarly.  Click “Finish.”  I typically deselect the “Shared Library” option since GridDyn doesn’t use that currently. Then click “Generate.” The configuration page should look similar to the following screen shot.


At this point in the process, you can open the project in Visual Studio and build the release version and debug version (if desired). Once that’s built you will need to build the INSTALL project as well, which can be done by right-clicking and selecting the “Build” option.


After SuiteSparse the next dependency is SUNDIALS, which can be downloaded from the LLNL SUNDIALS web page. SUNDIALS is a numerical solver library that is used in the default solvers in GridDyn.  The current version is 2.7.0.  However, GridDyn has not yet been tested with this version, so I recommend using the older version (2.6.2) for the time being. Build the directory structure shown in the following screen shot.


Next you’ll need to build SUNDIALS. This is a little more complicated process than the one used to build SuiteSparse. The Sundials build system has to know where to find SuiteSparse, but the build functionalities built into  Sundials to do this don’t always work well on Windows, they will work if you specify the folders directly.  I usually replace the findKLU.cmake file in the ${SUNDIALS_ROOT}/config directory with the equivalent one from GridDyn in the GridDyn/config directory. This requires that you have access to the GridDyn source code, which is available from GitHub at Look in the config directory, grab the findKLU.cmake file, and replace the similarly named file in the SUNDIALS source directory.

Next open CMake-gui again and point it to the SUNDIALS folder. I made several modifications to the default settings’ values, including the following:

— CMAKE_INSTALL_PREFIX should point to created install directory.
— Enable CXX.
— Select whether to enable the examples. If YES, point the install to the created examples directory.

After a first round of configuring, an option to specify KLU_DIR should be displayed. If everything works properly, you should be able to point this to the SuiteSparse install directory and run configure again.  The other locations should then be populated correctly and you should see a line like this:

Checking if KLU works… OK

If that line shows a failure, it may be necessary to manually fill in the KLU_INCLUDE_DIR and KLU_LIBRARY_DIR with the appropriate locations from the SuiteSparse installation.  The next figure shows a screenshot of the CMake Gui window when building the project files for SUNDIALS.  


At this point, SUNDIALS should configure and generate; once it has generated you can open the solution file and build it. I recommend that you switch to the release build instead of debug.  If the examples are built with CXX (a C++ source-code file type), it is likely an error will appear. In the file in question, it is necessary to change the string header #include<string.h> to #include<string>, then things should compile properly. This is a peculiarity of how Visual Studio manages string headers. I am pretty sure it was fixed in the newer version.

Building GridDyn

GridDyn also uses the CMake toolset. There are a number of options available when it is first configured. Refer to the GridDyn Users Guide for further explanation.

It will be necessary to replace the KLU_INSTALL_DIR location,  the SUNDIALS_INSTALL_DIR, and the BOOST_ROOT, which may only be available in the advanced options (an issue I am working on). If everything is specified correctly, it should configure (see the following screen shots).



If you are using Boost 1.62, you may see some warnings that the version is not recognized by CMake.  This will probably be fixed in newer versions of CMake; it doesn’t seem to impact operation.

Once it’s generated the solution file can be opened in Visual Studio and built (see the following Visual Studio screen shot).


If you set the testSystem as the startup process and press Ctrl-F5, it will run the test program in a command window and display something similar to the following.

Running 44 test cases...
completed power flow
case118.m completed in 0.001684
case1354pegase.m completed in 0.018043
case14.m completed in 0.000828
case2383wp.m completed in 0.044467
case24_ieee_rts.m completed in 0.001158
case2736sp.m completed in 0.042173
case2737sop.m completed in 0.063762
case2746wop.m completed in 0.054644
case2746wp.m completed in 0.056233
case2869pegase.m completed in 0.098323
case30.m completed in 0.001079
case300.m completed in 0.004637
case3012wp.m completed in 0.044684
case30Q.m completed in 0.001289
case30pwl.m completed in 0.001028
case3120sp.m completed in 0.057889
(-0.001000)[sim]::||WARNING||no SLK or PV bus found in network disconnecting buses case3375wp.m completed in 0.054416 (-0.001000)[sim]::||WARNING||no SLK or PV bus found in network disconnecting buses

case39.m completed in 0.001189 case4gs.m completed in 0.000819 case5.m completed in 0.000687 case57.m completed in 0.001386 case6ww.m completed in 0.000966 case89pegase.m completed in 0.003118 case9.m completed in 0.000718 case9241pegase.m completed in 0.311282 case9Q.m completed in 0.000919 case9target.m completed in 0.001002 case_ieee30.m completed in 0.000958 case118.m completed in 0.002274 case14.m completed in 0.000787 case24_ieee_rts.m completed in 0.001062 case30.m completed in 0.001215 case300.m completed in 0.004492 case30Q.m completed in 0.001094 case30pwl.m completed in 0.001029 case39.m completed in 0.001020 case4gs.m completed in 0.000914 case5.m completed in 0.000849 case57.m completed in 0.001210 case6ww.m completed in 0.001117 case89pegase.m completed in 0.002715 case9.m completed in 0.001169 case9Q.m completed in 0.001087 case_ieee30.m completed in 0.001054

exestring=C:/gridDyn/transmission/build/gridDynMain\Release\griddynMain.exe string C:/gridDyn/transmission/build/gridDynMain\Release\griddynMain.exe --version > C:\Users\top1\AppData\Local\Temp\exeText_2.out

after system call string C:/gridDyn/transmission/build/gridDynMain\Release\griddynMain.exe --version > C:\Users\top1\AppData\Local\Temp\exeText_2.out

out=GridDyn version 0.03 2014-07-10

string C:/gridDyn/transmission/build/gridDynMain\Release\griddynMain.exe C:\gridDyn\transmission\test\test_files/pFlow_tests/test_powerflow3m9b2.xml --powerflow-only --powerflow-output testout.cdf > C:\Users\top1\AppData\Local\Temp\exeText_2.out

after system call string C:/gridDyn/transmission/build/gridDynMain\Release\griddynMain.exe C:\gridDyn\transmission\test\test_files/pFlow_tests/test_powerflow3m9b2.xml --powerflow-only --powerflow-output testout.cdf > C:\Users\top1\AppData\Local\Temp\exeText_2.out

area count =0 busses=9 links= 9 gens= 3

Powerflow GridDynSimulation executed in 0.0020002 seconds with2 iterations Simulation GridDynSimulation executed in 0 seconds

(PRESTART)[sim]::Initializing Power flow to time -0.001000

(-0.001000)[sim]::Initializing Dynamics to time 0.000000 (1.000000)[4_to_14(8)]::Line fault at 0.250000 of line (1.000000)[sim]::state 7:BUS_4:voltage error= 307.565231 (1.000000)[4_14(1)]::condition 0 triggered terminal 1 (1.000000)[4_14(1)]::condition 1 triggered terminal 1 (1.000000)[14_4(4)]::condition 0 triggered terminal 2 (1.000000)[14_4(4)]::condition 1 triggered terminal 2 (1.002000)[4_to_14(8)]::Switch2 changed||state =OPEN, link status =DISCONNECTED (1.002000)[14_4(4)]::condition 0 action 0 taken terminal 2 (1.002000)[sim]::||ERROR||IDACalcIC failed with flag = -13 (1.002000)[sim]::||ERROR||IDACalcIC failed with flag = -13 (1.002000)[sim]::||ERROR||IDACalcIC failed with flag = -13 (1.002000)[sim]::increment voltage by 0.100000 (1.002000)[sim]::||ERROR||IDACalcIC failed with flag = -13 (1.079000)[sim]::Root detected (1.079000)[BUS_36::BUS_36_Gen_1::exciterIEEEtype1_275990(275990)]::root trigger above bounds (1.100000)[4_to_14(8)]::fault cleared (1.100000)[sim]::||ERROR||IDACalcIC failed with flag = -13 (1.100000)[sim]::||ERROR||IDACalcIC failed with flag = -13 (1.100000)[sim]::increment voltage by 0.100000 (1.100000)[sim]::increment voltage by 0.200000 (1.100000)[sim]::increment voltage by 0.300000 (1.100000)[sim]::increment voltage by 0.400000 (1.100000)[sim]::increment voltage by 0.500000 (1.100000)[sim]::increment voltage by 0.600000 (1.100000)[sim]::increment voltage by 0.700000 (1.100000)[sim]::increment voltage by 0.800000 (1.100000)[sim]::increment voltage by 0.900000 (1.100000)[sim]::increment voltage by 1.000000 (1.100000)[BUS_36::BUS_36_Gen_1::exciterIEEEtype1_275990(275990)]::root change V=0.916514 (10.000000)[sim]::collector successfully flushed to :dynfault.dat

*** No errors detected

Press any key to continue . . .

This build process is somewhat convoluted, but I am working on improving it; it will improve over time as more development takes place.   One thing I am exploring is the use of CMake external projects to script the entire build process for at least some of the build dependencies.

Fortunately, this is a process that is required only once per build method: after it is built the first time, the dependencies usually do not need to be built again, provided they do not change.

The next post will be about the build process using MSYS2 on Windows. In the coming weeks and months I will cover using GridDyn to perform a variety of simulations on the power grid.


The GridDyn Blog Site is up!

Welcome to The GridDyn Blog. 

GridDyn is a power-system simulator developed at Lawrence Livermore National Laboratory. It was created to meet a research need for exploring coupling between transmission, distribution, and communications system simulations. While good open-source tools existed on the distribution side, the open-source tools on the transmission side were limited in usability (in the language, platform or simulation capability) and commercial tools, while quite capable, simply did not allow the access to the internals required to conduct the research. Thus, the decision was made to design a platform that met the needs of the research project. Building off of prior efforts in grid simulation, GridDyn was designed to meet the current and future research needs of the various grid-related research and computational efforts. It is written in C++, making use of recent improvements in the C++ standards. It is intended to be cross-platform with regard to operating system and machine scale. The design goals were for the software to be easy to couple with other simulations, and be easy to modify and extend. It is very much still in development and as such, the interfaces and code are likely to change (in some cases significantly) as more testing is done. It is our expectation that the performance, reliability, capabilities, and flexibility will continue to improve as projects making use of the code continue and new ones develop. We expect there are still many issues so any bug reports or fixes are welcome. And hopefully even in its current state and as the software improves the broader power systems research community will find it useful.