On Thu, Apr 16, 2015 at 10:21 AM, Damon McDougall <da...@ices.utexas.edu>
wrote:
> 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.
>
This would certainly be my preference. By "bundled", I assume you mean as
a git submodule, as this also makes contributing back to upstream
relatively easy. If you can keep queso flexible enough that the libMesh
NumericVector interfaces remain completely optional, queso users won't even
have to incur the extra cost of downloading libmesh (git submodule update
can remain optional).
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.
>
I'm curious what the "NumericVector component" would actually look like in
practice. I think you would find that it would be fairly expansive/quite
difficult to separate NumericVector from the rest of libmesh. Off the top
of my head, you would also need a lot of the stuff in parallel/, large
chunks of the configure system, several different enumeration types, the
DenseVectors and DenseMatrices, the SparseMatrix classes, various utility
classes like UniquePtr, and probably a bunch of other stuff. If you
actually attempt this approach I'd be very curious to see what you end up
with.
Also, in this scenario do you envision that the NumericVector component
could be kept up-to-date automatically by a suitably sophisticated script
and git commands? If so, then queso contributors could still contribute
NumericVector changes back to libmesh upstream and they would eventually
make their way back into queso. That way we could try to avoid divergence
between the NumericVector stuff in libmesh and the NumericVector component
in queso, not sure how annoying it would be for queso developers to work
this way, though.
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.
>
By fork here I assume you mean a separate git repository for the
NumericVector component of libmesh which both libmesh and queso use. I'm
definitely against this approach. As Derek mentioned, you may actually
want to use other parts of libmesh in queso at some point, and I don't
think this approach scales well. And personally I would very much like to
avoid developing in and maintaining a repository which comprises 5-6 git
submodules that must each be updated asynchronously.
--
John
------------------------------------------------------------------------------
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
