Over at queso<https://github.com/libqueso/queso> we're thinking about how to move to supporting a variety of different vector and matrix implementations. Specifically, we'd need a wrapper around the implementation details (PETSc, Trilinos, and Eigen, for example) to provide an implementation-agnostic interface for our users.
I have a little bit of experience with libmesh, but not a lot. I have enough to know `NumericVector` does exactly this, and this is not currently standalone. Furthermore, the use of `NumericVector` would prevent the duplication of a lot of hard work, bug fixing, testing, and triaging that has already been done. Reading through this thread<https://github.com/libMesh/libmesh/issues/423> I see a lot of differing opinions on the matter, and understandably so; you want to maintain a streamlined development process. With that in mind, I'd like to suggest a few options for us to the development community here for feedback: 1. Add libmesh to the list of queso dependencies, and ship queso with libmesh bundled inside. This approach means, at configure time, we can turn off all the components of libmesh that queso doesn't need. Contributions to NumericVector are easily applied by contributing to libmesh. There's no effort required on the part of the libmesh community here, and libmesh increases its base of users. 2. Don't ship the whole of libmesh with queso, but just the NumericVector component, and keep queso in sync with upstream changes each time libmesh does a release. This requires considerably more effort on the part of the queso community than item 1. Mapping upstream changes to NumericVector to queso requires a nontrivial repeated overhead but it cuts down on what is actually required for queso. Specifically, we wouldn't build parts of libmesh we didn't need and therefore we would be able to distribute a leaner queso tarball and maintain a leaner queso repository. 3. Maintain a NumericVector fork. This would require moderate initial effort to set up the fork. Moderate to considerable effort would be required from the libmesh community to massage the build system to deal with another dependency. Moderate to considerable effort would be required from the queso community to do the same. The difference here is that any contributions made to NumericVector by the queso community are much more easily applied upstream than item 2, and no different than item 1. Additionally, this approach offers the opportunity for other open source projects to leverage and contribute to NumericVector. To reiterate, I understand there will be a lot of varied views and opinions but I'd like to solicit feedback on some of these ideas and perhaps probe for other ideas. Best wishes, Damon -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
