Доска объявлений

Не очень просто, но типа такого - выдавливание, пересечение, круговой массив, объединение. Неважно, в какой программе )  

согласно вашей логике, если во всём объёме модели модуль упругости постоянный при условии линейного материала, то и матрица жёсткости не должна меняться. в случае матрицы масс суммарная масса и масса каждого отдельного взятого КЭ, очевидно, тоже не критерий

Хотелось бы разобраться именно с COMSOL. C Ansys я почти не знаком.

2018sp5 умирает каждый день по нескольку раз i5 3xxxx 16gb win7

https://www.engineersrule.com/task-best-macro-batch-processor-solidworks/ А может это просто мои догадки, я не претендую на истину )  

@karachun Спасибо за подсказку, надо будет попробовать. А как же явления аэроупругости? Спасибо за подсказку, надо попробовать.

Давайте сделаем полностью готовую модель в CFX или Fluent)   С COMSOL тут на форуме мало кто работал.

А как связан Артем и Centralinnovation.com?

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

За последний год пересмотрел множество роликов на YouTube (в т.ч. англоязычные каналы), пролазил форумы, и только видел парочку людей, которые почти догадались обуздать таблицу параметров Excel в SW в полной мере. Ниже будет длиннопост о том, как можно по-новому взглянуть на методику проектирования (мы уже ей пользуемся почти год). Она подойдет не для всех предприятий и нацелена на работу в огромном коллективе при работе начиная от мелкосерийного производства. Для уникального оборудования она будет бесполезна. Очень много людей рассказывают о преимуществе контекстного и параметрического моделирования. Но на огромном предприятии все преимущества затмеваются недостатками, а именно: 1. Если мы говорим о том, что все детали будут контекстными и в PDM будет лежать только 1 файл сборки - то как диспетчеры ПДО догадаются их найти? Допустим они работают напрямую с моделями (например, отправка на ФГС, гибка деталей и т.д.) 2. Если мы говорим о том, что все детали будут лежать отдельными файлами, но связаны через контекстные взаимосвязи, то столкнетесь с тем, что одна и та же деталь должна будет привязана к разным сборкам, а так быть не должно (поэтому придется делать несколько таких деталей, что в геометрической прогрессии увеличит базу данных деталей) 3. Если вы подразумеваете делать несколько исполнений в одной контекстной сборке, то у вас все получится. Но когда вы вставите эти исполнения в вышестоящие сборки - у вас ничего не выйдет - у деталей, входящей в контекстную сборку может быть только одно исполнение. 4. И куча более мелких проблем... В связи с этими проблемами, у нас возникла идея остановиться на таблице параметров. Вот так выглядит одна из стандартных таблиц параметров. На фото - модель корпуса, слева - уже созданные конфигурации. Внизу - таблица параметров.  Таблица параметров Таблица параметров не простая, а основана на умной таблице Excel. Кто не знает, то это такая таблица, при которой новые введенные данные в нее автоматически просчитываются для всей строки. Поэтому конструкторам не требуется каждый раз "протягивать" таблицу вниз. Все остальные данные скрыты от посторонних глаз. Вот так выглядит таблица полностью Таблица параметров 2 Как видно из таблицы, формирование обозначения корпуса довольно сложно для рядового пользователя, поэтому придется немного разобраться в Excel для создания сложных иерархий обозначений. Также тут видно, что обозначение каждой из детали задается формулой, для того чтобы именно это исполнение появилось в том или ином корпусе. Поэтому предварительно конструктор должен создать все детали (также через таблицу параметров) - это единственный минус перед параметрическим контекстным моделированием. Но на предприятии корпуса создает 1 человек все сразу для проекта, поэтому - превращается в +.  Также в таблице параметров организован удобный выпадающий список возможных исполнений деталей, поэтому даже новичкам не приходится смотреть в чертеж, чтобы выбрать нужный ему корпус. А вот так выглядит часть чертежа с расшифровкой обозначений. Обозначения Для всех деталей и сборочных единиц мы принципиально отказались от таблицы исполнений, а перевели ее в "бесконечную" через L, B, H. Это намного повысило эффективность конструкторского отдела. Сначала все говорили что конструктора себе упростили жизнь, а другим службам - усложнили. Но ненамного. Через специальный софт мы считываем с 3D сборочной единицы все составные части в CSV файл с иерархией, и отправляем в программу, которой пользуется диспетчеры ПДО и технологи. Вот так она выглядит Производство Как видно, все детали, которые присутствуют в корпусе, автоматически перенеслись в программу производства. Никто не занимается ручным вписыванием/переписыванием этих деталей. По сути спецификация им даже не нужна. Спецификация нужна цеховым рабочим, которые получаются на руки все эти части и по спецификации собирают корпус. Технологи лишь расписывают пути следования эти деталей по станкам и выписыванием материалов. Но и это вполне по силам автоматизировать, так что в плюсе оказались даже технологи и диспетчеры ПДО.  Практически все производимые узлы перенесли на этот тип проектирования. Вот так выглядит наша папка в PDM для конструкторов.  Каталог Для конструкторов создан удобный каталог с гиперссылками на сборочные единицы. Для технологов - расчет сварочных материалов, материалов, лакокрасочным материалов, покупных изделий в зависимости от L, B, H. Для проекта создается таблица Excel, где ведущий конструктор выбирает необходимые комплектующие, и ему автоматически предлагаются уже типовые решения с уже расписанными материалам, покупными изделиями и т.д. для составления предварительной ведомости на заказ с точностью 97-99%. На мой взгляд, введение подобной схемы проектирования увеличило производительность конструкторов-технологов в 4 - 10 раз.