Development Roadmap for 2026 and beyond

[echoi]

Chase

Decision Gates: The following decisions must be confirmed before dependent implementation items can proceed.

1. Decision 1: Adopt SYCL (AdaptiveCPP) as the GPU backend
   This is the most consequential architectural decision in the roadmap. Confirmation unlocks or reframes several downstream items:

   • C++17 upgrade becomes a hard requirement
   • SoA memory layout refactor becomes higher priority
   • apply_bc_vel interface cleanup scope is defined by this decision
   • If declined, a long-term maintenance strategy for OpenACC must be separately evaluated

Implementation

1. Reorganize repository folder structure

   • Establishes clear module boundaries that reduce merge conflicts during large-scale changes
   • Lowers onboarding cost — directory structure serves as implicit documentation
   • The earlier this is completed, the less friction all downstream work encounters

2. Upgrade minimum C++ standard to C++17 ← Requires Decision 1

   • SYCL/AdaptiveCPP requires C++17 as a language prerequisite
   • Establishes a consistent language baseline across the codebase (if constexpr, structured bindings, std::optional, etc.)
   • Modern compilers provide better auto-vectorization and optimization support under C++17
   • Lays groundwork for future adoption of C++20 concepts for stricter template constraints

3. Refactor array2D memory layout from AoS to SoA ← Requires Decision 1, Item 2

   • SoA places fields of the same type contiguously in memory, significantly improving GPU coalesced access hit rates
   • A prerequisite for efficient SYCL kernel execution — irregular access patterns in AoS are especially costly on GPU
   • Also benefits CPU-side SIMD vectorization (AVX-512, NEON)
   • C++17 features make the refactor itself cleaner to express

4. Refactor apply_bc_vel time-varying boundary velocity ← Requires Decision 1

   • Cleans up the existing OpenACC interface before migration, preventing technical debt from carrying into SYCL
   • Decouples boundary condition logic from GPU offload regions, reducing data locality issues
   • Improves testability — boundary logic can be unit tested independently of the GPU environment
   • Provides a well-defined interface boundary that simplifies the subsequent SYCL migration

5. Migrate GPU backend from OpenACC to SYCL (AdaptiveCPP) ← Requires Items 2, 3, 4

   • SYCL is an open standard (Khronos Group), vendor-neutral, and supports NVIDIA, AMD, Intel GPUs, and CPUs from a single source
   • AdaptiveCPP is actively developing Apple GPU support, enabling GPU workloads to run natively on Apple Silicon (M-series) — a platform OpenACC has no roadmap for
   • OpenACC's ecosystem has been shrinking; SYCL's toolchain and community continue to grow, reducing long-term maintenance risk
   • With SoA and apply_bc_vel cleanup in place, SYCL kernel memory access patterns are well-structured and easier to profile and optimize

6. Two-phase flow ← Requires Decision 2

   • Physical model validation can begin on the existing OpenACC codebase — this item does not depend on the SYCL migration and can run in parallel
   • Once validated, the implementation can be ported to SYCL for cross-platform and performance benefits
   • Significantly expands the simulation's physical scope (gas-liquid interfaces, free surfaces, cavitation, etc.)
   • Parallel execution with Item 5 reduces overall project timeline risk

7. Periodic gravity (Tidal force) ← Requires Item 5

   • Implementation is relatively self-contained with low invasiveness to the existing solver — a good candidate for the first physics extension after SYCL stabilizes
   • Enables tidal-driven flow simulations, opening use cases in ocean engineering and estuarine dynamics
   • Serves as an additional correctness benchmark for validating the SYCL migration end-to-end

Eunseo

1. Refactoring stress update

   • How about grouping elements by rheology types and then starting element loop for each type?
   • "factory-plugin" style rheological model implementation

2. Output file organization

   • maybe outputs should be written to a folder by default?
   • Saving a copy of a complete input parameter file?
   • Policy for cleaning before writing when the same name files exist. Or leave it to users?

3.   Documentation

   • More cookbooks and tutorials
   • Comprehensive input parameter list and description, cross-linking with cookbooks and tutorials.

4. Making input file generation easier

   • Keep maintaining https://geoflac.github.io/des-inputgen/?
   • AI Chatbot style input generator?

5. Remeshing

   • Robustness test for MMG
   • Whether to adopt mmg as a default optimizer
   • If adopted, we include it in the build procedure rather than leave the installation to users.
   • Better options?

Sungho

1. Multiphysics coupling (Thermal–Hydraulic–Mechanical)

   • Add missing thermo-mechanical terms that are commonly needed: shear heating, volumetric (adiabatic) heating/cooling, and thermal stress / thermoelastic coupling.
   • It might be helpful to define these as modular “source-term” components so new physics can be added without touching too many core loops.

2. Poroelasticity + injection/production source terms

   • I’m currently implementing poroelasticity, and one extension I’m considering is allowing injection/production at arbitrary points (or small regions) with user-defined schedules (rate/pressure vs time).
   • Related idea: a general framework for point/line/region source terms that can be reused across mass/energy equations.

3. Monitoring points / diagnostics

   • Adding “monitoring points” defined at arbitrary coordinates to sample nodal/cell data and write time series outputs. This is not only for validation or debugging — for large models, extracting full spatial time series can be expensive, so having time series at a few selected points is extremely helpful for quick inspection and plotting.
   • This is almost finished on my side.

4. Web / cloud workflow (UX)

   • A web-based workflow where users enter inputs on a website, run in a cloud/containerized environment, and view basic outputs/plots could be a nice direction.
   • I am currently discussing this with technician Youngchae Kim at Keygam.