| Правила | Регистрация | Пользователи | Поиск | Сообщения за день | Все разделы прочитаны | Справка по форуму | Файлообменник | |
|
Поиск в этой теме |
14.01.2022, 05:05 | 6 | | #1 |
C#. Конвертеры сетки GMSH (*.msh) в FEA для Stark ES и SLI для Лиры
Инженер-философ
Хабаровск
Регистрация: 24.04.2019
Сообщений: 1,867
|
||
Просмотров: 3123
|
|
||||
Регистрация: 10.08.2013
Сообщений: 11,000
|
Код:
|
|||
|
||||
Инженер-философ Регистрация: 24.04.2019
Хабаровск
Сообщений: 1,867
|
Не программист, не в курсе, что такое вообще есть. Предыдущая версия лежит в теме про открытый решатель под акад, там все было на строках, и модель здания на 150тыс элементов тормозила полчаса. В этой версии сборку пары длинных строк заменил на список, теперь практические задачи в секунду укладываются. Сейчас проверил - замена сборки строк отдельных узлов и элементов со String на StringBuilder уже ничего принципиально не ускоряет, а читается хуже. Дальше оптимизировать пока нет смысла.
Главная проблема в том, что физические группы не переводятся автоматически в материалы, потому что они в старой версии MSH не сохраняются. Но старый формат сетки можно читать и переводить построчно, а новые надо разбирать, у них структура свободная. Возможно еще, что файлы с пользовательской нумерацией узлов и элементов не сконвертятся: узлы пишутся без коррекции номеров; с нумерацией по умолчанию это работает. Но, если все делать честно, вместо пары экранов кода и свободного вечера получается возня на много дней. А в моем языке программирования до начала кодинга запускается препроцессор ЛЕНЬ.exe, и редкая мысль переживает послеобеденный сон . |
|||
|
||||
YngIngKllr Регистрация: 29.03.2005
СПб
Сообщений: 12,968
|
Можно моделить в автокаде и через ifc или stl передавать в GMSH.
А в GMSH можно держать готовые патерны для перевода в msh.
__________________
Работаю за еду. Working for food. Für Essen arbeiten. العمل من أجل الغذاء Працую за їжу. |
|||
|
||||
Регистрация: 10.08.2013
Сообщений: 11,000
|
просто в .Net используется интернирование строк - т.е. например десять одинаковых строк в реальности: одна запись в хэш-таблице + 10 ссылок на нее. Плюсы - экономия памяти, проще сравнивать строки на совпадение. А минус - что нельзя строки менять непосредственно, как в плюсах - путем перераспределения памяти под нее. Поэтому был придуман StringBuilder - который собирает добавляемые символьные и строковые данные в обычный массив, и уже только на выходе преобразует в запись хэш-таблицы строк.
ну а что скорости не добавило существенно - значит, другие части кода занимают основное время выполнения. Но, например, внутри той же string.Format и ей подобных по работе со строками как раз StringBuilder "прячется" - не зря же) |
|||
|
||||
КИПиА Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
|
Цитата:
|
|||
|
||||
КЖ; C# Регистрация: 03.11.2005
Санкт-Петербург
Сообщений: 2,588
|
на вкус и цвет фломастеры разные, но почему строку по человечески то не записать?
Код:
и вот такого рода конструкции Код:
и вот тут: Код:
Последний раз редактировалось Boxa, 15.01.2022 в 16:24. |
|||
|
||||
Регистрация: 10.08.2013
Сообщений: 11,000
|
Еще бы поигрался с размерами буфера filestream, по умолчанию там всего DefaultFileStreamBufferSize = 4096. Чем меньше обращаетесь к диску, тем меньше тот же антивир влезает в процесс - ему же любопытно)
а ReadKey еще лучше, а перед ним подсказка Writeline("Press any key for exit...") |
|||
|
||||
Инженер-философ Регистрация: 24.04.2019
Хабаровск
Сообщений: 1,867
|
Контролировать при копипасте замену X на Y или [1] на [2] удобнее, когда они в столбик выровнены, а не в строку. Когда элемент на 8 узлов - строка длиннее экрана становится. И, самое главное, этот формат записи совместим и с JavaScript (nanoCad), и с Python (Blender). Нет смысла учить килограммы сахара под каждый язык, который используется раз в год - через год я забуду, что так можно было писать. Проще помнить минимальный общий синтаксис.
Потому что в прошлой версии не было списка и не надо было конвертировать типы. А в новой быстрее добавить (int), чем править по несколько строк на каждое изменение. И в короткой консольной программе проще вылететь с ошибкой, чем пытаться анализировать битые числа через TryParse. В программе на два экрана можно оставить малость грязи. Файл сетки на миллион узлов и миллион элементов обрабатывается за 1.5с. Гораздо дольше ждать, когда GMSH такую сетку нарежет. А я бы поубивал, например, авторов загрузочных окон автокада или нанокада, которые не дают работать пока его величество запускается. Или придумавших переспрашивать "вы точно хотите отключить слой?". Или "Вы тут выключаете компьютер, а программы при этом закрывать?". Не задалбывайте пользователя, и не задалбываемы будете. P.S. За советы по хорошему стилю спасибо, но они мне впрок не пойдут, слишком редко я пишу, чтобы их до автоматизма выучить. Также торжественно клянусь, если соберусь экспортер в Старк на C++ под нанокад/автокад перевести, сделать освобождение ресурсов на макросах через GOTO, потому что оно читается лучше, чем примеры обработки ошибок из документации по ObjectARX . |
|||
|
Опции темы | Поиск в этой теме |
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
JavaScript. nanoCAD 5. Экспорт геометрии в позиционный проект Stark ES | Нубий-IV | Готовые программы | 15 | 15.10.2020 17:47 |
Blender 2.80 / Python. Аддоны экспорта сетки в FEA-проект Stark / TXT-файл Scad / SLI-файл для Лиры-Сапр | Нубий-IV | Готовые программы | 10 | 10.06.2020 12:41 |
STARK ES. Проблема при генерации сетки КЭ. | EYELESS | STARK ES | 27 | 11.04.2013 11:56 |
Создание сетки конечных элементов для Лиры в Автокаде. | professor_off | Лира / Лира-САПР | 11 | 28.10.2010 20:39 |
генерация КЭ сетки в Stark ES 09 | Mavrovskiy | STARK ES | 1 | 24.02.2010 21:00 |