Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improving interpolation with MultiBlock and #480

Open
alexkaiser opened this issue Aug 11, 2021 · 9 comments
Open

Improving interpolation with MultiBlock and #480

alexkaiser opened this issue Aug 11, 2021 · 9 comments

Comments

@alexkaiser
Copy link

alexkaiser commented Aug 11, 2021

Description

I am combining blocks of RectilinearGrid data into a single data structure for further processing. The fields to plot are stored as cell data. If I convert to point data, then at boundaries between the blocks in the combined mesh, there is a visible seam when plotting in paraview. When plotting cell data directly, the cells are adjacent in space and no seams are visible. Code and an image of the seam in a plot follow.

Is there a way to add cells across the blocks so that paraview will apply its standard interpolation there or otherwise removed the seam? Perhaps this is because more cells are needed that go across boundaries of the blocks? Or some other thing with ghost zones?

dir_name = 'eulerian_vars1365'
files = natsorted(glob.glob(dir_name + "/*.vtr"))
blocks = pyvista.MultiBlock([pyvista.RectilinearGrid(f) for f in files])
mesh = blocks.combine()
mesh_points = mesh.cell_data_to_point_data()

Example Data

test_point_data

@akaszynski
Copy link
Member

It's possible you might be able to merge the adjacent blocks with clean after extracting the surface.

@alexkaiser
Copy link
Author

Calling extract_surface followed by clean is giving a mesh only for the boundaries of the blocks, and discarding the volumetric data. As in, I am only seeing the data at the location of the seams. The combined mesh, which has type UnstructuredGrid, does not appear to have a clean function.

Is there some way to re-assign these cleaned boundaries to the original mesh, or clean without extracting the surface?

Thank you,

Screen Shot 2021-08-11 at 12 37 38 PM

@akaszynski
Copy link
Member

What about combine(merge_points=True)?

@alexkaiser
Copy link
Author

This reduces the number of points by ~85k, which is a plausible number to be on the internal boundaries, but the seam remains in the plots.

@alexkaiser
Copy link
Author

There may be a problem with lack of data perfectly coinciding on the boundaries of the vtr files, so I end up with some redundant points. The total number of points should be (NX+1)(NY+1)(NZ+1) = 3164625 on the combined mesh, but instead there are 3266378.

If a point on the boundary of the block is then only connected to cells on its side of the boundary, its interpolated value is determined by only half the cells it should be. Then the redundant point only gets its neighbors on the other side, and the values do not agree, and this creates the seam in plotting. Does this make sense?

@alexkaiser
Copy link
Author

I tried calling mesh.cell_centers, which gives point data of the fields at the cell centers.

Is there a way to get cells centered at these newly constructed points? (The dual of the original cells.) The data looks right but only plots in paraview as literal points, not a surface, because of the absence of appropriate cell data.

@alexkaiser
Copy link
Author

I have found a solution. Using the cell centers, sort the points by x,y,z, then manually compute new cells connecting the centers. This is possible since it is a regular Cartesian mesh and the original numbers of cells, NX,NY,NZ are known. This works fine but felt relatively complicated and manual for something simple.

Is there a simpler way with filters to accomplish this? For example is there a tolerance parameter for combine(merge_points=True) that will combine points that differ only slightly? Reviewing the source, such a tolerance was not obvious, but perhaps easy to miss.

@akaszynski
Copy link
Member

Is there a simpler way with filters to accomplish this? For example is there a tolerance parameter for combine(merge_points=True) that will combine points that differ only slightly? Reviewing the source, such a tolerance was not obvious, but perhaps easy to miss.

I've added this #1595. Please checkout the branch and let me know if that solved your issue.

@alexkaiser
Copy link
Author

This works great. I set the tolerance to dx/10 and get exactly the right number of points. Thank you for introducing this prompt and effective fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants