LINUX.ORG.RU

Сообщения sshestov

 

Можно ли в Python вернуть значение через переменную-аргумент

Всем привет!

Хочу в Python вернуть значение в переменную, заданную через параметр-аргумент, типа такого:

diff=aspiics_optics.diffraction(header,params,msg=diff_msg)

Хочу получить наверх diff_msg. Чего-то не выходит, снаружи значение не меняется. По-видимому это связано с «передача по ссылке/передача по значение». Везде в интырнетах советуют писать типа такого и принимать кортеж

diff, diff_msg = aspiics_optics.diffraction(header,params)

Но мне чего-то так не хочется (привык я к обычным функциям, а голова уже уехала в отпуск). Есть ли простое решение?

 

sshestov
()

FFT на GPU, максимальный размер массива

Всем здравствуйте! У меня есть самописанная программа для расчета кое-какой дифракции, смысл которой состоит в многократном взятии FFT от 2Д-массивов. Необходимо, чтобы массивы были размером 4k x 4k (или больше) и комплексные. Сейчас я использую fftw и MPI-параллелизацию, при разбрасывании на 100 процессоров на кластере выходит минут 20 на одну конфигурацию.

Конечно же, хочется это дело ускорить и упростить, и поговаривают что cuda поможет. Процесс переписывания может оказаться долгий и мучительный (у меня это всё на фортране пока что) и вовсе не обязательно, что он увенчается успехом ввиду больших массивов. Вот здесь в разделе 2.8.4 вообще написано что только до 2k при комплексных 2Д.

Может кто-нибудь подсказать, правильно ли я понимаю там по ссылке, что при 2Д и комплексных числах оно только до 2k x 2k? У меня комплексные вообще двойной точности. Не будет ли возня с cudo-й слишком долгой, из-за копирования туда-сюда больших массивов?

 , ,

sshestov
()

Стала сегфолтится MPI-программа

Благородные доны, прощу совета по следующему вопросу: имеется кластер от SGI, на котором крутится какой-то модифицированный SLES. Имеется самописанная мной программа, которая использует fftw и mpi (рассчитывается дифракция при прохождении света через телескоп).

Программа успешно работала (почти целый год), но относительно недавно SLES проапгрейдили. Я не уверен, что именно это является причиной, но кажется лично я никаких других изменений не вносил в исходный код. Сама прога на фортране.

Сейчас она сегфолтится на весьма простом месте, типа

where (data <= 1.0)
  data = 0.0
elsewhere
  data = 1.0
endwhere
дата - массив само собой. Если эти строки чуть переделать (упростить), то начинает сегфолтитася на следующих строках. Т.е. по-моему это всё рандомно. Никакого особенного вывода я не вижу (идет обычный вывод и вдруг прерывается), scheduler (pbs) возвращает код 1, где-то там еще виден код возврата самой проги - 9 (интырнет говорит что сегфолт).

Изначально она компилировалась при помощи ifort 15, в качестве mpi использовалась mpt/2.12 (реализация mpi от SGI).

Опытным путем установлено, что если закомментить всё, что относится к mpi, то работает как нужно. Включение же даже mpi-инициализации типа

call MPI_INIT(ierr)
call MPI_COMM_RANK(MPI_COMM_WORLD,my_id,ierr)
call MPI_COMM_SIZE(MPI_COMM_WORLD,num,ierr) 
приводит к тому самому последующему сегфолту (через много строк).

Пробовал понижать -O, разные комбинации версий компилятора и mpt. Эффект тот же.

Прога успешно работает на другом компе попроще с gfortran/openmpi. Но именно их на кластере нет. Кто что посоветует? Как выявить источник проблемы?

Буду признателен за советы.

 , ,

sshestov
()

VisIt - не работает в режиме клиент-сервер

Здравствуйте

Использую VisIt для разглядывания результатов МГД-симуляции. Данные сидят на машине trunk (ubuntu 12 LTS; версии VisIt пробую разные - 2.8.2, 2.9.1, 2.9.2), смотрю их с различных машин.

Пока работало, оно работало так: запускаю VisIt локально, в нем создаю профиль удаленной машины trunk. В меню открытия файлов указываю trunk, оно чего-то там пыщь-пыщь, возможно пароль ssh, «launch metadata server» ... и вижу данные на ней.

Теперь, с обновлением версии VisIt локально и, видимо, с обновлением ubuntu зависает на стадии «launching metadata server» В процессах так:

31838 ?        Ss     0:00  |       \_ /usr/local/visit/bin/../current/linux-x86_64/bin/python /usr/local/visit/bin/frontendlauncher.py /usr/local/visit/bin/visit -v 2.9 -vcl -debug 5 -noloopback -sshtunneling -host localhos
31847 ?        S      0:00  |           \_ /usr/local/visit/2.9.1/linux-x86_64/bin/vcl -debug 5 -noloopback -sshtunneling -host localhost -port 28806 -key 2accd4caf640
31848 ?        Z      0:00  |               \_ [vcl] <defunct>

При этом на сервере появляется такой лог:

/usr/local/visit/2.9.1/linux-x86_64/bin/vcl -noloopback -sshtunneling -host localhost -port 28806 -key 2acc267d4cbe455af640
VisIt component launcher started.
ParentProcess::Connect: Called with (numRead=1, numWrite=2, argc=9, argv={/usr/local/visit/2.9.1/linux-x86_64/bin/vcl, -noloopback, -sshtunneling, -host, localhost, -port, 28806, -key, 2accbe640})
ParentProcess::Connect: hostName = localhost
ParentProcess::GetHostInfo: Calling gethostbyname("localhost")
ParentProcess::Connect: port = 28806
ParentProcess::Connect: securityKey = 2acc267d4cbe455af640
ParentProcess::Connect: Creating sockets
ParentProcess::Connect: Creating read sockets
ParentProcess::GetClientSocketDescriptor: Set up using port 28806
ParentProcess::GetClientSocketDescriptor: Creating a socket
ParentProcess::GetClientSocketDescriptor: Setting socket options
ParentProcess::GetClientSocketDescriptor: Calling connect
(If you see no messages after this one, VisIt was not
able to connect to the client machine.  Nine times out
of ten, this is a firewall issue on the client machine.
It could also mean that VisIt was unable to resolve the
IP address for the client machine.  You may need to verify the contents of /etc/hosts.)
ParentProcess::GetClientSocketDescriptor: Connected socket
ParentProcess::Connect: Creating write sockets
ParentProcess::GetClientSocketDescriptor: Set up using port 28806
ParentProcess::GetClientSocketDescriptor: Creating a socket
ParentProcess::GetClientSocketDescriptor: Setting socket options
ParentProcess::GetClientSocketDescriptor: Calling connect
(If you see no messages after this one, VisIt was not
able to connect to the client machine.  Nine times out
of ten, this is a firewall issue on the client machine.
It could also mean that VisIt was unable to resolve the
IP address for the client machine.  You may need to verify the contents of /etc/hosts.)
ParentProcess::GetClientSocketDescriptor: Connected socket
ParentProcess::GetClientSocketDescriptor: Set up using port 28806
ParentProcess::GetClientSocketDescriptor: Creating a socket
ParentProcess::GetClientSocketDescriptor: Setting socket options
ParentProcess::GetClientSocketDescriptor: Calling connect
(If you see no messages after this one, VisIt was not
able to connect to the client machine.  Nine times out
of ten, this is a firewall issue on the client machine.
It could also mean that VisIt was unable to resolve the
IP address for the client machine.  You may need to verify the contents of /etc/hosts.)
ParentProcess::GetClientSocketDescriptor: Connected socket
ParentProcess::Connect: Exchanging type representations.
ParentProcess::Connect: done
Xfer::Process: Opcode=4, len=118, type=LaunchRPC
Executing LaunchRPC
LaunchService::LaunchProcess: start
LaunchService::LaunchProcess: LaunchRPC command = visit, args=(-v 2.9 -mdserver -debug 5 -noloopback -host localhost -port 25832 -key 2acc267d4cbe455af640 -sshtunneling )
LaunchService::LaunchProcess: end
Xfer::Update: Sending: opcode=5, name=VisItRPC::RPCReply (from LaunchRPC)
Child 0 needs to be read (desc=11)
Lost connection to child 0

Все это получается при работе из виртуалки+Ubuntu14LTS с рабочего компа. Однако, виртуалка не при чем, тот же эффект с других машин с нативной убунтой. На ноуте стоит VisIt 2.8.0 и все работает, боюсь на него дыхнуть; при использовании 2.8.0 локально появляются другие проблемы, поэтому тож не вариант.

Официальный FAQ (from here https://wci.llnl.gov/simulation/computer-codes/visit/faqs/faq16) читал, но не помогло. В интырнетах забанили.

Какие-нибудь идеи? Прошу по существу. Спасибо.

 

sshestov
()

RSS подписка на новые темы