Rotating MVI vector voxels
SeanWalker
Posts: 27
in Oasis montaj
Hi,
Does anyone have a workflow for Rotating MVI voxels. I can think of one but wondering if anyone knows a better way.
VOXI inversions run faster if the X axis is smaller than the Y. So it is wise to rotate your data before inversion. I do this by rotating the X and Y coords in the gdb (Coordinates>Rotate) CCW about a point. I also adjust the declination value used in the inversion (since it is CCW subtract the value from the IGRF declination). You also need to rotate the PLY you are using. I find it easier to just generate a rotated data grid and then create a grid outline as a ply (Grid>Utilities>Grid Outline)
In order to get the MVI results back I do the following.
1) Convert Vector voxel to gdb (Voxel>Conversions>Vector Voxel to GDB).
2) Rotate the X and Y coords (opposite direction to what we did before)
For the MVI amplitude I do the folowing
3) Create a new voxel using inverse distance gridding (Voxel>New Voxel>Inverse Distance Weighted Gridding). There is a knowledge base article that suggests using kriging (not sure why). Set X, Y and Z cells to the sizes from the main part of the mesh.
4) Trim the top using the topo grid used in the inversion (Voxel>Utilities>Voxel Topo Clip).
5) Trim the XY using a ply file and trim the Z with a reasonable depth value (based on looking at your original results (Voxel>Utilities>Window a Voxel)
** we need to trim the voxel because the gridding process has extrapolated values beyond our model and we don't want them included.
My question is how to deal with the vector components. I guess I could repeat steps 3, 4 and 5 on the U, V and W components and them using the Voxels to Vector Voxel conversion (but put in the correct declination). This should work but would take a while. Any ideas for faster options would be appreciated.
Sean
Does anyone have a workflow for Rotating MVI voxels. I can think of one but wondering if anyone knows a better way.
VOXI inversions run faster if the X axis is smaller than the Y. So it is wise to rotate your data before inversion. I do this by rotating the X and Y coords in the gdb (Coordinates>Rotate) CCW about a point. I also adjust the declination value used in the inversion (since it is CCW subtract the value from the IGRF declination). You also need to rotate the PLY you are using. I find it easier to just generate a rotated data grid and then create a grid outline as a ply (Grid>Utilities>Grid Outline)
In order to get the MVI results back I do the following.
1) Convert Vector voxel to gdb (Voxel>Conversions>Vector Voxel to GDB).
2) Rotate the X and Y coords (opposite direction to what we did before)
For the MVI amplitude I do the folowing
3) Create a new voxel using inverse distance gridding (Voxel>New Voxel>Inverse Distance Weighted Gridding). There is a knowledge base article that suggests using kriging (not sure why). Set X, Y and Z cells to the sizes from the main part of the mesh.
4) Trim the top using the topo grid used in the inversion (Voxel>Utilities>Voxel Topo Clip).
5) Trim the XY using a ply file and trim the Z with a reasonable depth value (based on looking at your original results (Voxel>Utilities>Window a Voxel)
** we need to trim the voxel because the gridding process has extrapolated values beyond our model and we don't want them included.
My question is how to deal with the vector components. I guess I could repeat steps 3, 4 and 5 on the U, V and W components and them using the Voxels to Vector Voxel conversion (but put in the correct declination). This should work but would take a while. Any ideas for faster options would be appreciated.
Sean
Tagged:
0
Comments
-
Hi @SeanWalker ,
There is indeed a much simpler way!
If you define a new Projected Coordinate system that is rotated as you wish (with X smaller than Y), then you don't have to worry about all the steps you've described above.
Once the coordinate system is defined, you can create your VOXI project. The models, the predicted response database, and everything else will then have this coordinate system. And since it's defined relative to the real world (lat/long), Oasis montaj can handle all the reprojection on the fly. This means you can view your voxels, grids, etc. alongside other data without having to rotate back.
This also means that you don't have to tinker with the IGRF settings - as it will all be handled using the rotated coordinate system within Oasis montaj.
You can find steps to creating the new projected system here: https://my.geosoft.com/supportcentre#/kb/kA330000000VitmCAC
Also, VOXI for DCIP and FDEM currently supports built in rotation (when you create your VOXI from Polygon). We may, in the future, add this feature for other VOXI projects as well.Customer Success Manager - Geophysical Modelling0 -
Thanks @TaronishPithawala
The solution you describe works well as long as your voxel stays inside the Oasis Montaj system. Unfortunately most of my clients work in other GIS type environments or want voxels in other formats (UBC-GIF). While Oasis can make sure that the Voxel ends up in the correct location and orientation I would be concerned about having my deliverable to a client in a strange one-off projection that could be mis-located and rendered basically useless. Coming across old data in "Mine Grid" coordinates is always painful so I just have a gut reaction against storing results in a made up projections. Sadly these models can sit on hard drives and servers for quite a while and the person who eventually opens it may not know how to recover the correct projection.
While the workflow I describe is clunky and slow it does result in a voxel with a "real" projection.
Adding the built in rotation to the mag and gravity inversion would be great!
Sean0 -
Hi @SeanWalker
With the method I described, you could simply reproject the result back to the original projection before archiving.Customer Success Manager - Geophysical Modelling0 -
0
-
Hi @TaronishPithawala
The method is quite nice but the voxel re-projection step at the end is the one that causes me problems. Unlike grid re-projection where the data is regridded back onto a regular XY grid the Voxel re-projection rotates and translates the voxel. Therefore the voxels do not lie on a regular XY grid. Therefore when you try to export to UBC-GIF format you get this message.
A while back (before I paid for VOXI) I used to rotate my data to fit it into 50x50 grids and I found that the rotated voxels also failed to open correctly in Mapinfo discover (it ignored the rotation parameter). This was why I moved to the voxel to GDB to voxel method.
But thinking about this has helped me come up with a quicker way to do the re-projection using voxel math.
1) Create a voxi project with the un rotated ply file and dem.
2) Export the mesh as a voxel.
Use Voxel math
V0 = V1*0 + V2;
V0 = final_voxel_model
V1 = mesh_voxel
V2 = reprojected_voxel_model
This works with Vector Voxels as long as you convert V1 to a vector voxel. The GUI for reprojecting Vector Voxels will not let you select a vector voxel from the file manager window. However if you change the file type to geosoft_vectorvoxel it works. Then you can calc the X, Y, Z and Ampl voxels.
It appears to work and will save me quite a bit of time.
Thanks for the info.
Sean
0 -
Thanks Sean - this has long caused me problems too so I appreciate you solution. The first thing I have to do with any model is get it out of Geosoft for use by others (in Leapfrog, Analyst, or Gocad, in particular) so rotations don't work.
I assume your proposed approach requires that the coordinate transformation is purely a rotation around the center of the model without translation? If so, I'd be keen to learn how to get that right every time. I always struggle setting up local projections: it always seem way more tedious than it needs to be.0 -
Hi Nick, The article about local projections that Taronish started with is the procedure I used. It is a rotation and translation. The only thing I don't like about it is that you end with a whole bunch of Local grid transformations clogging up your projection lists. I do like that the local coord system appears to take care of the declination issue.
Sean0 -
Thanks @SeanWalker, I finally got to test your method and it works well.0
This discussion has been closed.