Greenspline error: Input data have 3 column(s) but at least 4 are needed

Dear all

I’m trying to interpolate a 2D surface. surface is working well, but now I’ve got some additional gradient constraints and gave greenspline a try. My call is

gmt greenspline depth.dat -Gout.grd -Agrad.dat+f1 -St0.25 -R-126/-122/43/50 -I0.1 -Z2

where depth.dat has the form latitude, longitude, depth, e.g.
-125.523 49.469 26.8897
-123.988 49.227 40.2961
-124.697 49.000 27.7391
-125.498 48.961 19.0781
-124.262 48.901 33.8943

and grad.dat has the form latitude, longitude, dip-direction, gradient (i.e. tan(dip)), e.g.:
-125.523 49.469 52.1 0.160174
-123.988 49.227 28.9 0.249328
-124.697 49.000 43.2 0.151236
-125.498 48.961 47.6 0.277325
-124.262 48.901 55.8 0.367928

I get the error message:
greenspline [ERROR]: Input data have 3 column(s) but at least 4 are needed

N.B.: I’m on gmt 6.4.0 and without the gradient file, it works just fine:
gmt greenspline depth.dat -Gout.grd -St0.25 -R-126/-122/43/50 -I0.1 -Z2

Does anyone have a clue about what’s going wrong here?

Unfortunately a porting bug. The fix will be approved soon I expect.

Thanks for looking into this swiftly, looking forward to getting it via conda. Would it be possible that the fix be included in a release before the end of the year?

We dont like to release something just before AGU so cannot promise 6.5.0 just yet. Fix now approved and merged into master.

1 Like

Just triggered a GMT dev build for conda-forge at Once that’s approved and merged, you should be able to get the bugfix by running

conda install -c conda-forge/label/dev gmt=6.5.0
1 Like

I actually need to

conda install -c conda-forge/label/dev gmt=6.5.0.dev2+b0c2f6d

Otherwise, I end up with 6.5.0.dev0:

$ gmt --version

Unfortunately the above command fails on my machine with:

UnsatisfiableError: The following specifications were found to be incompatible with each other:

Output in format: Requested package -> Available versions

Package libstdcxx-ng conflicts for:
gmt=6.5.0.dev2+b0c2f6d -> geos[version='>=3.11.0,<'] -> libstdcxx-ng[version='>=10.3.0|>=12|>=7.5.0|>=9.3.0']
conda-forge/linux-64::python==3.10.5=h582c2e5_0_cpython -> libffi[version='>=3.4.2,<3.5.0a0'] -> libstdcxx-ng[version='>=11.2.0|>=7.5.0']

Package libgcc-ng conflicts for:
gmt=6.5.0.dev2+b0c2f6d -> fftw[version='>=3.3.10,<4.0a0'] -> libgcc-ng[version='>=10.3.0|>=9.4.0|>=7.5.0|>=9.3.0|>=11.2.0']
gmt=6.5.0.dev2+b0c2f6d -> libgcc-ng[version='>=12']

Package libzlib conflicts for:
gmt=6.5.0.dev2+b0c2f6d -> hdf5[version='>=1.12.2,<'] -> libzlib[version='>=1.2.12,<1.3.0a0']
gmt=6.5.0.dev2+b0c2f6d -> libzlib[version='>=1.2.13,<1.3.0a0']

Package zlib conflicts for:
gmt=6.5.0.dev2+b0c2f6d -> libnetcdf[version='>=4.8.1,<'] -> zlib[version='>=1.2.12,<1.3.0a0']
gmt=6.5.0.dev2+b0c2f6d -> zlib[version='>=1.2.13,<1.3.0a0'

I see that you might not be able to fix this before the next point release, but still wanted to let you know. Perhaps I can come across some conda magic to fix this.

Hmm, those conflicts might be due to some other package in your existing conda environment. Usually I would end up deleting the entire conda environment and reinstalling the packages from scratch, but not sure if you want to go with that :slightly_smiling_face:

Note that we are currently dealing with some issues with GEOS 3.11.1 and GDAL 3.6.0 at, and that might help resolve some of the dependency conflicts, but it’ll take a few days to get ironed out.