Nitro: Multi-Domain Frameworks and Compounds

• Nitro is a polysemous term encompassing distinct computational frameworks and nitro-substituted compounds in chemistry.
• In computing, Nitro frameworks optimize LLM inference, enable integer-only deep learning, and enhance secure enclave operations with measurable performance gains.
• In chemistry, nitro compounds alter molecular properties and reaction dynamics, influencing phase behavior, bonding, and explosive decomposition.

Searching arXiv for the cited paper IDs and titles to ground the article in current records. In contemporary research usage, Nitro and NITRO denote several distinct technical constructs rather than a single unified concept. The label appears as the name of a framework for autoregressive LLM inference on Intel laptop NPUs, an integer-only training framework for deep CNNs, a sampling technique for software sketches, a family of secure-enclave mechanisms centered on AWS Nitro Enclaves, a tamper-evident audit logging system, and a broad class of nitro-substituted molecular and materials systems in which the $-\mathrm{NO}_2$ functionality materially alters structure, energetics, calibration behavior, or phase organization (Fei et al., 2024, Pirillo et al., 2024, Friedman, 2023, Winter et al., 2022, Zhao et al., 4 Sep 2025, Yamaletdinov, 2020).

1. Terminological scope and disambiguation

The term is therefore polysemous across disciplines. In computer systems and machine learning, it is primarily a project or framework name. In chemistry and materials science, it refers to nitro substitution and nitro-containing compounds. This suggests that the shared label functions as a naming convention rather than as a common methodological lineage.

Usage	Domain	Defining feature
NITRO	LLM systems	OpenVINO-based text and chat generation on Intel NPUs
NITRO-D	Integer-only learning	Native integer-only training of deep CNNs
Nitro sampling	Streaming algorithms	Geometric event-skipping for sketch updates
AWS Nitro / nitriding	Trusted execution	Enclave isolation, attestation, and networked deployment
Nitro	Audit logging	eBPF-based tamper-evident logging with forward authenticity
nitro compounds	Chemistry	Systems containing $-\mathrm{NO}_2$ substituents

A recurring source of confusion is that AWS Nitro Enclaves, nitriding, and the Nitro audit logger are unrelated systems that happen to share the same lexical root. Likewise, NITRO for Intel NPUs and NITRO-D for integer-only CNN training are separate frameworks with different architectural premises and performance objectives (Winter et al., 2022, Zhao et al., 4 Sep 2025, Fei et al., 2024, Pirillo et al., 2024).

2. NITRO for autoregressive LLM inference on Intel laptop NPUs

In "NITRO: LLM Inference on Intel Laptop NPUs," NITRO denotes NPU Inference for Transformers Optimization, a Python-based framework built on top of OpenVINO to support text and chat generation on Intel’s Meteor Lake NPU, whose official OpenVINO support is otherwise limited to static model inference (Fei et al., 2024). The central technical obstacle is that decoder-only Transformers such as LLaMA grow the KV-cache during autoregressive decoding, whereas OpenVINO IR and the NPU require static tensor shapes.

NITRO addresses this by fixing the cache and attention mask to a maximum sequence length $m$. If the actual past length at step $t$ is $n \le m$, the key and value tensors are zero-padded to $m \times d$, and a static mask $M \in \mathbb{R}^{1 \times m}$ is constructed with $M_i=0$ for $i \le n$ and $M_i=-\infty$ for $-\mathrm{NO}_2$0. The attention computation is then performed on fixed-size tensors, with the padded suffix always masked out. Rotary embeddings and attention masks are moved outside the model logic and fed in as explicit tensor inputs; pre-computed $-\mathrm{NO}_2$1 pairs, denoted freqs_cis, are sliced on CPU/NumPy so that the OpenVINO graph only sees fixed-size tensors. Each decoder layer becomes a static multi-input block receiving token embedding, full KV-cache, static mask, and rotary-embedding slice, and returning the next hidden state together with updated KV slices.

The OpenVINO integration is deliberately minimalistic. NITRO does not inject custom NPU kernels; instead, it relies on OpenVINO’s built-in operator fusions while ensuring that every tensor shape is fixed. Two implementation choices are central. First, chunked IR generation avoids the $-\mathrm{NO}_2$2 GB RAM requirement of converting a full 8B-parameter model in one pass by splitting the network into multiple chunks, each separately traced and compiled, then stitched together at runtime. Second, stateful KV-cache management uses OpenVINO ReadValue/Assign nodes so that the result of one inference call becomes the parameter of the next without explicit CPU-to-NPU copies. Deterministic node renaming such as token_in, x0, xL, cache_k_i, cache_v_i, and logits_out is used to simplify Python-side wiring.

At the software level, the stack mirrors Hugging Face usage. nitro.pytorch_model/ contains a rewritten PyTorch LLaMA with all-tensor inputs and fixed KV shapes; nitro/converter.py performs TorchScript tracing and chunked OpenVINO conversion; nitro/llm_base.py loads and binds IR chunks behind a unified __call__; and nitro/pipeline.py exposes from_pretrained, generate, and chat_generate. The generation loop tokenizes the prompt, initializes zero KV-caches on the NPU, slices freqs_cis at the current position, builds the static mask, embeds the most recent token, runs the chunked graph, and appends either the sampled or argmax token.

The empirical profile is specific. On an Intel Meteor Lake Core Ultra system running Ubuntu 22.04, Linux NPU Driver 1.10.0, and OpenVINO 2024.4.0, average decode latency for LLaMA3.2-1B is $-\mathrm{NO}_2$3 ms/token on CPU, $-\mathrm{NO}_2$4 on GPU, and $-\mathrm{NO}_2$5 on NPU; for LLaMA3.2-3B it is $-\mathrm{NO}_2$6, $-\mathrm{NO}_2$7, and $-\mathrm{NO}_2$8; and for LLaMA3-8B it is $-\mathrm{NO}_2$9, $m$0, and $m$1. On the 8B model, the NPU is therefore $m$2 faster than the CPU but $m$3 slower than the GPU. Sequence-length scaling from 128 to 2048 tokens is also revealing: GPU cost grows by $m$4 s/token, CPU by $m$5, and NPU by $m$6, so NPU scaling is closer to the CPU than to the GPU. Quantization via OpenVINO NNCF behaves asymmetrically: CPU and GPU obtain $m$7–$m$8 speedups down to $m$9–$t$0 s/token, whereas the NPU sees no INT8 boost, INT4 is slower, and symmetric schemes fail at compile time with low-level driver errors. The comparison baseline is also notable: Intel NPU Acceleration Library yields $t$1 ms/token versus NITRO’s $t$2 ms/token, while the OpenVINO GenAI extension was not runnable because of a segfault.

The planned trajectory remains within the same static-graph philosophy: in-graph rotary embeddings and mask generation, speculative decoding with heterogeneous draft and verification devices, deeper memory tiling and layer fusion, pruning or sparsity subject to static-graph limitations, and explicit energy-efficiency benchmarking for Meteor Lake and Lunar Lake.

3. NITRO-D and native integer-only deep learning

NITRO-D is a distinct framework whose target is training, not inference. It is presented as the first framework enabling the training of arbitrarily deep integer-only CNNs without introducing a quantization scheme, operating entirely in the integer domain during both training and inference (Pirillo et al., 2024). Its design is based on the Local Error Signals paradigm, in which a large network is decomposed into $t$3 independent integer local-loss blocks.

Each block contains forward layers—Integer Conv2D or Integer Linear, followed by a NITRO Scaling Layer and the NITRO-ReLU activation—and learning layers that map the block activation $t$4 to a local prediction $t$5, define a local loss $t$6, and propagate an integer local error back through the forward path. Because each block trains against its own loss, gradients do not traverse the full depth of the network. The framework states that this local-loss structure removes the risk of integer overflow in long backpropagation chains and enables true integer-only arithmetic throughout.

The NITRO Scaling Layer rescales pre-activations into the safe int8 range. If $t$7 is the output of an Integer Conv2D or Integer Linear layer, then

$t$8

with

$t$9

Backward propagation through this layer uses the straight-through estimator, effectively copying the incoming integer gradient.

The NITRO-ReLU is a bounded, integer-only variant of LeakyReLU, clamped to $n \le m$0 and then mean-centered. The details are specified in terms of an integer inverse slope $n \le m$1 and a pre-computed mean $n \le m$2. Its derivative is also represented in integer form, using $n \le m$3 on the negative branch and $n \le m$4 on the positive branch. The loss at each block is the Residual Sum of Squares,

$n \le m$5

with one-hot labels encoded as small integers.

Parameter updates are performed with IntegerSGD, which replaces floating-point learning rate and decay by their integer inverses. If $n \le m$6 and $n \le m$7, then the composite inverse decay is $n \le m$8. Gradient scaling is implemented through integer division, and weight updates remain fully integer-valued. Within a local-loss block, the framework further distinguishes the learning-layer and forward-layer update scales, introducing a NITRO Amplification Factor $n \le m$9, where $m \times d$0 is the number of classes.

The experimental setup spans MNIST, FashionMNIST, and CIFAR-10; MLPs aligned with prior PocketNN and LES work; and VGG-style CNNs including VGG8B and VGG11B. Activations and forward weights are stored as int8, internals fit in int32, and learned weights remain within int16 in practice. Hyperparameters include batch size $m \times d$1, $m \times d$2 epochs, initial $m \times d$3, separate integer weight-decay rates for forward and learning layers, dropout rates $m \times d$4, and learning-layer dimension $m \times d$5.

The reported results define the framework’s scope. For integer-only MLPs, NITRO-D improves over PocketNN by up to $m \times d$6 percentage points, with test accuracies such as $m \times d$7 on MNIST for MLP 1 and $m \times d$8 on FashionMNIST for MLP 2. For CNNs, VGG8B reaches $m \times d$9 on MNIST, $M \in \mathbb{R}^{1 \times m}$0 on FashionMNIST, and $M \in \mathbb{R}^{1 \times m}$1 on CIFAR-10, while VGG11B reaches $M \in \mathbb{R}^{1 \times m}$2 on CIFAR-10. The reported degradation relative to floating-point LES is $M \in \mathbb{R}^{1 \times m}$3 to $M \in \mathbb{R}^{1 \times m}$4, and the framework is positioned as improving over the only other integer-only MLP solution by $M \in \mathbb{R}^{1 \times m}$5 to $M \in \mathbb{R}^{1 \times m}$6 when extended to CNNs. The stated limitations are also precise: remaining accuracy loss is partly attributed to RSS loss and SGD, smaller guaranteed bit-widths are still an open target, and TinyML and privacy-preserving deployments are ongoing.

4. Nitro sampling in software sketches

In the streaming-systems literature, Nitro refers to a randomized event-skipping wrapper for sketch or counter updates rather than to a model architecture or security platform (Friedman, 2023). Fix a sampling probability $M \in \mathbb{R}^{1 \times m}$7. Instead of updating on every arrival, the sketch is updated with probability $M \in \mathbb{R}^{1 \times m}$8 and skipped with probability $M \in \mathbb{R}^{1 \times m}$9. To avoid a pseudorandom-number generation call for every stream element, Nitro samples inter-arrival skip lengths from a $M_i=0$0 distribution and maintains a counter skipsUntilNext.

The purpose is explicitly computational: fewer expensive hash-function computations, fewer random memory accesses, and fewer PRNG calls, with only a small increase in estimation error. The wrapper is generic. PerformUpdate(x) can be the increment of a hash-table counter, the update of all rows in a Count-Min sketch, or the insertion/increment of a fingerprint in a counting Cuckoo filter. If the sampled count for key $M_i=0$1 is $M_i=0$2, the unbiased estimate is returned as $M_i=0$3.

The analysis is standard but important. If the true frequency is $M_i=0$4, then the number of sampled updates $M_i=0$5 is $M_i=0$6, so

$M_i=0$7

The Chernoff bound given in the paper,

$M_i=0$8

formalizes the concentration behavior: heavy flows retain small relative error, while rarer flows exhibit higher relative error.

The evaluated embodiments are NitroHash and NitroCuckoo. NitroHash combines a dynamic hash-table of key-to-32-bit-counter pairs with Nitro sampling; NitroCuckoo combines Nitro with a counting Cuckoo filter. The paper’s headline result is that a simple hashing solution with Nitro provides the best trade-off between memory, error, and speed in the Rust implementations under study. At $M_i=0$9, write-only throughput on Chicago16Small rises from $i \le n$0 M ops/s for a baseline hash table to $i \le n$1 M for NitroHash, from $i \le n$2 M to $i \le n$3 M for Cuckoo to NitroCuckoo, and from $i \le n$4 M to $i \le n$5 M for CMS to NitroCMS. Approximation errors remain small for the hash-table and Cuckoo variants: on-arrival MSRE is $i \le n$6 for NitroHash and $i \le n$7 for NitroCuckoo on Chicago16Small, compared with $i \le n$8 for an exact hash table, $i \le n$9 for Cuckoo, $M_i=-\infty$0 for CMS, and $M_i=-\infty$1 for NitroCMS.

The deployment guidance is correspondingly concrete. The paper suggests values such as $M_i=-\infty$2 for $M_i=-\infty$3 sketch arrays or $M_i=-\infty$4 for CMS, recommends pre-allocating for the unsampled load in update-dominated monitoring, and notes that a cache-sized table reduced by roughly $M_i=-\infty$5 can be preferable in query-heavy settings. A sharp limitation is that Nitro does not support negative updates, so it applies only to one-way insertion or increment workloads.

5. AWS Nitro Enclaves and the nitriding toolkit

In the secure-systems literature, Nitro most prominently refers to AWS Nitro Enclaves, while nitriding is a toolkit designed to make those enclaves secure, powerful, and flexible in practice (Winter et al., 2022). The enclave security model derives from the AWS Nitro System: Nitro cards provide the hardware root of trust, secure boot, and I/O mediation; the Nitro security chip extends control to the main board and prevents unauthorized firmware updates; and the Nitro hypervisor is a minimal-footprint hypervisor that demultiplexes commands from the Nitro card and exposes no user-accessible networking or shell utilities. Isolation follows from dedicated CPU cores and memory, non-sharing of L1/L2 caches in parallel, cleansing of microarchitectural state on context switches, the absence of operator login, and a passive-communications design in which Nitro components never initiate outbound connections.

The native developer model is intentionally restrictive. An enclave is built from a Docker image converted by nitro-cli into an Enclave Image File, for which nitro-cli reports PCR measurements such as PCR0 for the enclave image file, PCR1 for the Linux kernel, PCR2 for the application, and PCR8 for the signing certificate. By default, however, enclaves have no Ethernet interface, only a VSOCK channel to the parent EC2 instance; third-party attestation is not built in; verified horizontal scaling is not available; and there is no out-of-the-box HTTPS or ACME support inside the enclave. On a c5.xlarge instance, raw TCP throughput over VSOCK is $M_i=-\infty$6 Gbit/s from client to server and $M_i=-\infty$7 Gbit/s from server to client, versus $M_i=-\infty$8 Gbit/s loopback.

Winter et al. introduce nitriding to remove these practical barriers while keeping the trust base small. The toolkit provides a deterministic build system based on kaniko, a secure networking layer built around a TAP interface bridged via VSOCK to a host-side proxy, and two network modes: reverse proxy, where HTTPS is terminated by nitriding and forwarded over localhost, and direct mode, where the proxied application speaks plain TCP or UDP. ACME with TLS-ALPN-01 runs inside the enclave so that the Let’s Encrypt private key never leaves the enclave.

The attestation protocol binds code identity to the network channel. A client sends a nonce; the enclave passes the nonce and its public key to the hypervisor; the hypervisor returns an attestation document signed under AWS’s root CA; and the enclave relays that document to the client. The client verifies the AWS signature, the nonce, the certificate fingerprint, and equality between local and remote PCR0 before trusting that TLS is terminating inside the enclave. Nitriding also implements user-verifiable horizontal scaling through mutual attestation and NaCl-encrypted transfer of long-term key material, discovered via DNS SRV, so that external KMS-based synchronization is unnecessary.

The toolkit’s case studies demonstrate breadth rather than a single benchmark niche. The Verifiable Configuration Transparency service fetches third-party CDN configuration on each request and returns it with an attestation document so that clients can verify properties such as IP scrubbing. The Tor bridge runs unmodified Tor inside the enclave behind nitriding’s reverse proxy on port 443 and is presented as resisting protocol-level deanonymization attacks. The in-enclave Chromium browser packages Ubuntu, Chromium, X11, TigerVNC, i3, and OpenSSH; nitriding attests an SSH key that the client uses to establish an SSH-tunneled VNC session.

The evaluation shows that attestation itself is inexpensive, while the networking shim is the main performance cost. Over $M_i=-\infty$9 seconds, the system serves $-\mathrm{NO}_2$00 attestation requests, or about $-\mathrm{NO}_2$01 requests per second, with median latency $-\mathrm{NO}_2$02 ms and $-\mathrm{NO}_2$03 below $-\mathrm{NO}_2$04 ms. HTTP performance is lower: with $-\mathrm{NO}_2$05 threads, loopback reaches $-\mathrm{NO}_2$06 req/s at about $-\mathrm{NO}_2$07 ms median RTT, raw enclave VSOCK reaches $-\mathrm{NO}_2$08 req/s at about $-\mathrm{NO}_2$09 ms, nitriding without reverse proxy reaches $-\mathrm{NO}_2$10 req/s at about $-\mathrm{NO}_2$11–$-\mathrm{NO}_2$12 ms, and full nitriding with reverse proxy and HTTPS reaches $-\mathrm{NO}_2$13 req/s at about $-\mathrm{NO}_2$14–$-\mathrm{NO}_2$15 ms. The paper characterizes this as roughly $-\mathrm{NO}_2$16 latency and $-\mathrm{NO}_2$17 throughput overhead beyond the raw VSOCK baseline.

6. Nitro as a tamper-evident audit logging system

A later and entirely separate systems line uses Nitro as the name of a high-performance, tamper-evident audit logging system based on eBPF rather than on enclaves (Zhao et al., 4 Sep 2025). Its contribution begins with a new definitional framework for logging. A protocol $-\mathrm{NO}_2$18 is specified by a state space $-\mathrm{NO}_2$19, a key space $-\mathrm{NO}_2$20, and a tag length $-\mathrm{NO}_2$21, together with a deterministic Update algorithm

$-\mathrm{NO}_2$22

and a deterministic Sign algorithm

$-\mathrm{NO}_2$23

The security notion is forward authenticity: no polynomial-time adversary should be able to output a shorter or modified prefix of previously logged messages together with a final tag that passes verification.

Nitro instantiates this model through XLog, a two-level design combining a MAC combiner and forward-secure key evolution. The MAC combiner uses a secure MAC $-\mathrm{NO}_2$24 modeled as a PRF with XOR as the combine operator, so the aggregate tag after $-\mathrm{NO}_2$25 messages is

$-\mathrm{NO}_2$26

State evolution is handled by a PRF $-\mathrm{NO}_2$27, with

$-\mathrm{NO}_2$28

The concrete instantiation uses Chaskey as the $-\mathrm{NO}_2$29-bit MAC and a Chaskey-based keyed permutation for $-\mathrm{NO}_2$30. The stated theorem is that, under standard multi-user PRF and MAC-unforgeability assumptions, XLog satisfies forward authenticity with adversarial advantage bounded by the PRF and forgery advantages.

The implementation is fully eBPF-based and requires no kernel recompilation. An in-kernel eBPF program attaches to syscall tracepoints, preprocesses each syscall into a fixed-length header $-\mathrm{NO}_2$31 and a dynamic payload $-\mathrm{NO}_2$32, maps syscall names to $-\mathrm{NO}_2$33-bit IDs, stores arguments in minimal types, pads $-\mathrm{NO}_2$34 to $-\mathrm{NO}_2$35-bit blocks, and computes the Chaskey MAC in fixed-iteration loops acceptable to the eBPF verifier. The average log size in the Postmark case is reduced from about $-\mathrm{NO}_2$36 bytes to about $-\mathrm{NO}_2$37 bytes. Signing state $-\mathrm{NO}_2$38 is held per core in a Per-CPU Array, eliminating locking. A two-level buffering hierarchy moves entries from the Per-CPU Array to a ring buffer at interval $-\mathrm{NO}_2$39, then from the ring buffer to user space at interval $-\mathrm{NO}_2$40.

The reduced-I/O variant Nitro-R inserts an in-kernel log-reduction stage before MAC computation. It forms a semantic key $-\mathrm{NO}_2$41, looks it up in an eBPF LRU hash map, and drops the new entry if it falls within a time window $-\mathrm{NO}_2$42, defaulting to $-\mathrm{NO}_2$43 s. The paper argues that because only unique events are passed to XLog, audit integrity is preserved for the retained stream.

Parameter tuning is explicit. The system sweeps $-\mathrm{NO}_2$44 KB, $-\mathrm{NO}_2$45 MB, $-\mathrm{NO}_2$46 ms, and $-\mathrm{NO}_2$47 ms, identifying an operating region with data loss below $-\mathrm{NO}_2$48 and overhead below $-\mathrm{NO}_2$49: $-\mathrm{NO}_2$50 KB, $-\mathrm{NO}_2$51 MB, $-\mathrm{NO}_2$52 ms, and $-\mathrm{NO}_2$53 ms. The chosen defaults are $-\mathrm{NO}_2$54 KB, $-\mathrm{NO}_2$55 MB, $-\mathrm{NO}_2$56 ms, and $-\mathrm{NO}_2$57 s.

The evaluation compares Nitro and Nitro-R with QuickLog2, eAudit, NoDrop, and eAudit-SEC. Under stress tests, Nitro reports runtime overheads such as $-\mathrm{NO}_2$58 for Postmark, $-\mathrm{NO}_2$59 for shbm, $-\mathrm{NO}_2$60 for tar, $-\mathrm{NO}_2$61 for find, $-\mathrm{NO}_2$62 for httperf, $-\mathrm{NO}_2$63 for rdwr, and $-\mathrm{NO}_2$64 for kernel, versus substantially larger overheads for QuickLog2 and eAudit-SEC. Data-loss rates remain near zero: for example, $-\mathrm{NO}_2$65 on Postmark, $-\mathrm{NO}_2$66 on shbm, and $-\mathrm{NO}_2$67 on kernel. The paper summarizes this as $-\mathrm{NO}_2$68–$-\mathrm{NO}_2$69 lower overhead than QuickLog2 under stress and $-\mathrm{NO}_2$70–$-\mathrm{NO}_2$71 lower overhead in real-world benchmarks, while Nitro-R reduces logs by $-\mathrm{NO}_2$72 in stress tests and $-\mathrm{NO}_2$73 in real-world tests, cutting Nitro’s overhead by $-\mathrm{NO}_2$74 and $-\mathrm{NO}_2$75, respectively.

7. Nitro in chemistry and materials science

In chemistry, nitro denotes systems bearing $-\mathrm{NO}_2$76 substituents, but the collected literature shows that the consequences of nitro incorporation are highly environment-dependent. The same nitro functionality can improve mesophase stability, fail to bind covalently to a carbon lattice, generate calibration failures in atomistic neural networks, or drive explosive decomposition (Vazquez-Salazar et al., 2022, Trišović et al., 2016, Yamaletdinov, 2020, Chaban et al., 2014).

A particularly instructive case arises in uncertainty quantification for atomistic neural networks. In the PhysNet-based evidential-regression study, QM9 excludes aliphatic nitro groups while retaining aromatic $-\mathrm{NO}_2$77, so the training data contain nitro bound to $-\mathrm{NO}_2$78 carbon but not to $-\mathrm{NO}_2$79 carbon (Vazquez-Salazar et al., 2022). The modified PhysNet emits Normal–Inverse–Gamma parameters $-\mathrm{NO}_2$80, from which the predicted mean, aleatoric uncertainty, and epistemic uncertainty are extracted. Despite this probabilistic structure, the paper shows that error and uncertainty are not linearly related. Nitro-containing aliphatic chains are the core failure mode: their learned feature-space distances in AtE and RBF coordinates are moderate to small, so the model assigns low variance, yet the DFT error can be $-\mathrm{NO}_2$81–$-\mathrm{NO}_2$82 eV while the predicted variance is $-\mathrm{NO}_2$83 eV$-\mathrm{NO}_2$84. For the B3 tautomer at $-\mathrm{NO}_2$85, $-\mathrm{NO}_2$86 eV, $-\mathrm{NO}_2$87 eV, the error is $-\mathrm{NO}_2$88 eV, and the predicted standard deviation is $-\mathrm{NO}_2$89 eV. The interpretation offered is chemical and statistical at once: redundancy of aromatic nitro examples is insufficiently specific, so the model is confident but wrong on aliphatic nitro scaffolds.

In liquid-crystal chemistry, nitro substitution appears in the five-ring pyridine-based bent-core mesogen B5-NO$-\mathrm{NO}_2$90, chemically named 2,6-bis[2-(4-(4-dodecyloxy-3-nitrobenzoyloxy)phenyl)ethenyl]pyridine (Trišović et al., 2016). Differential scanning calorimetry at $-\mathrm{NO}_2$91 identifies second-heating transitions at $-\mathrm{NO}_2$92 from $-\mathrm{NO}_2$93 to $-\mathrm{NO}_2$94, $-\mathrm{NO}_2$95 from $-\mathrm{NO}_2$96 to B1, and $-\mathrm{NO}_2$97 from B1 to isotropic, with the corresponding second-cooling transitions at $-\mathrm{NO}_2$98 from isotropic to B1 and $-\mathrm{NO}_2$99 from B1 to crystal. The phase is described as enantiotropic B1-like (columnar), spanning approximately $m$00–$m$01 on heating and reappearing around $m$02–$m$03 on cooling. Under polarized optical microscopy, smooth fan-shaped domains appear at $m$04, and a columnar texture with fine striations appears at $m$05. The nitro derivative is also photo-sensitive under $m$06 nm irradiation: the B1 texture darkens, and birefringent domains reappear after dark recovery. The source describes electron-withdrawing $m$07 as increasing intermolecular dipole coupling, raising clearing temperature by about $m$08 K relative to B5-H, but narrowing the mesophase width to about $m$09 K on heating.

For graphene-based materials, the nitro question is one of covalent attachment and local environment. First-principles calculations show that pristine graphene does not form a stable covalent C–NO$m$10 bond under the tested coverages and patterns, whereas graphane, fluorographene, and graphene oxide can in some local configurations (Yamaletdinov, 2020). The bond dissociation energy is defined as

$m$11

with positive values indicating a stable exothermic bond. The strongest reported case is pattern III in graphane, with $m$12 eV and C–N bond length $m$13 Å; graphane remains favorable across patterns I–VI, while fluorographene and graphene oxide become unstable in second-sphere-crowded patterns V and VI, where C–N distances reach $m$14 and $m$15 Å or otherwise indicate collapse toward physisorption. Hydrogens in the first coordination sphere stabilize C–NO$m$16 most effectively, followed closely by OH and then F; second-sphere substituents tend to destabilize the bond. Proposed synthetic routes include gas-phase radical nitration of partially hydrogenated or fluorinated graphene, plasma synthesis in NO$m$17 or N$m$18O$m$19/Ar, and liquid-phase nitrofluorination with NO$m$20F in N$m$21O$m$22.

Nitro substitution also defines the decomposition chemistry of the nanoscale explosive C$m$23(NO$m$24)$m$25, the “buckybomb” studied by Chaban et al. with reactive molecular dynamics (Chaban et al., 2014). On heating to $m$26 K, the first step is nitro-to-nitrito isomerization,

$m$27

with an estimated barrier of about $m$28 kJ/mol and a timescale of $m$29 ps. This exothermic step raises the system temperature from $m$30 K to about $m$31 K. Nitric oxide is then released and the fullerene surface acquires carbonyl groups; NO rapidly oxidizes to NO$m$32 in the presence of oxygen, and the fullerene cage subsequently breaks down to liberate CO$m$33. At the highest temperatures, CO$m$34 yields diatomic carbon. Temperature reaches $m$35–$m$36 K over $m$37–$m$38 ps depending on density, and pressure rises from ambient to several $m$39 MPa; at $m$40, pressure climbs from about $m$41 GPa to about $m$42 GPa between $m$43 and $m$44 ps. Density barely affects the initial intramolecular isomerization but accelerates subsequent heat accumulation and pressure buildup.

Taken together, these chemistry results show that nitro functionality is strongly context-sensitive. Aromatic versus aliphatic placement alters machine-learning calibration; mesogenic packing responds to the electron-withdrawing and photoactive character of $m$45; covalent nitration of carbon sheets depends on pre-existing $m$46 support and coordination-sphere patterning; and nitro-functionalized fullerenes can act as nano-energetic materials with a specific multistage decomposition pathway.