Describe the bug
In 2D or 3D problems, the velocity field can be represented by more than one variable, to account for the components of velocity in each dimension. However, in the latest version of pina-mathlab (according to pip: 0.2.1.post250505) passing a list of labels in the velocity field argument raises an error in the following check:
if velocity_field not in output_.labels:
raise RuntimeError(
f"Velocity {velocity_field} is not present in the output labels."
)
To Reproduce
a = LabelTensor(torch.ones((10,3)), ['ux','uy','p'])
b = LabelTensor(torch.ones((10,2)), ['x','y'])
advu = advection(a, b, velocity_field=['ux','uy'], components=['ux','uy'])
Expected behavior
The program attempts to compute the advection (and fails because the tensors do not require grad).
Output
The programs stops before attempting any gradient computation.
RuntimeError Traceback (most recent call last)
File ~/.../pina/operator.py:457, in advection(output_, input_, velocity_field, components, d)
RuntimeError: Velocity ['ux', 'uy'] is not present in the output labels.
Additional context
I assume this behaviour is unintended, because passing a list of variable names into velocity_field was supported in older versions.
Describe the bug
In 2D or 3D problems, the velocity field can be represented by more than one variable, to account for the components of velocity in each dimension. However, in the latest version of pina-mathlab (according to pip: 0.2.1.post250505) passing a list of labels in the velocity field argument raises an error in the following check:
To Reproduce
Expected behavior
The program attempts to compute the advection (and fails because the tensors do not require grad).
Output
The programs stops before attempting any gradient computation.
Additional context
I assume this behaviour is unintended, because passing a list of variable names into velocity_field was supported in older versions.