Why has the class FiniteElement been removed?

[dr-robertk]

Upon switching from 2024.2.0 to 2025.2.0 I realized that the class FiniteElement is now only available in test/utils.py, and therefore not accessible from outside.

Why? What is the idea here? Should one make a copy or how to solve this?

Also, the function extract_arguments_and_coefficients suddenly disappears without prior deprecation warning. It was not marked
with a leading underscore, so it's ok to use from outside of the ufl module.

[mscroggs]

Why? What is the idea here? Should one make a copy or how to solve this?

It could be made clearer, but there's a note in the AbstractFiniteElement docstring. Essentially, instead of UFL containing a load of information about elements that is then duplicated in the code where the elements are implemented, we've moved to getting this information about elements from a subclass that is implemented where the elements are implemented.

For Basix for example, this is done in https://github.com/FEniCS/basix/blob/main/python/basix/ufl.py. In FInAt, a copy of the old UFL elements is currently used, with I imagine some medium term plans to update this.

Also, the function extract_arguments_and_coefficients suddenly disappears without prior deprecation warning. It was not marked with a leading underscore, so it's ok to use from outside of the ufl module.

This I'm less sure about. Perhaps someone else can answer this?

[connorjward]

Also, the function extract_arguments_and_coefficients suddenly disappears without prior deprecation warning. It was not marked
with a leading underscore, so it's ok to use from outside of the ufl module.

This was removed in #303. The PR description states:

extract_arguments_and_coefficients is now called extract_terminals_with_domain, and it now also collects GeometricQuantys, so that we can correctly handle, say SpatialCoordinate(mesh1) and SpatialCoordinate(mesh2), in problem solving environments.

I don't know if UFL has a specific policy for deprecating things. For example #385 was recently merged which included a fair number of breaking API changes (and a deprecation process would have been very challenging to handle).

[adedner]

Release notes or changelog with possible replacements (i.e. the above mentioned extract_terminals_with_domain or with pointers to the relevant MRs) would be really helpful and appreciated. Perhaps it exists of course and I have not found it...

The last entry in the changelog file here is for the 2021 release. And on the docu page
the latest release notes are from 2019. That is all I could find.

In dune-fem we are currently still pinning to a the 2022 ufl release because switching to a newer release, trying to figure out what error mean, and what the replacement is has proven quite painful.

[connorjward]

Some release notes are automatically generated when releases are made: https://github.com/FEniCS/ufl/releases. I appreciate that they are quite difficult to read and don't really flag breaking changes.

[jhale]

The release notes are at https://github.com/FEniCS/ufl/releases

It seems inevitable that if you pin a dependency, the API will drift over approximately four releases. Looking ahead, in terms of picking up the effects of changes in UFL on your project, would some sort of integration testing be possible? This could either be done from your end, or from our end, as we do for TSFC and FFCx.

[adedner]

Thanks for pointing me to those release notes, I did miss those.

We were still on 2022 because moving to 2023 was not straightforward and then after we did finally fix the issues and were finished with porting to 2024 we decided we might as well go to 2025 and ran into the problems @dr-robertk described above.

Some integrated testing of the newest ufl would be great - we had already decided on having one of our github workflow based off the newest ufl (we were considering the newest release but possibly pulling from source is even better to see early what changes are coming).

How do you do integrated testing with TSFC and FFCx?

[jhale]

We can discuss this in our Slack #development channel, perhaps a bit more dynamic, if you wish.

In short there are two options:

1. An upstream test of UFL main against your main, see e.g. TSFC https://github.com/FEniCS/ufl/blob/main/.github/workflows/tsfc-tests.yml and FEniCSx https://github.com/FEniCS/ufl/blob/main/.github/workflows/fenicsx-tests.yml. For this to be truly effective, you would need to take a more active role in UFL development, as both FEniCS and Firedrake do. In the initial period, we would probably make it non-blocking in terms of merging PRs.

2. A downstream test of your package against UFL main, as you propose.

[dr-robertk]

Thanks for the explanations. We will certainly look into option 2. Option 1. is of course favorable but may not be possible due to limited resources.

I have made a copy of the FiniteElement class. I just found it unsatisfactory to have one copy in ufl/test/utils.py and then one in dune-fem. But it works.

As for the extract_arguments_and_coefficients it would have been great (and rather easy) to add a fallback function like this:

# ufl newer than 2024.2.0, use extract_terminals_with_domain
# remove for version 2026.2.0
from ufl.algorithms.analysis import extract_terminals_with_domain
def extract_arguments_and_coefficients(a):
    print("Replace `extract_arguments_and_coefficients` with `extract_terminals_with_domain`")
    ret = extract_terminals_with_domain(a)
    return ret[0], ret[1]

It think that such a fallback makes it easier for everybody, because code does not break and it's clear what the replacement should be.

[adedner]

Thanks everyone for the quick reply and suggestions. As @dr-robertk said we'll start with (2) and depending on how things go make a suggestion for (1) - but definitely non-blocking.