Refactoring of CellValues and Fields about gridap.jl

[fverdugo]

With commit 0a9acd5, a first version of the new design of CellValues and Fields is available (for the moment only in branch refactoring_cell_values, where the code downstream from this part is still commented).

Features of the new design:

• Introduction of NumberKernel and ArrayKernel. Two types that represent operations that return numbers and arrays respectively. These operations are allowed to have arbitrary number of arguments. E.g. CellsumKernel takes an array and returns another array resulting from summing up all the entries in one dimension. Other available kernels are e.g., VarinnerKarnel, LinCombKernel.

• Introduction of the function apply. It takes a NumberKernel or an ArrayKernel and an arbitrary number of CellValues. It lazily applies the given kernel to the given CellValues. E.g., applying the VarinnerKernel to a CellBasis and a CellField will return a CellMap object representing an (unevaluated) element vector. In the arguments of the apply function, we can mix e.g., CellMaps and CellArray in an (almost) arbitrary way. E.g., we can apply the LinCombKernel to a CellBasis and a CellVector, which will result in a CellField . Applying the LinCombKernel to a CellMatrix and a CellVector will return a CellVector. The function apply has several overloaded methods for optimization. E.g., applying a kernel to a set of ConstantCellValues will return also a ConstantCellValue. Applying it to a set of IndexCellValues will return an IndexCellValue.

• Expressivity, extensibility and performance. By defining its own kernels and using the apply function, the user will rarely need to implement CellValue types (which is quite tedious) for their particular needs. The kernels also allow to fuse very complex operations in a single CellValue object instead of having a very complex operation trees between CellValue objects, which will definitively improve performance and compilation times.

• Fields, Basis, CellFields, and CellBasis return always the same object when calling the gradient function. Before, each time the gradient function was called, a new object was created. Now the same object is always returned. This is a first step in order to optimize loops by do not recomputing values associated to quantities that appear in several terms. The next step will by to cache the values returned at each cell (to be done). I was not able to achieve this in all cases. E.g., for ConstantCellValues. So, we cannot assume that the gradient function will return always the same object. In any case, I think this is not strictly needed always. Only for the FEBasis, FEFunction and CellFields obtained from an analytical function we really need this behavior.

• New design is based on the TensorValues package. This allows to define const FieldValue = Number, and to simplify a lot broadcasting.

• New code structure based on reexport. I am following a new code structure, where each file defines a module. I have learned (the hard way) that this is a must in a large project. In particular, if we want that the files can be moved easily without worrying a lot about the using and import statements. I am also using reexport. The objective is that (with few exceptions) modules only export names that are going to be used in the top level name-space of the Gridap project. This also allows to simply write using Gridap within Gridap itself to get access to the names that have already been defined and exported. E.g., in the files related with fe spaces, it will be only necessary to write using Gridap to get access to e.g., CellField.

[fverdugo]

Things to be done:

• apply function can take up to 6 arguments for the moment. This can be easily generalized by using generated functions. This is still to be fixed. Moved to a separate issue (see issue #32)
• An internal julia error es appearing very often. I have included a set of hacks to circumvent this error, but this has to be fixed better. I think it is related with the fact that I am storing tuples of objects in the fields of structs... I have obtained some help from the Julia developers (JuliaLang/julia#32322) about this. The issue is fixed in julia master, and they suggested me a workaround to avoid it in the 1.1 version.
• The rest of the code has still to be adapted to the new design

[fverdugo]

I have opened an issue in julia about the internal error (JuliaLang/julia#32322)

[fverdugo]

The refactoring is already available in master since PR #31.
Closing issue

[fverdugo]

Note for developers (specialy for @santiagobadia ):

PR #31 has introduced backward incompatible changes into master.

This is an illustrative (but strictly speaking incomplete) list of the changes to be aware of:

• VectorValue{D,T}, TensorValue{D,T,L}, and Point{D,T} are now parametrized also by T the type of the stored entries. Before T was always Float64. So, if, e.g., we want to initialize an array of points we need also to specify T: zeros(Point{3,Int},10,3)

• The celldata function used to get the unique value in a ConstantCellValue is removed. Use the field value instead.

• To get access to the cell value wrappers (e.g., CellValueFromArray) one has to write using Gridap.CellValuesGallery

• celltypes and cellorders functions have been removed from the Triangulation interface (now, they are only in the Grid interface). Instead, we have defined CellRefFEs(::Triangulation) that returns a CellValue{<:RefFE} (usually a ConstantCellValue) indicating the reference elements in the cells of the triangulation.

• Renamed cellcoordinates(::Triangulation) -> CellPoints(::Triangulation)

• Renamed cellbasis(::Triangulation) -> CellBasis(::Triangulation)

• Renamed geomap(::Triangulation) -> CellGeomap(::Triangulation)