I will still vote for #1 myself. To me, libMesh is small enough and stable
enough that adding it as a dependency isn't a big deal.
Plus, then you can use lots of other stuff from libMesh. For instance,
task-based threaded parallelism (wraps OpenMP, Intel TBB and Pthreads) and
the excellent MPI wrappers. Not too mention other stuff like DenseMatrix
and more. All of that stuff can be used independently of any of the
finite-element infrastructure. In fact, I've been using this strategy for
a while for many of my own little projects with a lot of success.
I would definitely be in support of some more configure options for libMesh
that allow you to turn off parts of the library (--no-fe ?).
If we were to start breaking it apart... where does it end? Basically
every subdirectory in libMesh is a self-contained entity that is useful by
itself to different projects. Do we break the whole thing apart into 7-8
separate libraries? It makes most sense to leave it together and turn off
the pieces you don't need.
Derek
On Thu, Apr 16, 2015 at 12:21 PM 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.
>
> 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
>
------------------------------------------------------------------------------
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
