|Target version:||Candidate for next minor release|
The CUBE Uncertainty pRopagated Variance Equation (CURVE) provides a gridded uncertainty estimate for sparse data gridding algorithms that often lack inherent uncertainty estimations.
#1 Updated by Samantha over 2 years ago
CURVE is an algorithm we have developed and would very much like to see about how to included it within GMT. We augmented CUBE's propagated variance equation to account for bottom slope and made it applicable to Sparse data. In our work, we couple this gridded uncertainty estimate with a gridded surface from GMT's Splines-In-Tension.
#3 Updated by Samantha over 2 years ago
#4 Updated by Paul over 2 years ago
- Status changed from New to Feedback
Sorry we have not responded. I'm workin on a proposal so little time. Some comments from the group suggest this could be used for any of the gridding routines in GMT and that while the CUBE part is generic the CURVE part is more specific to data such as bathy. As far as implementing this in GMT: If it is considered generic and not tied to a single gridding algorithm then it could be a new module, decoupled form the gridding function. As far as who should be doing this: Maybe you are in the best position. Given the GMT5 API and the GMT Custom project examples you could probably code this up from what you already have done into a GMT-like module. Our plates are pretty full at the moment so waiting for us to take the lead could take some time. Let me know. Alternatively, if ONR actually had funds to help with this implementation then it could be sped up as well, since reality is we work on funded stuff first.
#5 Updated by Joseph over 2 years ago
I agree we should make Sam do this All kidding aside, my side of the building could use this too, and since you (Samantha) are writing a paper on it, you are sort of the authority. My super quick glance at the paper suggests it would be pretty easy to code this as a GMT script using "grdmath"; IF you abandoned the TIN representation long enough to calculate a TPU grid, which could then be "re-TIN-ed".
I could help you with some of the tricks involved with grdmath and surface and such, but I don't have time to reinvent grdmath for data stored in a TIN...
#6 Updated by Samantha over 2 years ago
I am having quite some trouble trying to build and install the GMT-custom. On Windows, I was finally able to build but I cannot install due to not target definition for the make -j1 install command and missing gmt_dev, gmt_config.h...and others when building the VS. I've looked and have re-downloaded but nothing seems to be working. I've also tried on CentOS. Any ideas? --Thanks
#9 Updated by Paul over 2 years ago
To get GMT 5.2 you need to svn from the root, e.g.,
svn co svn://gmtserver.soest.hawaii.edu/gmt5 gmt5-dev
and then gmt5-dev will contain the three directories trunk (i.e., 5.1.3 at the moment), branches (which only contains 5.2.0) and tags (ignore this). You then cd into branches/5.2.0 and preform the same cmake setup and build there as you would normally do in the trunk.
#15 Updated by Samantha over 2 years ago
I copied the missing files into compat, replaced common_string.h and gmt_notposix.h from the trunk, and am using Windows SDK 7. Doing this gives redefinition and macro redefinition errors. I am performing cmake -G "NMake Makefiles" .. without problems followed by nmake which crashes.
#20 Updated by Samantha over 2 years ago
I think the problem is that I'm using vs 2010. Its include doesn't have these files but I added them. I was finally able to pick the errors out of the hay-stack:
-gmt_vector.c(426) error c3014: expected a for loop following OpenMp 'parallel for' directive. I moved the #define section immediately before the following for loop.
-gmtregress.c (1108) cannot convert double * to _Bool. I did a quick cast
k. The error now is TestBigEndian failure. no suitable type found.
#22 Updated by Samantha over 2 years ago
The TestBigEndian is failing when the debug settings in ConfigUser.cmake are commented back in.
I had to add GMT_BINDIR explicitly and
I added the following to cmake/modules/CreateDebugSym.cmake
- usefull macros
+ include (CustomHelperMacros)
In order to do the nmake I changed inline to _inline in customVersion.h
I added #include "gmt_synopsis.h" to gmtaverage.c and gmtmercmap.c and copied the file to src/
Does svn://gmtserver.soest.hawaii.edu/gmt-data work?
I changed set (CMAKE_SHARED_MODULE_SUFFIX .so) to set (CMAKE_SHARED_MODULE_SUFFIX .lib)
and pointed gmt.conf to it but I can't find it from gmt to run
.... and I am officially out of ideas... its so close I can taste it....
#24 Updated by Paul about 2 years ago
ON vacation until next week so cannot help but once I am back I could have a look. Are you able to build a tar/zip ball for me? Can it build under Unix? How about running things in debug in VS and step through and see why it does not go into your shared lib. Permission issues? Path not correct (the GMT_CUSTOM_LIBS setting must have full path to the actual name, i.e., C:\path\custom.dll.
#25 Updated by Samantha about 2 years ago
Thank you so much. I can create a .tar with 7zip. Do you want the whole directory for custom and 5.2? Unix stirs up a whole slew of new problems starting at the beginning. I use the entire path because if I don't I get an error message saying it cannot either open or find the dll, that's how I know it finds it... I just don't get the modules. Let me know how you would like me to send the tars. Thank you again!
#26 Updated by Paul about 2 years ago
I don't need 5.2, just your custom directory. Joaquim is offline but emailed me to tell you that "best is to put the dll in the same place as the supplements.dll
If it still doesn't work that's because of those two files I don't remember now (a .c and a .h) with module description that are not correct. " These are the two special files with "module" in their name that is created by running that script.