NOTE: At the moment, it is not possible to have different data sources for the same output file. This requires some more changes in the Write() methods. In principle, each hemelb::extraction::OutputField should have its own dataSource and OutputField should be virtual class. Each specific output can then be derived from OutputField and implement the proper Write() methods. This would eliminate the need for all that switch-case shenanigans.

This is a not so elegant but unavoidable workaround for the lack of abstraction in the PropertyWriter. Essentially, we introduce a std::map<OutputField::FieldType, IterableDataSource*>& that is passed through to hemelb::extraction::LocalPropertyOutput where the constructor initialises the dataSource according to the map. In principle, this information should be encapsulated in hemelb::extraction::PropertyOutputFile (which should really be called PropertyOutputDescriptor), however, during initialisation of PropertyOutputFile the propertyCaches are yet uniinitalised. Ultimately, the whole simulation master should be re-designed to have a proper distinction between allocation and initialisation.

…ceMap than a single dataSource. This is still not fully general, as the size and position will always be determine from the first data source.

…tionDiffusionDataManager, advectionDiffusionModel.

because it is only used there.

NOTE: At the moment, it is not possible to have different data sources for the same output file. This requires some more changes in the Write() methods. In principle, each hemelb::extraction::OutputField should have its own dataSource and OutputField should be virtual class. Each specific output can then be derived from OutputField and implement the proper Write() methods. This would eliminate the need for all that switch-case shenanigans.

This is a not so elegant but unavoidable workaround for the lack of abstraction in the PropertyWriter. Essentially, we introduce a std::map<OutputField::FieldType, IterableDataSource*>& that is passed through to hemelb::extraction::LocalPropertyOutput where the constructor initialises the dataSource according to the map. In principle, this information should be encapsulated in hemelb::extraction::PropertyOutputFile (which should really be called PropertyOutputDescriptor), however, during initialisation of PropertyOutputFile the propertyCaches are yet uniinitalised. Ultimately, the whole simulation master should be re-designed to have a proper distinction between allocation and initialisation.

the newly introduced map between OutputField::FieldType and IteratedDataSource.

This should be made a cmake option at some point.

* GeometryReader will now store all links read in the GeometrySite object.
* LatticeData will do the mapping to the links of the actual DnQm model used.
This change allows to instantiate separate LatticeData objects that use different DnQm lattices. This should resolve hemelb-codes#706.

…position"

This reverts commit d110d5a.

This reverts commit 82b8d14.

…ve effect on simulation results!

…ions