fenics team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxx>]

For future development I agree that ufl+ufc+ffc make sense, but I think it
is a good idea to keep Dolfin separate.

Best
Johan

> 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
>>
> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp
>