Подходы к построению проблемно-ориентированных интерфейсов для пакетов прикладных программ в ГридННС презентация

П. Гулин, А. К. Кирьянов, Н. В. Клопов,
С. Б. Олешко, Ю. Ф. Рябов

ПИЯФ

с сертификатами
и управление заданиями)

ППИ
для
заданий

ППИ
для
файлов

ППИ
для
виджетов

Плагин
ПОИ

общими свойствами:
Пакет состоит из одного основного приложения (часто – MPI) и набора вспомогательных средств;
Входные данные нужно подготовить (перевести в правильный формат);
Параметры обработки многочисленны и обычно находятся в отдельном текстовом конфигурационном файле;
Во время обработки создаётся набор фалов, некоторые из которых являются промежуточными.

управления внешними хранилищами в ВИГ нет и, как показывает практика, приложений, требующих работы с ними, тоже;
Для плагинов ППИ не выделяется какое-либо отдельное место в файловой системе;
Целесообразным представляется группировать файлы, относящиеся к конкретному ППИ в подкаталоге с его именем, не засоряя корень домашнего каталога;
Выбор входных файлов для заданий при этом ограничивать подкаталогом ППИ не следует, а вот выходные файлы стоит сохранять в отдельном подкаталоге с уникальным именем, чтобы избежать конфликтов в случае человеческой ошибки.

встретить понятие «проекта». В рамках проекта производится конкретное исследование, хранятся все относящиеся к нему файлы и конфигурация;
Для ППИ такой подход практически всегда оправдан, поскольку результатом выполнения задания всегда являются несколько файлов (журналы работы, выходные и промежуточные данные);
Переключение между проектами в ПОИ должно приводить к смене контекста, чтобы пользователь не запутался в собственных данных. При этом лучше иметь возможность клонировать проекты, чем разделять одни и те же файлы между несколькими.

производить операции над проектами и файлами в их каталогах, а также запускать проект на счёт.

для работы с ними – одна из основных задач ПОИ;
Пользователь пакета, знающий предметную область, обычно хорошо представляет себе смысл конфигурационных параметров, поэтому подробное их описание в интерфейсе не требуется;
Некоторые конфигурационные параметры могут зависеть от других. Такие комбинации желательно обрабатывать автоматически, чтобы исключить человеческую ошибку.

более того, разные этапы могут требовать выполнения программ разной архитектуры (MPI, не-MPI);
СУВЗ ГридННС не позволяет выполнять программы разной архитектуры в рамках одной элементарной задачи, в таком случае требуется определить сложное задание с несколькими последовательно выполняющимися задачами;
Передача промежуточных данных между этапами обычно происходит через файлы. Проверка правильного именования файлов на разных этапах должна быть автоматизирована;

при этом, если задание было подготовлено через объект редактора НАГ, то описание задания в формате JSON может быть получено через метод text(). Сохранять описание задания в виде файла при запуске не требуется;
После запуска ход выполнения задания можно отслеживать в общей таблице заданий ВИГ;
Поскольку передача файлов с результатами работы происходит автоматически, при завершении задания они могут быть созданы непосредственно в каталоге проекта.