Subject: [Fenics] Merge of ufc-geometry branch

From: Anders Logg <[email-masked]>
Date: Mon, 4 Mar 2013 17:26:25 +0100

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.

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.

All tests in FFC and DOLFIN pass, but since quite a few things needed
to be changed (including some tedious and error-prone translation of
nested arrays for Jacobians and such into flattened arrays) there may
be bugs so watch out...

--
Anders

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Mon, 4 Mar 2013 17:42:44 +0100

For the uflacs backend, lets just say it's experimental for now. Selecting
representation "uflacs" in ffc should work for forms with only cell
integrals, "non-fancy" elements, only first order derivatives, and no cell
volume and such. Preliminary informal benchmarking shows that basic
hyperelasticity compiles in 1/13 of the time as the old optimized
quadrature representation with comparable runtime performance. More
features are on the way and more benchmarks will be presented at the FEniCS
2013 workshop.

Martin

On 4 March 2013 17:26, Anders Logg <[email-masked]> wrote:

> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp
>

---

From: "Marie E. Rognes" <[email-masked]>
Date: Tue, 05 Mar 2013 10:08:47 +0100

>    Instead, all data should be passed by primitive C data types.

Very nice!

> objections) to simplify the continued work as it involves changes on

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?

--
Marie

---

From: Anders Logg <[email-masked]>
Date: Tue, 5 Mar 2013 13:38:51 +0100

> 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.

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.

--
Anders

---

From: "Marie E. Rognes" <[email-masked]>
Date: Tue, 05 Mar 2013 13:57:22 +0100

> 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

---

From: Florian Rathgeber <[email-masked]>
Date: Tue, 05 Mar 2013 22:43:41 +0000

On 05/03/13 12:57, 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!
>>>> 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

---

From: Martin Alnæs <[email-masked]>
Date: Tue, 5 Mar 2013 23:53:19 +0100

No, FEniCS does not make any API promises at that detail level. However 1.1.x will be bugfixes for 1.1.0, while 1.2.0 breaks several APIs, e.g. ufc is reworked quite a bit.

Martin

Den 5. mars 2013 kl. 23:43 skrev Florian Rathgeber <[email-masked]>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----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-----
>

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 6 Mar 2013 08:38:39 +0100

Thinking a bit about this, what would it even mean for a cross-language
project like FEniCS?

And looking at the C++ code only, what would be the API that we would
want/be able to keep stable? If we lock down all headers in dolfin we have
no room to maneuver and the project will become a horrible mess down the
line. We have limited resources to spend on something that doesn't advance
the project.

There's no chance in hell that we'll spend time trying to preserve binary
compatibility. But we will try to preserve source code compatibility, i.e.
the users should preferably be able to run their code unchanged on new
versions, but it will have to be a tradeoff vs progress and developer
resources.

We've tried to keep the API defined as "everything used by code snippets in
the book" unchanged for a while. Recently we decided to loosen up for a
while for the sake of progress, in particular changing a lot of
uint->size_t for 64bit, reworking ufc a lot, reworking the assemblers,
changing the shape of 1D vector quantities in ufl, changing the meaning of
*dx. So we're clearly breaking compatibility at multiple levels these days.
Later it will stabilise again.

Martin

On 5 March 2013 23:53, Martin Alnæs <[email-masked]> wrote:

> No, FEniCS does not make any API promises at that detail level. However
> 1.1.x will be bugfixes for 1.1.0, while 1.2.0 breaks several APIs, e.g. ufc
> is reworked quite a bit.
>
> Martin
>

---

From: Florian Rathgeber <[email-masked]>
Date: Wed, 06 Mar 2013 10:48:12 +0000

My question wasn't implying that semantic versioning is the only or
necessarily the right way to go. As you point out it's very hard to
define what the FEniCS API is and even if it was clearly defined,
rigorously applying semantic versioning is a lot of effort. So I'm not
necessarily suggesting to adopt that.

However, a documented guideline for how release versions are numbered
in FEniCS would be helpful for both users and developers I think.

Florian

On 06/03/13 07:38, Martin Sandve Alnæs wrote:
> Thinking a bit about this, what would it even mean for a
> cross-language project like FEniCS?
> 
> And looking at the C++ code only, what would be the API that we
> would want/be able to keep stable? If we lock down all headers in
> dolfin we have no room to maneuver and the project will become a
> horrible mess down the line. We have limited resources to spend on
> something that doesn't advance the project.
> 
> There's no chance in hell that we'll spend time trying to preserve 
> binary compatibility. But we will try to preserve source code 
> compatibility, i.e. the users should preferably be able to run
> their code unchanged on new versions, but it will have to be a
> tradeoff vs progress and developer resources.
> 
> We've tried to keep the API defined as "everything used by code
> snippets in the book" unchanged for a while. Recently we decided to
> loosen up for a while for the sake of progress, in particular
> changing a lot of uint->size_t for 64bit, reworking ufc a lot,
> reworking the assemblers, changing the shape of 1D vector
> quantities in ufl, changing the meaning of *dx. So we're clearly
> breaking compatibility at multiple levels these days. Later it will
> stabilise again.
> 
> Martin
> 
> 
> On 5 March 2013 23:53, Martin Alnæs <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> No, FEniCS does not make any API promises at that detail level. 
> However 1.1.x will be bugfixes for 1.1.0, while 1.2.0 breaks
> several APIs, e.g. ufc is reworked quite a bit.
> 
> Martin
> 
> Den 5. mars 2013 kl. 23:43 skrev Florian Rathgeber 
> <[email-masked]
> <mailto:[email-masked]>>:
> 
>>>>>>> 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:
>>>>>>> 
>>>>>>> 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.
> 
> backwards-incompatible API changes which would require
> incrementing the major version number?
> 
> Florian
>> 
>> _______________________________________________ Mailing list:
>> https://launchpad.net/~fenics Post to     :
>> [email-masked]
> <mailto:[email-masked]>
>> Unsubscribe : https://launchpad.net/~fenics More help   :
>> https://help.launchpad.net/ListHelp
> 
>

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 6 Mar 2013 12:04:58 +0100

Ok! Short version is that in 1.x.y, increments to y are bugfix releases,
while increments to x are feature releases and stuff may break (but we try
not to do that without reason). I think that's about as formal as we treat
it, so a longer version is not really needed :)

Martin

On 6 March 2013 11:48, Florian Rathgeber <[email-masked]>wrote:

> iEYEARECAAYFAlE3HuwACgkQ8Z6llsctAxaLtACguZ+Rw1tiD7kZ8RnLBHCkrY/I
> 714AoNFKw2rS3REM/CTk/BzGbQQjOWlz
> =EpJ5

---

From: Anders Logg <[email-masked]>
Date: Fri, 8 Mar 2013 11:41:49 +0100

There's also this page with a big picture describing the big picture:

http://fenicsproject.org/contributing/development_model.html

--
Anders

On Wed, Mar 06, 2013 at 12:04:58PM +0100, Martin Sandve Alnæs wrote:
>   Ok! Short version is that in 1.x.y, increments to y are bugfix
>   releases, while increments to x are feature releases and stuff may
>   break (but we try not to do that without reason). I think that's about
>   as formal as we treat it, so a longer version is not really needed :)
>   Martin
>   On 6 March 2013 11:48, Florian Rathgeber

>   > On 5 March 2013 23:53, Martin Alnæs <[2][email-masked]
>   >
>   > <[4][email-masked]
>     > <mailto:[5][email-masked]>>:
>   >
>   >
>   > versioning ([6]http://semver.org/)? If so, will the merge introduce
>     > <mailto:[9][email-masked]>
>   >
>   >
>   Comment: Using GnuPG with Thunderbird - [12]http://www.enigmail.net/
> Referenser
>   1. mailto:[email-masked]
>   2. mailto:[email-masked]
>   3. mailto:[email-masked]
>   4. mailto:[email-masked]
>   5. mailto:[email-masked]
>   6. http://semver.org/
>   7. https://launchpad.net/~fenics
>   8. mailto:[email-masked]
>   9. mailto:[email-masked]
>  10. https://launchpad.net/~fenics
>  11. https://help.launchpad.net/ListHelp
>  12. http://www.enigmail.net/