Неструктурированные сетки имеют свое место.
Возможно, вы захотите взглянуть на структуру моделирования системы Земли (ESMF). У них есть некоторый код для повторного создания сетки - специально для этой цели - и они также сделали некоторые изящные вещи с параллельным кодом. Вся система предназначена для объединения моделей, поэтому там могут быть и другие полезные вещи.
Некоторые другие заметки:
«нет способа сделать это эффективно для любого значительного количества очков»
Что ж, эффективность - это относительная вещь: если у вас есть сетка в древовидной структуре, вы можете искать ее в O (logn), что может быть чертовски быстрым, хотя и не O (1), как поиск в регулярной сетке является.
Кроме того, похоже, что в то время как интерполяция должна выполняться на каждом временном шаге, если сетки не адаптируются, то отображение из одной сетки в другую остается постоянным. Таким образом, вы можете вычислить это отображение (то есть, какой элемент в каждой сетке соответствует какому элементу в другом) любым удобным способом, сохранить его, и тогда вам никогда не потребуется вычислять его снова (до тех пор, пока сетки не изменятся).
Таким образом, у вас остается код интерполяции, где вы захотите сбалансировать точность и производительность. Простая линейная интерполяция по треугольнику быстра и может быть достаточно хорошей.
«Я думал об использовании дерева kd для поиска ближайшего узла данной точки, тогда я использовал бы функции формы этого элемента»
помните, что ближайший узел не дает вам элемент - поэтому вы захотите сделать немного больше, чтобы найти нужный элемент. Один из вариантов - вместо этого использовать rtree, которое хранит / выполняет поиск с помощью ограничивающего прямоугольника - при каждом поиске вы получите более одного элемента, но затем вы можете проверить, какой из них является правильным.