Процесс зависает перед завершением с человечностью 18.04
При использовании ABAQUS 6.14 (но также и 2018 ABAQUS) на человечности 18.04 все, кажется, хорошо работает кроме завершения standard процесс (процесс, запущенный при выполнении неявного анализа - если Вы не знакомы с этим, он не имеет значения).
Анализ действительно работает, как можно также видеть в файле журнала ( .sta файл, для тех, кто знаком с abaqus), сообщение THE ANALYSIS HAS COMPLETED SUCCESSFULLY. Выходная база данных содержит результаты анализа. Однако после того, как анализ был завершен, процесс standard остается в состоянии сна с помощью 0% ЦП и сохраняя ту же сумму RAM как тогда, когда это работало.
От strace Я добираюсь:
[pid 23191] close(8) = 0
[pid 23185] <... select resumed> ) = 0 (Timeout)
[pid 23185] select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=50000} <unfinished ...>
[pid 23193] <... select resumed> ) = 0 (Timeout)
[pid 23193] futex(0x7f3acd917db0, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 23191] futex(0x7f3acd917db0, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
[pid 23193] <... futex resumed> ) = 0
[pid 23191] <... futex resumed> ) = -1 EAGAIN (Resource temporarily unavailable)
[pid 23191] futex(0x7f3acd917db0, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>
[pid 23191] munmap(0x7f3ab130b000, 327680) = 0
[pid 23191] munmap(0x7f3ab136b000, 1114112) = 0
[pid 23191] munmap(0x7f3ab16db000, 1114112) = 0
[pid 23191] munmap(0x7f3ab0fbb000, 1114112) = 0
[pid 23191] munmap(0x7f3ab0ddb000, 1114112) = 0
[pid 23191] munmap(0x7f3ab0a0b000, 1114112) = 0
[pid 23191] munmap(0x7f3ab03fb000, 1114112) = 0
[pid 23191] munmap(0x7f3ab050b000, 1114112) = 0
[pid 23191] munmap(0x7f3ab00cb000, 1114112) = 0
[pid 23191] munmap(0x7f3ab02eb000, 1114112) = 0
[pid 23191] munmap(0x7f3ab14eb000, 1114112) = 0
[pid 23191] futex(0x7f3ab8a5dd44, FUTEX_WAIT_PRIVATE, 8, NULL) = -1 EAGAIN (Resource temporarily unavailable)
[pid 23191] futex(0x7f3ab8a5dd44, FUTEX_WAIT_PRIVATE, 12, NULL <unfinished ...>
[pid 23193] <... select resumed> ) = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000}) = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>
[pid 23185] <... select resumed> ) = 0 (Timeout)
[pid 23185] select(10, [5 6 8 9], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>
[pid 23193] <... select resumed> ) = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>
[pid 23185] <... select resumed> ) = 0 (Timeout)
[pid 23185] select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=50000} <unfinished ...>
[pid 23193] <... select resumed> ) = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000}) = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>
[pid 23185] <... select resumed> ) = 0 (Timeout)
[pid 23185] select(10, [5 6 8 9], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>
[pid 23193] <... select resumed> ) = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>
[pid 23185] <... select resumed> ) = 0 (Timeout)
[pid 23185] select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=50000} <unfinished ...>
[pid 23193] <... select resumed> ) = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000}) = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000}) = 0 (Timeout)
[pid 23193] select(7, [4 5 6], NULL, NULL, {tv_sec=0, tv_usec=20000} <unfinished ...>
Как то, если два процесса были в состоянии мертвой блокировки. Кроме того, команды
pid -p 7002
и
pid -p 7010
действительно дайте пустой вывод. Директора /proc/7002 и /proc/7010 не существовать.
Единственное abaqus-связанное выполнение процессов
david 6995 0.0 0.1 295428 51388 pts/0 S 17:00 0:00 /opt/abaqus/6.14-1/code/bin/python /opt/abaqus/6.14-1
david 6998 0.0 0.2 368744 97948 pts/0 S 17:00 0:00 /opt/abaqus/6.14-1/code/bin/python std_inst.com
david 7001 0.1 0.0 122076 20096 pts/0 Sl 17:00 0:03 /opt/abaqus/6.14-1/code/bin/eliT_DriverLM -job std_in
david 7008 0.4 0.5 735812 185364 pts/0 Sl 17:00 0:07 /opt/abaqus/6.14-1/code/bin/standard -standard -acade
На человечности 16.04 та же самая версия работает как очарование. Здесь то же strace на человечности 16.04 (с той же версией ядра как мои 18.04, т.е. 4.15.0-29):
3890 close(8) = 0
3892 <... select resumed> ) = 0 (Timeout)
3892 futex(0x7f29e43e1db0, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
3890 futex(0x7f29e43e1db0, FUTEX_WAKE_PRIVATE, 1) = 0
3892 <... futex resumed> ) = -1 EAGAIN (Resource temporarily unavailable)
3892 futex(0x7f29e43e1db0, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
3890 futex(0x7f29e43e1db0, FUTEX_WAKE_PRIVATE, 1) = 0
3892 <... futex resumed> ) = -1 EAGAIN (Resource temporarily unavailable)
3892 futex(0x7f29e43e1db0, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
3890 futex(0x7f29e43e1db0, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
3892 <... futex resumed> ) = 0
3890 <... futex resumed> ) = -1 EAGAIN (Resource temporarily unavailable)
3890 futex(0x7f29e43e1db0, FUTEX_WAKE_PRIVATE, 1) = 0
3892 select(7, [4 5 6], NULL, NULL, {0, 20000} <unfinished ...>
3890 munmap(0x7f29c7adb000, 327680) = 0
3890 munmap(0x7f29c7b3b000, 1114112) = 0
3890 munmap(0x7f29c7eab000, 1114112) = 0
3890 munmap(0x7f29c778b000, 1114112) = 0
3890 munmap(0x7f29c75ab000, 1114112) = 0
3890 munmap(0x7f29c71db000, 1114112) = 0
3890 munmap(0x7f29c6bcb000, 1114112) = 0
3890 munmap(0x7f29c6cdb000, 1114112) = 0
3890 munmap(0x7f29c689b000, 1114112) = 0
3890 munmap(0x7f29c6abb000, 1114112) = 0
3890 munmap(0x7f29c7cbb000, 1114112) = 0
3890 exit_group(0) = ?
3891 +++ exited with 0 +++
3893 +++ exited with 0 +++
3892 +++ exited with 0 +++
3890 +++ exited with 0 +++
3880 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 3890
3880 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3890, si_uid=1000, si_status=0, si_utime=107, si_stime=7} ---
У кого-то есть хорошая идея, как решить это? Или в котором должно направление, я занимаюсь расследованиями далее.
4 ответа
В этом месяце система Dassaults опубликовала исправление ошибки:
Вам необходимо обновить Abaqus 2018 до Abaqus 2018-HF16. из https://software.3ds.com/ более подробную информацию можно найти на https://github.com/willfurnass/abaqus-2017-centos-7-singularity/issues/5# issue-713025844
Я попробовал обновить Abaqus 2020 до Abaqus 2020-HF5, и это сработало как для Ubuntu 20.04, так и для Fedora 32.
Я встретил эту проблему с Linux Mint 19 также. Abaqus 6.14-5 установленных в Linux Mint 19. Это не может быть завершено автоматически, но замеченная форма .sta файл, анализ завершается. Я думаю, что эта проблема связана с ядром. Между прочим, Вы находите какие-либо решения теперь?
Я нашел решение, которое обходит мертвую блокировку при помощи контейнера особенности, как предложено Will Furnass здесь: http://learningpatterns.me/posts-output/2018-01-30-abaqus-singularity/
Хотя немного сложный во-первых, это работает как очарование когда установка правильно. Я изменил свои псевдонимы для abaqus в моей хост-системе (Manjaro/Arch Linux) таким образом, что они указывают на установку в контейнере особенности и выполняют команду в среде контейнеров. Однако, так как мне нужен Intel Fortran Compiler, я генерировал основные песни 7 контейнеров и изменил его впоследствии для установки компиляторов и abaqus (v2019 в этом случае) вместо того, чтобы использовать .def сценарий, как предложено Will Furnass.
Это занимает время для установки, но теперь у меня есть контейнерное изображение, с которым я могу работать в любой системе, которая выполняет особенность, которая довольно хороша :)
Править: Я также протестировал копирование рабочей установки на более свежей системе Linux (и предотвращение новой установки abaqus), я могу подтвердить, что это не работало в моем случае (Установка CentOS 7, скопированная в систему Manajaro).
Я хотел бы представить свою работу вокруг для этой проблемы. Я сделал обертку Python для abq2018 решателя, который проверяет .sta файл на полноту. После того как .sta файл завершен, любой процесс, названный стандартом, будет уничтожен. Я нашел, что решатель выходит корректно, когда стандарт уничтожается, и анализ завершен.
Эта работа вокруг не является идеальным решением. Текущие проблемы с этой работой вокруг:
- не может заменить abq2018 вызов решателя непосредственно
- не будет работать от GUI, должен быть выполнен от оболочки
- только задание синтаксических анализов = аргумент
- можно только выполнить один анализ в во время, так как все стандартные процессы уничтожаются
- abq зависнет навсегда, если .sta файл не будет создан или изменен
Как использовать это обходное решение:
- Создайте файл Python, названный abq. Код для abq подробно изложен ниже. Если Вы используете решатель кроме abq2018, заменяете строку cmd = 'abq20xx.. с решателем, который Вы используете.
- Сделайте abq исполняемый файл и доступный в Вашем пути. Я поместил abq в папку команд Abaqus, затем работал
chmod +x abq - Выполните задание стандарта Abaqus путем выполнения
abq job=Job-1. Это выполнит Задание-1.inp, затем это уничтожит стандартный решатель, после того как Задание-1.sta завершается.
Код для abq ниже
#!/usr/bin/python
import subprocess
import sys
import time
arguments = sys.argv
jobname = arguments[1].split('job=')[-1]
cmd = 'abq2018 cpus=4 ask_delete=OFF background job=' + jobname
p = subprocess.call(cmd, shell=True)
complete = False
termination_criteria = [' THE ANALYSIS HAS COMPLETED SUCCESSFULLY\n',
' THE ANALYSIS HAS NOT BEEN COMPLETED\n']
while complete is False:
# wait every 5 seconds
time.sleep(5)
try:
with open(jobname + '.sta', 'r') as f:
last = f.readlines()[-1]
if last in termination_criteria:
# this will kill any process named standard
subprocess.call('pgrep standard | xargs kill', shell=True)
complete = True
except IOError:
# model.sta has been deleted or doesn't exist
# try again in 5 seconds
time.sleep(5)