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

Model dimensions are not correct #978

Open
AlexanderJuestel opened this issue Jan 12, 2025 · 4 comments
Open

Model dimensions are not correct #978

AlexanderJuestel opened this issue Jan 12, 2025 · 4 comments
Labels

Comments

@AlexanderJuestel
Copy link
Contributor

Describe the bug
I am creating a simple model with the extent [0, 1000, 0, 1000, -600, 0]. When looking at the PyVista plots, I noticed that the model is smaller than the extent, see screenshot.

The behavior becomes more apparent, when you want to calculate smaller submodels with a higher resolution and merge them later on. See second screenshot and the gaps between the models.

To Reproduce
Provide detailed steps to reproduce the behavior:

Building a model with the shown extent

Expected behavior
The meshes stretch all the way to the provided extent.

Screenshots
image

image

@javoha
Copy link
Member

javoha commented Jan 13, 2025

Hi Alex,
pretty sure I know why this is happening. It looks like the Pyvista plotter is not given the extent but instead matches what is displayed. The Dual contouring meshes that gempy v3 create seem not to cover the full area to the extent. If you set show_lith=True the correct extend should be displayed.
If this did not happen in the pervious gempy version, I would be pretty optimistic that you get meshes that cover the complete extent if you instead use marching cubes. I would need to try to confirm though.

Edit: Yes, in fact in my case the mc meshes work. Let me know if you need the code for that.

@AlexanderJuestel
Copy link
Contributor Author

Yes, I can confirm that the lith_block covers the entire area.

If you have the code for the marching cubes at hand, I gladly take it.

@javoha
Copy link
Member

javoha commented Jan 13, 2025

Of course! This gets all the mc_meshes from the lithology block of a gempy model. Just note that it does not include faults. You would need to get them the same way from the corresponding fault blocks,

# get mc meshes
mc_vertices=[]
mc_edges=[]
block = geo_model.solutions.raw_arrays.lith_block.reshape(geo_model.grid.regular_grid.resolution)
for i in np.unique(block)[:-1]:
    verts, faces, _, _ = measure.marching_cubes(block, i,
                                                spacing=(geo_model.grid.regular_grid.dx,
                                                        geo_model.grid.regular_grid.dy,
                                                        geo_model.grid.regular_grid.dz))
    mc_vertices.append(verts)
    mc_edges.append(faces)

And the plotting part, the loop here hacked to loop over the number of elements (without faults)

# plotter = pv.Plotter(off_screen=not show_plotter)
plotter = pv.Plotter()

colors = ['#4285f4', '#ea4335', '#fbbc05', '#34a853', '#673ab7']
for i in range(3):
    plotter.add_mesh(
        pv.PolyData(mc_vertices[i],
                    np.insert(mc_edges[i], 0, 3, axis=1).ravel()),
                    color=colors[i])

plotter.show_bounds()
plotter.show()

@AlexanderJuestel
Copy link
Contributor Author

I am trying to make my way around that now. The idea is to create multiple models and combine the meshes afterwards. Actually, since we are extracting the meshes using marching cubes from the lith blocks, we could combine the lith_blocks first and then extract the meshes from the lith_blocks. However, some formations may not be present in one submodel, therefore, we have to filter the interface points and orientations for each submodel and automatically create the mapping object and fault_group. We must also ensure that all elements that are present in the big model in one block are also present in the small blocks. This is i.e. the case for a fault that crops out in one block and is located in another block at a greater depth.....

This sounds more like hierarchical modeling again.....

@javoha javoha added the bug label Feb 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants