wperkins / gridpack Goto Github PK

Provide a native port of GridPACK on M$ Windoze. This is a catch all issue.

Using the PETSc MATSHELL. The new type would require the following capabilities: conversion from and to stock PETSc dense types; matrix/matrix multiply; matrix/vector multiply

With real-valued PETSc, @bjpalmer has found that complex matrix transpose may be incorrect. Develop a non-trivial unit test with complex values to see if this is the case.

Templatize the current nonlinear solver class tree and make it like the linear solver class tree

The use of variable length C arrays is pervasive in the GridPACK code. This is a GNU extension to the C++ standard and Microsoft compilers simply do not support it. It hides a memory allocation that may the programmer (especially a Fortran programmer) may not think is there. Variable length arrays should be replaced with std::vector<> instances.

The matrix interface should include two methods to solve a system. In repeated solves with exactly the same coefficient matrix, some PETSc steps can be skipped. I propose to have the current method

void LinearSolver<>::solve(const VectorType& b, VectorType& x) const

act as it does now. In repeated solves, this method would be used if the coefficient matrix changes between solves. A second method

void LinearSolver<>::resolve(const VectorType& b, VectorType& x) const

would be used repeatedly after a single call to solve() to solve the system in when the coefficient matrix does not change (even values) between solves.

Shri (@abhyshr) found this.

Be able to run the optimizer in a parallel enviroment. This would involve at least

1. Collect variables, constraints, and objective to all processes.
2. Figure out how to deal with variables that are shared between processors.
3. Create a problem and run the (serial) optimizer on all processes.
4. Put optimized variable values back into (local) variables.

Templatize matrices just like vectors. Allow complex matrices, including (limited, perhaps) operations. The main goal would be the ability to solve a complex linear system on top of a real-valued PETSc library.

Implement sparse and dense matrices that matches the Vector implementation.

Constraints are assumed have an (linear) expression on the LHS and a constant on the RHS. A global constraint is one where all or some processes contribute to the expression on the LHS. It's assumed that individual processor contributions are simply summed to create the global constraint.
Global constraints have a name. A global constraint must be defined consistently on all processes (or perhaps only contributing processes) with an empty LHS, e.g.:

ExpressionPtr empty;
ConstraintPtr c(empty < 45);
optimizer.createGlobalConstraint("global", c);

or zero LHS, e.g.:

ExpressionPtr zero(new RealConstant(0.0));
ConstraintPtr c(zero < 45);
optimizer.createGlobalConstraint("global", c);

(using zero will cause problems w/ CPLEX and GLPK).
Individual processes would then contribute to the LHS of the constraint with calls like this:

optimizer.addToGlobalConstraint("global",  -2*v0 +14*v8)
optimizer.addToGlobalConstraint("global",  v4-19)

The expressions specified are added to the LHS of the expression, and all process LHS contributions are eventually added together before the constraint is submitted to the optimization software.

There are apparently problems with building GridPACK on top of PETSc 3.6. This is typical. The PETSc API gets changed at the drop of a hat.

The matrix unit test storage fails when matrix norms are computed with PETScMatrixImplementation<>:p_applyAccumulator(). The routine is only used when complex matrices are implemented on a real PETSc. The unit test builds a matrix with the storage scheme being tested (sparse/dense) then converts it to the other storage scheme (dense/sparse) . A segmentation violation is thrown when the serial complex dense matrix is converted to sparse (admittedly a bad move) and norms are computed for both. The exception is thrown when the sparse matrix is destroyed. The work around is to use fallback::norm2(). It may be appropriate to just drop p_applyAccumulator() since p_norm() is the only place it's used.

Probably using Epetra. It would be nice to use Tpetra, but templated solver interfaces appear immature.

Shri (@abhyshr) wants this. Allow the user to specify a function/functor (via boost::function) that is executed after each time step is computed.

This is a result of a recent overhaul of the powerflow components. A segmentation fault happens when the network is in "State" mode (the mode I added for powerflow2).

The current GridPACK optimization interface allows the specification of constraints and objectives in a natural way within C++ code. The COIN-OR provides the FlopC++ provides a similar, and more mature, facility. FlopC++ is described as

An open source algebraic modelling language implemented as a C++ class library.

Furthermore, the model produced by FlopC++ can be used to run optimization software directly through the COIN-OR Osi generic linear programming interface. Osi appears to support the solvers we would like to use (CPLEX, Gurobi, GLPK).

Of course, there are several issues that would need to be worked out:

• serialization and communication of FlopC++ classes
• support for mixed integer and quadratic programming
• adapting for parallel optimization software

During configuration, the underlying type used to build the PETSc library is identified. Some checks are performed to make sure it is a supported type: complex (--with-scalar-type=complex) or real (--with-scalar-type=real). Configuration should also verify that the underlying PETSc type should be double precision (--with-precision=double). An error occurs if any condition is not met.

The libraries upon which GridPACK depends need to be built on Windoze with some consistent platform set up. The sandbox code should be added to and utilized for verification of builds. Try to stay away from the full GridPACK repository until this is done.

Probably in this order:

• Boost
• PETSc, with
  • SuperLU
  • Suitesparse,
  • CBLAS
• Parmetis
• Global Arrays
• GLPK or link to installed CPLEX

Platforms to consider

• Native Windows 7 and 10
  • MS-MPI (really the only MPI implementation available)
  • MS Visual C++ Express (2010 or 2015) compiler
  • Intel C++ and Fortran
• Cygwin
  • GNU 5.x C++ and Fortran
  • OpenMPI
• Mingw
  • cross compiled in Cygwin or Linux?

This is a much discussed issue for Doxygen. When Boost smart pointers are used, they are ignored in Doxygen collaboration diagrams.

Provide LinearSolver<RealType> and LinearSolver<ComplexType> classes that use the corresponding Vector<> and Matrix<> classes.

Certain linear problems are solved quickly only with serial methods, even when the matrix and RHS are assembled in parallel. Add a facility to perform linear solves by reducing the coefficient matrix and RHS to a single processor, solving the system on a single processor, and redistributing the solution.

The GLPK linear and mixed integer programming algorithms. This may be insufficient for most electrical network optimization problems, but it is useful for testing.

The most difficult part of a port to Windoze (#30) is getting Global Arrays to build. It would be nice to be able to build part of GridPACK without Global Arrays for testing. Nearly all of the math code can be built without GA. This task would make GA optional in the CMake configuration and try to build as much as possible without GA.

This is a catch-all task for activities related to the trilinos math implementation. The main sub tasks are

• Vector implementation (#26)
• Matrix implementation (#28)
• Linear Solver Implementation ()
• Nonlinear Solver Implementation ()
• ODE/DAE Solver implementation ()