Hi, All!

I'm new to both Manifold 9 and this forum, and also technologically illiterate, so please forgive me lol anyway, I come here as a QGIS user performing various tasks, and for nearly everything I need to do, it's quite sufficient. However, one task that my needs are now exceeding its operational efficiency on is interpolating large datasets of z-values based on lat/lon points, which, through research, has led me to Manifold 9. Before purchasing, I wanted to try it out on Viewer. After many trials, much time spent into checking/re-checking/adjusting settings of my GPU (NVIDIA GeForce GTX 1060 6GB), and consternation, it seems that Manifold 9 Viewer is clearly optimizing my CPU cores, but is not touching my GPU at all even though it seems to be working fine otherwise, and is resulting in calculation times that are significantly longer than what I would expect (anywhere from 1-5 HOURS) given the available information on how Manifold 9 operates. When I set up my parameters for the interpolation, I have the "all CPU cores, all GPU cores" option selected, and in the Help - About window, it is recognizing that my graphics card is there.

To be fair, the observed performance on this task is still lightyears better than what QGIS can give, as often times the process takes 10, 20, even 30 hours depending on the exact dataset, but still, I can't help but think that something isn't right. I know forums are often times a fantastic resource, so before I contacted the company seeking advice, I was wondering if anybody here might be able to help guide me as to what to look for and/or reconfigure/adjust?

Thank you so much for your time and any insight that you all can provide!

It used to be that specific CUDA enabled nvidia drivers were needed. I would have thought that it is all integrated these days, however your GPU is old enough that maybe that needs to be checked. I just checked my Viewer and the correct CUDA settings are detected (older than yours) Good Luck.

Thanks so much for your response! How can I tell which CUDA drivers are needed against those that are currently active on my machine? Or, maybe phrased another way, what should my settings look like for either my graphics card and/or Viewer? Like I said, I’m technologically challenged, so the more detail, the better, but appreciate any and all insight haha

In your system tray, there should be an Nvidia icon. Right clicking on it would bring up a small window with Nvidia Control Panel & possibly Nvidia GeForce Experience options. Click on the Control Panel.

An app should then open. In the lower left corner of this app is an icon labeled System Information. Click this.

In here will be two tabs. In the first one "Display" on the left side will have listed at least one GPU listed as "Items" Are there more than one listed? if you click on the GPU listing there, then check the reported settings on the right, there should be an entry for "CUDA Cores". Are there any numbers reported? If you then click on the second tab labeled "Components" there should be a list of drivers loaded. Under "3D Settings" there should be an entry for NVCUDA.DLL, then file version, and Driver description. Is that there?

Only GPU listed is the NVIDIA card. 1,280 CUDA cores. And then it looks like I have the driver you’re talking about…

Attachments:
IMG_3033.jpeg

Well, when all else fails, sometimes the user manual has a few useful tips.

In this case, that would be the GPGPU topic, in the Getting Started section, which is packed with helpful advice, like how to tell if you have a GPU installed and recognized.

If you follow the tips in that topic, in the "Is a GPU Installed?" section, does your installation report a GPU in the Help - About dialog? What is reported by

? CALL SystemGpgpus()

If the system reports a GPU, you have one installed and Manifold recognizes it.

Other things to check, of course, are in the "64-bit Windows Required" section. Are you running 64-bit Windows? What version of Windows? What version of Viewer are you running?

If all that checks out, we get to...

it seems that Manifold 9 Viewer is clearly optimizing my CPU cores, but is not touching my GPU at all even though it seems to be working fine otherwise, and is resulting in calculation times that are significantly longer than what I would expect (anywhere from 1-5 HOURS) given the available information on how Manifold 9 operates.

Well, if you're not familiar with Manifold, you might not be realistic in your expectations what GPU can do and where it is completely useless. The GPGPU topic has some tips, like in the "Notes" Section with stuff like...

Does GPU parallelism speed up everything?- No. It only speeds up computational tasks that are big enough to be worth dispatching to the GPU. It does nothing at all for tasks that involve no computation.

For example, GPU can't speed up tasks that involve virtually no computation but are disk bound. The system isn't going to waste time dispatching a task to GPU if it can be done faster in CPU. The topic discusses some of that.

For that matter, if a task involves computation but is still disk bound, GPU also won't help.

Suppose, for example, you want to do some operations on a very large raster that is in a many gigabytes file you link into your project, but the actual data is stored in a different computer that you can only reach across a corporate network that is slower than a carrier pigeon. Well, it doesn't matter that the GPU can do the calculations blindingly fast if it takes hours to get the data over the slow network. The job will still take hours because most of the time the system will be doing nothing but waiting for bytes to dribble in across the slow network.

The user manual has other topics with suggestions to deal with such stuff, like the Performance Tips topic in the Basics chapter.

If you describe exactly the software you're using, the details of the data you're using (and how you use it in Viewer), and what you want to accomplish, that will let folks in this forum offer some more specific advice.

Hi, and thanks for your added input! I've read through that GPGPU topic a couple of times, and everything seems to check out until I get toward the end, but I'll answer your questions in succession for good order.

1. If you follow the tips in that topic, in the "Is a GPU Installed?" section, does your installation report a GPU in the Help - Aboutdialog?

See the attached image "Help - About".

2. What is reported by "? CALLSystemGpgpus()"?

See the attached image "Call function in Manifold 9".

3. Are you running 64-bit Windows? What version of Windows? What version of Viewer are you running?

64-bit Windows 10. Manifold Viewer 9.0.181, 64-bit.

The data files that I am using are all stored locally on my machine, and are all several-MB-sized CSV files containing simple point data (latitude, longitude, and snowfall, in this case, but could be any other variable). I have attached one as a sample for reference ("Jan. 10th Contours"). I am trying to use Manifold to expedite the process of interpolating the snowfall values in this file (and others) to create a raster with a resolution of 0.01°. As I said before, QGIS can do it, but it's not operationally useful, and Manifold is already multiple times faster with the parallelized CPU, but since this is a computationally heavy task, I feel that I should be getting more out of it. I know and understand the process of adding schema and a new Geom field with lat/lon coordinate system, as well as Composing the lat/lon point data. I am also still ok with setting up the interpolation process within Manifold. But my suspicion that something isn't right is raised in the last image file attached ("Task Manager GPU").

I noticed in an earlier reading of the GPGPU topic page that the example of the Task Manager display includes monitors/graphs for "CUDA" and "Compute", neither of which I seem to have in mine, even though my GPU clearly has CUDA capability. This is what seems to be the issue, in my opinion, that my GPU is somehow not set for computations, but graphics processing only, and I cannot for the life of me figure out how to change it. I've been into the NVIDIA App, the NVIDIA Control Panel, even regular computer graphics settings, and I cannot figure out how to activate those components.

Again, I appreciate all of your support and guidance, and if you or anybody else needs any further clarification, please ask!

Attachments:
Call function in Manifold 9.png
Help - About.png
Jan. 10th Contours.csv
Task Manager GPU.png

Thanks for the info.

As the GPGPU topic states and as the images you've posted prove, your GPU is indeed set up with CUDA and Manifold is indeed recognizing it. (help about, and call function screenshots). So don't waste any time thinking the GPU isn't ready to do parallel work.

You write

The data files that I am using are all stored locally on my machine,

but you don't mention exactly how you're using the data you get from the CSV file, for example, whether you're importing it or linking.

Leaving the data stored in the CSV instead of importing it into Manifold is a guarantee of wretched performance. (See the Performance Tips topic... full of useful advice). It's not clear exactly (I don't take anything for granted) what you're doing when you write

I know and understand the process of adding schema and a new Geom field with lat/lon coordinate system, as well as Composing the lat/lon point data.

I assume you've created a drawing, in which case you shouldn't be talking about CSV because that's not what you're using any more. You're using a Manifold drawing. It could be you're still working with a table that you imported from the CSV. I don't think that's an issue but, like I said, it doesn't pay to take anything for granted when debugging something done by someone just getting used to the system.

You also don't mention exactly how you're interpolating, and all the settings that you're using, or the exact results of the interpolation.

It looks like you're making some incorrect assumptions, for example,

since this is a computationally heavy task

No. Interpolation is pretty trivial arithmetic. Some forms involve slightly more computation but it's not demanding math. Usually where it blows up in terms of taking long is when people tell the system to do something truly enormous, by specifying unnecessary, unrealistically large options and so forth. For example, if you tell the system to create an interpolated raster that ends up being 200 GB in size when given the resolution of your starting data a mere 200 MB would already be overkill, it will faithfully follow your orders.

My guess is you're at risk of doing some of that inadvertently because you've already stated you're ignoring the advice in the interpolation topic for the Transform pane:

To keep units straight, it is best to do interpolations using drawings that have been projected into linear coordinate systems, and not radial coordinate systems like Latitude / Longitude.

But you've said you want a resolution of 0.01°, so you're still using a radial coordinate system. That can still be done, of course, but there's more opportunities for error doing it that way (hence the advice in the user manual to use a linear coordinate system... takes but a second to arrange).

The above are just guesses. To help you debug your process we have to know every detail of exactly what you're doing (the exact nature of the data in your project ) and how you're doing it (all settings for how you're interpolating, whether you're using the transform pane, whether you're using some query you've written or a script, etc.)

Regarding:

I noticed in an earlier reading of the GPGPU topic page that the example of the Task Manager display includes monitors/graphs for "CUDA" and "Compute", neither of which I seem to have in mine, even though my GPU clearly has CUDA capability. This is what seems to be the issue, in my opinion, that my GPU is somehow not set for computations, but graphics processing only, and I cannot for the life of me figure out how to change it.

Thinking that the GPU isn't configured for computations because the Task Manager performance display on your computer doesn't show a Compute display is leaping to the wrong conclusion. (It also indicates the GPGPU topic might have just been skimmed and not actually read.)

The Manifold user manual doesn't normally duplicate Windows documentation to explain how to operate standard Windows dialogs, but in this case it explicitly talks about what you mentioned in the GPGPU topic, in the section headed Windows Task Manager and GPGPU. That has useful illustrations and comments such as...

Windows Task Manager's Performance tab may not report actual GPGPU utilization using default settings.

[... illustrations, text, etc. ...]

If we switch to the GPU report, depending on how we have the GPU displays configured we may not see any GPU usage. GPUs have many uses, and the Task Manager displays might be configured to show specialized functions such as 3D, or Video Decode, and not GPGPU parallel computation. Generally, we have to choose Compute_0, Compute_1, or Cuda in the pull down lists to get a display of GPGPU function.

[...illustration, text...]

In the illustration above choosing Cuda in the upper display shows 100% utilization of the GPU, all 1280 CUDA cores in the GTX 1060 GPU working at full saturation to perform the computation. [...] Note, however, that despite the GPU being used 100% with all cores running 100%, the readout in the lower left corner of the display still shows 0% GPU. If that is all we look at, we might wrongly conclude the GPU is not being utilized.

Task Manager has a lot of capabilities, so it pays to get familiar with it. If anything in the above is unclear, search for information on Task Manager on the web and you'll find other discussions of it that you may find more useful, like:

By default, the Task Manager has enough room to display only four different graphs. However, if you want to change one of them and monitor some other feature, you can click or tap on the small arrow button on the top-left corner of a graph and select what to watch. You can choose from things like Video Processing, Legacy Overlay, Security, Cuda, VR, and so on, depending on the actual features offered by that video card.

That's from this site. That site is for Windows 8 but it's the same for 10 and 11.

The resolution of Task Manager is pretty poor when it comes to GPU. If the application is mostly disk bound with only quick use of GPU every now and then, Task Manager can miss that. It could also be that Manifold's optimizer realized that it's quicker to execute on CPU cores instead of dispatching to GPU for a trivial computation.

There are other possible issues discussed in the GPGPU topic that should not be overlooked. For example, there's the discussion in the Windows and GPGPU section. If you unknowingly command an unnecessarily large operation and you're using the same GPU for display and computation you could end up triggering the Windows system's bad habit of flushing GPU computation to make sure your GPU is fully available in case the mouse cursor moves a pixel and should be updated (just kidding about that, as even Windows 10 isn't that stupid...). That's usually not an issue but without knowing all details we can't say.

Regarding performance overall...

There are plenty of other hardware and software details that could matter, like those listed in the Performance Tips topic. Most cases of interpolation are disk bound, not compute bound, so it pays to look at what might affect performance given the usual interplay between things like random access and slower memory.

For example, people try working with large data, dozens of gigabytes in size, when they only have 8 GB of RAM in a machine. That's going to be slow. Or they do something else that guarantees Windows will be doing lots of paging but they have a really slow page store, have the max size of their Manifold process set too low, etc. To get into all that people have to know more about your setup and more about your data, like how big it is, how big the .map project is, etc.

Overall, my guess is what's going on is one or more factors:

1. Possible command to do unnecessarily detailed rasters. For example, if your data points are a kilometer apart it doesn't make sense to do an interpolation where the pixels are ten centimeters in size. That doesn't add precision.

2. Transform - interpolation settings that add busy work but don't really do anything given your data.

3. Unrealistic expectations thinking the task is compute intensive when in reality it's almost certainly disk bound.

4. Slow data store architecture, such as linking a CSV instead of importing into the .map file, insufficient memory for fast operation, slow page files, running the project or having tmp space on a USB stick or other dead-slow data store, etc.

5. Something else that causes slowness, like running a virtual Windows system on an old Linux laptop, overall slow processor or system, etc. The GPU isn't a miracle worker. It can help a lot in certain specific cases but if the overall system architecture includes one or more tourniquets it can't force blood to flow through a stone.

A 1060 was a fine GPU for parallel computations. But a 1060 is nine years old, a very old card that predates the modern shift to SSD on the motherboard and other essential performance enhancing system features. If you're running a 1060 it could be that the rest of your system isn't particularly super fast when it comes to disk bound tasks.

So, tell us a lot more details about your system, exactly what your project looks like, and exactly what you're doing by way of interpolation and we can drill further into what's going on.

It could be that making a simple change in 1. or 2. above could make your work go dramatically faster. Worth a look.

Hi, Dimitri, and thank you for your detailed response! I apologize in my delayed response, but it's been a busy couple days. Anyway, let me try to respond in kind.

In response to your first section:

-I am fully importing the data file into Manifold as a data source. Then, I am copying the data table from the data source and then pasting/adding it into the Project pane as a separate entity so that I can take further action.

-I am not creating a drawing, as the drawing itself has no inherent value to me in this part of the process. I am strictly working with and within the data table.

-As for the interpolation, I am trying to interpolate the snowfall (z-value) based on the latitude/longitude at a resolution of 0.01° to create a raster (see attached image, "Interpolation settings") utilizing the Interpolation function within the Transform Menu. The resulting raster is what I then want to use in additional work to be done in QGIS. And yes, I do understand that Viewer is read-only, but I want to see how efficient it/I can be given my current equipment before upgrading/purchasing Manifold.

-As for converting degrees to a linear coordinate system, the data set that I am interpolating is created in and based on a radial coordinate system, and in my entire workflow, it would require multiple conversions back and forth across several different programs/processes if I formally incorporate Manifold into it and use a linear coordinate system, which would be pretty annoying and is something that I would ultimately like to avoid.

In response to your second section about the Task Manager:

-I did read the whole page, but the point that I was trying to highlight with my earlier attachment "Task Manager GPU" is that nowhere in that display is there even an option for me to see activity by CUDA, compute, etc.. If you look closely, I have the list of options opened and none of them even exist. It's like the card itself is not realizing that it has such capabilities even though it says it does and Manifold recognizes that it does. Is that possible? Could the CUDA drivers be corrupted somehow? I know they exist because I checked that the other day and did a full driver re-installation...again, this is what's sparking my confusion.

-I do currently have the computer to use my NVIDIA card for graphics, but that's only because I changed it to be that way thinking that it might make a difference. I previously was using the dedicated internal GPU for display and there was no difference in performance from then to now, so I don't think that's an issue.

In response to your third section about possible sources of decreased performance:

1. Possible command to do unnecessarily detailed rasters. For example, if your data points are a kilometer apart it doesn't make sense to do an interpolation where the pixels are ten centimeters in size. That doesn't add precision.

My intention of interpolating to 0.01° is based on other steps that I need to take outside of Manifold, as they based on that resolution. I understand that there is no need to over-interpolate for the reasons you already mentioned, but having datasets based on the same resolution is optimal.

2. Transform - interpolation settings that add busy work but don't really do anything given your data.

This appears to be tied to "1", and I don't think its applicable. The menu settings are pretty straightforward and again, I am only trying to interpolate to the resolution I need, no more.

3. Unrealistic expectations thinking the task is compute intensive when in reality it's almost certainly disk bound.

This is certainly possible given what you stated above about interpolations not being overly computationally intensive, as I was not previously under that impression.

4. Slow data store architecture, such as linking a CSV instead of importing into the .map file, insufficient memory for fast operation, slow page files, running the project or having tmp space on a USB stick or other dead-slow data store, etc.

This was covered above. I am importing the CSV file as a data source, copying the data source table into the Project pane, and then working directly in that.

5. Something else that causes slowness, like running a virtual Windows system on an old Linux laptop, overall slow processor or system, etc. The GPU isn't a miracle worker. It can help a lot in certain specific cases but if the overall system architecture includes one or more tourniquets it can't force blood to flow through a stone.

I am working directly on my machine, no virtual interface, and have access to 16GB of RAM (see "System About" image attached).

I think that I have gotten to everything, but please feel free to ask for any additional details or clarification as needed. And again, your help is tremendously appreciated!

Attachments:
Interpolation settings.png
System About.png

As an addendum to my preceding post, I ended up being an idiot about not being able to see CUDA or Compute statistics in the Task Manager window, so please excuse my momentary lapse of reason there lol however, my overlying concern and confusion still remain.

I am currently running a test just to see if I was in fact missing the performance of the GPU because of my ineptitude, but please see the three attachments "CUDA", "Compute-0" and "Compute-1"; all of which are screenshots of the active interpolation (only set to 0.1° resolution instead of my desired 0.01°), and all of which indicate 0 activity from CUDA/parallelism. The same situation exists when I run the task at my desired 0.01° resolution, even though all six of my CPU cores are maxed out.

Attachments:
Compute-0.png
Compute-1.png
CUDA.png

I find that a good way to test the GPU is to run a Slope transform on a DEM, which I know from the documentation can use GPU. While Task Manager is "ok", the "Process Explorer" windows app, which is part of the very cool SysInternals Suite (https://learn.microsoft.com/en-us/sysinternals/downloads/microsoft-store), seems to more bluntly report GPU "use".

So, you can get excellent DEM tiffs from the ArcticDEM program (https://data.pgc.umn.edu/elev/dem/setsm/ArcticDEM/strips/latest/2m/)

In this screen capture I've performed a Slope transform on an imported ArcticDEM tiff, using a radius of 7. Big note here is that the GPU-processing functionality is not invoked on radii of "9 or greater", so be sure to test with 7 or something.

For this run, I am not writing the results of the Slope transform into a new field, nor into a new table component, I am only interested in the query output, so all processing "should" invoke GPU, and seems to, fwiw.

Attachments:
slope_rad7.png

(only set to 0.1° resolution instead of my desired 0.01°), and all of which indicate 0 activity from CUDA/parallelism. The same situation exists when I run the task at my desired 0.01° resolution, even though all six of my CPU cores are maxed out.

Don't waste time on what you've already excluded as a possible issue:

As the GPGPU topic states and as the images you've posted prove, your GPU is indeed set up with CUDA and Manifold is indeed recognizing it. (help about, and call function screenshots). So don't waste any time thinking the GPU isn't ready to do parallel work.

All that your experiment indicating zero activity indicates is that your system is either a) indeed choosing to execute on CPU cores because that's faster, or b) the occasional use of GPU in a process dominated by non-GPU work goes by so fast that Task Manager doesn't catch it, or c) both. That's also discussed in the GPGPU topic.

Note that would be especially true with 0.1 degree resolution given how natural neighbors works (read the wikipedia page on it that the Manifold documentation suggests) where it makes no sense at all to do all that busy work for very large numbers of points that are on top of each other given the resolution commanded. It's a classic case of lots of busy work that doesn't add any value to the result and which any sensible optimizer would not upload into GPU. My guess (just a guess) is that something similar would apply in the 0.01 degree resolution.

You can avoid such possible issues by following the step by step advice in my other post.

If for any reason you doubt what I advise and what the GPGPU topic says, there's nothing wrong with absolutely proving that the issue is not failure to recognize or operate the GPU. That can build confidence.

You can do that by trying what joebocop advises, or by duplicating specific examples, such as the ever-popular Example: Enhance Terrain with Curvatures- that topic also has links to example videos and other examples where GPGPU speeds up computation. You can download the USGS data for that example (the link in the example still works) and other examples and duplicate them.

Some notes...

Looking at your data, you have 111,440 points, with very, very many that are within 0.01 degree of each other, at least based on the screen shot you posted. So why are you using natural neighbors interpolation? That's an enormous amount of overhead for a case where masses of points are virtually on top of each other given the resolution you want.

What happens when you use different interpolations, such as triangulation or kriging?

You don't mention key parameters, such as the overall size (both in number of records, as well as geographic extent) of the data. That's one reason it is wise to first create a drawing (takes basically zero space and time) so you can see if you have any outliers. All you need is one or two points that are far outside the convex hull of all the rest and suddenly you're asking for 0.01 degree resolution of half the world.

4. Slow data store architecture,

[...]

This was covered above. I am importing the CSV file as a data source, copying the data source table into the Project pane, and then working directly in that.

No, that wasn't covered, because you don't say where the project is stored. For example, did you create the .map project file on a USB drive? You also don't mention where your TEMP file, is, etc.

Natural neighbors, by the way isn't mathematically difficult but it is very intensive in terms of hitting a lot of records and creating a lot of intermediate data, such as the Voronoi tiling. That means it hits memory, including possibly disk memory, a lot. It's a classic example of something that does well with manycore CPU because the simple math is fast on CPU while keeping all back and forth to system memory (or disk) on the high speed busses between CPU and main memory/disk is a benefit.

On resolution...

My intention of interpolating to 0.01° is based on other steps that I need to take outside of Manifold, as they based on that resolution. I understand that there is no need to over-interpolate for the reasons you already mentioned, but having datasets based on the same resolution is optimal.

You can always alter the resolution of the raster you create to match what your downstream tools require. Consider a thought experiment: suppose your starting data points are spaced a kilometer apart, but your downstream tools require ten centimeter resolution.

The wrong way to do that is to do an interpolation that specifies ten centimeter resolution. The right way to do that is to interpolate to kilometer spacing, and to then take the raster image that has kilometer pixels and make an image with ten centimeter pixels. That's faster because you don't waste time doing interpolations that are pointless.

While you're at it, it only takes a second to go back and forth from lat/lon to a sensible linear system. Please use a linear projection.

I suggest doing the following:

1. Create a drawing from the table. Takes but a second and zero extra space.

2. See where the drawing is (use it as a layer in a map over a layer like Bing or Google) and note the extents, taking care to check if there are any outlier points that could, and should, be safely removed.

3. Reproject the drawing from lat/lon into some sensible projection. If all of your data is local (somewhere northwest of Utica, NY, looks like...) there are plenty of great projections, like Lambert Azimuthal Equal Area Projection, Orthographic, or even Lambert Conformal Conic. Takes but a second.

4. Zoom into your drawing of points and use the Path tool to measure what looks like the average distance between points. There's usually no point in picking a resolution bigger or smaller than that if you want the "best" interpolation possible.

5. Using that resolution, try a couple of different interpolations, starting with triangulation and kriging. I bet it goes a lot faster than what you've been doing.

6. If you must export a raster in lat/lon projection, no problem. Re-project the image into lat/lon. Takes but a second.

7. If you must export a lat/lon in a certain pixel size, re-size your raster into that size using the merge command. There's a step by step example that shows how. Also takes but a second.

There are many examples that show one or more of the above steps. A useful example that has many of them is this one, where a raster image is interpolated from a NASA PDS (basically a table of points) data set.

Thank you joebocop and Dimitri - I am pressed for time at the moment, but may have a chance to sit down and try that slope transform exercise tonight after I get out of work. However, I would like to answer some of the additional questions from Dimitri.

Note that would be especially true with 0.1 degree resolution given how natural neighbors works (read the wikipedia page on it that the Manifold documentation suggests) where it makes no sense at all to do all that busy work for very large numbers of points that are on top of each other given the resolution commanded. It's a classic case of lots of busy work that doesn't add any value to the result and which any sensible optimizer would not upload into GPU. My guess (just a guess) is that something similar would apply in the 0.01 degree resolution.

The reason for the very large number of data points in very close proximity to one another is because I am effectively trying to extract numerical values from contours drawn on maps in non-GIS programs (like Microsoft Paint) and then re-create the images with geographic references so that I can take further action and do further analysis. Therefore, I am essentially tracing the original contours in QGIS by redrawing them manually, and then converting the lines to points so that I can then interpolate values between the contours. Now, I could use fewer points, I'm sure, but I have to have enough points along each contour so that when the interpolation is performed at the .01° resolution, the original contour remains in tact, so that's why there are so many.

If for any reason you doubt what I advise and what the GPGPU topic says, there's nothing wrong with absolutely proving that the issue is not failure to recognize or operate the GPU. That can build confidence.

You can do that by trying what joebocop advises, or by duplicating specific examples, such as the ever-popular Example: Enhance Terrain with Curvatures- that topic also has links to example videos and other examples where GPGPU speeds up computation. You can download the USGS data for that example (the link in the example still works) and other examples and duplicate them.

I'm not doubting you all, and I apologize if it's coming across that way. If anything, it's my lack of experience and understanding that is leading to all the questions and back and forth. I don't just like knowing the answers, I like to know the why behind the what. This is all a learning experience for me - everything that I know about GIS is self-taught; I have zero background in how to use software or any of that, or even how a lot of it works on a computational level (source coding, CPU versus GPU, etc.). What I have learned has been purely out of necessity, so I fully admit that I do not know much.....akin to a digital weekend warrior, and just enough to get myself into trouble aha

Looking at your data, you have 111,440 points, with very, very many that are within 0.01 degree of each other, at least based on the screen shot you posted. So why are you using natural neighbors interpolation? That's an enormous amount of overhead for a case where masses of points are virtually on top of each other given the resolution you want.

What happens when you use different interpolations, such as triangulation or kriging?

You don't mention key parameters, such as the overall size (both in number of records, as well as geographic extent) of the data. That's one reason it is wise to first create a drawing (takes basically zero space and time) so you can see if you have any outliers. All you need is one or two points that are far outside the convex hull of all the rest and suddenly you're asking for 0.01 degree resolution of half the world.

Natural neighbor interpolation provides the best and smoothest presentation of the data as opposed to the others, hands down. The geographic extent for now is a subsection of the northern Mid-Atlantic through north-central New England (see attached image "Geographic extent of data"). The location can and probably will change over time, but the general geographic extent would probably remain about the same. The number of records will vary depending on the original maps that I am working with, but I'd say between 100,000 and 500,000 (rough estimate, and depends on how many contours I am tracing and how big they are, and a subjective number of data points used during the conversion process from lines to points). I know there are no outliers because I am the one creating the initial point/CSV dataset lol

No, that wasn't covered, because you don't say where the project is stored. For example, did you create the .map project file on a USB drive? You also don't mention where your TEMP file, is, etc.

Everything that I am working with is saved on my local machine on the desktop. These preliminary test files were originally created on another machine, but I email them to myself and then download/save them directly to my desktop. Then, like I said, I import the CSV file as a data source within Manifold and work from there. So from that perspective, my understanding is that there shouldn't be any bottlenecking issues caused by a slow source.

Natural neighbors, by the way isn't mathematically difficult but it is very intensive in terms of hitting a lot of records and creating a lot of intermediate data, such as the Voronoi tiling. That means it hits memory, including possibly disk memory, a lot. It's a classic example of something that does well with manycore CPU because the simple math is fast on CPU while keeping all back and forth to system memory (or disk) on the high speed busses between CPU and main memory/disk is a benefit.

So, THIS seems to be more in line with what I am trying to get at - it seems that the interpolation function I am trying to perform may just be heavily dependent upon CPU rather than GPU. If that is the case, then that will have answered my question and given me a direction - I would simply need more processing power.....aka, an upgrade lol

You can always alter the resolution of the raster you create to match what your downstream tools require. Consider a thought experiment: suppose your starting data points are spaced a kilometer apart, but your downstream tools require ten centimeter resolution.

The wrong way to do that is to do an interpolation that specifies ten centimeter resolution. The right way to do that is to interpolate to kilometer spacing, and to then take the raster image that has kilometer pixels and make an image with ten centimeter pixels. That's faster because you don't waste time doing interpolations that are pointless.

I am going to respectfully disagree with this. If you do an interpolation at 1km resolution, your pixel will be 1km² . If all you do is re-project that down to a resolution of 1cm, you are still working with the same pixel value, just broken up into a smaller grid through additional resampling/interpolation, which can introduce unnecessary errors/values that are less accurate. That isn't what I need. I need each pixel to be on the same order of magnitude as my later data/processes with as few mathematical steps as possible to prevent incorrectly assigning pixel values to future data points that may vary fairly significantly (for my purposes) in the span of a 0.01° grid. This is akin to running a forecast model - the further out in time you project, the more your projections are based on previous projections rather than hard data, and are therefore significantly more prone to propagating error. So, why would I would project onto a coarser grid, and then re-project from there when I can just do it once and have better data integrity from the get-go? When it comes to this, accuracy is much more important than speed to me. So, if it turns out that I need to upgrade my system to increase the speed, then so be it. Again, this is all preliminary testing for me to see my system's current capabilities and operational effectiveness anyway.

1. Create a drawing from the table. Takes but a second and zero extra space.

2. See where the drawing is (use it as a layer in a map over a layer like Bing or Google) and note the extents, taking care to check if there are any outlier points that could, and should, be safely removed.

Again, see my attached image "Geographic extent of data". I know where it is and that there are no outliers, as I am the one creating the CSV file.

3. Reproject the drawing from lat/lon into some sensible projection. If all of your data is local (somewhere northwest of Utica, NY, looks like...) there are plenty of great projections, like Lambert Azimuthal Equal Area Projection, Orthographic, or even Lambert Conformal Conic. Takes but a second.

6. If you must export a raster in lat/lon projection, no problem. Re-project the image into lat/lon. Takes but a second.

I can try this later to see if it makes a difference, just about to log into work now lol

5. Using that resolution, try a couple of different interpolations, starting with triangulation and kriging. I bet it goes a lot faster than what you've been doing.

Absolutely faster, but nowhere near as smooth.

7. If you must export a lat/lon in a certain pixel size, re-size your raster into that size using the merge command. There's a step by step examplethat shows how. Also takes but a second.

Again, this could introduce unnecessary changes/errors to the pixel values that I am trying to avoid.

There are many examples that show one or more of the above steps. A useful example that has many of them is this one, where a raster image is interpolated from a NASA PDS (basically a table of points) data set.

I will have to check this out later.

Thank you again for your continued support with all of this, and like I said, I will probably test out the examples provided by both you and Joebocop. If you have any responses to me in the mean time, though, I am all ears....eyes lol

Attachments:
Geographic extent of data.png

Just for reference, in my above image you will see that some of the lines are not closed contours, they are just line segments - those are me adding in contours to represent local maxima values so that the interpolation can account of the intended upper-bound of the original map that I am tracing.

The correct way is to draw closed contours (remember, if it's not closed it's not a contour) that happen to be long, thin shapes that cover the local maxima regions.

OK, I think I see what's going on. The basic problem is you're trying to create data where you have no data, and even doing that you're not using GIS tools effectively.

Let's start with the Geographic extent of data.png image you attached. I take it what you are referring to are "contours" are what look like the fatter lines that have an orange dot in them. I assume those are just very many points and only the last one of them shows other than the black outline you used for the orange point symbol.

First, a contour isn't a contour unless it is a closed line that ends where it started. A single line is not a contour. Contours represent the boundaries of a region. Think of the region as a flat sheet of styrofoam. Cut out flat sheets of styrofoam with the boundary of each being the contour line and you can stack them up and get a terraced 3D presentation of your data, like terrain elevation data, snowfall or whatever. The value of your data is exactly the same at every location on a contour line, just like the value of your data is exactly the same at every location on the flat sheet of styrofoam cut out that boundary.

You can't add information by adding more dots to the boundary line. If you have a boundary line that's a straight line, like the long straight segment out in the Atlantic that roughly parallels Long Island, you can't make that any more accurate by replacing the straight line between two points with a zillion points.

Converting the very, very low resolution lines you have into zillions of points is just making a lot of work and kidding yourself. There is nothing, guaranteed, nothing you can add that's truthful using any statistical method by doing that manually. Just use the lines.

From those contour lines you can do interpolations, at least in Manifold and in any decent GIS (you'd think...). See the Example: Vector to Raster using Kriging topic for how.

Therefore, I am essentially tracing the original contours in QGIS by redrawing them manually, and then converting the lines to points so that I can then interpolate values between the contours. Now, I could use fewer points, I'm sure, but I have to have enough points along each contour so that when the interpolation is performed at the .01° resolution, the original contour remains in tact,

You gain nothing by converting the lines into zillions of points except make more work for the process for absolutely zero gain in "accuracy" or truth. Make contour lines (remember, they close) and use those.

the original contour remains in tact

I don't know what you mean by that. Performing an interpolation at any resolution doesn't add or remove information.

Natural neighbor interpolation provides the best and smoothest presentation of the data as opposed to the others, hands down.

Do you want to present the truth or do you want to create a presentation that tells lies?

If by "best" you mean telling the truth, no, the above quote is completely false. If telling the truth is what you mean by "best," the best you can do with the data you have is a presentation that has flat color in between the very gross and low resolution contours you have, like this:

Can you draw smooth color transitions instead of just filling the contours with flat colors? Sure. But that's fakery, not telling the truth.

For example, drawing interpolated gradients of color between the outermost contour out there in the Atlantic ocean and the big contour region over northern Pennsylvania and much of western New York State could sure produce smooth color variations over Maryland, Delaware, New Jersey, Long Island, Connecticut, Rhode Island, and Massachusetts, but all of that would be a lie, because you don't have any data in those regions. All that the data you have tells you is that the value of snowfall there is the value of the outer contour line. That's it. Anything else is fakery.

Now it's true that statistical math can provide some reason to believe that more closely spaced data can be interpolated with upper and lower bounds to likely values, giving interpolated values some credibility in regions where you have appropriately closely spaced real data. For example, if you interpolated in the thin strip paralleling the Great Lakes that might not be total lies. But not over the Atlantic coastal states.

I know there are no outliers because I am the one creating the initial point/CSV dataset lol

LOL indeed. Never assume you've never made any mistakes. Taking a moment to check you haven't is wise. The opposite isn't. Likewise, never assume that your data wasn't corrupted in some tiny way that can have a really big impact.

and then download/save them directly to my desktop.

That's a nuance that probably doesn't matter if you have just one SSD drive for your machine. But people have all sorts of disk architectures on their machines, and some of that stuff can be really slow. Where the project is created (a virtual project in the case of Viewer) can have impact if that's created on a slow disk, or USB drive. It's not the "source" it's where those 500,000 points are really stored. Even in a Manifold project they're stored somewhere on the machine.

If all you do is re-project that down to a resolution of 1cm, you are still working with the same pixel value, just broken up into a smaller grid through additional resampling/interpolation, which can introduce unnecessary errors/values that are less accurate.

No, that's not true. Take a big square of red color that's one meter by one meter and cut it up into a million squares that are one millimeter by one millimeter and all of them will have exactly the same red color. It's true you can lose data by resampling incompetently, so you'd want to make sure that the cell size you're using in a reprojected raster is also small.

I need each pixel to be on the same order of magnitude as my later data/processes with as few mathematical steps as possible to prevent incorrectly assigning pixel values to future data points that may vary fairly significantly (for my purposes) in the span of a 0.01° grid.

Well, in your case your data is so very low resolution there's zero chance that reprojection is going to lose data. Your data is very approximate, in many locations within the huge contour regions likely not "accurate" give or take a hundred miles. Using 0.01 degree resolution is pretending it's accurate to about a half mile, which is simply pure nonsense for the region illustrated using the contours shown in the attached .png.

The data you have is like taking a photograph of the Mona Lisa using a camera that has a resolution of 10 pixels by 10 pixels. What you get is a mosaic of square blobs. The process you're talking about is like saying, well, OK, let's take each one of those square blobs and divide it up into a thousand squares, and then I don't want to reproject those because if I do that the result won't look like the way Leonardo drew it. Well, that ship sailed when you took a picture using a 10 x 10 pixel camera. Subdividing grossly low resolution data into smaller pieces doesn't make it high resolution data.

The basic problem you have is your data is low resolution. Accept that. You can't add truthful data about snowfall in southern New Jersey that you don't have.

Absolutely faster, but nowhere near as smooth.

Of course not. That's because your data isn't smooth. If you want to tell the truth the best you can do is the image I've included above. If you want more detailed data that's truthful, with reasonably accurate smoothness, you need to have far, far more contour lines. In particular, if you want a presentation that's truthful and accurate to a half a mile, then you need to find snowfall data where the contour lines are packed only half a mile apart.

And then, by the way, probably the last interpolation method that would make sense to use would be natural neighbors. In what you're doing one reason natural neighbors is so slow is because you're using the wrong method for the very low resolution data you have. Interpolations don't make sense with data points that are so very far apart, especially for nonlinear phenomena like weather, so the natural neighbors process is chugging along doing a vast amount of pointless work.

If you really want to create a presentation that tells lies about your data with fake smoothness, try just creating contour lines using the relatively few points you used to create those in your illustration, and do natural neighbors from those lines. I don't know how good or bad that would be, but it would be an interesting experiment. Fake, of course, but interesting.

Attachments:
snow_contours.png

Thanks again, Dimitri (and joebocop too)!

For the record, I did run a quick test using the aforementioned Crater Lake Lidar data and the Slope function, and it did fully engage both my CPU AND GPU (see attached image "Test"). So, it looks like I have the answer to my original question - it is not an issue with my GPU or the link between Manifold and my GPU at all, it's just that the operation that I am trying to perform is being assessed by Manifold to be better off running via the CPU cores only, hat tip Dimitri. The only way to increase the performance of my current algorithm, verbatim, is to upgrade my machine.

To follow my above statement, though, and Dimitri, this is directed at you (respectfully), if you would like to continue this discussion, we certainly can, though I would ask if we could somehow take it to a more private platform so that I could more fully explain why I am doing what I am and respond more acutely to the points that you brought up above. I would just rather not have an open discourse about the whole thing lol If not, that's cool too, and again, I want to sincerely thank you all for your input and guidance! If I ever have any additional questions, I definitely know where I'll come for answers haha

Attachments:
Test.png

it did fully engage both my CPU AND GPU (see attached image "Test").

Thanks for posting the Test.png image. That's one to save... not often do you see 100% use of all CPU cores and also 99% use of 1280 GPU cores. :-) It's very hard to keep many GPU cores busy, so that's a classic example of how CPU parallelism can be used to drive massively parallel GPU computation.

Regarding why you are taking the path you are, I admit to being curious but, alas, I don't have time to contribute beyond participating in this forum. Here everybody can discuss and learn together instead of just one person.

My only advice would be to avoid making assumptions that box you into horrifically inefficient workflows.

As the Performance Tips topic famously puts it in the section captioned "The User,"...

The user is almost always the key factor in performance. The greatest gains in performance are usually achieved by using smarter, more skilled workflow, not by throwing money at faster hardware. More often than not the sole factor in whether a better method is used is the expertise and clarity of mind that can be mustered by the user. A healthy, well-rested, expert user is the best performance accelerator around.

Don't throw money at faster hardware. Besides burning money, throwing money instead of skill at a problem usually ends up getting far, far less improvement than a simple change to a better method can accomplish for free.

I don't know why you are doing what you're doing the way you are doing it, but it seems to me so wildly wrong that there has to be some sort of mistaken assumption that is denying you the ability to use much better approaches.

I couldn't resist seeing how fast the workflow goes if you follow my advice and interpolate directly from contour lines. So I tried it. It's instantaneous. Here's what I did... (click the images below for a full-sized view) ...

1. Georeference the hand drawn image to a map:

...I used Bing as a base map layer. Georeferencing is very fast, took about four minutes using 15 control points mostly at the boundaries of state borders. The display above uses 50% opacity for the georegistered layer, so you can see how well it georegistered even with very quick, sloppy clicking of control points.

Here are the control points I used, if anybody is interested:

2. Draw contour lines in a new contour lines layer:

... also very fast, since the contour lines are just a few inflection points each. I used contour line values of 10, 100, and 200 since I didn't know what your contour lines were supposed to represent. Since the image posted by the OP cut off the top of the map I just drew in closed lines in the far north.

3. This shows just the contour lines layer:

... I styled them using the same colors as in the hand drawn image (use the color picker for single click matching of colors).

4. Use Transform - Trace to create a layer of contour areas:

... I likewise styled those to the same color. This is the truthful presentation that shows the data that you have with no added fakery. This and subsequent use 80% opacity in the layer so you can see the Bing reference layer underneath.

5. Using the contour lines layer, use Transform - Interpolate with natural neighbors and resolution of 10000 (10 km) to create a raster image. Took less than a second:

... I styled the image with three breaks at 10, 100, and 200, using the same colors as the original hand drawn map and interpolation between colors.

6. Using the contour lines layer, use Transform - Interpolate with triangulation and resolution of 10000 (10 km) to create a raster image. Took less than a second:

... I styled the image with three breaks at 10, 100, and 200, using the same colors as the original hand drawn map and interpolation between colors.

7. Just for the heck of it, using the contour lines layer, use Transform - Interpolate withnatural neighborsand resolution of 1000 (1 km) to create a raster image. That's the rough equivalent of using 0.01 degree at those latitudes. Took less than a second:

... I styled the image with three breaks at 10, 100, and 200, using the same colors as the original hand drawn map and interpolation between colors.

I also tried the natural neighbors interpolation from lines using a resolution of 500 meters, which is far more detailed than 0.01 degree, and that also took less than a second. That has no visible difference from using 1000 meters.

Note that only the presentation showing flat colored areas is truthful, in that it represents honestly the data from which it was created. None of the interpolations are truthful, because they're all interpolating from data that is too low resolution for what they claim to present. They're all candidates for inclusion in the famous book, "Lying with Maps." But they are pretty.

Timings:

natural neighbors at 10000 meters:

Transform: [contour lines] - [Geom] - Interpolate : natural neighbors (0.029 sec)

triangulation at 10000 meters:

Transform: [contour lines] - [Geom] - Interpolate : triangulation (0.011 sec)

natural neighbors at 1000 meters:

Transform: [contour lines] - [Geom] - Interpolate : natural neighbors (0.391 sec)

natural neighbors at 500 meters:

Transform: [contour lines] - [Geom] - Interpolate : natural neighbors (0.879 sec)

As you can see, using contour lines instead of zillions of points also creates a "smooth" presentation even at far greater resolution than 0.01 degree pixels, yet it takes less than a second. At about the same resolution as 0.01 degree pixels it takes less than half a second.

Even if you want to create a basically fake presentation, it does not make sense to use the approach you've been using.

Attachments:
snow01.png
snow02.png
snow03.png
snow04.png
snow05.png
snow06.png
snow07.png
snow08.png