Add VTKm Probe filter for regular grid resampling #1247
Conversation
…. still need to figure out where to re-call vtkh_bounds so that the larger grid bounds get set properly
| //move origin to lower left corner | ||
| m_origin[0] = m_origin[0] - (m_dims[0]/2); | ||
| m_origin[1] = m_origin[1] - (m_dims[1]/2); | ||
| m_origin[2] = m_origin[2] - (m_dims[2]/2); |
There was a problem hiding this comment.
I want to make sure I understand the origin shift.
Does VTK-m create Uniform Datasets from the center of the Volume?
There was a problem hiding this comment.
VTKm creates uniform datasets from the lower left corner, whereas conduit starts in the middle (and I'm copying that format), so I shifted middle to lower left. Does that make sense?
https://vtk-m.readthedocs.io/en/latest/dataset.html#creating-uniform-grids
There was a problem hiding this comment.
In general, Conduit also starts with an origin + dx,dy,dz. Which is lower left corner with respect to an overall coordinated system.
That said the blueprint example you are using may be centering things at 0 and have volume that covers both negative and positive parts of the overall coordinate system.
Want to make sure we aren't confusing a specific case for testing with what we need for the general case.
There was a problem hiding this comment.
Ahh ok, that's good to know! Must have just saw this special case and assumed it was the default. Let me add some tests with different input data.
src/libs/vtkh/filters/SampleGrid.cpp
Outdated
| const int num_domains = this->m_input->GetNumberOfDomains(); | ||
|
|
||
| for(int i = 0; i < num_domains; ++i) | ||
| { |
There was a problem hiding this comment.
I think we need more logic here to support the distributed memory case.
If all ranks are doing the resample to the same grid, we would have do a reduction to compose the results on each task.
Also, we may want to distribute the output grid across MPI tasks as well for high res resampling.
There was a problem hiding this comment.
Do we have to compose the results? If each rank is responsible for it's own portion of the data, they will either have a point that gets sampled or they won't, and in the end they are still in charge of their own portion of the new grid.
I have a concern about needing to do a large resample, right now we have to create the global grid on each rank.
There was a problem hiding this comment.
I will add a parallel test
There was a problem hiding this comment.
yes - I think so. Let's chat about the cases high bandwidth.
To test this you can use the 2D spiral mulit-domain blueprint example and dish out domains to different mpi tasks.
…todo: more tests, reduceall to rank 0
…lues, sorryboutit). check for dupe valid coords and divide by num dupes. trust user did better and the values are the same?
|
Will require updated VTK-m. (2.2 or 2.1.1) |
| /// | ||
| ///. (We know that all ranks will have something to reduce, b/c | ||
| ///. even if they have no domains, the still created the local | ||
| /// output grid) |
There was a problem hiding this comment.
@nicolemarsaglia see note here of how we can accomplish this w/o MergeDataset -- allowing us to use vtk-m 2.1
Also, this would be more memory efficient b/c merging will create a fused unstructured grid which can require a lot more space if the input was uniform (explicit coords and connectivity, maybe copying and repacking of field arrays)
|
@nicolemarsaglia this looks good to me, we can discuss today! |
No description provided.