fenics team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

We definitely need to take some time to figure out such branching issues
before we are in too deep. One way to reduce the hit could be to merge ufl
and ufc into ffc. I dont know how well bzr will handle reverting and
merging files that are moved around. Also, the dolfin utils and ufc design
could get some overhaul for cleaner separation as Anders mentioned.

Martin
Den 6. feb. 2013 18:42 skrev "David Ham" <David.Ham@xxxxxxxxxxxxxx>
følgende:

> I think Martin's suggestion of Dolfin + the rest as the split would
> largely meet my concerns, and it sounds like it mostly meets your
> concerns below as well. It also essentially takes the project back to
> being one almost Python only project with limited dependencies (except
> UFC but that's small) and Dolfin which is big and has more
> dependencies. It also preserves the solver-independent aspect of the
> first set of packages.
>
> I'm not going to attempt to tell you how to run your project so if you
> really need to go to one repository then we'll have to cope, but my
> preference would be the two way split above.
>
> Regards,
>
> David
>
>
>
> On 6 February 2013 17:28, Anders Logg <logg@xxxxxxxxx> wrote:
> > On Wed, Feb 06, 2013 at 04:39:47PM +0000, David Ham wrote:
> >> Hi Martin,
> >> We're not amazingly happy about that idea.
> >> The design of FEniCS as I understand it provides a series of tools
> >> which *can* be used in conjunction but need not be. In particular, our
> >> toolchain (which currently revels in the name flop.py) employs UFL,
> >> FFC, FIAT and Instant, but not UFC or Dolfin (since we employ PyOP2
> >> and Fluidity in those roles). Merging the repositories would give us a
> >> de facto Dolfin dependency which we don't need. It also more generally
> >> undermines the stand-alone nature of these tools and undermines the
> >> idea that these are generic tools which might usefully be used by
> >> solvers other than Dolfin (eg the UFL Dune project we heard about a
> >> while back).
> >
> > We could make installation targets for specific subpackages (those you
> > mention) and add tests run by the buildbot that those can actually be
> > installed and used (for a set of test problems of your choice) without
> > needing to build DOLFIN.
> >
> > The reason I suggested this in the first place was after sitting 5
> > people for one whole day making the releases of DOLFIN, FFC, FIAT,
> > Instant, UFC, UFL. It sounds ridiculous but there is something like 20
> > different steps to go through for each release (including pressing
> > buttons on Launchpad) so it's a big hassle for anyone wanting to make
> > a release. Then multiply that by a factor 6 and realize why we don't
> > make releases that often...
> >
> > Another issue is working on new features. The same factor of 6 (or
> > more commonly only just 3-4) applies there.
> >
> > We started out with 2 projects (DOLFIN + FIAT) which naturally were
> > separate (one C++ library and one Python library). Then we added FFC
> > and SyFi and UFL and UFC were added as a glue between the different
> > form compilers. At the time, this was an efficient way to collaborate
> > and allow different groups to work independently on interoperable
> > codes. The situation has since changed. Now most core developers touch
> > all the codes all the time so a common repository would be more
> > convenient.
> >
> > The reason for the proposed change is all about making life more
> > convenient for developers and cutting down on administrative overhead.
> >
> >> I am also concerned that having them all in the same repository would
> >> tempt people to break tool orthogonality by introducing
> >> cross-dependencies which are not necessary but might appear convenient
> >> to the coder at the time. This would potentially turn a de facto
> >> dependency into a real one and could really make our life hard.
> >
> > We will likely see code being moved from one place to the other, but
> > cross-dependencies could likely be avoided by introducing new tests.
> > One particular test would be to check that the UFL unit tests and the
> > FIAT unit tests run without installation of any of the other packages.
> >
> > --
> > Anders
> >
> >
> >
> >>> Whether to merge all fenics projects into one repository was discussed
> >>> offline in january, my tests of today show that it is definitely
> feasible.
> >>>
> >>> Before we eventually do that, we should allow some time for people to
> >>> foresee eventual issues, e.g. we'll need changes to the buildbot, which
> >>> projects should be included, etc.
> >>>
> >>> The blueprint interface is not really a good place to discuss, as it
> doesn't
> >>> handle concurrent access by multiple users, so chip in on this thread
> if you
> >>> have anything to say.
> >>>
> >>> Here's a summary of pros and cons:
> >>>
> https://blueprints.launchpad.net/fenics/+spec/combine-projects-into-one-repository
> >>> including a link to an already merged repository prototype and a
> script to
> >>> create it.
> >>>
> >>> Martin
>
>
>
> --
> Dr David Ham
> Department of Computing
> Imperial College London
>
> http://www.imperial.ac.uk/people/david.ham
>