• vox and vox_display classes
• Jupyter notebook example
• Fix TODO: cell size calculator in gxpy.vox is inconsistent with Geosoft.
• Pull VOX from master to 9.3.1 branch

There may be other scaling artifacts. This is caused by the 3D view not having a base view as a reference. See the sclmap.gx that helps people deal with this.

[‎11/‎6/‎2017 11:42 AM] Jacques Beaurain:
https://github.com/GeosoftInc/gxc/blob/master/examples/sclmap/sclmap.gxc
SetMapScale_MAP

Code:

import geosoft.gxpy.gx as gx
import geosoft.gxpy.voxset as gxvox
gx = gx.GXpy()
with gxvox.Voxset.new("test_new", dimension=(35, 50, 12), temp=True) as vox:
    print(vox.nx, vox.ny, vox.nz) # print to show we got here

@jbgeosoft

See commit 6ead822

Seems that an error may be raised but is being lost, or there is something seriously wrong in the API interface. I have run from command line with nosetests test_gdb.py, and in PyCharm and the behaviour is the same. It just stops/exits with no messages at all. GX close is never called, so Python is not exiting normally:

From PyCharm:

GX open
...........
Process finished with exit code 95867

From command line:

C:\Development\github\gxpy\geosoft\gxpy\tests>nosetests test_gdb.py
...........
C:\Development\github\gxpy\geosoft\gxpy\tests>

33991b0
Uncomment line 51 in test_vox_display.py and the test will fail unable to access the geosoft_voxel file. But the next line is fine, and it too access this file, so there is some kind of weirdness in packing the file.

See https://my.geosoft.com/forum#/discussion/1091/defragment

This is to support more power in jupyter notebooks.

• Coordinate with Geosoft CRG team (@hasnein) to catch the next build, expected to be 9.3.1.
• Remove if entitled tests in map.py and group.py
• Verify jupyter tutorial notebooks.

@natalie

Large array limits are currently untested.

In order to support vector voxels I need VV read/write support for GS_FLOAT2D, GS_FLOAT3D, GS_DOUBLE2D, GS_DOUBLE3D. These are missing from the current gxapi_cy_extend.pyx.

I modified the get_array_data_vv(), but we need to extend the GXVV.get_data_np()/set_data_np functions to accept a dimension argument for dimensions 2 and 3 as numpy does not have these vector dtypes.

see also gxpy.utility.gx_dtype_dimension() and dtype_gx_dimension(), which are the utility functions to translate between Geosoft and numpy types with the addition of dimension.

OM missing gxapi_cy.

The 3D view opens in a 3D viewer, but the Map viewer disappears so that when I close the 3D view the map view is gone. Perhaps as intended, but this did not seem natural to me as the 3D view was child of the parent 2D map view, but it became a peer in a singleton viewer experience.

@jbgeosoft see line 53 in tests\base.py. The current() method does not exist so this verification always passes.

added for 9.3 here: 0a737d7
and I cherry-picked them to 9.3.1, but perhaps I should not have.

GXAPIError: Unable to bind the "?Create_MAPL@@YAJPEAUh_gxx@@PEBD1PEBJ@Z" wrapper function. This might be due to a missing DLL or license, or you are running an application outside of Oasis montaj.

Tutorial example is not behaving as the test behave.

a4c64c8

at line 855 in group.py we call GXMVU.contour. For a 2D view the scaling of line detail (thickness, annotation height etc) is as expected. For 3D views the scale is wrong - to my eye it seems stuck at a scale of 1000, which is the default map scale when the "data" view is open. In a 3DV there is only one view, the "3D" view and this is the "data" view. Since the view is open calling GetMapScale will return 1000, which I suspect is the problem. Internally I think it should be getting the scale from the view. Just a thought.

See: https://my.geosoft.com/forum#/discussion/1048/standalone-python-script-to-read-gdb-to-numpy-array

Currently awaiting customer database to test on 9.3.

From Tom: I discovered that a couple of “GM-SYS” entries were replaced by “GM- GXSYS <geosoft.gxapi.GXSYS>” in this file, which I’ve corrected. This seems like it may be a derived file, so I am not sure whether these are the only changes to be made. The history of this file does not show when these changes were made.

see https://geosoft.vanillaforums.com/discussion/1030/not-able-to-create-a-gxvoxe#latest and http://confluence.geosoft.com/display/PM/9.3+licensing+review+for+GX+Developer+interoperability

• grids
• databases
• voxels

Messing with page sizes seems unpredictable.

• Process to install/verify/instantiate Python fro Geosoft Desktop.

gxapi.IMG_QUERY_rCOMPRESSION_RATIO should be gxapi.IMG_QUERY_COMPRESSION_RATIO. Note the 'r' before COMPRESSION. This is just one example of the problematic pattern in gxapi.

This improves python behaviour for in-line class instantiation

@jbgeosoft

In looking deeper into this there appear to be a number of problems handling dummies. This will need some careful review and expansion of test cases.

• fixed and verified in 9.4
• verified in 9.3.1 RC
• update known issues

Code:

import geosoft.gxpy.gx as gx
import geosoft.gxpy.vox as gxvox
import numpy as np
gx = gx.GXpy()
data = np.zeros(3 * 4 * 6).reshape((6, 4, 3))
with gxvox.Vox.new("test_new", data=data, temp=True) as vox:
    print(vox.nx, vox.ny, vox.nz) # print to show we got here

abort_930_126_2017_11_29_07_43_22.log

When Geosoft asserts during a test the program immediately stops, as expected, but the abort log is lost. The PyCharm behaviour does not help identify the source of the bug:

Process finished with exit code 95867

Replaces #41

From Tom: I discovered that a couple of “GM-SYS” entries were replaced by “GM- GXSYS <geosoft.gxapi.GXSYS>” in this file, which I’ve corrected. This seems like it may be a derived file, so I am not sure whether these are the only changes to be made. The history of this file does not show when these changes were made.

https://github.com/GeosoftInc/gxapi/commit/f6a75889ed1c3bda49cf46a819e03079709e51e7

https://github.com/GeosoftInc/gxapi/commit/e0885759def0733a773f3e7db98f0f999738ee71