Q : "Что будет самым быстрым вариантом для меня в этом случае? ... не хватает времени. Я уже в середине симуляции."
Салюты Аахену. Если бы не предварительное замечание, самый быстрый вариант состоял бы в предварительной настройке вычислительной экосистемы таким образом, чтобы:
- проверил полную информацию о вашем устройстве NUMA - используя
lstopo или lstopo-no-graphics -.ascii, а не lscpu 
- , инициируйте ваши задания, имея максимально возможное число рабочих процессов MPI, отображаемых на физическое (и лучше всего каждое из них отображается исключительно на его приватное ) ядро ЦП (поскольку они этого заслуживают, поскольку несут рабочую нагрузку ядра FEM / обработки сетки)
- , если ваша политика FH не запрещает сделав это, вы можете попросить системного администратора ввести сопоставление с процессором (которое защитит ваши данные в кеше от выселения и дорогостоящих повторных выборок, что сделает отображение 10-CPU исключительно для использования вашим коллега и упомянутые 30-ЦП, отображенные исключительно для ваших приложений, а остальные из перечисленных ресурсов ~ 40-ЦП ~ являются " shared " - для использования обоими, в соответствии с вашей привязкой к ЦП маски.
Q : «Использование 30 процессов MPI?»
Нет, это не разумное допущение для обработки ASAP - использовать как можно больше процессоров для рабочих для уже распараллеленного MPI-моделирования FEM (они имеют высокую степень параллелизма и чаще всего имеют «узкую» местность по своей природе (будь она представлена как разреженная) -матрица / N-полосная матрица), поэтому параллельная часть часто очень высока по сравнению с другими числовыми задачами) - Закон Амдала объясняет почему. 
Конечно, могут быть некоторые академические c -противоречивости относительно возможного небольшого различия, в случаях, когда накладные расходы на связь могут быть немного уменьшены на одного работника (-ов), но потребность в правилах обработки грубой силы в FEM / решателях сетки (затраты на связь, как правило, намного дешевле, чем крупномасштабная часть FEM-сегментированных вычислений, отправляющая небольшое количество соседних блоков данные о состоянии «граничного» узла
htop покажет вам фактическое состояние (может отметить процесс: процессорное ядро блуждает из-за трюков с тепловой / балансировкой ядра HT / CPU, которые уменьшаются итоговая производительность)
И обратитесь к meshfree поддержке их источников знаний в базе знаний о передовой практике.
В следующий раз - лучшим вариантом было бы приобрести менее ограничивающую вычислительную инфраструктуру для обработки критических рабочих нагрузок (учитывая, что в критических бизнес-условиях это считается риском гладкой BAU, тем более, если это влияет на ваш бизнес- преемственность).