FiberVISH  0.2
Fish-TheFiberBundleAPIfortheVishVisualizationShell
Frequently Asked Questions

Fields and Fragments

Q: The FragmentIterator allows to iterate over the fragments of one field. How to iterate over the fragments of multiple fields?

A: First issues if those multiple fields belong to the same Grid. Only then a common iteration is possible, otherwise it needs independent fragment iteration. Assuming both fields are in the same Grid, then one must chose a primary field to iterate over. The FragmentIterator::apply() function in the iterator has two arguments, the fragment ID and the data creator pointer. The data creator pointer refers to the primary field's data for the respective fragment. The fragment ID is valid for all other fields in the same Grid (more precisely, in the same Skeleton only) and can be used to access other field's fragment data via the Field::getCreator() (deferred loading) or Field::getData() (immediate data loading) functions. What remains to do is to equip the user- defined fragment iterator (the child class of FragmentIterator) with one or more RefPtr<Field> that refer to the secondary field(s) such that they can be accessed in the apply() function.

Possible Complications: Mixing of fragmented and unfragmented fields is allowed. The same Representation may, for instance, contain unfragmented coordinates but a fragmented scalar field. Typical application is a uniform Grid stemming from an distributed application with a global coordinate system but domain decomposition on the scalar fields. The coordinates (bounding box) of each fragment is then computable via the fragment location information. For iteration one should use the scalar field as the primary field, not the coordinate field, which by itself would be unfragmented. This is the only kind of mixing allowed, if two fields in the same Skeleton are fragmented, then their fragmentation must be compatible. Having one field with 10 fragments and another one with 33 fragments both covering the same Skeleton is not allowed. However, not each fragment needs to be defined in every field, some fragment ID's may be invalid on some fields. If they are valid however, then then they need to correspond to the same spatial domain.

Internals: FragmentID's are internal data structures for looking up fragments in a Field. To allow consistent lookup, Fields manage FragmentID's via a shared FragmentIDCollection. Thus when creating a new Field, it must be ensured that the FragmentIDCollection of another, compatible Field is available. Given the FragmentID, it provides properties such as a textual name or a numerical ID. It's possible to lookup a field fragment also reverse via the textual name or via the numerical ID. Both should be avoided however because such reverse lookup impacts performance.