You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
seems to require all fields to agree with the geometry dtype, which seems overly restrictive given that, as of the complex merge, Firedrake supports complex data. Florian Bruckner reported this on Slack, with a backtrace like the following:
doublelayer_sphere.py:4: DeprecationWarning: meshmode.array_context is deprecated. Import this functionality from the arraycontext top-level package instead. This shim will remain working until 2022.
from meshmode.array_context import PyOpenCLArrayContext
/firedrake/src/pytential/pytential/symbolic/primitives.py:1584: UserWarning: specified the name of the direction vector
return DirectionalSourceDerivative(
/firedrake/src/sumpy/sumpy/kernel.py:1246: UserWarning: specified the name of the direction vector
return type(kernel)(
/firedrake/src/firedrake/firedrake/external_operators/potential_evaluation/potentials.py:196: UserWarning: Functions in continuous function space will be projected to/from a 'Discontinuous Lagrange' space. Make sure any operators evaluated are continuous. Pass warn_if_cg=False to suppress this warning.
warn("Functions in continuous function space will be projected "
/firedrake/src/loopy/loopy/target/execution.py:185: ParameterFinderWarning: Unable to generate code to automatically find 'nunit_dofs' from the shape of 'dst':
division with remainder in linear solve for 'nunit_dofs'
warn("Unable to generate code to automatically "
Traceback (most recent call last):
File "doublelayer_sphere.py", line 20, in <module>
K = DoubleLayerPotential(u1, LaplaceKernel(dim=3), places, actx=actx, function_space=V, op_kwargs={'qbx_forced_limit': None})
File "/firedrake/src/firedrake/firedrake/external_operators/abstract_external_operators.py", line 133, in evaluate
return self._evaluate_action(x, *args, **kwargs)
File "/firedrake/src/firedrake/firedrake/external_operators/potential_evaluation/potentials.py", line 144, in _evaluate_action
return self._evaluate()
File "/firedrake/src/firedrake/firedrake/external_operators/potential_evaluation/potentials.py", line 105, in _evaluate
return self._eval_potential_operator(self.density, out=self)
File "/firedrake/src/firedrake/firedrake/external_operators/potential_evaluation/potentials.py", line 99, in _eval_potential_operator
return self.connection.to_firedrake(potential, out=out)
File "/firedrake/src/firedrake/firedrake/external_operators/potential_evaluation/pytential.py", line 190, in to_firedrake
self.target_to_meshmode_connection.from_meshmode(evaluated_potential)
File "/firedrake/src/meshmode/meshmode/interop/firedrake/connection.py", line 515, in from_meshmode
self._validate_field(mm_field, "mm_field", dtype=dtype)
File "/firedrake/src/meshmode/meshmode/interop/firedrake/connection.py", line 356, in _validate_field
check_dof_array(field, field_name)
File "/firedrake/src/meshmode/meshmode/interop/firedrake/connection.py", line 349, in check_dof_array
raise ValueError(f"'{arr_name}.entry_dtype' must be {dtype},"
ValueError: 'mm_field.entry_dtype' must be float64, not 'complex128'
meshmode/meshmode/interop/firedrake/connection.py
Lines 513 to 515 in 6e0dffc
seems to require all fields to agree with the geometry dtype, which seems overly restrictive given that, as of the complex merge, Firedrake supports complex data. Florian Bruckner reported this on Slack, with a backtrace like the following:
cc @benSepanski
The text was updated successfully, but these errors were encountered: