0018 — The OpenCL sources are never compiled

ID	0018
Class	ARCHITECTURE
Severity	1
Status	blocked
Models	Net/NetStructure
Found	2026-09-15 audit (e3f3107)
Decision needed	"delete the OpenCL sources" or "keep them, mark as dormant in the documentation".

Evidence

src/net/CMakeLists.txt:104-109

target_sources(${TARGET}
    PRIVATE
    ${Net_SRC}
    ${Appendage_SRC}
    ${OpenCL_based_SRC}
)

OpenCL_based_SRC is never set — a grep across every CMakeLists.txt and .cmake in the repository finds this one reference and no definition — so it expands to nothing. NetStructureOCL.cpp, NetPanelForcesOcl.cpp and netpanelforces.c appear in neither Net_SRC (src/net/CMakeLists.txt:45-70) nor Net_HDR (:72-99).

The guarded include has the same problem from the other side — src/fhsim_marine_elements.h:40-42:

#ifdef OPENCL_FOUND
#  include "net/NetStructureOCL.h"
#endif

OPENCL_FOUND is never defined anywhere in the build (no find_package(OpenCL), no target_compile_definitions setting it, nothing in conanfile.py), so the include is unreachable. NetStructureOCL is also not registered as a type string (src/fhsim_marine_elements.cpp has no row for it).

Effect

Three source files and a header are carried in the tree, installed as public headers by the install(DIRECTORY src/ … PATTERN "*.h") rule in src/CMakeLists.txt, and never built on any platform or configuration. A reader cannot tell this from reading them, and a maintainer editing them gets no compiler feedback at all — so they have been free to rot. src/net/NetStructureOCL.h already shows one symptom: it includes environment/IBasicBottom.h, an un-namespaced path unlike the <fhsim_environment/...> spelling the maintained classes use, which would not compile today.

Possible fix

• (a) Delete src/net/NetStructureOCL.{h,cpp}, src/net/NetPanelForcesOcl.{h,cpp}, src/net/netpanelforces.c, the ${OpenCL_based_SRC} line and the OPENCL_FOUND block.
• (b) Wire it up: find_package(OpenCL), set OpenCL_based_SRC and OPENCL_FOUND under it, add the registration row, and fix whatever no longer compiles.

Owner question, open

is GPU panel-force evaluation on the roadmap? If it is, (b), accepting that it is real work — the include paths alone show the code predates the 3.x environment interface. If it is not, (a), and the code stays recoverable from git history.

Test that would prove it

The absence of the target is the evidence. Under (b), the test is that the library builds with OpenCL found and SimObject.NetStructureOCL_* agrees with the CPU Net/NetStructure on a shared fixture — which is also the only thing that would establish the GPU path is correct.

Risk

Option (a) removes installed public headers, which is a packaging change even though nothing can be using them. Option (b) introduces an optional dependency and a configuration that CI would then have to cover, or it rots again.

---

Why not solved (fix pass 2026-09-15)

Re-confirmed at HEAD: the OpenCL sources are never compiled because OpenCL_based_SRC is undefined and OPENCL_FOUND is never set by any CMake file. Deleting the sources discards a GPU path someone may intend to revive; wiring them up requires an OpenCL toolchain, a build option and validation that the kernels still match the CPU implementation. That is a roadmap decision, not a fix. Smallest owner decision: "delete the OpenCL sources" or "keep them, mark as dormant in the documentation".

---