After creating a grid function space, I usually print out the number of degrees of freedom associated with the space. If the space is a non-leaf space, e.g. a composite grid function space, I also print out the number of degrees of freedom of its children since I consider this an interesting information; in particular for multi domain simulations. While adapting my code to PDELab 2.0 and its new ordering mechanism, I stumbled upon two problems: 1. The size of child spaces does not seem to be available when using a composite grid function space together with the ```EntityBlockedOrderingTag``` (calling ```child_gfs.size()``` results in a GridFunctionSpaceHierarchyError: "Size cannot be calculated at this point in the GFS tree), while it is available for the ```LexicographicOrderingTag```. 2. When using a composite grid function space together with the ```EntityBlockedOrderingTag```, ```composite_gfs.ordering()``` yields an instance of ```GridViewOrdering``` which inherits from OrderingBase. Since OrderingBase provides methods like ``` typename Traits::SizeType size(const typename Traits::SizeType child_index) const ``` ```GridViewOrdering``` provides those methods as well. But ```OrderingBase``` implements its own ```update()``` method which overrides the update method from ```OrderingBase```. Some inherited class members which are required by inherited methods (like the size method mentioned above) are thus left in an uninitialized state, yielding undefined behavior. For example, calling ``` composite_gfs.ordering().size(child_index) ``` results in a segfault. The method accesses the elements of the uninitialized inherited class member ```OrderingBase::_child_size_offsets``` which is an empty ```std::vector```. I would try to deal with the issue myself, but I would have to understand the code of the new ordering mechanism first. Trying to do so unfortunately turned out to be a little hard without having a reasonably detailed description of the mechanism and the ideas of its implementation at hand.