Таки на чём писать модели?

С++.

что планируется моделировать? в зависимости от задачи надо и выбирать, на чём писать. C# имхо не лучший выбор, я взял бы или какой-нить ФП, или питон.

Не катит, т.к. людям как минимум нужен сборщик мусора.

Пистон - ацкий тормоз, а тут "тяжелое моделирование".

>Не катит, т.к. людям как минимум нужен сборщик мусора.

Обойдутся, просто наймите людей, которые умеют программировать на С++.

Тяжёлому моделированию - тяжёлый инструмент :) Но факт - тот же haskell легко порвёт его и по скорости работы, и по удобству и выразительности написания кода.

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

Пайтон не катит, т.к. медленно. С ФП все три человека толком дела не имели в прошлом, хотя почему бы не научиться? Что там есть интересного с биндингами к Qt?

А для чего, собственно, переписывать?

>очень тяжеловесное моделирование

>Переписывать её всё на том же C#, но в качестве фреймворка использоваться будет mono.

Учтите, что mono может в результате оказаться сильно медленнее дотнета вплоть до десятков и сотен раз.

Обойдутся, просто наймите людей, которые умеют программировать на С++.

Кафедра скорее оборудование для чего-нибудь купит, оно пока приоритетнее собственных инструментов моделирования.

>Что там есть интересного с биндингами к Qt?

AFAIR, ко всем распространённым языкам они есть. Хотя никто не мешает написать логику моделирования на фп, а графический фронтенд - на чём угодно.

> Но факт - тот же haskell легко порвёт его и по скорости работы, и по удобству и выразительности написания кода.

Это по сравнению с дотнетом?

Что нибудь типа краевых задач для уравнения теплопроводности в нецилиндрической неограниченной области? Такие штуки на фортране пишут, нахрена тут ФП? Поскольку в фортране писать для Qt х.з. как остается С++.

Хотя никто не мешает написать логику моделирования на фп, а графический фронтенд - на чём угодно.

Вообще сказать, да. Тут в интерфейсе только входные данные задаются + пауза в моделировании есть (чтобы можно было изменить некоторые параметра прямо во время просчёта/визуализации) + область, где в прямом эфире рисуется opengl'ная визуализация, так что на том же языке, что и модель, делать это не надо.

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

> Тепло- и массоперенос в массиве грунта (с мерзлотой).

Нахрена тут сборка мусора?!

Тут тепло — самое простое, что есть. Самое главное — массоперенос воды (льда, пара), гораздо комплекснее. Плюс механика. Прослои льда (шлиры) растут, бугры пучения. Химия (состав грунта, состав раствора) учитывается.

Ты бы знал, сколько тут всего учитывать надо :)

>Тепло- и массоперенос в массиве грунта (с мерзлотой). Там очень много математики, операции проходят с несколькими огромными массивами, в общем нужно дофига памяти и процессорного времени.

Вообще, Саныч прав. Для матричных рассчётов ФП не очень катит, это я не зная подробностей взялся агитировать :) Берите C++ со смарт-пойнтерами или какой-нить реализацией сборщика мусора, если руками памятью управлять лень (хотя если массивы действительно очень большие (настолько, что все не будут одновременно помещаться в ОЗУ), упрётесь в необходимость вручную управлять своппингом их на диск).

но, таки, сборка мусора тут ни при чём.

ну, если так уж страшно, то std::auto_ptr тебе в руки и std::vector в жопу :)

на С++, короче, писать надо.

питон, те места где требуется высокое быстродействие сделайте на C.
опять же к питону полно либ для ресурсоемких вычислений.

Первое, что пришло в голову: D

> Такие штуки на фортране пишут, нахрена тут ФП?

УБИВАТЬ-УБИВАТЬ-УБИВАТЬ! За фортран сразу яйца к потолку гвоздями.

> Пайтон не катит, т.к. медленно.

Попробуйте тесты погонять на каком-нибудь SciPy.

Следовать заветам и разделить на две части сервер для вычислений <==протокол==> гуй

> Следовать заветам и разделить на две части сервер для вычислений <==протокол==> гуй

Первый разумный совет... И тогда не так важно, на чем GUI писать, да и для вычислений выбор остается.

JAVA

>Не катит, т.к. людям как минимум нужен сборщик мусора.
Оберон

>Тепло- и массоперенос в массиве грунта (с мерзлотой).

Ититтттвою!!!!!!! Когда проектировали БАМ на фортране моделирование было написано! Сделал сотни расчетов для мостов. Дописывал кусочек для холодильных установок Гапеева. FORTRAN IV жуткая жуть!!!!!!!!!

>Там очень много математики, операции проходят с несколькими огромными массивами, в общем нужно дофига памяти и процессорного времени. Само моделирование идёт очень долго.

В конечных разностях делаете? Ню-ню... Как говорится, флаг в руки.
ЗЫ. Было сделано ГАРАААААААААААААААЗДО проще. Ну и по опыту, за 50 лет мерзлота стабилизировалась.

>Ты бы знал, сколько тут всего учитывать надо :)

Ловите блох. Растительность на поверхности (величина среднепотолочная) оказывает СУМАШЕДШЕЕ влияние на результаты. А так же ориентация к горизонту, наклон поверхности, отражающая способность, ветер...

Ууууууууууууууу........ страшно вспомнить.

> Следовать заветам и разделить на две части сервер для вычислений <==протокол==> гуй

Гуй вообще выкинуть. Сделать интерфейс командой строки.

> Ловите блох. Растительность на поверхности (величина среднепотолочная) оказывает СУМАШЕДШЕЕ влияние на результаты. А так же ориентация к горизонту, наклон поверхности, отражающая способность, ветер...

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

> В конечных разностях делаете? Ню-ню... Как говорится, флаг в руки.

Как оно сейчас считается — не знаю, пока что не смотрел. Знаю только, что в самой модели используются дифференциальные уравнения миграции влаги, миграции ионов, количества незамёрзшей воды в зависимости от температуры и мильёна других параметров и прочее.

Самым главным отличием от предыдущих проектов (от «Тепла», например), помимо гораздо бОльшего числа учитывающихся параметров, бОльшей точности и удобной визуализации, является динамический размер ячеек — т.е. теперь грунт может набухать, распучиваться, может идти осадка...

> Ну и по опыту, за 50 лет мерзлота стабилизировалась.

Чего?

Так что ты имел в виду по фразой про 50 лет?

Гуй вообще выкинуть. Сделать интерфейс командой строки.

+1

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