High-level feedback and open questions

[mlange05]

First of all, I think that this is a really great attempt at unifying the internal pieces required to represent a wide range of computational kernels that share a common set of parallelization and domain-specific assumptions. I have a few high-level comments/questions regarding certain concepts, that are mostly of a general nature and might simply be due to the need for more examples to accompany the API spec:

• I am not entirely sure about the differences between variables (VarDecl) and fields (FieldDecl). The former seems to indicate a generic multi-dimensional array that shares no dimension with the grid, while the latter can only be defined in GridDimensions implying (unless I'm misunderstanding this) that it is restricted to scalar fields in the spatial domain. To illustrate this point better; how would I define a tensor field that consists of a 5x5 matrix at each gridpoint (eg. f(x, y, z, n, n)where n is a utility dimension of n=5)?

  I'm raising this because I fear that this distinction creates a certain amount of redundancy in the spec, as VarAccess/FieldAccess and DimensionLevel/Offset nodes are potentially capturing very similar concepts.

• This comment was already raised in our recent face-to-face meeting, but I want to mention it here for completeness:
  The concept of ExternalKernel is somewhat ambiguous and includes two distinct use cases:

  • A kernel that modifies the state of a variable/field with a "global" scope and thus forces any parallel contexts to be closed, as well as imposing potential dataflow/controlflow dependencies with other kernels (Computation).
  • An "inlined", locally scoped external call (eg. calling a library solver for my point-wise 5x5 matrix that is part of a Computation context and can be in-lined.

  I'm unsure whether these two cases should exist as separate nodes in the tree, or whether adding some sort of "scope" attribute to the ExternalKernel type would suffice, but I think booth modes need to be supported and should possibly be illustrated in an additional example.

• Have any consideration been given to user-defined attributes or any extensible mechanism by which individual packages (eg. separate compiler passes) can "annotate" an existing HIR tree? For example, annotating statements, loops and conditional with variable scoping or dependency information might be useful to multiple packages further downstream in a code-generation toolchain. I'm wondering if such a mechanism should be formalized as part of the IR definition, whether this would simply be done by developers adding custom attributes to the XML definition or whether mapping this information to tree elements is/should be the responsibility of the DSL/codegen/compiler package?

• The BoundaryCondition element does not seem to have any "iteration space" information associated with it. I'm wondering how to express parallelism for BC computations unless at least a subset of GridDimensions over which to iterate is specified (eg, apply f(x=0) = my_func() and how scheduling this kernel in relation to other Computation kernels could be done? Maybe an additional example could further illustrate this?

• As a follow-on from the above, I was wondering if any consideration has been given to further generalizing the concept of an "iteration space" beyond Dimension and DimensionInterval. Could things like Cells/Facets/GridPoints/DoFs be expressed even further as global objects that define a set of Dimensions in relation to a domain?