Refactor Grids and Solution Class

[AndrewAnnex]

Is your feature request related to a problem? Please describe. The current implementation for Solutions, Grids, a model's "Grid" object is very confusing and could be simplified greatly.

Describe the solution you'd like The Grid class should be replaced with a "Grids" class or just a python list that manages a collection of Grid objects. Sections, RegularGrids, CustomGrids etc should be subclasses of a parent "Grid" Class. Those grid classes could be activated/deactivated by an attribute on the class or by their presence in the "Grids" class queue or list.

When using compute/compute_at, the model should return or contain a list of the Solutions, or the Solutions should be contained in each Grid class.

some example psuedo code of what this could look like from the user's prospective:

model = gp.creat_model
gp.init_data
gp.set_interpolator
gp.compute_model

section = gp.core.grids.Section(...)
my_cool_custom_grid = my.whatever.CoolGrid(cool args)

model.add_grids([section, my_cool_custom_grid])
solutions = gp.compute_model
# and/or
solutions = gp.compute_model_at(model, [section, my_cool_custom_grid],  reset_block=False, reset_scalar=False, reset_weights=False)

# plot my section
gp.plot.plot_section(model, solutions[0])

This would lend itself to a more flexible and clear interaction with the model class and when attempting to compute sections, or when I for example want to fit the kriging weights once and evaluate on grids I manage to fit within the gpu memory.

I haven't fully thought this through yet, but this would be a huge change to the API for gempy and would require a large re-write of the tutorials. Given the rest of the activity on the repository I think it is important for some of the currently open PRs/wips to be merged in, as this isn't a huge priority for me at the moment. This issue is mainly to capture the idea for others to view.

Describe alternatives you've considered I am writing my own wrapper around gempy to provide these interactions for myself by wrapping around the model class and making brittle hacks to make gempy behave the way that makes sense to me. Once I have things in a better state locally I may share it but a lot of the code is specific to my research needs.

[Leguark]

Hi @AndrewAnnex ! Thank you for the contribution. I have had similar thoughts since a while. The current implementation Grid/Solution emerged when only the regular grid existed. Since then we implemented this idea of several grids - which on paper I think it is good to move to a more modular mesh less design - but that makes the current Solution not fitting too well.

I really like the idea of having two super classes: Solutions and Grids as containers, and then subclasses for each individual type of grids that are inherited by them. Needs more thought but I think we are thinking on the same direction!

Next gempy version is going to bring its fair share of refactoring but maybe we can follow up this idea this fall!

[Leguark]

GemPy v3 has a better API to grab results for a given grid