call function treats empty-tuples and None and no-argument type differently

[anilbeycorintis]

Hi I first reported this on Firedrake [https://github.com/firedrakeproject/firedrake/issues/4452] and the maintainers suggested here is the place.

Description

The behaviour of subdomain_id varies between the empty tuple case, None case, and no-argument cases.

fd.dx()         ✅  # Equivalent to Measure('cell', subdomain_id='everywhere')
fd.dx(None)     ✅  # Same as above
fd.dx(())       ❓  # Accepted, but becomes Measure('cell', subdomain_id=()), not 'everywhere'

As a result, these two functions behave differently. Shouldn't passing None and empty container behave the same?

1. Implementation with empty tuples

def get_subdomains() -> tuple[int]:
    """Returns the fluid subdomains."""
    result = fetch_result()
    return result

fd.dx(get_subdomains())

2. Implementation with the optional types

def get_subdomains() -> tuple[int] | None:
    """Returns the fluid subdomains."""
    result = fetch_result()
    if len(result) == 0:
        return None
    else:
        return result

subdomains: tuple[int] | None = get_subdomains()
fd.dx(subdomains)

[jorgensd]

I would call this a documentation issue, as:

subdomain_id=None -> integrate everywhere
subdomain_id=tuple[int] -> integrate over regions that are marked with integers from the tuple.

Further notes:
The reasons for the three cases above, is that you do not use the keywords when specifying arguments.
The first one, ufl.dx() does not set the domain (interpreted by the integrand) and assumes integration everywhere.
ufl.dx(None) re-interprets the first argument as the domain: https://github.com/FEniCS/ufl/blob/main/ufl/measure.py#L240C9-L241C63 as all arguments are none (as the first case).
The third case, you are setting subdomain_id=(), which restricts integration to no marked subdomains.

[anilbeycorintis]

I see, thanks a lot for the quick reply. Now I understand the implementation differences but from the user's point of view this behaviour is very confusing and error-prone.

Specifying None currently behaves as All, which is counterintuitive: the user indicates “nowhere” (None), yet the function integrates “everywhere” (All).

Also not always we call ufl.dx() on its own but sometimes the results are coming from some other function which treats None as nowhere.

Perhaps ufl.dx() could enforce keyword argument usage to make its behavior more explicit and predictable.

[jorgensd]

I see, thanks a lot for the quick reply. Now I understand the implementation differences but from the user's point of view this behaviour is very confusing and error-prone.

Specifying None currently behaves as All, which is counterintuitive: the user indicates “nowhere” (None), yet the function integrates “everywhere” (All).

Also not always we call ufl.dx() on its own but sometimes the results are coming from some other function which treats None as nowhere.

Perhaps ufl.dx() could enforce keyword argument usage to make its behavior more explicit and predictable.

Not sure we would want that, as a ton of ufl has been written as ufl.dx(i) where i is an integer, which would then suddenly break.
I would say that you as a user could enforce keyword arguments in your own code, i.e.
ufl.dx(domain=..., subdomain_id=).
However, this wouldn't really resolve the
ufl.dx(subdomain_id=None) vs. ufl.dx(subdomain_id=()) which would have different behaviors.

I guess one could think of it as follows.

• If subdomain_id is not set by the user, it integrates over all entities of the domain.
• If subdomain_id is set to something that is not None, it integrates over those marked entities. If you supply an empty list/tuple, you will not integrate over anything.

[dham]

Could we improve the situation by changing the default value of subdomain_id from None to "everywhere"? I don't think that would change the visible behaviour except to remove the unfortunate clash of () and None.

[jorgensd]

Could we improve the situation by changing the default value of subdomain_id from None to "everywhere"? I don't think that would change the visible behaviour except to remove the unfortunate clash of () and None.

That I would be fine with, yes.

[jorgensd]

Could we improve the situation by changing the default value of subdomain_id from None to "everywhere"? I don't think that would change the visible behaviour except to remove the unfortunate clash of () and None.

Looking more at the source code, I guess the issue is that __call__ is similar to reconstruct, in the sense that not supplying an argument means keeping what is already set.
For example

dx = ufl.Measure("dx", domain=mesh, subdomain_id=(1,2,3), subdomain_data=...)
dx2 = dx()

Should dx and dx2 be the same?
Currently, they will be the same, i.e. dx2 integrates over the subdomain_data with markers (1,2,3).
With the proposed change, dx2 would integrate over all mesh entities.

[dham]

Yuck. I wonder why that was done. Anyway, I agree that that makes it problematic to change anything. I don't much like what we've got but I also don't have an immediate fix.

[mscroggs]

dx = ufl.Measure("dx", domain=mesh, subdomain_id=(1,2,3), subdomain_data=...)
dx2 = dx()

Does anyone know what the justification for dx being callable here is? It feels cleaner to use reconstruct if that's what the user wants to do, and to make dx not be callable

[dham]

dx = ufl.Measure("dx", domain=mesh, subdomain_id=(1,2,3), subdomain_data=...)
dx2 = dx()

Does anyone know what the justification for dx being callable here is? It feels cleaner to use reconstruct if that's what the user wants to do, and to make dx not be callable

Calling dx is the way users parametrise the measure. E.g. f*dx(1). I think the somewhat messy abstraction here is caused by wanting both that and f*dx to work.

[mscroggs]

dx = ufl.Measure("dx", domain=mesh, subdomain_id=(1,2,3), subdomain_data=...)
dx2 = dx()

Does anyone know what the justification for dx being callable here is? It feels cleaner to use reconstruct if that's what the user wants to do, and to make dx not be callable

Calling dx is the way users parametrise the measure. E.g. f*dx(1). I think the somewhat messy abstraction here is caused by wanting both that and f*dx to work.

Ah, yes.

Maybe a sensible suggestion then is to raise if dx is called with any input other than a subdomain id. Or at least raise if it's given no inputs... I'm starting to see why this is so messy

... Maybe it's still a good suggestions to make dx not callable and instead force users to do something like dx.sub(1), but that's an interface change that would need more thought

[jorgensd]

... Maybe it's still a good suggestions to make dx not callable and instead force users to do something like dx.sub(1), but that's an interface change that would need more thought

This i don't like at all.

I would say that the call function should rather just accept subdomain id, as you proposed in the prior sentence.
The option for doing

dx = ufl.Measure(domain=.., subdomain_data=...)

and then making

dA = dx((1,5,8))
dc = dx((2))

etc is super nice for users and makes the code extremely readable.

[dham]

I think users also routinely use the call function to set quadrature. Like subdomain ID, that's something that can change from integral to integral in the same problem.

[jorgensd]

I think users also routinely use the call function to set quadrature. Like subdomain ID, that's something that can change from integral to integral in the same problem.

Fair point. Do you know if they do it through degree or metadata?