PDA

Показать полную графическую версию : Моделирование физических процессов


Страниц : [1] 2

nix_c
24-12-2012, 21:33
Добрый вечер! Я занимался разработкой компьютерных моделей физических процессов на языке программирования С++. Хочу создать Компьютерную модель катода (Н-р газоразрядной, люминесцентной или натриевой лампы). Предыдущие модели разрабатывал в MS VS2008 Express. Уровень программирования невысокий, опыта программирования мало. Так же по возможности хотелось бы провести параллельное программирование модели и для Unix подобных ОС (Linux в частности).
Может быть есть у кого опыт разработки подобных моделей? Буду рад выслушать ваши предложения. Заранее Спасибо!

Tau_0
24-12-2012, 22:05
Буду рад выслушать ваши предложения. »
Я бы простолте душевной на FORTRAN делал...

Главное --- Физику Всего ентова дела понимать. А кодирование --- последний этап *енря.

ЗЫ Я Физик, но таких спецкурсов не слушал...

nix_c
25-12-2012, 19:02
Главное --- Физику Всего ентова дела понимать. А кодирование --- последний этап *енря. »
Физика процессов пока изучена мало. В предыдущих моделях возникали сложности (н-р при портации кода с True Basic на С++). Также часто и в физике используется метод Монте Карло требующий достаточное большое число итераций. Поэтому хочется бы чтобы модель работала относительно быстро.

lxa85
26-12-2012, 00:10
nix_c, ой, слушай, найди меня как нить через день два. Я тебе под рюмку чая расскажу что да как :)

nix_c
26-12-2012, 00:59
nix_c, ой, слушай, найди меня как нить через день два. Я тебе под рюмку чая расскажу что да как »
ок)

nix_c
09-01-2013, 16:00
Подскажите какая реализация С++ подойдет для этой цели лучше всего?

XPEHOMETP
15-01-2013, 13:28
Вы поймите, конкретный язык программирования (или его реализация) - это вещи глубоко второстепенные. Главное - это понять суть физических процессов и суметь их описать на некотором языке программирования, адекватно отражающем протекающие физические процессы. Боюсь показаться профаном, но тут главное - не как программировать (и на чем), а что программировать. Если Вы понимаете суть процессов, то сможете адекватно их промоделировать на чем угодно. Фортран тут в теме всплывал не зря - это давний язык научных расчетов. На самом деле, он по сути не имеет особых преимуществ перед другими языками. Все то же самое можно записать на любом другом языке программирования. Любая реализация языка С++ годится, лишь бы Вы могли на этом варианте языка написать адекватную программу. Удобство написания программы в данное время (при достигнутом быстродействии компьютеров) играет гораздо большую роль, чем время ее фактического выполнения. Ибо писать ее вы в любом случае будете большее время, чем то, за которое она будет выполняться. Пишите на чем Вам удобно, это точно окупится.

Iska
15-01-2013, 15:34
На самом деле, он по сути не имеет особых преимуществ перед другими языками. »
Именно особые — имеет.

lxa85
15-01-2013, 16:03
Iska, XPEHOMETP, Кто имеет? Фортран? Фортран имеет особые преимущества. Но в целом я согласен с Вы поймите, конкретный язык программирования (или его реализация) - это вещи глубоко второстепенные. Главное - это понять суть физических процессов и суметь их описать на некотором языке программирования, адекватно отражающем протекающие физические процессы. »
Лишь поправлю: на языке математики, с вероятностным учетом физических событий. (Тут недавно был пример про принадлежность точки к окружности тут (http://forum.oszone.net/thread-249357.html))
Это раз.
Затем ищется язык программирования, достаточно удобный для описания найденной математики. Например готовые инструменты для расчетов потоков частиц.

nix_c
16-01-2013, 12:01
Пишите на чем Вам удобно, это точно окупится. »
Спасибо за совет. Буду писать на С++ , постараюсь каждый отдельный процесс запрограммировать в отдельном приложении. Буду делать множество приложений (скорее всего консольных). Один процесс одно приложение. А потом соединю все приложения в одно Windows form, установлю взаимосвязи между ними.
Для начала промоделирую процессы диффузии и адсорбции (с применением метода Монте-Карло).

Iska
16-01-2013, 14:31
Iska, XPEHOMETP, Кто имеет? …»
lxa85, всё верно.

постараюсь каждый отдельный процесс запрограммировать в отдельном приложении. Буду делать множество приложений (скорее всего консольных). Один процесс одно приложение. А потом соединю все приложения в одно Windows form, установлю взаимосвязи между ними. »
nix_c, напрасно.

XPEHOMETP
16-01-2013, 16:15
Фортран? Фортран имеет особые преимущества. »
Я согласен (я сам как бы на Фортране программы пишу для обработки данных эксперимента). В данном случае фортран ровно в том же положении, что и другие языки. Ибо конкретно тут важнее всего алгоритм, который нужно написать на некотором языке программирования, а на каком - это уже глубоко вторичный вопрос.

nix_c, напрасно. »
Может быть. Но - что именно напрасно? Консольные приложения для решения конкретных научных задач - это стандарт, можно сказать. Напрасно объединять их некой GUI-оболочкой? А почему бы и не сделать такое? Внешняя оболочка вряд ли затормозит реальные вычисления.

lxa85
16-01-2013, 16:46
Тут наверно надо рассмотреть архитектуру предлагаемой системы. Т.к. много-много консольных программ меня тоже смущают. Как отработка небольшого алгоритма - вполне. Каждый раз запускать ".exe" для выполнения маленькой задачи при большом расчете - вряд ли. Полезнее было бы их объединить в нечто среднего уровня. ИМХО

nix_c
16-01-2013, 19:24
Тут наверно надо рассмотреть архитектуру предлагаемой системы. Т.к. много-много консольных программ меня тоже смущают. Как отработка небольшого алгоритма - вполне. Каждый раз запускать ".exe" для выполнения маленькой задачи при большом расчете - вряд ли. Полезнее было бы их объединить в нечто среднего уровня. ИМХО »
Для отладки процесса моделирования будет создано "много .exe" файлов лишь для того чтобы было проще адаптировать каждый процесс, т.е каждую закономерность и не лазать по всему коду дабы не повредит что либо. Далее отладить их и уже потом обьеденить в один .EXE файл. ИМХО так будет лучше, но у меня нет подобного опыта программирования.

Iska
16-01-2013, 23:47
Но - что именно напрасно? »
Разбивать одну задачу моделирования на кучу процессов. Затем пытаться сводить их вместе.

nix_c
17-01-2013, 08:10
Разбивать одну задачу моделирования на кучу процессов. Затем пытаться сводить их вместе. »
Чем это чревато?

lxa85
17-01-2013, 11:03
nix_c, все зависит от уровня абстракции. Чем это чревато? »
Дополнительными накладными расходами на создание процессов.
Пример:
Сервер Apache. В Windows он работает как один процесс и множество нитей. Т.к. на платформе Windows создавать процесс -- "дорого".
В Linux Apache работает множеством процессов. Т.к. в Linux создание процесса -- "дешевая" операция.

XPEHOMETP
18-01-2013, 15:24
Разбивать одну задачу моделирования на кучу процессов. Затем пытаться сводить их вместе. »
Согласен. Разбивать полезно для отлаживания каждого процесса по отдельности, чтобы не влияли возможные ошибки в других процессах. Но: когда все окончательно доведено до ума, почему бы и не объединить в едином GUI? Чисто для удобства юзера. Лишний фантик, я понимаю, но, когда все уже заработало, почему бы и не навести красивостей?

nix_c
18-01-2013, 18:54
Скажите пожалуйста, может быть кто слышал от таких программах: MARLOWE, CRISTAL-TRIM, TRIM, TRIM.SP, TRIDYN, DYTRIRS, ACAT-DIFFUSE? Может есть у кого?
С помощью эти программ промоделированы процессы соударения частиц на мишени при ионном облучении.
Хотелось бы посмотреть исходный код. Есть описание на английском для некоторых из них, но где скачать так и не нашел...

lxa85
18-01-2013, 19:39
nix_c, это крайне специфическое ПО, широко известное в узких кругах. К сожалению ничем не могу помочь, кроме как советом найти эти самые узкие круги.
Подключайте научного руководителя и его связи. Это действительно узкая специальность и тут надо знать ключевых людей и ключевые слова. Первый, кто в этом может помочь -- науч.рук. + институты и кафедры профильного направления. Это, к сожалению, ищется даже не за неделю человеком со стороны, например меня.




© OSzone.net 2001-2012