Fault Surface Colors in new 3D plotting API not displayed correctly

[AlexanderJuestel]

Describe the bug When using the new 3D plotting API it was noticed that the color of the fault interfaces do not match with the colors of the computed fault surfaces (see screenshot, the faults go from left to right). The colors for the stratigraphic interfaces are correct though. (The light blue interfaces have a dark blue surface, the purple interfaces a yellow surface, the yellow interfaces a (light) blue surface...)

Expected behavior All surfaces should have the color that was attributed to the respective surface during surface mapping, especially when using different colors for fault and not just one color.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10
• GemPy Version
  • if cloned from GitHub: 1.01-1193-gb934f07

Additional context It is not a big issue but should be fixed at some point for consistency purposes

[AlexanderJuestel]

In connection with issue #386 I tried to manually add surfaces to the 3D visualition with the fmts argument in the plot_surfaces_all()-function (see code block 1). The code for plotting is shown in code block 2. The fmts argument seems not be taken in gp._plot.plot_3d(geo_model...), hence the workaround. When applying the workaround, I would only like to display the "SandgewandFault" and "EasternGrabenJump", I noticed that the surface for "EasternGrabenJump" is in the wrong place and should actually be where the surface data is (purple points a little further down, screenshot 1). There seems to be a mix up with the attribution of surfaces. This mix up was also confirmed for other surfaces.

@pytzcarraldo

Code 1:

def plot_surfaces_all(self, fmts: Iterable[str] = None, **kwargs):
        """Plot all geomodel surfaces. If given an iterable containing surface
        strings, it will plot all surfaces specified in it.

        Args:
            fmts (List[str], optional): Names of surfaces to plot. 
                Defaults to None.
        """

Code 2:

# gp._plot.plot_3d(modelA2, render_topography = False,  ve =1, cpos = [[1. , 1. , 1], [0.0, 0.0, 0.0], [0, 0, 1]], fig_path = os.pardir+'/Data/Output/Models/ModelA%d/ModelA%d_3D_Plot2.png' % (model,model))

cpos = [[1. , 1. , 1], [0.0, 0.0, 0.0], [0, 0, 1]]
gpv = gp._plot.Vista(modelA2)
gpv.set_bounds()
#gpv.p.camera_position = cpos
# gpv.plot_structured_grid("lith")
gpv.plot_surfaces_all(fmts = ['EasternGrabenJump', 'SandgewandFault'])
gpv._plot_surface_points_all()
gpv._plot_orientations_all()
gpv.plot_topography()
gpv.p.show(screenshot = os.pardir+'/Data/Output/Models/ModelA%d/ModelA%d_3D_Plot2.png' % (model,model))
gpv.p.camera_position

Screenshot 1:

[alex-schaaf]

Thanks for the info!

So with the faults being out of order seems to be a problem with how the faults are ordered in the solutions. In my implementation I assumed the same ordering as in the series dataframe - is this not correct @Leguark?

gp._plot.plot_3d(geo_model) is supposed to be just a simple method to look at your model and we can only provide so much customisation options without going crazy. For anything more, the user should really use the granular plotting api using gp._plot.Vista, as they then have also direct and easy access to all pyvista functionality to fine tune their plots 🤔

Another tip for posting code @AlexanderJuestel : best to avoid screenshotting code, as its not very legible when images are scaled - best use markdown code blocks like so https://help.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks

[AlexanderJuestel]

@pytzcarraldo thanks for the hint with the screenshots, I changed the comment now. I do like the Syntax highlighting with Ruby ;)

I agree with you with respect to fine tuning of the plot. Implementing everything possible would be a little too much.

[domist07]

@AlexanderJuestel when you defining the surfaces as faults, did you have set geo_data.set_is_fault(['Fault1', 'Fault2'], change_color=False) ? The last part should avoid changing the colour in 3D plot.

[AlexanderJuestel]

Yep, since I define custom colors for my faults, turned it off (I add them one by one in case I have to deactivate some for testing purposes).

modelA2.set_is_fault(['FeldbissFault'],         change_color =False)
modelA2.set_is_fault(['EasternGrabenJump'],     change_color =False)
modelA2.set_is_fault(['StolbergGrabenFault'],   change_color =False)
modelA2.set_is_fault(['WesternMainJump'],       change_color =False)
modelA2.set_is_fault(['SandgewandFault'],       change_color =False)
modelA2.set_is_fault(['WeisweilerJump'],        change_color =False)
modelA2.set_is_fault(['OmerbachFault'],         change_color =False)
modelA2.set_is_fault(['BettendorfJump'],        change_color =False)
modelA2.set_is_fault(['WeisweilerJumpTrench'],  change_color =False)
modelA2.set_is_fault(['MerodeFault'],           change_color =False)
modelA2.set_is_fault(['EilendorfThrust'],       change_color =False)
modelA2.set_is_fault(['BurtscheidThrust'],      change_color =False)
modelA2.set_is_fault(['VennThrust'],            change_color =False)

[Leguark]

Yes, the problem happens when the faults are not on the top of the pile. We were using quite dumb code. In my branch it should work already (do not try yet because I am changing a lot).

closed by #396

[Leguark]

can you check this one with the new update

[AlexanderJuestel]

Will be checked with other projects soonish and then closed :)

[agzimmerman]

Will be checked with other projects soonish and then closed :)

@AlexanderJuestel did you check this yet?

[AlexanderJuestel]

@alexanderzimmerman, I am still working with GemPy 2.1.1 but I will ask someone who is already building models in 2.2.1

[AlexanderJuestel]

@alexanderzimmerman, I checked with someone else and the colors a correct now. Issue closed

[agzimmerman]

@alexanderzimmerman, I checked with someone else and the colors a correct now. Issue closed

Thanks!