← Back to team overview

fenics team mailing list archive

Re: Merge of ufc-geometry branch

 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/03/13 12:57, Marie E. Rognes wrote:
> On 03/05/2013 01:38 PM, Anders Logg wrote:
>> On Tue, Mar 05, 2013 at 10:08:47AM +0100, Marie E. Rognes wrote:
>>>> The ufc-geometry branches of UFC, FFC and DOLFIN have been
>>>> merged into trunk. In addition, the FFC branch merges in
>>>> Martin's addition of the new uflacs compiler backend to FFC.
>>>> (Martin can comment on the status of the uflacs backend.)
>>>> 
>>>> The changes in ufc-geometry were motivated by a cleanup of
>>>> the codesnippets in FFC and a simplification (?) of the UFC
>>>> interface. Some changes:
>>>> 
>>>> - Introduce header ufc_geometry.h in UFC to replace
>>>> codesnippets. Quite a few codesnippets remain and should be
>>>> migrated to the same header file.
>>>> 
>>>> - Use flattened arrays for all data structures. See comment
>>>> on top of ufc_geometry.h for some remarks on the efficiency
>>>> vs nested arrays and flattened/nested std::vector.
>>>> 
>>>> - Remove ufc::cell as a common data structure holding a bunch
>>>> of data that may not be needed and therefore should not need
>>>> to be updated. Instead, all data should be passed by
>>>> primitive C data types.
>>> Very nice!
>>>> Some of these are work in progress and more work needs to be 
>>>> done. Before this, I'm going to merge UFC into FFC (if there
>>>> are no objections) to simplify the continued work as it
>>>> involves changes on both ends.
>>> Since we have added/changed quite a bit of functionality since
>>> 1.1 (PDEs on surface, changes in the meaning of dx for
>>> instance); would it be an idea to make a release before
>>> starting to merge projects?
>> Yes, why not. This can be 1.2. In that case, the release should
>> come pretty quick since I would like to go ahead with the merging
>> now.
> 
> Yes, definitely. I've just spoken to our new FEniCS release manager
> -- he will follow-up asap :-)
> 
> -- Marie
> 
>> Then I suggest 2.0 after the merge. For UFC (then bundled with
>> FFC) the version can be x.2.0 (?) since 2.0 and 2.1 have already
>> been released for UFC. Then we synchronize the version numbers
>> starting with 3.0.

Is FEniCS following a version numbering scheme s.a. semantic
versioning (http://semver.org/)? If so, will the merge introduce
backwards-incompatible API changes which would require incrementing
the major version number?

Florian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlE2dRwACgkQ8Z6llsctAxbDdgCdHhLd0bWqcf1+ZRdGbbUVVqgn
nRwAniKbOhwp1twGQ1tGWrKTGHbdV0Er
=6d01
-----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


Follow ups

References