leouieda
commented
7 years ago @rowanc1 this is great! Those two examples are exactly what we need.
That is the model I've been using (meshes behave like lists of primitives) but I've been reconsidering it because it doesn't allow slicing of the meshes, which is very useful for plotting.
My plan was to convert the mesh into something like that indexes like a numpy array:
mesh = TensorMesh([50, 50, 10])
# Get horizontal slice (would be another TensorMesh
layer = mesh[:, :, 0]
# Looping over them would be like looping over arrays
# To get the previous fatiando behavior:
for prism in mesh.ravel():
prism.boundsThis isn't too difficult to do. It would mostly be using slice objects in __getitem__ and figuring out the geometry of the new mesh.
Would that be useful for SimPEG as well?
There are a couple major differences between the packages, much of the discretize codebase works on vectorization/matrix multiplication to create differential operators. I believe that fatiando is mostly about for loops, and creating (on the fly) representations of the geometric primitives so that calculations can be done on each one?
Our code is designed like that because the meshes and primitives only represent the Earth model. We don't model the fields and data with these meshes as well, like you do in SimPEG because of the numerical PDE approach. We mainly deal with analytical equations for simple mass elements: prisms, polygons, polygonal prisms, spheres, etc.
We also use the primitives to create synthetic data or sometimes on inversions that don't deal with meshes, like estimating magnetization directions.
So our forward modeling is something like:
def gz(x, y, z, model):
result = 0
for element in model:
# calculate analytical solution for element
result += field
return resultSo we have exact solutions to approximate geometries. From what I understand, SimPEG does approximate solutions to exact physical property distributions (discretized, of course). This is a nice quirk of fate because it means we have little overlap and can gain a lot from using both libraries together.
There may also be some opportunities to work together on how we deal with physical properties, how these are related to the geometric objects, and how you can abstractly define them (e.g. through mapping classes). This was a big push in SimPEG recently, but that got us to v0.9, still lots of thought to be done on how best to do this.
In Fatiando, they are stored in a props dictionary within each geometric element. We've come across some examples where this doesn't work because the physical property is somehow tied to the geometry (like in self-demagnetization or depth-varying density). It's also a chore to have to type prism.props['density'] all the time. But I came up with this before I knew of @property.
I'm curious how you're dealing with these right now in SimPEG. I'm hoping that you've solved this problem already :)
rowanc1
I am leaving this open for a general open discussion around the idea of bringing some aspects of the fatiando meshing/gridding software to either make use of or replace aspects of this package. With the goal of de-duplicating small parts of the geo-scientific stack and bringing in some common dependencies.
The
SquareMeshfor example is quite similar to theTensorMeshin 2D: http://www.fatiando.org/api/mesher.html#fatiando.mesher.SquareMeshThe 3D tensor mesh and octree meshes could generate
PrismMeshes: http://www.fatiando.org/api/mesher.html#fatiando.mesher.PrismMeshIt looks like there would need to be some work in looping over cells to generate geometric primitives. This is actually exactly what we are doing in the treemesh code (this code is dense). https://github.com/simpeg/discretize/blob/master/discretize/TreeMesh.py#L2282
But basically what I could see is:
There are a couple major differences between the packages, much of the discretize codebase works on vectorization/matrix multiplication to create differential operators. I believe that fatiando is mostly about for loops, and creating (on the fly) representations of the geometric primitives so that calculations can be done on each one?
There may also be some opportunities to work together on how we deal with physical properties, how these are related to the geometric objects, and how you can abstractly define them (e.g. through mapping classes). This was a big push in SimPEG recently, but that got us to v0.9, still lots of thought to be done on how best to do this.
Again, I see this as a way to bring our two communities a bit closer together, as there are significant overlaps: grav/mag, srtomo, inv framework, utilities like data fetching, etc. But one step at a time. :)
@leouieda has noted some of these things in fatiando/fatiando#278 and also pointed out a few opportunities to improve the
discretizepackage (e.g. pep8) #39, which we should seriously consider.