Open anderson2981 opened 1 week ago
For a simpler example, the error can be reproduced with any inviscid driver in mirgecom. The pulse.py
example has been prepared to easily reproduce on mirgecom@update-overintegration-tests
:
python -m mpi4py pulse.py --tpe --overintegration --lazy
The default when using tensor product elements is to create a QuadratureGroupFactory(order=p)
where p
is the degree of the polynomial basis for the elements. By default this gets us a JacobiGauss quadrature rule with (p+1)^d
quadrature nodes that is exact up to 2p + 1
. But currently, sending anything less than 2p
to QuadratureGroupFactory
reproduces the error.
We can work around the error by just refusing to fuse those kernels identified as nestable. An example of that work-around is here.
The real error message (for pulse) is:
File "/Users/mdiener/Work/e5/meshmode/meshmode/array_context.py", line 1706, in transform_loopy_program
knl = fuse_same_discretization_entity_loops(knl)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/mdiener/Work/e5/loopy/loopy/tools.py", line 968, in wrapper
result = func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
File "/Users/mdiener/Work/e5/meshmode/meshmode/array_context.py", line 927, in fuse_same_discretization_entity_loops
knl = _fuse_loops_over_a_discr_entity(knl, DiscretizationDOFAxisTag,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/mdiener/Work/e5/meshmode/meshmode/array_context.py", line 886, in _fuse_loops_over_a_discr_entity
lp.get_kennedy_unweighted_fusion_candidates(
File "/Users/mdiener/Work/e5/loopy/loopy/transform/loop_fusion.py", line 766, in get_kennedy_unweighted_fusion_candidates
raise LoopyError(f"'{iname}' and '{conflict_iname}' "
loopy.diagnostic.LoopyError: '_pt_sum_r0_15' and '_pt_sum_r1_1' cannot fused be fused as they can be nested within one another.
caused by this part of the code in meshmode/array_context.py: fuse_same_discretization_entity_loops()
:
knl = _fuse_loops_over_a_discr_entity(knl, DiscretizationDOFAxisTag,
"idof",
True,
orig_knl)
Removing that line of code also works around the issue.
Is there perhaps a stray DiscretizationDOFAxisTag
in the code?
Specifying a quadrature order seems to confuse the transformation chain. The attached example demonstrates this behavior.
Specifically, setting order=1 and quadrature_order=1 yields the following error:
error message
here is an input file
run_params.yaml
occurs in y3prediction driver
mpirun -n 1 python -u -O -m mpi4py driver.py -i run_params.yaml --lazy --overintegration
using the mesh at
data/cav5_comb4/2D/coarse_quads/