Ratel: Multi-Domain Research Artifacts

• Ratel is a term that designates diverse research tools including a GPU-enabled finite element solver for fracture simulation, a DBMS fuzzer, an SGX enclave binary translator, and a graph theory co-author.
• In computational solid mechanics, Ratel employs matrix-free finite element methods with Bayesian calibration to simulate high-fidelity finite-strain, phase-field fracture on large GPU clusters.
• Its implementations in enterprise DBMS fuzzing and trusted execution demonstrate innovative coverage analysis and complete instruction-level interposition for improved software verification.

Searching arXiv for papers referring to “Ratel” across domains to ground the article in cited sources. Search query: Ratel arXiv

Ratel is a name used for several unrelated research artifacts and, in one case, for a researcher’s surname. In recent arXiv literature, it denotes a GPU-enabled solid mechanics finite element software used for finite-strain phase-field fracture simulation and uncertainty-aware calibration, a coverage-guided fuzzer for enterprise-level DBMSs, and a dynamic binary translation engine for Intel SGX enclaves designed for complete instruction-level interposition and binary compatibility. In graph-theoretic work on adjacency labeling for Cartesian products, “Ratel” appears as the third coauthor of an earlier Journal of Graph Theory paper rather than as a software system (Schmid et al., 29 Aug 2025, Wang et al., 2021, Cui et al., 2021, Esperet et al., 2022).

1. Taxonomy of usages

The cited literature places the name in separate technical lineages. The term therefore has no single domain-independent definition; its meaning is fixed by disciplinary context.

Usage of “Ratel”	Research context	Defining description
Ratel	Computational solid mechanics	GPU-enabled solid mechanics finite element software and DNS engine
Ratel	DBMS fuzzing	Coverage-guided fuzzer for enterprise-level DBMSs
Ratel	Trusted execution and binary compatibility	Dynamic binary translation engine inside Intel SGX enclaves
Ratel	Graph theory authorship	Surname of a coauthor in degeneracy-based adjacency labeling work

This multiplicity is not merely terminological. Each usage refers to a different layer of the computing stack: specimen-scale nonlinear mechanics, software testing infrastructure, instruction-level enclave mediation, and graph-theoretic structural analysis. A plausible implication is that citations to “Ratel” require domain qualifiers to avoid ambiguity.

2. Ratel in computational solid mechanics

In computational mechanics, Ratel is a high-performance, performance-portable solid mechanics library built on matrix-free finite element technology, p-multigrid preconditioning, libCEED, and PETSc, and is explicitly designed to run efficiently on modern heterogeneous architectures, including large numbers of NVIDIA GPUs (Schmid et al., 29 Aug 2025). In the cited study it serves as the direct numerical simulation engine for 3D, finite-strain, phase-field fracture analyses of bonded granular materials derived from CT scans of cylindrical specimens. The computational meshes contain about 2.3–2.9 million tetrahedral elements and roughly 12–15 million total degrees of freedom, and the production runs are executed on up to 40 NVIDIA Volta V100 GPUs.

The constitutive setting implemented in Ratel is a monolithically coupled finite-strain hyperelastic plus phase-field damage model. The elastic strain energy density is written in terms of the Eulerian logarithmic strain tensor,

$$\psi(\boldsymbol{e}^e) \equiv \frac{1}{2} \boldsymbol{e}^e : \mathsf{C} : \boldsymbol{e}^e,$$

and brittle damage is represented by an Ambrosio–Tortorelli AT2-type scalar phase field $\phi \in [0,1]$ with degraded elastic energy

$g(\phi) = (1 - \eta)(1 - \phi)^2 + \eta .$

The implementation includes viscous regularization, residual stiffness, quasi-static momentum balance, and frictional contact boundary conditions with a baseline Coulomb coefficient $\mu = 0$ and viscous damping $F_v = 0.01\ \text{N·m/s}$.

Ratel’s role in the calibration workflow is computationally central. Hundreds of high-fidelity simulations are used to calibrate the matrix parameters $$\boldsymbol{\theta} = [E^{(M)}, G_c^{(M)}, \xi^{(M)}]$$ against experimental unconfined compression data. From each simulation, the quantities of interest are the initial slope $m$, peak force $F$, and displacement at peak force $d_F$, giving a surrogate target map

$$\boldsymbol{\theta} \mapsto \boldsymbol{m}(\boldsymbol{\theta}) = [m, F, d_F].$$

A polynomial chaos expansion with multivariate Legendre polynomials and total order $\phi \in [0,1]$0 in dimension $\phi \in [0,1]$1 is then fit to the Ratel-generated database, and Bayesian inference is carried out with PyMC and MCMC using 4 chains of 50,000 steps each. Each full quasi-static compression simulation takes about 2–4 hours on 40 V100 GPUs, which is what makes the surrogate-based calibration and uncertainty quantification workflow practically feasible.

The physical study for which Ratel is used concerns mock high explosives composed of 95 wt% Idoxuridine grains, 2.5 wt% BDNPA/F, and 2.5 wt% Estane-5703 binder. The calibrated simulations reproduce the initial elastic response, progressive damage nucleation in the matrix near grain boundaries aligned with loading, and gradual peak and post-peak softening without large force drops. The reported findings are that manufacturing temperature influences the elastic response, with higher temperatures yielding a stiffer response, whereas the initial configuration of the grains has a negligible impact on the overall behavior, although local damage accumulation could still be altered.

3. Ratel in enterprise-level DBMS fuzzing

In software testing, Ratel is an industry-oriented, coverage-guided fuzzer for enterprise-level DBMSs such as Huawei GaussDB, Bloomberg Comdb2, and PostgreSQL (Wang et al., 2021). Its design is organized around three obstacles identified in industrial DBMS fuzzing practice: collecting precise coverage in large distributed systems, generating robust inputs for complex SQL dialects, and analyzing root causes in stateful multi-process executions. The implementation spans Rust, C, and C++, with LLVM-based instrumentation passes, a Rust orchestration layer using tokio, and parsing and generation logic adapted from Squirrel.

Its coverage subsystem replaces AFL-style hashed edge bitmaps with bijective block mapping and inter-binary coverage linkage. Each basic block is assigned a unique counter index in a global coverage array, eliminating collisions, and critical CFG edges are modeled by inserting dummy basic blocks to refine branch sensitivity. Coverage is collected across multiple binaries and processes rather than only a single server process. The fuzzing loop combines AST-based generation, relaxed syntax checks, dictionary-guided mutation with DBMS-specific keywords, and corpus enrichment from valid sub-AST fragments extracted from interesting inputs. This is paired with an online anomaly-analysis pipeline based on ptrace, ring-buffered stdout/stderr capture, coverage snapshots, stack traces, and deduplication keyed by coverage and call-stack similarity.

The reported quantitative gains are substantial. Relative to industrial black-box fuzzers SQLsmith and SQLancer, and the academic coverage-guided fuzzer Squirrel, Ratel covered 38.38%, 106.14%, and 583.05% more basic blocks than the best results of the other three fuzzers in GaussDB, PostgreSQL, and Comdb2, respectively. It also discovered 32 unknown bugs in GaussDB, 42 in Comdb2, and 5 in PostgreSQL. The case studies include a PostgreSQL client-side null-pointer crash involving pg_cancel_backend and a Comdb2 stack-use-after-scope bug triggered during schema change, both of which depended on deeper dialect-specific or state-dependent execution paths than the competing fuzzers reached.

4. Ratel in Intel SGX enclaves

In trusted execution research, Ratel is a dynamic binary translation engine running inside Intel SGX enclaves on Linux, built by porting and adapting DynamoRIO into the enclave environment (Cui et al., 2021). Its central objective is complete interposition: the ability to interpose on all executed instructions in the enclave and monitor all interactions with the OS. The design is motivated by the claim that the enclave–OS interface becomes extremely large if existing unmodified binaries are to run inside enclaves, and that instruction-level interposition offers a general foundation for inline security monitors.

The architecture is organized around five SGX design restrictions. R1 is spatial memory partitioning between enclave-private and public memory, which forces a two-copy mechanism for data exchanged with the OS. R2 is static memory partitioning, which prevents dynamic resizing and ordinary permission changes in private memory. R3 is non-shareable private memory, which breaks ordinary futex-based synchronization. R4 is one-to-one private virtual-to-physical mapping, which disallows multiple private aliases of the same physical page. R5 is fixed entry points and context constraints, which complicate exception and signal delivery because the enclave resumes at the same instruction and context unless special mediation is inserted. Ratel resolves these in favor of complete interposition by using public/private copy-in and copy-out for system interfaces, a pre-allocated stash region and private procmap-like metadata for memory emulation, an in-enclave lock manager based on SGX hardware spinlocks, and a primary-entry trampoline for signals and exceptions.

The execution model preserves DynamoRIO’s basic code-cache structure inside the enclave. Application code is translated into instrumented basic blocks in a code cache; illegal instructions such as syscall, cpuid, and rdtsc are rewritten; and all syscalls, dynamic code, signals, and control transfers are mediated by enclave-resident handlers. Signal handling is virtualized by a primary handler registered with SGX platform software and secondary handlers registered by the application via sigaction. Threading is supported through TCS-managed clone handling and TLS multiplexing across SGX runtime, DynamoRIO, and application contexts.

The later report states that Ratel offers binary compatibility with over 200 programs, including micro-benchmarks, Linux shell utilities, and standard benchmarks for Python and R, both of which work out of the box without specialized handling (Cui et al., 2021). The earlier formulation characterizes the system as the first attempt to offer binary compatibility with existing software on SGX and reports implementation of 212 out of 318 Linux syscalls, with 193 via full delegation, 6 via full emulation, and 13 via partial emulation plus delegation; it also reports that 203 baseline-compatible binaries ran successfully and unmodified (Shinde et al., 2020). Performance is workload-dependent and reflects the stated design choice to prioritize security and compatibility over speed: SPEC, I/O, memory-intensive, and multi-threaded workloads incur overhead from enclave transitions, copying, limited EPC size, and spinlock contention.

5. “Ratel” as a surname in graph-theoretic labeling theory

In graph theory, “Ratel” refers not to a software artifact but to the third coauthor of a 2020 Journal of Graph Theory paper by Chepoi, Labourel, and Ratel, cited as a precursor in later work on optimal adjacency labels for subgraphs of Cartesian products (Esperet et al., 2022). That earlier paper studied the structure of general Cartesian products with a view toward adjacency labeling, using degeneracy as its main technical tool and then applying the Kannan–Naor–Rudich degeneracy-based labeling scheme.

The later arXiv paper explains the earlier contribution in explicit asymptotic terms. If the base class $\phi \in [0,1]$2 has degeneracy $\phi \in [0,1]$3, then the Chepoi–Labourel–Ratel analysis yields

$\phi \in [0,1]$4

which, combined with the KNR92 black-box scheme, gives adjacency labels of size $\phi \in [0,1]$5. For subgraphs of hypercubes, the same degeneracy-based route gives $\phi \in [0,1]$6 labels in the worst case. The newer work improves this by replacing the multiplicative $\phi \in [0,1]$7 overhead with an additive one, obtaining $\phi \in [0,1]$8 in the degeneracy-only scenario and the optimal $\phi \in [0,1]$9 bound for subgraphs of hypercubes. Here, the encyclopedic significance of “Ratel” is bibliographic: the name indexes a foundational but superseded degeneracy-based stage in the development of optimal adjacency labeling for Cartesian-product classes.

6. Disambiguation and research significance

The cited uses of Ratel are unrelated in method and application. One is a matrix-free, GPU-enabled finite element code for finite-strain fracture and uncertainty-aware calibration; one is a coverage-guided fuzzer for large DBMSs; one is a DBT-based enclave runtime for SGX; and one is an author name in graph-theoretic work. A plausible implication is that the term functions less as a stable concept than as a context-bound label attached to enabling infrastructure.

There is, however, a structural resemblance across the software systems. Each named Ratel operates at a low level of the relevant stack and makes higher-level workflows feasible: specimen-scale DNS and Bayesian calibration in mechanics, enterprise-scale coverage-guided fuzzing in DBMS testing, and binary compatibility plus complete mediation inside SGX enclaves. This suggests a recurring role for the name in the literature as an implementation substrate rather than as a narrow application-layer algorithm.

A separate disambiguation issue arises with the acronym RATT, which denotes “Robust Active Target Tracking” in multi-robot planning under sensing and communication attacks and is unrelated to any of the Ratel systems (Zhou et al., 2021). In practice, accurate interpretation therefore depends on the surrounding domain vocabulary: fracture mechanics, DBMS fuzzing, SGX enclaves, adjacency labeling, or adversarial robot tracking.