You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am doing a review of the various non-file methods of passing grids into GMT, prompted by #3532. For input, here are the various methods and their status (from looking at the code):
GMT_IS_DUPLICATE: This means we are getting a GMT_GRID via memory and are asked to return a copy or subset of the input grid. It implements a subset (given w/e/s/n) as well. It treats the input grid as read-only since we allocate and return a new grid.
GMT_IS_REFERENCE: This part is confusing. You would think this is truly the read-only case but my comments [NOT SURE ABOUT THIS] are worrying... Anyway, what it does is to simply pass the input pointer back as the output pointer, i.e., reference (so not so crazy after all?). As for subsets it uses gmtlib_expand_headerpad to change the pad and header->wesn so that we do not touch the G->data array but we do modify the header (so not truly reference).
GMT_IS_DUPLICATE|GMT_VIA_MATRIX: This means our input is a GMT_MATRIX but we want to return a grid. A grid and header is allocated, header is filled out, and data is carefully transcribed from whatever data unit the matrix uses. There are no provision for selecting a subset (or warnings about it); this is what triggered Overhaul mechanism for passing data by duplication or reference #3532.
GMT_IS_REFERENCE|GMT_VIA_MATRIX: Similar, with the reassuring comment [NOT YET FULLY TESTED]. This differs in that we create a grid structure and header (we must, since input does not have it), but then proceed to set the G->data pointer to the M->data pointer. Here, we do test and insist that no subset is specified and that the matrix is float. Only then do we let this happen. We then set the pointer, and then there is commented-out code that would call gmtlib_expand_headerpad as in the other case.
The output methods are the same and seem to not be fully finalized either. But returning a matrix from, say, surface, should be OK since there is no provision in the module to limit a subset on output.
My task, should I accept it, is to implement the subsetting for the two last options. The first creates a grid so should be fine to only get the subset from the input matrix. The second seems similar to case 2 above but we would not violate any reference since the grid header is created by us anyway.
The text was updated successfully, but these errors were encountered:
* Enable matrix subset requests
See #3535 for context. This PR allows us to get a subset grid from an input matrix.
* Update gmt_api.c
* Update api.rst
* Call grdcut in external programs
* Api import grid matrix (#3538)
* Enable matrix subset requests
See #3535 for context. This PR allows us to get a subset grid from an input matrix.
* Update gmt_api.c
* Update api.rst
* Update gmt_api.c
* deal with reference case
* Finalize REF vs DUP
Co-authored-by: Paul Wessel <pwessel@hawaii.edu>
Description of the problem
I am doing a review of the various non-file methods of passing grids into GMT, prompted by #3532. For input, here are the various methods and their status (from looking at the code):
[NOT SURE ABOUT THIS]
are worrying... Anyway, what it does is to simply pass the input pointer back as the output pointer, i.e., reference (so not so crazy after all?). As for subsets it uses gmtlib_expand_headerpad to change the pad and header->wesn so that we do not touch the G->data array but we do modify the header (so not truly reference).[NOT YET FULLY TESTED]
. This differs in that we create a grid structure and header (we must, since input does not have it), but then proceed to set the G->data pointer to the M->data pointer. Here, we do test and insist that no subset is specified and that the matrix is float. Only then do we let this happen. We then set the pointer, and then there is commented-out code that would call gmtlib_expand_headerpad as in the other case.The output methods are the same and seem to not be fully finalized either. But returning a matrix from, say, surface, should be OK since there is no provision in the module to limit a subset on output.
My task, should I accept it, is to implement the subsetting for the two last options. The first creates a grid so should be fine to only get the subset from the input matrix. The second seems similar to case 2 above but we would not violate any reference since the grid header is created by us anyway.
The text was updated successfully, but these errors were encountered: