Closed jorgensd closed 2 years ago
I think we should have two separate kernels, one for each quadrature rule.
I think we should have two separate kernels, one for each quadrature rule.
That is not true. FFCx supported multiple quad rules per integral, see https://github.com/FEniCS/ffcx/pull/405
Is this fixed by #405?
Yes, resolved in #405 .
@IgorBaratta I am not sure if this was the only reason for https://github.com/FEniCS/ufl/issues/70, in that case you can close it too.
Please note we have always one generated kernel per one IntegralData
, but intermediate representation for this kernel has a dictionary for integrands which maps quadrature_rule --> integrand expression tree. See also https://github.com/FEniCS/ufl/pull/27 for related discussions.
@IgorBaratta I am not sure if this was the only reason for FEniCS/ufl#70, in that case you can close it too.
Please note we have always one generated kernel per one
IntegralData
, but intermediate representation for this kernel has a dictionary for integrands which maps quadrature_rule --> integrand expression tree. See also FEniCS/ufl#27 for related discussions.
That's not the only issue that motivated FEniCS/ufl#70. I think a flag would do the trick. And the change would allow tabulating data at quadrature points and some simplification on the input data. I would preferably do it at UFL level than reverse engineer forms/integral data in ffcx.
@IgorBaratta I am not sure if this was the only reason for FEniCS/ufl#70, in that case you can close it too. Please note we have always one generated kernel per one
IntegralData
, but intermediate representation for this kernel has a dictionary for integrands which maps quadrature_rule --> integrand expression tree. See also FEniCS/ufl#27 for related discussions.That's not the only issue that motivated FEniCS/ufl#70. I think a flag would do the trick. And the change would allow tabulating data at quadrature points and some simplification on the input data. I would preferably do it at UFL level than reverse engineer forms/integral data in ffcx.
I do not see any reverse engineering there, FFCx just generates code for how it was preprocessed in UFL. Arguably, one could wish for better control over what UFL does (especially control grouping of terms, not only for forced quadrature degree but also for the estimated). But compute_form_data UFL interface is just bloated now and already smells, would need redesign.
What simplifications on input data do you mean? Multiple quad rules per kernel has the advantage that temporaries which do not depend on quadrature loop are computed just once. Also, the overhead of packing data for kernel on the caller side is smaller.
Originally reported at: https://fenicsproject.discourse.group/t/help-needed-in-analyzing-a-mindlin-plate-in-fenicsx/6768?u=dokken
Following is a MWE:
with error