Вы говорите правильный вещи, если бы я здесь сделал некую свою реализацию метода и претендовал на практическое применение.
Возможно, получилось некое-то недоразумение, давайте я все разложу все по полочкам:
если вы решились на собственную реализацию МКЭ — должны быть причины. Каковы они?
Написать максимально простой, но выразительный код на современном языке реализующий простершее применение МКЭ.
На примере кода постараться кратко изложить суть метода.
Я написал несколько велосипедов по МКЭ. В одном из случаев даже не совсем бесполезную. Делал я это исключительно из моего любопытства к методу. Не всегда легко читать литературу насыщенную математикой из теории упругости и затем думать как же это реализовать на практике. Информацию я собирал из нескольких источников, в основном из книги Зенкевича, что в итоге позволило мне написать несколько программ реализующих данный метод.
Здесь я просто решил поделиться собранным мною опытом и я постарался написал максимально краткий, простой и выразительный код. Насколько у меня это получилось судить вам.
Вы создаете программное средство, которое используя МКЭ проводит приблизительный расчет. Именно приблизительный. И какова предметная область? Насколько физический эксперимент конкретно взятой задачи соответствует численному решению?
Я взял самый классический случай реализации МКЭ. Я не придумал ничего нового. Здесь я сжато изложил (возможно немного своеобразно, но именно так я хотел его преподнести) суть МКЭ, которая ничем не отличается от его изложения во многих классических книгах по МКЭ.
Если реализация классическая, проверенная временем, использованная множество раз на практике, к чему вопросы по соответствие с физическим экспериментом? Или вы не верите таким авторам как Olgierd Zienkiewicz? Vj
Вопрос по верификации, самого метода здесь поднимать я думаю не уместно. Как и любой метод решение прикладных задач, он также работает с упрощенной моделью. Поэтому здесь ответ на вопрос про соответствие с экспериментом зависит от того, что именно и для каких целей мы хотим получить.
Да расчет приблизительный. Но, если говорить о соответствии с экспериментом, то тут все упираться будет не в МКЭ, а в физическую модель. Мы можем сделать мельче сетку, использовать элементы более высокого порядка и получить решение заданных дифф. уравнений с требуемой точностью. А вот насколько хорошо данные дифф. уравнений моделируют реальность, это уже отдельный вопрос. В рамках рассмотренной задачи, как показала практика, достаточно хорошо.
100%? Вы шутите? Один приближенный расчет вы сравниваете с другим? И говорите про 100%?
А что тут плохого? Или вы хотите сказать, что в Abaqus'e неправильно реализован МКЭ?
Я реализовал классическую схему.
Расчет совпадает с расчетом Abaqus'а.
Следовательно, ошибок в программной реализации хорошо известной математики нету.
Раз совпадение 100%, то в Abaqus'е с большой долей вероятности реализована абсолютно точно такая же математика для этого типа задачи и элемента.
Подчеркну, я говорю про 100% совпадение с расчетом Abaqus'а, не более (но именно этого и достаточно).
Одна и та же сетка, решение совпадает, что еще надо? Я провел больше тестов, здесь привел только один.
Я говорю, что решение проверенной реализации МКЭ совпадает с моим решением (в рамках данной задачи). Я не в коем случае не говорю, что оно должно совпадать с экспериментом или еще с чем. Но если вам интересно, то аналитическое решение задачи о пластине с отверстием дает коэффициент концентрации — 3, у меня — 3.05152.
Что вы понимаете здесь под верификацией? В последнем примере, решение я сравнил с решением Abaqus'а, получил 100% совпадение. А сам метод уже давно математически обоснован, проверен на практике и имеет хорошо известные ограничения и особенности.
На счет узкоспециализированности метода я бы поспорил, или вы про конкретную реализацию для решения плоской задачи напряженно-деформируемого состояния?
Самые часто используемые решения я перечислил выше, на самом деле их намного больше.
Применения метода, ну я уже писал в статье, это и решение всякого рода механических задач (при этом не надо ограничиватья машиностроением), термодинамика, электродинамика, аэродинамика.
Сейчас без него ни спутник на орбиту вывести, ни платину построить, ни атомный реактор расчитать.
При этом, метод имеет свой потенциал и в игровой индустрии для создания деформируемого/разрушаемого окружения.
Почему пример простейшей реализации, написанный для целей объяснить принцип работы метода — велосипед? Тогда можно каждый туториал велосипедом назвать.
Давайте еще велосипедом назовем пример реализации МКЭ в книге Зенкевича? Только он там на фортране пример привел.
Метод старый, все примеры реализации как правило на фортране, вот я и решил восполнить этот пробел.
Думаю это будет не просто сделать.
Фокус техники описанной выше, в том что паттерн смещений применяется в скринспейсе, причем паттерны чередуются в строгой последовательности. Плюс к этому участок текстуры, который мы сэмплим, имеет строго заданный размер, в данном случае 4х4 текселя, и он не меняется.
Такой подход дает лучший результат, чем если бы мы просто сэмплили рандомно.
In our implementation, we have changed the PCF algorithm slightly to make it easy and efficient to apply. Instead of calculating the region to be shaded in shadow map space, we simply use a 4x4-texel sample region everywhere. This region is large enough to significantly reduce aliasing, but not so large as to require huge numbers of samples or stochastic sampling techniques to achieve good results. Note that the sampling region is not aligned to texel boundaries. An aligned region would not achieve the antialiasing effect that we want.
Our implementation uses a fixed-size sample region instead. A fixed-size region lets us skip a complicated transformation and allows us to calculate a precise shadow percentage instead of an approximate one using stochastic sampling.
Как такое сделать с стенсилом, я честно даже не представляю. Если будете пробовать, обезательно отпишитесь.
В картах теней предусмотрен шаблон сглаживания (если вы внимательно посмотрите на текстуру, изображенную ниже, увидите в красном канале упомянутый ранее эффект шахматной доски). Это позволяет сгладить границы теней.
Я когда-то делал реализацию изложенного в статье метода, очень крутая оптимизация, позволяет практически получить хорошее качество с минимум операций сэмплинга. Если в добавок включить хардварную фильтрацию, то результат шикарный. Даже если потом не делать операцию сглаживания, на ретина дисплэях такая шахматная доска незаметна.
У меня продуктивность падает даже когда я просто сижу не за привычным мне местом, казалось бы, без видимых на то причин. С трудом представляю как можно что-то разрабатывать в дороге.
Да, автор писал о другом. Скорее всего о разработке системного софта, ведь, он бывший разработчик OpenBSD. Там то уж часто нужно весьма плотно работать с железом. Отсюда и проблемы с поддержкой платформ, особенно если, как писал автор, есть проблемы с: тулчейном, флагманскими проектами и документацией.
Я же в качестве примера написал, что проблемы возможны и с прикладным софтом, причем на ровном месте.
ну это — кроме как по недосмотру — вообще детская ошибка
Вы не поверите, в одной крупной компании, свой кастомный графический движок так все игровые ресурсы читает. Причем внутри струкур находятся указатели, которые хранят оффсеты на другие структуры в файле. При чтении файла, к значению указателя добавляется абсолютный адрес и получаем указатель на струкуру в памяти.
Так как автор — бывший разработчик OpenBSD, смею предположить, что речь идет все же больше о системном софте.
Ничего страшного в использовании int32_t как раз и нету, проблемы начинаются там где используется long. Например для 64-х битных платформ есть несколько моделей придставления типов данных: LLP64/IL32P64, LP64/I32LP64, ILP64 SILP64. На платформе win64, long длиной 32 бита, на большинстве unix-like систем — 64 бита. Но это все в принципе не проблема.
По своему скромному опыту, могу сказать, что на больших проектах даже переход с armv7 на aarch64, может быть очень болезненным. Проблемы начинаются тогда, когда:
Есть оптимизации, которые зависят от выравниваний.
Где-то есть всевозможные хитрых манипуляции с указателями, которых делают предположение, что они именно 32-х битных.
Когда структуры в прямом виде пишуться/читаются из файла.
Используюся различные ассмеблерные вставки, скажем для использования NEON.
Используются сдвиговые операции.
В коде Хавока, есть место где вообще вручную правят vtable.
H. Other Use Restrictions. The grants set forth in this License do not permit you to, and you agree not to, install, use or run the Apple Software on any non-Apple-branded computer, or to enable others to do so.
Я тоже писал, лет пять назад. Тот эмулятор вот только такие самодельные ОС и мог запускать, не более. Сделал реализацию 8186, понаделал кучу тестов, сравнивал работу с bochs, в итоге все уперлось в реализацию биоса. Документации по набору команд *86, хоть отбавляй, взять даже тот трехтомник intel по IA32. А вот подробной документации по функциям биоса уже не так много. Можно конечно было слизать с bochs, я тогда зеленый был, и меня пугал его код.
Помню как все пытался запустить MS DOS 6.22. Я тогда первичный загрузчик вдоль и поперек продебажил. Первичный загрузчик отрабатывал нормально, загружал вторичный, который грузил какие-то большие файлы с диска, а затем вдруг начиналось дерганье всех подряд функций биоса. Большую часть я кое как реализовал, но были некоторые вызовы, про которые я документацию так и не нашел. В итоге система зависала, помучавшись пару недель, я бросил это неблагодарное занятие. До сих пор удивляюсь, как у меня терпения хватило столько намучаться.
Вот эта штука на удивление нормально работала: www.codenet.ru/progr/os/
Более того, даже если не брать во внимание, подсчеты бит в ДНК, сама идея, что разница между человеком и шимпанзе включает в себя искомый интеллект в корне неверна. Я далек от биологии, но что-то мне подсказывает, что нету никакой принципиальной разницы между мозгом человека и шимпанзе. У человека просто более большой «каток» и немного по-другому настроенный.
Никогда бы не подумал, что они без рейтрейсинга все это делают. Теперь ясно, почему «геометрический свет» для них был проблемой. Вообще я поражен, что можно получать картинку такого высокого качества, не прибегая к рейтрейсингу.
Любопытно, а в чем именно была загвоздка с «геометрическим светом»? Возможно, я что-то неправильно понимаю, но вот например в vray, есть emissive materials, которые можно применить к любой произвольной геометрии и получить описанный в статье эффект. Конечно, не нужно ставить vray и RenderMan в один ряд, но мне как-то странно слышать, что в RenderMan такого функционала раньше не было. Одно дело риалтайм рендр используемый в играх, там добиться такого эффекта крайне сложно, совсем другое дело рейтрейсинг. На первый взгляд, рейтрейсинг сам по себе, из коробки, позволяет использовать произвольную геометрию в качестве источника света. Может все дело в производительности?
они за вас копируют back buffer в отдельную текстуру и отдают вам ее на обработку.
Как такое вообще можно реализовать средствами OpenGL ES 2.0 на iPad2? Наверное, можно было бы использовать glBlitFramebuffer, но эта функция доступна только в OpenGL ES 3.0.
Возможно я ошибаюсь, и можно присоединить render buffer к back buffer, к которому в свою очередь присоединена текстура. Я так никогда не делал и никогда не видел подобных решений. Думаю, что это вряд ли возможно, т.к. back buffer это все таки не frame buffer, хотя я и не уверен в случае с ios. Если это все же возможно, что должно произойти после swap'а front и back буфера?
По моему личному мнению, было бы очень странно, если в Unity действительно перед пост процессингом, содержимое из back буфера копировалось в текстуру.
Почему нельзя? Так можно, более того я даже думаю, что в тех случаях, когда нужно сделать прогноз на небольшой промежуток времени и при наличии большого числа параметров влияющих на систему, именно так и делают.
Да, один из минусов это некая погрешность, связанная с ошибками интегрирования и вычислений с плавающей точкой. Однако это не такая большая беда, в виду того, что мы можем сделать мельче шаг и использовать числа повышенной точности, благо современная вычислительная техника это позволяет.
Самый главный минус — мы не сможем воспользоваться всеми прелестями аналитического решения. Ведь численное решение это всего лишь очень большой набор данных, которые нужно еще как-то обработать.
Аналитическое решение обычно представляет собой систему с ограниченным числом параметров. Зная общее решение, мы можем находить эти параметры для других случаев. Можем решать задачи оптимизации и многое многое другое.
Аналитическим, оно хорошо интегрируется. Некоторые решения (которые нас интересуют) дают эллипс в полярных координатах. Я хотел показать почему именно орбиты имеют форму близкую к эллипсу. Вобщем во второй части все будет.
К слову, я тоже только сочувствующий.
1)Они были открыты за полвека до уравнений, которые приводит автор.
Я примерно так и написал: Кеплер его не выводил, а интуитивно подобрал на основе своих наблюдений
2)Не нужно смешивать в одно применимость и возможность получения аналитического решения. Как по вашему численно решается задача о трех телах? Сомневаюсь, что без законов Ньютона.
Да я знаю, что в реальных расчетах применяются другие намного более сложные модели, к сожалению я в них еще не разобрался и не знаю как они работают. Но было бы странно браться за что-то сложное не разобравшись в элементарной модели.
на больших интервалах времени будет откровенно врать
У вас есть какие-то оценки того на сколько большие будут ошибки, скажем лет через 20?
Спасибо за ссылки.
Возможно, получилось некое-то недоразумение, давайте я все разложу все по полочкам:
Я написал несколько велосипедов по МКЭ. В одном из случаев даже не совсем бесполезную. Делал я это исключительно из моего любопытства к методу. Не всегда легко читать литературу насыщенную математикой из теории упругости и затем думать как же это реализовать на практике. Информацию я собирал из нескольких источников, в основном из книги Зенкевича, что в итоге позволило мне написать несколько программ реализующих данный метод.
Здесь я просто решил поделиться собранным мною опытом и я постарался написал максимально краткий, простой и выразительный код. Насколько у меня это получилось судить вам.
А что тут плохого? Или вы хотите сказать, что в Abaqus'e неправильно реализован МКЭ?
Подчеркну, я говорю про 100% совпадение с расчетом Abaqus'а, не более (но именно этого и достаточно).
Одна и та же сетка, решение совпадает, что еще надо? Я провел больше тестов, здесь привел только один.
Я говорю, что решение проверенной реализации МКЭ совпадает с моим решением (в рамках данной задачи). Я не в коем случае не говорю, что оно должно совпадать с экспериментом или еще с чем. Но если вам интересно, то аналитическое решение задачи о пластине с отверстием дает коэффициент концентрации — 3, у меня — 3.05152.
На счет узкоспециализированности метода я бы поспорил, или вы про конкретную реализацию для решения плоской задачи напряженно-деформируемого состояния?
Самые часто используемые решения я перечислил выше, на самом деле их намного больше.
Применения метода, ну я уже писал в статье, это и решение всякого рода механических задач (при этом не надо ограничиватья машиностроением), термодинамика, электродинамика, аэродинамика.
Сейчас без него ни спутник на орбиту вывести, ни платину построить, ни атомный реактор расчитать.
При этом, метод имеет свой потенциал и в игровой индустрии для создания деформируемого/разрушаемого окружения.
Почему пример простейшей реализации, написанный для целей объяснить принцип работы метода — велосипед? Тогда можно каждый туториал велосипедом назвать.
Давайте еще велосипедом назовем пример реализации МКЭ в книге Зенкевича? Только он там на фортране пример привел.
Метод старый, все примеры реализации как правило на фортране, вот я и решил восполнить этот пробел.
Фокус техники описанной выше, в том что паттерн смещений применяется в скринспейсе, причем паттерны чередуются в строгой последовательности. Плюс к этому участок текстуры, который мы сэмплим, имеет строго заданный размер, в данном случае 4х4 текселя, и он не меняется.
Такой подход дает лучший результат, чем если бы мы просто сэмплили рандомно.
Как такое сделать с стенсилом, я честно даже не представляю. Если будете пробовать, обезательно отпишитесь.
Я так предполагаяю, что используется вот этот трюк: Shadow Map Antialiasing
Я когда-то делал реализацию изложенного в статье метода, очень крутая оптимизация, позволяет практически получить хорошее качество с минимум операций сэмплинга. Если в добавок включить хардварную фильтрацию, то результат шикарный. Даже если потом не делать операцию сглаживания, на ретина дисплэях такая шахматная доска незаметна.
Я же в качестве примера написал, что проблемы возможны и с прикладным софтом, причем на ровном месте.
Вы не поверите, в одной крупной компании, свой кастомный графический движок так все игровые ресурсы читает. Причем внутри струкур находятся указатели, которые хранят оффсеты на другие структуры в файле. При чтении файла, к значению указателя добавляется абсолютный адрес и получаем указатель на струкуру в памяти.
Ничего страшного в использовании int32_t как раз и нету, проблемы начинаются там где используется long. Например для 64-х битных платформ есть несколько моделей придставления типов данных: LLP64/IL32P64, LP64/I32LP64, ILP64 SILP64. На платформе win64, long длиной 32 бита, на большинстве unix-like систем — 64 бита. Но это все в принципе не проблема.
По своему скромному опыту, могу сказать, что на больших проектах даже переход с armv7 на aarch64, может быть очень болезненным. Проблемы начинаются тогда, когда:
В коде Хавока, есть место где вообще вручную правят vtable.Взято от сюда
Причем я говорю именно про легальность использования. То что все ставят хакинтошы и ни у кого с этим проблем нету — это отдельная тема.
Помню как все пытался запустить MS DOS 6.22. Я тогда первичный загрузчик вдоль и поперек продебажил. Первичный загрузчик отрабатывал нормально, загружал вторичный, который грузил какие-то большие файлы с диска, а затем вдруг начиналось дерганье всех подряд функций биоса. Большую часть я кое как реализовал, но были некоторые вызовы, про которые я документацию так и не нашел. В итоге система зависала, помучавшись пару недель, я бросил это неблагодарное занятие. До сих пор удивляюсь, как у меня терпения хватило столько намучаться.
Вот эта штука на удивление нормально работала: www.codenet.ru/progr/os/
Как такое вообще можно реализовать средствами OpenGL ES 2.0 на iPad2? Наверное, можно было бы использовать glBlitFramebuffer, но эта функция доступна только в OpenGL ES 3.0.
Возможно я ошибаюсь, и можно присоединить render buffer к back buffer, к которому в свою очередь присоединена текстура. Я так никогда не делал и никогда не видел подобных решений. Думаю, что это вряд ли возможно, т.к. back buffer это все таки не frame buffer, хотя я и не уверен в случае с ios. Если это все же возможно, что должно произойти после swap'а front и back буфера?
По моему личному мнению, было бы очень странно, если в Unity действительно перед пост процессингом, содержимое из back буфера копировалось в текстуру.
Да, один из минусов это некая погрешность, связанная с ошибками интегрирования и вычислений с плавающей точкой. Однако это не такая большая беда, в виду того, что мы можем сделать мельче шаг и использовать числа повышенной точности, благо современная вычислительная техника это позволяет.
Самый главный минус — мы не сможем воспользоваться всеми прелестями аналитического решения. Ведь численное решение это всего лишь очень большой набор данных, которые нужно еще как-то обработать.
Аналитическое решение обычно представляет собой систему с ограниченным числом параметров. Зная общее решение, мы можем находить эти параметры для других случаев. Можем решать задачи оптимизации и многое многое другое.
1)
Они были открыты за полвека до уравнений, которые приводит автор.Я примерно так и написал:
Кеплер его не выводил, а интуитивно подобрал на основе своих наблюдений2)Не нужно смешивать в одно применимость и возможность получения аналитического решения. Как по вашему численно решается задача о трех телах? Сомневаюсь, что без законов Ньютона.
У вас есть какие-то оценки того на сколько большие будут ошибки, скажем лет через 20?
Спасибо за ссылки.