Начнём с конца:

2Lepsik
автормы подобное считаем в C++ STL матрицы порядка 10000x10000x10000

Матриц порядка 10000x10000x10000 в природе не существует, это размер вашей сетки (судя по тому, как Вы её описываете, структурированой, люди, работающие с неструктурированными сетками, обычно прост говорят сколько у них всего узлов). Поэтому порядок Вашей матрицы 10^12*(кол-во уравнений в узле), хотя она конечно хорошо разрежена. Чисто из личного любопытства - какие такие в STL есть приличные солверы для больших линейных систем с разреженными матрицами? Я там ничего такого не нашёл, хотя и не особо искал - бо это не STL задача - реализовывать LU или GMRES - разве что как как отдельные строительные блоки/кирпичики. А что за задача если не сикрет, прочность или МЖГ?

2f_w_p
авторМне кажется, что в СУБД можно хранить исходные данные для расчетов, а саму систему уравнений - нет смысла. Даже если она не помещается в ОЗУ.

Саму систему уравнений (точнее её конечно-разностное или конечно-элементное представление) не имеет смысла хранить нигде и никогда (даже в процессе решения, только матрицу - ессно если метод неявный, сетку и решение на стольких временных слоях, сколько требуется для адекватной аппроксимации временных производных - ну если они конечно присутствуют в Вашей задаче), ибо она не представляет абсолютно никакой ценности. Хранить надо численное решение Вашей начально-краевой задачи и сетку, на которой оно получено. Вот это последнее есть смысл обсуждать.

2nik_x
авторНасколько я разумею, что метод конечных разностей,
что метод граничных элементов в конечном счете используют
проходы шаблоном по элементам матрицы...
Интересно посмотреть, как это будет выглядеть, при использовании СУБД.
Особливо, если шаблон по вертикали/горизонтали имеет размер,
ну допустим элементов 9.
Традиционно, если матрица не помещается в озу, то ее хранят внешним файлом.
Обсчитывая только те элементы, кои находятся в окне прохода шаблона.

А вообще - полезный совет: пересмотри алгоритм расчета в пользу использования вариаций... Считать будет и точнее, и быстрее.

Извините, но это какая-то бессмысленная сборная солянка, причём местами употребление терминологии просто гротескно ("Проход шаблоном по матрице..."). Да и совет типа "пересмотри алгоритм расчета в пользу использования вариаций (конечный элемент?)... Считать будет и точнее, и быстрее..." не зная конкретной краевой задачи я бы давать не стал.

Собсно сабж. Вообще то СУБД и вычматы имеют мало общего. Да, некоторые команды вычислителей хранят результаты рассчётов в СУБД. Но тут надо понять одну вещь - такие результаты есть вещь довольно специфическая, обычно требуется их прогонять через графические редакторы или вычислять некие объемные/поверхностные интегральные(силы/моменты)/дифференциальные(потоки) характеристики. ИМХО - это удобнее делать если решение и сетка записаны в файл. Говорить же сколь-нибудь серьёзно о хотя бы косвенном применении СУБД в качестве солверов для решения реальных начально-краевых задач просто не приходится. Да Вы возьмите и попробуйте полностью самостоятельно численно решить простенькую задачу Коши для одного обыкновенного дифура. Получилось? Поздравляю. Теперь усложмите -возьмите краевую задачу с сингулярностью (пограничным слоем например). Справились? Молодец! Переходим к классическим задачам урматов. Жив курилка? Ну тогда берёмся за сингулярно вырожденные, некорректно поставленые (по Адамару) задачи. Вот здесь уже нирванна во всю. К чему это всё? А к тому, что у людей зашедших по этому пути достаточно далеко не возникает уже никакого желания использовать СУБД как-нибудь ещё кроме их прямого назначения.

2Lepsik

Глянул страничку. Почти соседи, однако (по меркам Канадских просторов). Правда понять какая у Вас конкретно физическая модель так и не смог, вроде просто транспорт (блин, ну не поверю что полный Навье-Стокс на 10^12 узлах да и ещё на полностью неявной схеме - это уже масштабы НАСА...). Но вот эта фраза:

авторНeкоторые люди используют наш продукт для моделирования электрических полей

вызывает смутное подозрение что это просто 3D Лаплас для топологически сложных областей. Тепло?