Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update basix.ufl.mixed_element factory function for case of a single element #882

Closed
wants to merge 6 commits into from

Conversation

garth-wells
Copy link
Member

@garth-wells garth-wells commented Nov 19, 2024

With this change, a call to basix.ufl.mixed_element with a list of just one finite element simply returns the single element.

This allows an element to be 'constructed' from a list of one element without making a single element into a mixed element (when it's not a mixed element).

@garth-wells garth-wells changed the title Update Basix for mixed elements Update mixed element factory for case of a single element Nov 19, 2024
@garth-wells garth-wells marked this pull request as ready for review November 19, 2024 21:47
@garth-wells garth-wells changed the title Update mixed element factory for case of a single element Update basix.ufl.mixed_element factory function for case of a single element Nov 19, 2024
Copy link

@nate-sime nate-sime left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This proposed resolution doesn't seem like the natural way to deal with the problem.

I'd like a mixed element constructed as implemented in the DOLFINx library. I don't want Basix to give me unexpected behaviour returning the element I provide as an argument. The interface should be explicit.

The returned type will not be a mixed element in all cases as stated in the documentation.

Copy link

@RemDelaporteMathurin RemDelaporteMathurin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for looking into this @garth-wells

FWIW I agree with @nate-sime in the way that we would like a "mixed element" of only one element to behave like an actual MixedElement. The problem isn't only at the construction level but also later on when used.

For example I want to be able to call ufl.split on a function of a functionspace built with that "mixed" element. I believe the proposed interface would not make this possible, which means I need to have different ways to handle things depending on the number of sub-elements, which defeats the purpose imo.

@garth-wells
Copy link
Member Author

This proposed resolution doesn't seem like the natural way to deal with the problem.

I'd like a mixed element constructed as implemented in the DOLFINx library. I don't want Basix to give me unexpected behaviour returning the element I provide as an argument. The interface should be explicit.

The returned type will not be a mixed element in all cases as stated in the documentation.

We need a statement of needs rather than likes. What functionality is needed (preferably with concrete examples)? We don’t want to bogged down with semantics. We need to be precise on the concepts. My starting point is that the main distinction between an element and a mixed element is a well-defined value shape.

@RemDelaporteMathurin
Copy link

RemDelaporteMathurin commented Nov 20, 2024

What functionality is needed (preferably with concrete examples)?

Sure, I tried to be more specific in this comment festim-dev/FESTIM#922 (comment) although this is hard to parse because it's FESTIM-specific. I'll try to make a pure dolfinx example to show how we use this

EDIT: I added an example here FEniCS/dolfinx#3519 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants