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

Refactor cells #168

Merged
merged 21 commits into from
Jun 27, 2023
Merged

Refactor cells #168

merged 21 commits into from
Jun 27, 2023

Conversation

mscroggs
Copy link
Member

@mscroggs mscroggs commented Jun 7, 2023

Make cells into abstract base classes so cells can be implemented easily outside UFL is desired.

(They may wish do this if, for example, if someone wanted to define a hexagon cell or any other cell not implemented in UFL directly.)

This does not change the current user interface or remove any available functionality, aside from removing a few dicts that no-one should've been using anyway.

This is coupled with FEniCS/ffcx#571

@mscroggs mscroggs marked this pull request as draft June 7, 2023 15:24
@mscroggs mscroggs requested review from garth-wells and dham June 7, 2023 15:53
@mscroggs mscroggs marked this pull request as ready for review June 7, 2023 15:53
class AbstractCell(UFLObject):
"""A base class for all cells."""
@abstractmethod
def topological_dimension(self) -> int:
Copy link
Member

Choose a reason for hiding this comment

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

Could we make things properties rather than methods where appropriate?

Copy link
Member Author

Choose a reason for hiding this comment

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

I was planning to do that in a separate PR.

I was aiming for this PR to need no changes (or negligible changes) in FFCx, DOLFINx, TSFC, and Firedrake so we could get it merged more easily and I can start experimenting with whether its useful to implement cells in the Basix UFL wrapper.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've opened #169 and #170 for things I'm planning to do following this that will change the interfaces to elsewhere

ufl/cell.py Outdated Show resolved Hide resolved
Comment on lines +71 to +82
def __lt__(self, other: AbstractCell) -> bool:
"""Define an arbitrarily chosen but fixed sort order for all cells."""
if type(self) == type(other):
s = (self.geometric_dimension(), self.topological_dimension())
o = (other.geometric_dimension(), other.topological_dimension())
if s != o:
return s < o
return self._lt(other)
else:
if type(self).__name__ == type(other).__name__:
raise ValueError("Cannot order cell types with the same name")
return type(self).__name__ < type(other).__name__
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could one define a total order over cells given information about the cell complex they represent? Or is that insufficient because you might have two different cell implementations that both represent a hexahedron (say).

Copy link
Member Author

Choose a reason for hiding this comment

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

you might have two different cell implementations that both represent a hexahedron (say).

Exactly that

Copy link
Collaborator

Choose a reason for hiding this comment

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

Is it sufficient (for sorting) to only define __lt__ or does one need to provide __eq__ and then @functools.total_ordering ?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good question. __eq__ is defined as part of UFLObject (formerly @attach_operators_from_hash_data). Only this and __lt__ were previously defined so I guess it's enough for what UFL currently does, but adding @functools.total_ordering probably isn't a bad idea

ufl/cell.py Outdated Show resolved Hide resolved
Copy link
Collaborator

@wence- wence- left a comment

Choose a reason for hiding this comment

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

Some docstring fixes required I think.

ufl/cell.py Outdated Show resolved Hide resolved
ufl/cell.py Outdated Show resolved Hide resolved
ufl/cell.py Outdated Show resolved Hide resolved
ufl/cell.py Outdated Show resolved Hide resolved
ufl/cell.py Outdated Show resolved Hide resolved
__all_classes__ = ["AbstractCell", "Cell", "TensorProductCell"]


# --- The most abstract cell class, base class for other cell types
class AbstractCell(UFLObject):
Copy link
Collaborator

Choose a reason for hiding this comment

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

My usual preferred approach these days for abstract interfaces is typing.Protocol rather than ABC. That said, I think because you have implementation in this class and third-party libraries will inherit from it, Protocol is not necessarily better.

WDYT?

Copy link
Member Author

Choose a reason for hiding this comment

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

In the element class, I think it has to be an ABC for now, as there's some implementation in the base class.

Long term, we should maybe aim for Protocols, but for now I think it's confusing to have a mixture of the two, so I'm leaning towards making them ABCs for now

ufl/cell.py Outdated Show resolved Hide resolved
ufl/cell.py Outdated Show resolved Hide resolved
ufl/cell.py Outdated Show resolved Hide resolved
@garth-wells
Copy link
Member

@mscroggs is this almost ready?

@mscroggs
Copy link
Member Author

@mscroggs is this almost ready?

Yes, I think this one is ready

@mscroggs mscroggs merged commit 4b54aed into main Jun 27, 2023
@mscroggs mscroggs deleted the mscroggs/cell branch June 27, 2023 08:58
jorgensd added a commit that referenced this pull request Oct 15, 2023
The deprecation was introduced 4 months ago (#168).
Since all the core objects of UFL is using it (Mesh and FunctionSpace) it means that pytest is throwing tons of deprecation warnings at import:
```python
python3 -W error::DeprecationWarning -c "import ufl.Mesh"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/root/shared/ufl/__init__.py", line 265, in <module>
    from ufl.domain import as_domain, AbstractDomain, Mesh, MeshView, TensorProductMesh
  File "/root/shared/ufl/domain.py", line 190, in <module>
    class TensorProductMesh(AbstractDomain):
  File "/root/shared/ufl/core/ufl_type.py", line 56, in attach_operators_from_hash_data
    warnings.warn("attach_operators_from_hash_data deprecated, please use UFLObject instead.", DeprecationWarning)
DeprecationWarning: attach_operators_from_hash_data deprecated, please use UFLObject instead.
```
mscroggs added a commit that referenced this pull request Oct 16, 2023
)

* Remove deprecated functionality (attach_operators_from_hash_data).

The deprecation was introduced 4 months ago (#168).
Since all the core objects of UFL is using it (Mesh and FunctionSpace) it means that pytest is throwing tons of deprecation warnings at import:
```python
python3 -W error::DeprecationWarning -c "import ufl.Mesh"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/root/shared/ufl/__init__.py", line 265, in <module>
    from ufl.domain import as_domain, AbstractDomain, Mesh, MeshView, TensorProductMesh
  File "/root/shared/ufl/domain.py", line 190, in <module>
    class TensorProductMesh(AbstractDomain):
  File "/root/shared/ufl/core/ufl_type.py", line 56, in attach_operators_from_hash_data
    warnings.warn("attach_operators_from_hash_data deprecated, please use UFLObject instead.", DeprecationWarning)
DeprecationWarning: attach_operators_from_hash_data deprecated, please use UFLObject instead.
```

* Flake8

* implement __str__ for function spaces

---------

Co-authored-by: Matthew Scroggs <[email protected]>
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