llnl/griddyn

GridDyn is an open-source power transmission simulation software package

GridDyn is a power system simulator developed at Lawrence Livermore National Laboratory. The name is a concatenation of Grid Dynamics, and as such usually pronounced as "Grid Dine". 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 either in the language or 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 simulation, and be easy to modify and extend. It is very much still in development and as such, the interfaces and code is likely to change, in some cases significantly as more experience and 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.

The public library is initial construction phases and likely will have some issues as we finalize the release and get it working over the next week or so

Documentation

Users Guide

** API Guide ** --coming soon

Also available are a series of presentations

• [Intro] (docs/presentations/Griddyn_intro.pptx)
• [Execution Flow] (docs/presentations/GridDyn_execution_flow.pptx)
• [Objects] (docs/presentations/GridDyn_objects.pptx)
• [Object Construction and properties] (docs/presentations/GridDyn_object_construction_and_properties.pptx)
• [States and offsets] (docs/presentations/stateData_solverModes_solverOffsets.pptx)
• [Validation and Performance] (docs/presentations/GridDyn_validation_and_performance.pptx)

Installation

Installation Guide.

Quick Start

quick start guide.

Get Involved!

GridDyn is an open source project. Questions, discussion, and contributions are welcome. Contributions can be anything from new packages to bugfixes, or even new core features. We are actively working on improving it and making it better, as well as development related to specific projects.

Contributions

We are still working out the details of accepting contributions For the moment you can submit a pull request. and we can work with you to make sure the licensing is order, which basically involves making sure your contributions are released back to the repo under a BSD license like the rest of the code.

Before you send a PR, your code should pass all the non-experimental test cases in testSystem, testLibrary, and testComponents

If the code is a new feature or new model, it should have additional test cases explicitly testing it

A style check is periodically run on the code to ensure consistent indentation and spacing. While some style guidence has been followed it is not rigorously enforced yet. A more formal style guide will likely evolve in the near future.

The current git master branch is considered expirimental so there is no stable branch to maintain as everything is in development. It is anticipated a more formal branching structure will be defined once the code base undergoes more testing and validation, and other features are added.

Authors

GridDyn was originally written by Philip Top, [email protected]. A number of other people have contributed, see the Users Guide for more details

Release

GridDyn is released under a BSD license. For more details see the LICENSE file.

LLNL-CODE-681053

griddyn's Issues

sundialsJac does not consistently check for null dstate_dt

In griddyn/solvers/sundialsInterface.cpp, sundialsJac is allowed to be passed a null dstate_dt. It acknowledges this here and here.

However,

GridDyn/src/griddyn/solvers/sundialsInterface.cpp

Line 462 in cf850ab

NVECTOR_DATA (sd->use_omp, dstate_dt), filterAd, cj, sd->mode);

and

GridDyn/src/griddyn/solvers/sundialsInterface.cpp

Line 471 in cf850ab

NVECTOR_DATA (sd->use_omp, dstate_dt), *a1, cj, sd->mode);

do not check for this, and can segfault. These should have the same nullptr check as above.

Calls to factory prepObjects leak memory

All of the calls to factory->prepObjects (here for example) result in memory leaks. I'm not sure why that happens.

Deleting these calls probably degrades performance across successive deconstructions and constructions, but it also fixes the leaks.

Check behavior of timestep when using GriddynRunner

See how the timestep parameter is used when running in a coupled simulation -- should be treated as the maximum time delta from the current time? vs telling GridDyn what time it should be at after returning from the step function.

failure in the valgrind run

There appears to be something wrong with the valgrind=true run for GridDyn
link on Travis.

kinsolInterface::initialize leaks if called multiple times

LS and J are leaked upon successive calls to kinsolInterface::initialize. Additionally, KINInit leaks if called more than once for a given solverMem.

KINInit should be only called when !flags[initialized_flag], and LS/J should be freed here (or in sundialsInterface::allocate, where that happens with the other variables sundialsInterface manages).

creating a GridDyn project group

I am starting to wonder if it might be a good idea to create project group for GridDyn, so we could have examples as a separate repo and some of the other libraries split out from GridDyn in a group? I am not sure if we would use that as the main on or this one as the main one and miror it?

@nightlark @mcneish1 What do you think?

GridDyn autobuild on Windows

Both AUTOBUILD_SuiteSparse and AUTOBUILD_KLU need to be given to GridDyn to make SuiteSparse get autobuilt (AUTOBUILD_SuiteSparse didn't show up in the list of options with the initial configuration on Windows). Is the behavior of needing to provide both of these options intended?

valgrind run

Can we add flags to the valgrind run?
Specifically I want to get line numbers for the allocation call. As far as I can tell that involves adding --track_origins to the valgrind call, as well as making sure we are compiling with the -g flag.

Possible issue with scaling published voltage in helics load using basevoltage

User wasn't able to get the voltage value published for a load in volts to change with the basevoltage parameter -- published value was still pu. Remind @nightlark to look into the issue.

variant.hpp fails to compile with MSVC 19.15

The variant.hpp file doesn't compile with MSVC 19.15; the issue for the bug on GitHub for the third party library is: mpark/variant#48
mpark/variant PR to disable constexpr in MSVC 2017: mpark/variant#49

And the compiler bug report on the Visual Studio developer community can be found at: https://developercommunity.visualstudio.com/content/problem/275141/c2131-expression-did-not-evaluate-to-a-constant-fo.html (upvoting will make it more likely to get fixed sooner)

CI build not showing up in PR's

Do we know why the CI results are not showing up in the PR anymore?

links/hvdc.cpp is not constructable

GridDyn/src/griddyn/links/hvdc.cpp

Line 38 in cf850ab

dcl->set ("type", "slk");

A dcLink can not be set to be a slack bus, so that statement throws unconditionally. This additionally leaks dcl.

This was added in 573966f, so I don't know what the expected behavior is.

Build Failing on Mac OS

Hi, I am trying to build GridDyn on Mac OS Catalina, and I am running into the following issue:

[ 79%] Linking CXX executable griddynMain
Undefined symbols for architecture x86_64:
  "_IDADense", referenced from:
      idaInterface::initialize(double) in libgridDyn.a(idaInterface.cpp.o)
  "_IDAKLU", referenced from:
      idaInterface::initialize(double) in libgridDyn.a(idaInterface.cpp.o)
  "_IDAKLUReInit", referenced from:
      idaInterface::sparseReInit(solverInterface::sparse_reinit_modes) in libgridDyn.a(idaInterface.cpp.o)
  "_IDASlsGetNumJacEvals", referenced from:
      idaInterface::get(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const in libgridDyn.a(idaInterface.cpp.o)
  "_IDASlsSetSparseJacFn", referenced from:
      idaInterface::initialize(double) in libgridDyn.a(idaInterface.cpp.o)
  "_KINDense", referenced from:
      kinsolInterface::initialize(double) in libgridDyn.a(kinsolInterface.cpp.o)
  "_KINKLU", referenced from:
      kinsolInterface::initialize(double) in libgridDyn.a(kinsolInterface.cpp.o)
  "_KINKLUReInit", referenced from:
      kinsolInterface::sparseReInit(solverInterface::sparse_reinit_modes) in libgridDyn.a(kinsolInterface.cpp.o)
  "_KINKLUSetOrdering", referenced from:
      kinsolInterface::initialize(double) in libgridDyn.a(kinsolInterface.cpp.o)
  "_KINSlsGetNumJacEvals", referenced from:
      kinsolInterface::logSolverStats(int, bool) const in libgridDyn.a(kinsolInterface.cpp.o)
      kinsolInterface::get(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const in libgridDyn.a(kinsolInterface.cpp.o)
  "_KINSlsSetSparseJacFn", referenced from:
      kinsolInterface::initialize(double) in libgridDyn.a(kinsolInterface.cpp.o)
  "_SlsSetToZero", referenced from:
      idaJacSparse(double, double, _generic_N_Vector*, _generic_N_Vector*, _generic_N_Vector*, _SlsMat*, void*, _generic_N_Vector*, _generic_N_Vector*, _generic_N_Vector*) in libgridDyn.a(idaInterface.cpp.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [gridDynMain/griddynMain] Error 1
make[1]: *** [gridDynMain/CMakeFiles/griddynMain.dir/all] Error 2
make: *** [all] Error 2

Check Sundials autobuild logic

Sundials seems to be getting rebuilt even though it is cached by Travis.

HELICS autobuild fails on Linux

I tried enabling autobuild for HELICS, and there were a number of errors. It would be good to go over the HELICS and ZMQ find/autobuild scripts to make sure that variable names getting set are correct; different configurations of autobuilding/finding can result in different variables being set.

issue with code coverage build

There appears to be some issue with the code coverage build on travis after the last merge.

CMake package config files

Export cmake package config files with targets.

Run tests on Travis/Appveyor

• Run quick tests for each check-in
• Run larger set of tests daily