Как создать, открыть и отправить на проверку вашу работу

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

Репозиторий и ветка

Сделайте форк семестрового репозитория вашей группы (процессы/потоки, направление).
Создайте ветку, имя которой точно совпадает с папкой вашей задачи: <фамилия>_<инициал>_<краткое> (например, nesterov_a_elem_vec_sum).

Предварительные требования

Установите инструменты и зависимости (см. «Инструкция → Окружение»).
Убедитесь, что вы можете сконфигурировать и собрать проект локально с помощью CMake.
Если вы работаете из форка, клонируйте свой форк и добавьте основной репозиторий курса как upstream.

Структура папки задачи (единая)

Создайте папку tasks/<фамилия>_<инициал>_<краткое>/ со следующей структурой:

common/include/common.hpp — общие типы и BaseTask:

using InType = int;        // example
using OutType = int;       // example
using TestType = std::tuple<int, std::string>; // if needed
using BaseTask = ppc::task::Task<InType, OutType>;

Реализации технологий (добавляйте только нужные в семестре): — Процессы (MPI/SEQ): seq/include, seq/src, mpi/include, mpi/src — Потоки: seq, omp, tbb, stl (аналогичное разделение include/src)

Каждая реализация определяет класс, унаследованный от BaseTask, и переопределяет ValidationImpl, PreProcessingImpl, RunImpl, PostProcessingImpl. Также добавьте:

static constexpr ppc::task::TypeOfTask GetStaticTypeOfTask() { return ppc::task::TypeOfTask::kMPI; }
// or kSEQ/kOMP/kTBB/kSTL as appropriate

Минимальный скелет (пример для SEQ):

// seq/include/ops_seq.hpp
#pragma once
#include "<last>_<initial>_<short>/common/include/common.hpp"
namespace <last>_<initial>_<short> {
class MyTaskSEQ : public BaseTask {
 public:
  static constexpr ppc::task::TypeOfTask GetStaticTypeOfTask() { return ppc::task::TypeOfTask::kSEQ; }
  explicit MyTaskSEQ(const InType& in);
 private:
  bool ValidationImpl() override;
  bool PreProcessingImpl() override;
  bool RunImpl() override;
  bool PostProcessingImpl() override;
 };
} // namespace <last>_<initial>_<short>

// seq/src/ops_seq.cpp
#include "<last>_<initial>_<short>/seq/include/ops_seq.hpp"
namespace <last>_<initial>_<short> {
MyTaskSEQ::MyTaskSEQ(const InType& /*in*/) : BaseTask(/*in*/ InType{}) {}
bool MyTaskSEQ::ValidationImpl() { return true; }
bool MyTaskSEQ::PreProcessingImpl() { return true; }
bool MyTaskSEQ::RunImpl() { /* compute */ return true; }
bool MyTaskSEQ::PostProcessingImpl() { /* write result */ return true; }
} // namespace <last>_<initial>_<short>

Тесты (единое размещение): — tests/functional/main.cpp — функциональные тесты на базе ppc::util::BaseRunFuncTests и вспомогательных функций. — tests/performance/main.cpp — тесты производительности на базе ppc::util::BaseRunPerfTests + MakeAllPerfTasks.

Пример функциональных тестов:

const auto kTasks = std::tuple_cat(
  ppc::util::AddFuncTask<MyTaskMPI, InType>(params, PPC_SETTINGS_<task_id>),
  ppc::util::AddFuncTask<MyTaskSEQ, InType>(params, PPC_SETTINGS_<task_id>)
);
INSTANTIATE_TEST_SUITE_P(..., MyFuncTests, ppc::util::ExpandToValues(kTasks), ...);

При необходимости используйте PPC_ID_<task_id> для доступа к ресурсам из data/.

Пример тестов производительности:

const auto kAllPerfTasks = ppc::util::MakeAllPerfTasks<InType, MyTaskMPI, MyTaskSEQ>(PPC_SETTINGS_<task_id>);
INSTANTIATE_TEST_SUITE_P(..., MyPerfTests, ppc::util::TupleToGTestValues(kAllPerfTasks), ...);

Советы по тестам

Делайте тесты детерминированными и укладывающимися в лимиты времени; используйте переменные окружения (см. «Инструкция → Переменные окружения») вместо задержек.
Используйте PPC_ID_<task_id> для доступа к файлам из data/.
Покрывайте крайние случаи в функциональных тестах; добавьте ровно два стиля перфтестов (task и pipeline) внутри набора.
data/ — опциональные входные файлы для тестов (например, изображения).
settings.json — включение необходимых технологий для вашего семестра, например:
```
{ "tasks_type": "processes", "tasks": { "mpi": "enabled", "seq": "enabled" } }
```

info.json — данные студента для автоматизации (scoreboard, макросы):

{ "student": { "first_name": "Имя", "last_name": "Фамилия", "middle_name": "Отчество", "group_number": "Группа", "task_number": "1" } }

Сборка и локальный запуск

Конфигурация и сборка:

cmake -S . -B build -DENABLE_ADDRESS_SANITIZER=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo
cmake --build build -j

Запуск тестов через вспомогательный скрипт:

export PPC_NUM_THREADS=4
export PPC_NUM_PROC=2
python3 scripts/run_tests.py --running-type threads --counts 1 2 4
python3 scripts/run_tests.py --running-type processes --counts 2 4
python3 scripts/run_tests.py --running-type performance

Исполняемые файлы (где искать тесты)

Исполняемые файлы генерируются в build/bin (или install/bin при установке): - core_func_tests — тесты ядра библиотеки - ppc_func_tests — функциональные тесты для всех задач/технологий - ppc_perf_tests — тесты производительности для всех задач/технологий

Runner автоматически применяет gtest‑фильтры для выбора наборов тестов по технологиям.

Pull Request

Формат заголовка (пример):

<Фамилия Имя>. Технология <SEQ/MPI/...>. <Название задачи>. Вариант <N>.
Описание должно включать: — Полное описание задачи; номер варианта; используемую технологию — Краткое описание реализации и отчёта — Чек‑лист (CI зелёный в форке, clang‑format/clang‑tidy пройдены, функциональные/перф‑тесты ок, ветка названа как директория задачи, достоверность сведений).

Шаблон PR (чек‑лист)

## Description
- Task: <Full task name>
- Variant: <N>
- Technology: <SEQ | MPI | OMP | TBB | STL | ALL>
- Summary: Brief description of your implementation and report

---

## Checklist
- [ ] CI is green in my fork (build, tests, docs)
- [ ] Task folder is named `<last>_<initial>_<short>` and matches branch name
- [ ] clang-format passed locally
- [ ] clang-tidy passed locally (no warnings/errors introduced)
- [ ] Functional tests pass locally
- [ ] Performance tests pass locally
- [ ] Report (`report.md`) is added and follows the template
- [ ] I confirm that provided information is truthful

Частые ошибки (прочтите перед отправкой)

Неверное имя папки/ветки. Должно быть <фамилия>_<инициал>_<краткое> везде.
Отсутствует или неверное значение GetStaticTypeOfTask для технологии.
Тесты зависят от случайности или задержек вместо лимитов по времени окружения.
В settings.json не включена нужная технология — тесты не запустятся.
Namespace не соответствует имени папки и конфликтует с другими.
Количество или именование перфтестов отклоняется от требуемых шаблонов.

Полезные примеры для ориентирования

Процессы: tasks/example_processes, tasks/example_processes_2, tasks/example_processes_3
Потоки: tasks/example_threads
Работайте из своего форка в отдельной ветке (не master). Имя ветки должно совпадать с именем папки задачи.

Примечания

Все классы должны находиться в уникальном пространстве имён (например, <фамилия>_<инициал>_<краткое>).
Делайте тесты детерминированными и укладывающимися в лимиты времени; используйте переменные окружения вместо задержек.
Соблюдайте стиль кода (clang-format/clang-tidy) и запускайте pre-commit локально.