PCMSolver v2.Y.Z wishlist

[robertodr]

I am opening this meta-issue to discuss how the API for the next version should look and what additional features we want the library to have. I had opened a project, but the Kanban-style board is not very good for discussion. And we need a discussion before breaking this one up into issues and action items.

• Add new items in comments.
• Already existing issues can be taken up by anyone, and pull requets should be directed towards the master branch.

Infrastructure

• Move to CMake 3.3 (or even later). Switch to CMake 3.5 #59
• Drop C++03 in favor of C++11. Drop C++03 compliance in favor of C++11 #57
• Rewrite the timer class using C++11. Timers using C++11 standard library #43 Not so sure if this is any help. Profiling should give a more accurate picture of where time is spent and we have good enough documentation on how to do that now.
• Decide what to do with the logger. Overhaul (or throw away) Logger class #44

API

The context API idea has worked great for us, but what we offer is not as flexible as it could be. From the point of view of the host, the API is mostly pure and we should strive towards greater purity.

• Drop the requirement for the host to use our own input parser. Input should be parsed by the host and passed down in a well-defined data structure. The advantage of this approach is that the data structure can be clearly versioned and deprecated within the code itself. To run the standalone executable we would need a parser and this can be whatever, as long as the final result of input reading and parsing is the same exact data structure expected by the API initialization function.
  The v2 initialization function would then look:
  PCMSolver_API pcmsolver_context_t * pcmsolver_new(struct PCMSolverInput * input);
  Issues might arise with Fortran interoperability, since we would be shoving at least one function pointer in a user-defined type.
• More flexible surface functions. We currently assume that our surface functions are vectors of the size of the cavity. This was found to be troublesome to get the ddCOSMO terms out to the host, since they are defined as a matrix. However, once the library has been initialized the dimensions of the PCM matrix (whatever that might be) and the dimensions of the MEP and ASC vectors (whatever those may be) are known and they won't change within a calculation. So we could add the following concoction to our interface (I don't know if this is legal C!):

struct PCMSolverDimension {
   int rank;
   int shape[rank+1];
};

struct PCMSolverDimension pcmsolver_get_site_function_dimension() {
   return((struct PCMSolverDimension) {
        // This is the number of dimensions in the MEP and ASC.
        .rank = 1;  // Column or row vector
        // This is the number of rows
        int nrows = 100;
        // This is the number of columns
        int ncols = 1; // We will work with column vectors
        .shape = {nrows, ncols};
    });
}

int pcmsolver_get_site_function_rank() {
   return dimension_.rank;
}

int[] pcmsolver_get_site_function_shape() {
   return dimension_.shape;
}

• As shown above, I suggest we rename "surface functions" as "site functions".

Functionality

• Finish up interface with ddCOSMO.

Solvers

• Allow usage of iterative solvers. Eigen provides infrastructure for CG and BiCGSTAB, also in matrix-free form.