Overview and architectural principles

Architecture documentation section of TMC Suite. Purpose of the package, key principles of code and build organization, technology stack.

1. Purpose of the package

TMC Suite is a set of programs for electrodynamic modeling of planar structures and visualization of the results. Its origin is an original scientific development (author K. N. Klimov).

The package addresses two major tasks:

1. Computation — the compute kernels model the propagation of the electromagnetic field in planar structures using the method defined in the source code (H-polarization and X-mode) and produce output data: scattering matrices (S-matrices), field distributions, and time signals.
2. Visualization — the viewers and FieldView display the results: S-matrix frequency responses, radiation patterns, time signals and fields in 2D/3D.

2. Type of architecture

TMC Suite is a set of standalone Windows desktop applications joined by:

• a common set of static libraries (reuse of code for reading files, complex arithmetic, expression parsing, etc.);
• common file formats (the programs exchange data through files on disk, not through shared memory or IPC).

Each program launches and runs independently. They communicate through files: one application writes a file, another reads it. This is a classic file-based pipeline; see Data flow.

            ┌────────────────────────┐
            │   6 static .lib files   │   ← shared reusable code
            └───────────┬────────────┘
                        │ linking
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
   Compute kernels    Viewers        FieldView
   (.exe)             (.exe)         (.exe, OpenGL)
        │               ▲               ▲
        └──── files ─────┴──── files ───┘

3. Key architectural principles

3.1. Shared sources, separate builds

A single set of source code lives in src/. The outputs of the two platforms go to separate folders:

• win32 → dist/win32/lib, dist/win32/bin
• win64 → dist/win64/lib, dist/win64/bin

Source code is never duplicated per platform. See Build architecture for details.

3.2. Separation of "computation vs. visualization"

The compute kernels and the viewers are different programs. A kernel does not draw graphs; a viewer does not compute. This makes it possible to:

• run the heavy computation separately (including long runs, with no GUI load);
• view finished results again, without recomputation;
• develop visualization independently of the math.

3.3. Reuse through static libraries

Common functionality (reading/writing S-files, complex arithmetic, expression parsing, error handling, the preprocessor, topology / induced-current computation) is extracted into 6 static libraries. Each program links against the subset it needs; see Dependencies.

3.4. Untouchable math and shared headers

• Do not change the computation math without explicit permission — it is scientific code.
• Do not edit the shared headers for the sake of individual configurations. For example, the X-mode is enabled through 6 preprocessor macros in the project settings, not by editing Typerth.h / Tmcgrviw.h — otherwise the H-mode and the viewers would break.

3.5. Preserving the original encoding

The source files contain Russian comments (likely Windows-1251). The encoding is preserved as is and is not changed without verification.

4. Technology stack

Historical note

The package used to be built for win16 and win32 (old code from early Visual C++ versions). The win64 build is a new task: it required targeted width fixes (pointers do not fit into int, LONG → LONG_PTR in MFC, no inline assembly, removal of win16-type remnants). The porting strategy is to first fully build win32, then fix 64-bit errors one by one. See Build architecture and the porting log docs/build-guide/.../08-porting-changes.