This PR does two things. First, it disables the ability to process multiple meshes at a single time and second, it pre-loads commonly used variables. Currently, MeshHandler.nearest_cell would preform multiple IO calls to the same variables. With small meshes, these IO calls are negligible, but with larger meshes it becomes a problem.
@mgduda what do you think of MeshHandler.subset_fields? In issue #13 we mentioned reading in all of the variables of a mesh, but some of the mesh fields (e.g. dvEdge, weightsOnEdge, and the Cartesian fields) are not explicitly used. Do you think we should load these fields as well? Or keep the implementation contained within this PR?
This PR does two things. First, it disables the ability to process multiple meshes at a single time and second, it pre-loads commonly used variables. Currently, MeshHandler.nearest_cell would preform multiple IO calls to the same variables. With small meshes, these IO calls are negligible, but with larger meshes it becomes a problem.
@mgduda what do you think of MeshHandler.subset_fields? In issue #13 we mentioned reading in all of the variables of a mesh, but some of the mesh fields (e.g. dvEdge, weightsOnEdge, and the Cartesian fields) are not explicitly used. Do you think we should load these fields as well? Or keep the implementation contained within this PR?
This PR closes issue #13.