Хм… Пускай фальшивая монета под номером 100.
Она участвует только во втором взвешивании.
Таким образом, число которое нарисуется после трех вхвешиваний будет 101 (или 121) — ни один из вариантов не совпадает с номером монеты.
Я чесно говоря не знаю что такое Ева.
Это пре-пост процессор CATOPO. Разрабатывается украинской фирмой. Пользователи — автомобилестроительные компании Германии.
Вы немного путаете задачи.
Проекты которые испльзовали FOX (в которых я работал) были как раз пре- и пост- процессорами.
Лично я писал в них интерфейсы для работы с солверами (если знаете: Permas, ABAQUS, Ansys, отчасти Nastran, топологические оптимизаторы OptiStruct, Tosca) поэтому я прекрасно понимаю о чем вы говорите. Есть набор типичных условий и набор интегральных характеристик в виде результатов.
Но в моем случае задачи ставились нетипичные. А для анализа промежуточных результатов требовались нетипичные интегральные характеристики.
Так чтобы не особо вдаваться в подробности…
Метод, который я развиваю на новый круг задач — очень чувствителен к дискретизации исследуемых (обтекаемых) поверхностей. Тоесть представте себе, что для обтекания сферы она (сфера) должны быть дискретизирована панелями строго определенным образом (так же как земля — паралели и мередианы). Решение с любой другой дискретизацией дает абсолютно неверный результат.
Далее. Данный метод не предполагает автоматического определения мест отрыва потока от поверхности — они задаются вручную.
Просмотр результатов так же имеет свои особенности. Иногда нужно посмотреть всю картину формирования вихревой пелены за объектом, то нужно получить ее срез, то нужно получить распределение скорости по этому срезу, но нужо получить пограниченые значения давления при подходе к поверхнсти с одной и другой стороны и т.д. Тоесть это речь еще не идет о типичных результатах Cx, Cy, полях скоростей и давлений.
Вы просто представте, что решалась не конкретная задача. А создавалась новая мат-модель, модификация метода. И, аналогично как и в программировании, вы ставите какие-то breakpoints, смотрите на промежуточные значения, отключаете временно определнные расчетные блоки и т.д. И когда на все это можно смотреть только на 3д — поскольку просмотр цифр вам не дает общей картины — приходится создавать интерфейсы. А еще если учесть что экспериментальная задача может считаться ночь, но увидеть неверное поведение решения можно буквально на ранних итерациях — нужна была возможность считать и смотреть уже решенные итерации одновременно. Как тут без GUI?
А там где можно было использовать что-то вншнее — это делалось. Для линейно алгебры использовались BLAS, LAPACK.
ПРИМЕР:
Нужно было получить эффект один на струе. Используя этот ментод его еще никто не получал. Вот сидел так, эксперементировал, наделал кучу всего для отлавливания условий в которых этот эффект проявляется — ничерта. Нет эффекта и все тут. А потом таки получил. При чем данный метод выдает этот физический эффект в гораздо более узких условиях. К примеру, в жизни он наблюдается на струях газа вытекающих в газ той же плотнтости и на струях жидкости вытекающих в газ. А метод его показывает только на струях жидкости. Значит его можно испльзовать на задачах именно жидкость-газ.
И на эту тему эксперементировал я долго — года полтора наверно. Помимо решения других задач.
Сам я пользовался базовыми возможности (загрузка иконок, соханения принтскринов и т.д.), глубоко не копал. Но на сайте (http://www.fox-toolkit.org/) у них доступны для загрузки библиотеки:
JPEG Image Support
PNG Image Support
TIFF Image Support
TIFF LZW Support
Качните, посмотрите в доках что они там предлагают.
ну если работаете с opengl — то естественно он каким-то образом должен подключаться. Для windows — это opengl.dll, То же самое касается и остальных внешних библиотек.
Но никакие системные библиотеки по-умолчанию не требуются — все реализовано внутри FOX на С++.
Под windows в качестве компилятора использовался VS2003, под linux — sourcenavigator.
FOX компилируется в lib (a) и подключается к проекту.
Для примера, exe более подвязанного на фокс проекта со скриншота — тянул где-то мегайбай на 20
Громоздкого? Точно не скажу. Читал. Но не пробовал. А вы сами FOX пробовали — а то ведь будет говорить как слепой с глухим :)
Дисер по аэрогидродинамике.
В основе расчетов собственная модификация существующего метода, приминимо к решению узкого круга задач. Ну а поскольку достаточно небольшие модели (далекие от реальных) решаются по несколько десятков часов — то необходимо была оптимизация приложения во всех отношениях: распаралеливание изсходя из внутренней структуры данных, оптимизация внутренней (достаточно громоздкой) стрктуры данных и т.д.
Кроме того, как я говорил, FOX содержит набор классов для работы с 3Д (начиная от запуска oepngl и заканчивая такими моментами как выделение (и множественное выделение) и перемещение объектов на сцене), перенсим (полностью компилируется в exe-шник не требуя никаких билиотек).
А если учесть, что все это связано с большим количеством эксперементов, с учетом и без учета большого количества свойств жидкостей, приминимо к данным задачам — то, сами пнимаете, при таких сроках расчета эксперементировать можно всю жизнь :)
ПОдобные проекты это как правило препроцессор (работа с графикой и GUI при создании модели, формировании начальных условий), решатель (расчетная часть) и постпроцессор (графика и GUI для расчета и просмотра полей скоростей и давлений по решению задачи). Поэтом по совокупности — пре- и пост-процессор было решено писать на FOX а решатель делать на С++ с использованием того же FOX.
Сравнить, к сожалению, могу только с MFC — ни с Qt ни с wxWidgets не работал. Посмотрю обзоры этих фреймворков — попробую что-нибдуь выудить.
С полпинка — FOX не такой громоздкий как например Qt. Но база проработана достаточно хорошо. И из того что я знаю — FOX один из самых быстрых фреймворков. Преимущества фокса следует искать именно в этом. А еще в лицензии, в кросплатформенности (а у wxWidgets с этим по-моему проблемы). Вобщем попробую развить тему.
Только начал разбираться — вообще интересный фреймворк конечно. Но только есть один момент из примера спорный. По крайней мере как для программиста с++.
Зачем в каждом классе-наследнике Template_Controller переопределяется поле template? Если это делается для определение дефолтового значения переменной в классе-наследнике — то по канонам ооп это должно делаться в конструкторе класса. Собственно, я поэтому вместо Template_Controller написал свой базовый абстрактный класс, который при рендеринге переменной проверяет инициализацию этой по сути абстрактной переменной.
Она участвует только во втором взвешивании.
Таким образом, число которое нарисуется после трех вхвешиваний будет 101 (или 121) — ни один из вариантов не совпадает с номером монеты.
Это пре-пост процессор CATOPO. Разрабатывается украинской фирмой. Пользователи — автомобилестроительные компании Германии.
Проекты которые испльзовали FOX (в которых я работал) были как раз пре- и пост- процессорами.
Лично я писал в них интерфейсы для работы с солверами (если знаете: Permas, ABAQUS, Ansys, отчасти Nastran, топологические оптимизаторы OptiStruct, Tosca) поэтому я прекрасно понимаю о чем вы говорите. Есть набор типичных условий и набор интегральных характеристик в виде результатов.
Но в моем случае задачи ставились нетипичные. А для анализа промежуточных результатов требовались нетипичные интегральные характеристики.
Так чтобы не особо вдаваться в подробности…
Метод, который я развиваю на новый круг задач — очень чувствителен к дискретизации исследуемых (обтекаемых) поверхностей. Тоесть представте себе, что для обтекания сферы она (сфера) должны быть дискретизирована панелями строго определенным образом (так же как земля — паралели и мередианы). Решение с любой другой дискретизацией дает абсолютно неверный результат.
Далее. Данный метод не предполагает автоматического определения мест отрыва потока от поверхности — они задаются вручную.
Просмотр результатов так же имеет свои особенности. Иногда нужно посмотреть всю картину формирования вихревой пелены за объектом, то нужно получить ее срез, то нужно получить распределение скорости по этому срезу, но нужо получить пограниченые значения давления при подходе к поверхнсти с одной и другой стороны и т.д. Тоесть это речь еще не идет о типичных результатах Cx, Cy, полях скоростей и давлений.
Вы просто представте, что решалась не конкретная задача. А создавалась новая мат-модель, модификация метода. И, аналогично как и в программировании, вы ставите какие-то breakpoints, смотрите на промежуточные значения, отключаете временно определнные расчетные блоки и т.д. И когда на все это можно смотреть только на 3д — поскольку просмотр цифр вам не дает общей картины — приходится создавать интерфейсы. А еще если учесть что экспериментальная задача может считаться ночь, но увидеть неверное поведение решения можно буквально на ранних итерациях — нужна была возможность считать и смотреть уже решенные итерации одновременно. Как тут без GUI?
А там где можно было использовать что-то вншнее — это делалось. Для линейно алгебры использовались BLAS, LAPACK.
ПРИМЕР:
Нужно было получить эффект один на струе. Используя этот ментод его еще никто не получал. Вот сидел так, эксперементировал, наделал кучу всего для отлавливания условий в которых этот эффект проявляется — ничерта. Нет эффекта и все тут. А потом таки получил. При чем данный метод выдает этот физический эффект в гораздо более узких условиях. К примеру, в жизни он наблюдается на струях газа вытекающих в газ той же плотнтости и на струях жидкости вытекающих в газ. А метод его показывает только на струях жидкости. Значит его можно испльзовать на задачах именно жидкость-газ.
И на эту тему эксперементировал я долго — года полтора наверно. Помимо решения других задач.
Вот что значит — ушел в веб-разработку :)
Потом на eclipse+gcc перешли
JPEG Image Support
PNG Image Support
TIFF Image Support
TIFF LZW Support
Качните, посмотрите в доках что они там предлагают.
Интерфейса кстати почти полная копия CATIA (http://www.3ds.com/products/catia/) — а это дефакто стадарт.
Но никакие системные библиотеки по-умолчанию не требуются — все реализовано внутри FOX на С++.
Под windows в качестве компилятора использовался VS2003, под linux — sourcenavigator.
FOX компилируется в lib (a) и подключается к проекту.
Для примера, exe более подвязанного на фокс проекта со скриншота — тянул где-то мегайбай на 20
Мой проект, 156 файлов (около 70-ти классов), 900Кб исходников = 1.2Мб exe
Дисер по аэрогидродинамике.
В основе расчетов собственная модификация существующего метода, приминимо к решению узкого круга задач. Ну а поскольку достаточно небольшие модели (далекие от реальных) решаются по несколько десятков часов — то необходимо была оптимизация приложения во всех отношениях: распаралеливание изсходя из внутренней структуры данных, оптимизация внутренней (достаточно громоздкой) стрктуры данных и т.д.
Кроме того, как я говорил, FOX содержит набор классов для работы с 3Д (начиная от запуска oepngl и заканчивая такими моментами как выделение (и множественное выделение) и перемещение объектов на сцене), перенсим (полностью компилируется в exe-шник не требуя никаких билиотек).
А если учесть, что все это связано с большим количеством эксперементов, с учетом и без учета большого количества свойств жидкостей, приминимо к данным задачам — то, сами пнимаете, при таких сроках расчета эксперементировать можно всю жизнь :)
ПОдобные проекты это как правило препроцессор (работа с графикой и GUI при создании модели, формировании начальных условий), решатель (расчетная часть) и постпроцессор (графика и GUI для расчета и просмотра полей скоростей и давлений по решению задачи). Поэтом по совокупности — пре- и пост-процессор было решено писать на FOX а решатель делать на С++ с использованием того же FOX.
С полпинка — FOX не такой громоздкий как например Qt. Но база проработана достаточно хорошо. И из того что я знаю — FOX один из самых быстрых фреймворков. Преимущества фокса следует искать именно в этом. А еще в лицензии, в кросплатформенности (а у wxWidgets с этим по-моему проблемы). Вобщем попробую развить тему.
Зачем в каждом классе-наследнике Template_Controller переопределяется поле template? Если это делается для определение дефолтового значения переменной в классе-наследнике — то по канонам ооп это должно делаться в конструкторе класса. Собственно, я поэтому вместо Template_Controller написал свой базовый абстрактный класс, который при рендеринге переменной проверяет инициализацию этой по сути абстрактной переменной.