add wiki
This commit is contained in:
김경종
@@ -0,0 +1,71 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Assumed Transverse Shear Strain Interpolation"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- assumed shear strain interpolation
|
||||
- transverse shear tying
|
||||
- shear locking remedy
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000020
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- shell-elements
|
||||
- locking
|
||||
status: current
|
||||
related:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
- "[[Shell Locking Phenomenon]]"
|
||||
- "[[Uniform Optimal Convergence]]"
|
||||
- "[[A Continuum Mechanics Based Four-Node Shell]]"
|
||||
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
|
||||
- "[[MITC Study Notes]]"
|
||||
- "[[MITC4 Shell Element]]"
|
||||
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
|
||||
- "[[Mixed Finite Element Formulations]]"
|
||||
- "[[Displacement-Based Finite Element Formulation]]"
|
||||
- "[[Isoparametric Finite Elements]]"
|
||||
sources:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
- "[[A Continuum Mechanics Based Four-Node Shell]]"
|
||||
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
|
||||
- "[[MITC Study Notes]]"
|
||||
---
|
||||
|
||||
# Assumed Transverse Shear Strain Interpolation
|
||||
|
||||
## Definition
|
||||
|
||||
Assumed transverse shear strain interpolation replaces the shear strains implied directly by the displacement interpolation with a separately interpolated shear strain field chosen to avoid artificial stiffness in shell bending.
|
||||
|
||||
## How It Works
|
||||
|
||||
In the four-node shell paper, the transverse shear strain components are interpolated in convected coordinates from selected tying locations rather than taken directly from the standard displacement field everywhere in the element. This lets the element approximate the near-zero transverse shear strains required by thin-shell bending while preserving a low-order quadrilateral element.
|
||||
|
||||
The MITC4 source presents the same practical idea under the Mixed Interpolation of Tensorial Components name. Its assumed transverse shear strains are computed from values at edge-midpoint tying locations and then transformed back to Cartesian strain components.
|
||||
|
||||
The MITC study notes keep this as the motivating issue: direct shell interpolation locks in thin shells, so the transverse shear strain field must be treated separately from the rest of the displacement-derived strain field.
|
||||
|
||||
The Korean shell FE review generalizes the same idea: reducing selected strain interpolation can relieve locking, but the assumed field must still satisfy consistency and avoid spurious zero-energy behavior.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
Standard displacement interpolation can cause shear locking: the element cannot represent the bending state without introducing parasitic transverse shear strain, so the computed shell becomes too stiff as thickness decreases. The assumed shear strain field is a targeted correction that keeps the four-node shell usable for thin shells without abandoning the economical element topology.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Continuum Mechanics Based Four-Node Shell Element]] uses this technique as a core formulation choice.
|
||||
- [[MITC4 Shell Element]] names the same locking remedy as mixed interpolation of tensorial components.
|
||||
- [[Mixed Finite Element Formulations]] provides a broader context for introducing extra or altered fields to satisfy constraints.
|
||||
- [[Displacement-Based Finite Element Formulation]] explains the displacement-only path that can lock.
|
||||
- [[Isoparametric Finite Elements]] explains the low-order quadrilateral mapping context.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[A Continuum Mechanics Based Four-Node Shell]]
|
||||
- [[Four-Node-Quadrilateral-Shell-Element-MITC4]]
|
||||
- [[MITC Study Notes]]
|
||||
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Basic Shell Mathematical Model"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- basic shell model
|
||||
- shell mathematical model
|
||||
- degenerated shell mathematical model
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000043
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- shell-elements
|
||||
status: current
|
||||
related:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
|
||||
- "[[MITC Shell Kinematics]]"
|
||||
- "[[Displacement-Based Finite Element Formulation]]"
|
||||
- "[[Shell Structure Asymptotic Behavior]]"
|
||||
sources:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
---
|
||||
|
||||
# Basic Shell Mathematical Model
|
||||
|
||||
## Definition
|
||||
|
||||
The basic shell mathematical model is a general shell model that represents bending, membrane, transverse shear, and their coupling through midsurface geometry and director-based kinematics.
|
||||
|
||||
## How It Works
|
||||
|
||||
The model defines a shell through a midsurface, thickness coordinate, covariant and contravariant base vectors, and a director normal to the midsurface. The displacement field is expressed as a midsurface displacement plus a through-thickness rotation term. From that kinematic description, the model derives strain terms and a variational equilibrium equation for the shell.
|
||||
|
||||
The paper emphasizes that this is the mathematical model underlying degenerated or continuum-mechanics-based shell finite elements. That makes it the bridge between three-dimensional continuum mechanics and practical shell elements such as [[Continuum Mechanics Based Four-Node Shell Element]] and [[MITC4 Shell Element]].
|
||||
|
||||
## Why It Matters
|
||||
|
||||
Shell FE errors cannot be diagnosed only at the mesh or solver level. If the analyst does not understand what shell mathematical model is being approximated, it is easy to misread a converged-looking result that is actually affected by locking or wrong asymptotic behavior.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[MITC Shell Kinematics]] is a derivation-level implementation of director-vector shell kinematics.
|
||||
- [[Shell Structure Asymptotic Behavior]] uses the shell model's bending and membrane energy terms to classify thin-shell limits.
|
||||
- [[Shell Locking Phenomenon]] occurs when an element's interpolation space cannot approximate the relevant bending or membrane constraints of this model.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
|
||||
@@ -1,69 +0,0 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Compounding Knowledge"
|
||||
complexity: basic
|
||||
domain: knowledge-management
|
||||
aliases:
|
||||
- "Knowledge Compounding"
|
||||
- "Persistent Synthesis"
|
||||
created: 2026-04-07
|
||||
updated: 2026-04-07
|
||||
tags:
|
||||
- concept
|
||||
- knowledge-management
|
||||
status: mature
|
||||
related:
|
||||
- "[[LLM Wiki Pattern]]"
|
||||
- "[[Hot Cache]]"
|
||||
- "[[Andrej Karpathy]]"
|
||||
- "[[concepts/_index]]"
|
||||
sources:
|
||||
---
|
||||
|
||||
# Compounding Knowledge
|
||||
|
||||
The central insight behind the [[LLM Wiki Pattern]]: knowledge in a wiki compounds like interest in a bank. Every source added, every question answered, every analysis filed makes the wiki more valuable — not just by adding pages, but by enriching the connections between existing pages.
|
||||
|
||||
---
|
||||
|
||||
## Why Normal AI Chats Don't Compound
|
||||
|
||||
In a standard chat, knowledge is ephemeral. Each session starts fresh. Even if you upload the same documents repeatedly, the LLM re-derives the same insights from scratch. Nothing accumulates.
|
||||
|
||||
The same is true of most RAG systems: they index raw documents and retrieve chunks at query time. The retrieval gets the right fragments, but no synthesis is built up. Nothing is compiled. Ask the same complex question twice and you get the same assembly process twice.
|
||||
|
||||
---
|
||||
|
||||
## How Wiki Knowledge Compounds
|
||||
|
||||
When a new source arrives, the LLM doesn't just index it. It integrates it:
|
||||
- Updates entity pages with new information
|
||||
- Flags contradictions with existing claims
|
||||
- Strengthens or challenges the evolving synthesis
|
||||
- Adds cross-references from the new source to existing pages and back
|
||||
|
||||
The cross-references are already there next time. The contradictions have already been flagged. The synthesis already reflects everything that was read.
|
||||
|
||||
**The wiki is pre-compiled knowledge.** RAG re-compiles on every query.
|
||||
|
||||
---
|
||||
|
||||
## The Maintenance Problem
|
||||
|
||||
Wikis maintained by humans decay. The maintenance burden grows faster than the value — updating cross-references, keeping summaries current, noting when new data contradicts old claims. Humans abandon wikis because no one wants to do the bookkeeping.
|
||||
|
||||
LLMs don't get bored. They don't forget to update a cross-reference. The cost of maintenance is near zero. This is the practical reason the wiki pattern works: the entity that's best at the tedious maintenance work is the same entity that reads and writes the wiki.
|
||||
|
||||
---
|
||||
|
||||
## In Practice
|
||||
|
||||
One X user turned 383 scattered files and over 100 meeting transcripts into a compact wiki and dropped token usage by 95% when querying with Claude. The drop came from two sources: better navigation (index + hot cache vs. full document search) and pre-compiled synthesis (no re-deriving the same insights from scratch).
|
||||
|
||||
---
|
||||
|
||||
## Connections
|
||||
|
||||
See [[LLM Wiki Pattern]] for the full architecture.
|
||||
See [[Hot Cache]] for the session context mechanism.
|
||||
See [[Andrej Karpathy]] for the origin of this framing.
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Continuum Mechanics Based Four-Node Shell Element"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- four-node shell element
|
||||
- Dvorkin-Bathe shell element
|
||||
- continuum mechanics shell element
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000019
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- shell-elements
|
||||
- nonlinear-analysis
|
||||
status: current
|
||||
related:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
- "[[Basic Shell Mathematical Model]]"
|
||||
- "[[Shell Locking Phenomenon]]"
|
||||
- "[[A Continuum Mechanics Based Four-Node Shell]]"
|
||||
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
|
||||
- "[[MITC4 Shell Element]]"
|
||||
- "[[Scordelis-Lo Shell Benchmark]]"
|
||||
- "[[Assumed Transverse Shear Strain Interpolation]]"
|
||||
- "[[Total Lagrangian Shell Formulation]]"
|
||||
- "[[Isoparametric Finite Elements]]"
|
||||
- "[[Nonlinear Finite Element Analysis]]"
|
||||
sources:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
- "[[A Continuum Mechanics Based Four-Node Shell]]"
|
||||
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
|
||||
---
|
||||
|
||||
# Continuum Mechanics Based Four-Node Shell Element
|
||||
|
||||
## Definition
|
||||
|
||||
A continuum-mechanics-based four-node shell element is a quadrilateral shell finite element whose behavior is derived from the three-dimensional continuum virtual work statement rather than from a specialized plate or shell theory.
|
||||
|
||||
## How It Works
|
||||
|
||||
The element represents shell geometry through a general four-node, non-flat quadrilateral description. It uses convected coordinates and a three-dimensional constitutive setting, while constraining the shell kinematics so the element can model thin and thick shells efficiently. The paper's central practical modification is a separate interpolation of transverse shear strains, which prevents the element from becoming overly stiff in thin-shell bending.
|
||||
|
||||
The MITC4 implementation paper restates this lineage in an implementation-focused form: the four-node quadrilateral shell is treated as a three-dimensional continuum description degenerated to shell behavior, with all element degrees of freedom concentrated at the four vertices.
|
||||
|
||||
[[On-the-Finite-Element-Analysis-of-Shell-Structures]] names the [[Basic Shell Mathematical Model]] as the underlying model for continuum-mechanics-based shell finite elements. That source makes the element's locking behavior a consequence of how well the discretization can approximate the model's bending, membrane, and transverse shear strain spaces.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
Four-node shell elements are attractive in large structural models because they are computationally economical, but low-order shell elements can lock, distort poorly, or admit spurious modes. This formulation shows how a low-order element can remain useful for nonlinear shell analysis when the shear strain field and nonlinear kinematics are handled carefully.
|
||||
|
||||
## Validation Thread
|
||||
|
||||
The source tests the element against simple patch and rigid-body checks, classical shell benchmarks such as the Scordelis-Lo roof and pinched cylinder, large-deflection cantilever behavior, shallow spherical shell response, stiffened plate buckling, and elastoplastic circular plate response.
|
||||
|
||||
The MITC4 source adds an [[OOFEM]] implementation thread, including patch tests and the [[Scordelis-Lo Shell Benchmark]] as the main convergence demonstration.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Assumed Transverse Shear Strain Interpolation]] is the locking remedy inside the element.
|
||||
- [[Total Lagrangian Shell Formulation]] is the nonlinear kinematic framework used for large displacement and rotation response.
|
||||
- [[Isoparametric Finite Elements]] supplies the mapping and integration context.
|
||||
- [[Nonlinear Finite Element Analysis]] supplies the incremental solution context.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[A Continuum Mechanics Based Four-Node Shell]]
|
||||
- [[Four-Node-Quadrilateral-Shell-Element-MITC4]]
|
||||
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Direct Time Integration Methods"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- finite element dynamics
|
||||
- direct integration
|
||||
- Newmark method
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000014
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- dynamics
|
||||
status: current
|
||||
related:
|
||||
- "[[Finite Element Method]]"
|
||||
- "[[Nonlinear Finite Element Analysis]]"
|
||||
- "[[Nonlinear Newmark-Beta Integration]]"
|
||||
- "[[Dynamic Buckling Analysis]]"
|
||||
- "[[Finite Element Eigenproblem Solvers]]"
|
||||
sources:
|
||||
- "[[Finite Element Procedures]]"
|
||||
- "[[MITC Study Notes]]"
|
||||
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
|
||||
---
|
||||
|
||||
# Direct Time Integration Methods
|
||||
|
||||
## Definition
|
||||
|
||||
Direct time integration methods advance finite element equilibrium equations through time without necessarily transforming the problem into modal coordinates.
|
||||
|
||||
## How It Works
|
||||
|
||||
Dynamic finite element systems include mass, damping, stiffness, and time-dependent loading. The source covers central difference, Houbolt, Newmark, and Bathe methods, then analyzes approximation, load operators, stability, accuracy, numerical damping, and coupling of different integration operators.
|
||||
|
||||
The MITC study notes add a focused nonlinear Newmark-beta derivation: Newton iteration is used at each time step, and Newmark relations express acceleration and velocity increments through the displacement increment.
|
||||
|
||||
The dynamic buckling thesis uses time-dependent axial compression as the loading context. It connects dynamic response, natural frequency, and buckling instability boundaries rather than treating time integration as a standalone transient solve.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
Time integration choices control stability, phase accuracy, numerical damping, and computational cost. Explicit methods can be efficient for very small stable time steps; implicit methods are more expensive per step but can support larger steps and nonlinear equilibrium iterations.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Finite Element Eigenproblem Solvers]] supports modal superposition and vibration analysis.
|
||||
- [[Nonlinear Finite Element Analysis]] couples time integration with nonlinear iteration.
|
||||
- [[Nonlinear Newmark-Beta Integration]] is the specific implicit nonlinear dynamics workflow extracted from the MITC notes.
|
||||
- [[Finite Element Heat Transfer and Field Problems]] uses related transient integration ideas for first-order field equations.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Finite Element Procedures]]
|
||||
- [[MITC Study Notes]]
|
||||
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Displacement-Based Finite Element Formulation"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- displacement formulation
|
||||
- displacement method
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000008
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- structural-mechanics
|
||||
status: current
|
||||
related:
|
||||
- "[[Finite Element Method]]"
|
||||
- "[[Isoparametric Finite Elements]]"
|
||||
- "[[Mixed Finite Element Formulations]]"
|
||||
- "[[Solid Element Notes]]"
|
||||
- "[[Solid Element Strain-Displacement Matrix]]"
|
||||
- "[[Solid Element Stiffness Integration]]"
|
||||
- "[[Assumed Transverse Shear Strain Interpolation]]"
|
||||
sources:
|
||||
- "[[Finite Element Procedures]]"
|
||||
- "[[A Continuum Mechanics Based Four-Node Shell]]"
|
||||
- "[[Solid Element Notes]]"
|
||||
---
|
||||
|
||||
# Displacement-Based Finite Element Formulation
|
||||
|
||||
## Definition
|
||||
|
||||
The displacement-based finite element formulation uses nodal displacements as the primary unknowns and derives element and global equilibrium equations from a virtual work, energy, or variational statement.
|
||||
|
||||
## How It Works
|
||||
|
||||
Element displacement fields are interpolated from nodal degrees of freedom. Strains are computed from displacement gradients, stresses from constitutive laws, and element stiffness matrices from the strain-displacement and material matrices. Element contributions are assembled into the global equilibrium system, commonly represented in linear static form as `K u = R`.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
This is the main formulation path for linear solid and structural mechanics in the source. It is direct and broadly useful, but it has limits for incompressibility, locking, and constraints, which motivates [[Mixed Finite Element Formulations]].
|
||||
|
||||
The four-node shell paper gives a concrete locking example: direct displacement interpolation can impose nonphysical transverse shear strains in thin-shell bending, motivating [[Assumed Transverse Shear Strain Interpolation]].
|
||||
|
||||
[[Solid Element Notes]] gives the corresponding 3D continuum path: interpolate nodal translations, compute small strains with the solid `B` matrix, apply the Hooke-law `D` matrix, and integrate `B^T D B` over the element volume.
|
||||
|
||||
## Practical Checks
|
||||
|
||||
- Does the interpolation reproduce rigid-body motion and constant strain states where required?
|
||||
- Are displacement boundary conditions imposed consistently?
|
||||
- Are stresses recovered in a way that reflects the approximation quality?
|
||||
- Does mesh refinement improve the relevant response quantities?
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Finite Element Procedures]]
|
||||
- [[A Continuum Mechanics Based Four-Node Shell]]
|
||||
- [[Solid Element Notes]]
|
||||
@@ -1,295 +0,0 @@
|
||||
---
|
||||
type: concept
|
||||
title: "DragonScale Memory"
|
||||
address: c-000001
|
||||
complexity: advanced
|
||||
domain: knowledge-management
|
||||
aliases:
|
||||
- "DragonScale"
|
||||
- "DragonScale Architecture"
|
||||
- "Fractal Memory"
|
||||
created: 2026-04-23
|
||||
updated: 2026-04-24
|
||||
tags:
|
||||
- concept
|
||||
- knowledge-management
|
||||
- memory
|
||||
- architecture
|
||||
- fractal
|
||||
status: proposed
|
||||
related:
|
||||
- "[[LLM Wiki Pattern]]"
|
||||
- "[[Compounding Knowledge]]"
|
||||
- "[[Hot Cache]]"
|
||||
- "[[concepts/_index]]"
|
||||
sources:
|
||||
---
|
||||
|
||||
# DragonScale Memory
|
||||
|
||||
A memory-layer design for LLM wiki vaults, inspired by the Heighway dragon curve. Four mechanisms (fold operator, deterministic page addresses, semantic tiling, boundary-first autoresearch) give an LLM-maintained wiki a principled way to grow, compact, and stay coherent. The dragon curve is a design-justification device, not a reasoning architecture.
|
||||
|
||||
> **Status: v0.4 2026-04-24.** All four mechanisms shipped as opt-in features. Phase 0 (spec) + Phase 1 (wiki-fold skill, dry-run verified) + Phase 2 (address MVP) + Phase 3 (semantic tiling) + Phase 3.5/3.6 (hardening) + Phase 4 (boundary-first autoresearch). See Review History for the progression.
|
||||
|
||||
---
|
||||
|
||||
## Scope
|
||||
|
||||
DragonScale is a **memory architecture**: it governs how a wiki grows, compacts, addresses its pages, and checks for duplicates. It is **not a search, planning, or reasoning algorithm.** Agent reasoning uses existing patterns (Tree of Thoughts with BFS/DFS/beam search; Yao et al. 2023).
|
||||
|
||||
**Honest disclaimer**: memory-layer choices are never neutral with respect to reasoning. What the vault surfaces, and in what order, shapes what the model sees. Long-context performance is position-sensitive (Liu et al. 2023, *Lost in the Middle*), and MemGPT's premise is that paging policy affects task success (Packer et al. 2023). One of the four mechanisms below (boundary-first autoresearch) explicitly crosses into agenda control; it is included deliberately and marked as such.
|
||||
|
||||
---
|
||||
|
||||
## The Core Analogy
|
||||
|
||||
Four dragon-curve properties map onto memory-system patterns already validated in adjacent fields. The word is *analogue*, not *identity*.
|
||||
|
||||
| Dragon curve property | Memory analogue | Strength of analogy |
|
||||
|---|---|---|
|
||||
| Paper-folding recursion: `D_{n+1} = D_n · R · swap(reverse(D_n))` | Hierarchical rollup / materialized summary with exponential fanout | Loose. Shares exponential batch structure, not compaction semantics. |
|
||||
| Turn derivable from bits of `n` (regular paperfolding sequence, OEIS A014577) | Deterministic page addresses as organizational convention (MVP is a creation-order counter, not a true content hash) | Loose. Deterministic addressing is useful independent of the dragon. |
|
||||
| Tiling / no self-intersection | Canonical-home coverage: one concept, one page | Medium. Dedup lint enforces this mechanically. |
|
||||
| Boundary dim ≈ 1.523627 vs interior dim 2 | Agent attention weighted toward frontier pages | Aesthetic. The fractal dimension number does no load-bearing work. |
|
||||
|
||||
The curve is useful for deciding *which knobs to tighten and why*, not as a math proof that any given mechanism is optimal.
|
||||
|
||||
---
|
||||
|
||||
## Mechanism 1 — Fold Operator
|
||||
|
||||
After a batch of ingests, run a fold: produce a meta-page summarizing the batch, link children back, update the index. Folds stack: after enough level-`k` folds accumulate, a level-`k+1` fold produces a super-summary.
|
||||
|
||||
This is a **hierarchical rollup**, loosely similar to LSM-tree compaction but with important differences.
|
||||
|
||||
**What it shares with LSM compaction:**
|
||||
- Exponential batch fanout across levels (like LevelDB's fixed level-size ratio, typically 10× per level in leveled mode)
|
||||
- Periodic consolidation rather than per-write work
|
||||
|
||||
**What it does NOT inherit from LSM:**
|
||||
- No sorted-key semantics (pages have semantic, not key-ordered, identity)
|
||||
- No SSTable/memtable distinction, no tombstones, no Bloom filters
|
||||
- No write-amplification arithmetic; no read-path acceleration
|
||||
- **Folds are additive**: children remain in place. LSM compaction rewrites and deletes. A DragonScale fold is closer to a materialized view than a compaction.
|
||||
|
||||
**Trigger options:**
|
||||
- `2^k` entry count (k=4 ⇒ every 16 log entries). Simple to implement; straightforward level math; ignores page size and novelty.
|
||||
- **Adaptive trigger (preferred for production)**: token budget (e.g., fold when unfolded batch exceeds N tokens), novelty score (average embedding distance from existing summaries), or staleness age (last fold > T days). Phase 1 will implement entry-count for MVP; adaptive triggers are a follow-up.
|
||||
|
||||
**Invariants:**
|
||||
- Idempotent on the same range (re-running is a no-op).
|
||||
- Reversible (children stay; a fold is additive).
|
||||
- Level-bounded: with entry-count trigger `2^k`, fold depth is at most `⌈log₂(N)⌉` above leaf pages. Derived, not empirical.
|
||||
|
||||
---
|
||||
|
||||
## Mechanism 2 — Deterministic Page Addresses
|
||||
|
||||
Every new page gets a stable `address` field in frontmatter. The Phase 2 MVP uses a simple creation-order counter:
|
||||
|
||||
```yaml
|
||||
address: c-000042
|
||||
```
|
||||
|
||||
Format: `c-<6-digit-counter>`. `c-` means "creation-order counter." Zero-padded.
|
||||
|
||||
**Future extension** (documented, not shipped in Phase 2):
|
||||
- Fold-relative path: `f1.2/c-000042` once folds exist, where `f1.2` encodes the fold-tree lineage.
|
||||
- Content hash suffix: `c-000042:h7f3c2` once the hash-rotation policy is decided.
|
||||
|
||||
**What Phase 2 MVP gives:**
|
||||
- Uniqueness: counter is monotonically increasing; deleted pages' addresses are retired, never reused.
|
||||
- Stability: never changes across content edits.
|
||||
- Determinism: derivable from the counter state at `.vault-meta/address-counter.txt`.
|
||||
- Ordering: preserves creation sequence.
|
||||
|
||||
**What this does NOT give (renamed "content-addressable paths" was misleading in v0.1):**
|
||||
- **No content-addressability in the MVP.** The Phase 2 address is a sequence counter, not a content hash. Renaming this mechanism from "content-addressable paths" to "deterministic page addresses" is more honest about what actually ships.
|
||||
- **No prompt cache benefit** (already corrected in v0.1 → v0.2). Per Anthropic docs, cache hits require byte-identical prefixes; an address field in frontmatter only helps if the frontmatter itself is inside a cached block AND stays byte-identical. Stable prefixes, not addresses, drive cache hits.
|
||||
|
||||
**Phase 2 exclusions** (all deferred):
|
||||
- Backfill of legacy pre-Phase-2 pages (will use `l-` prefix with its own counter).
|
||||
- Fold-ancestry bit prefix (requires committed folds from a future fold-of-folds skill).
|
||||
- Content hash suffix (rotation policy unresolved; see limitations).
|
||||
|
||||
**Implementation** (Phase 2, shipped):
|
||||
- `scripts/allocate-address.sh`: flock-guarded atomic allocator. All counter reads/writes go through this script; direct Write/Edit on `.vault-meta/address-counter.txt` is prohibited (would fire PostToolUse hook).
|
||||
- `skills/wiki-ingest/SKILL.md` → Address Assignment section: opt-in feature detection; delegates allocation to the helper; records path-to-address mapping in `.raw/.manifest.json` `address_map` for re-ingest stability.
|
||||
- `skills/wiki-lint/SKILL.md` → Address Validation section: format check, uniqueness check, counter-drift check, address-map consistency check.
|
||||
|
||||
**Lint severity model** (matches `skills/wiki-lint/SKILL.md` Address Validation behavior):
|
||||
- Post-rollout pages (frontmatter `created:` >= 2026-04-23, or any page newly created after DragonScale adoption) that lack an address are **errors**. This is the silent-regression guard.
|
||||
- Legacy pages (`created:` < 2026-04-23) without addresses are **informational**. The optional `.vault-meta/legacy-pages.txt` manifest can grandfather pages whose `created:` metadata is wrong or missing.
|
||||
- Meta pages (`_index.md`, `index.md`, `log.md`, `hot.md`, etc.) and fold pages are excluded entirely.
|
||||
|
||||
---
|
||||
|
||||
## Mechanism 3 — Semantic Tiling Lint
|
||||
|
||||
The tiling property says the same concept should live in one canonical page. Enforce it with an embedding-based dedup check in `wiki-lint`.
|
||||
|
||||
**Procedure (calibrated, not a guess):**
|
||||
1. Compute embeddings for every page. Default model: local `nomic-embed-text` via ollama on `http://127.0.0.1:11434`. Cost: local hardware time only (no API fees). The script supports a remote override under `--allow-remote-ollama`; remote endpoints may incur provider API fees.
|
||||
2. Compute pairwise cosine similarities for all page pairs.
|
||||
3. **Calibration** (one-time, before first use): label 50-100 in-vault page pairs as duplicate/near/distinct; find the thresholds that optimize target precision for each band.
|
||||
4. **Default bands** (used before calibration, then refined):
|
||||
- `≥ 0.90` — near-duplicate, lint error
|
||||
- `0.80 – 0.90` — review bucket, lint warning
|
||||
- `< 0.80` — distinct, no flag
|
||||
5. Never auto-merge. Output a review list.
|
||||
|
||||
**Why not a fixed 0.85?** v0.1 used 0.85 with no justification. Published thresholds in the embeddings literature span a wide range (Sentence Transformers' `community_detection` defaults to 0.75; Quora-duplicate calibrations land around 0.77–0.83; sparse-model defaults differ again). Thresholds are model-, corpus-, and objective-dependent, so calibration is required.
|
||||
|
||||
---
|
||||
|
||||
## Mechanism 4 — Boundary-First Autoresearch
|
||||
|
||||
> **Status: shipped (Phase 4, opt-in)** as of 2026-04-24. Implementation: `scripts/boundary-score.py`. Integration: `skills/autoresearch/SKILL.md` Topic Selection section B. Tests: `tests/test_boundary_score.py`.
|
||||
|
||||
Boundary pages (high out-degree relative to in-degree, recency-weighted) are the vault's frontier. `/autoresearch` invoked without a topic reads the top-5 boundary pages and offers them as research candidates; the user selects one (or types a free-text topic, or declines all and falls back to the original ask-user mode).
|
||||
|
||||
**Formula (exact)**:
|
||||
|
||||
```
|
||||
out_degree(p) = count of distinct filename-stem wikilinks in body of p that resolve to scoreable pages
|
||||
in_degree(p) = count of distinct scoreable pages whose body contains a wikilink to p
|
||||
recency_weight(p) = exp(-days_since_updated / 30) # no floor; old pages approach 0
|
||||
boundary_score(p) = (out_degree - in_degree) * recency_weight
|
||||
```
|
||||
|
||||
**Link resolution**: filename-stem only. `[[Foo]]` resolves to `Foo.md` anywhere in the vault. Aliases declared via frontmatter `aliases:` are NOT parsed. Folder-qualified links (e.g. `[[notes/Foo]]`) are resolved by stem alone. This matches Obsidian's default behavior for unique filenames but does not implement full alias resolution.
|
||||
|
||||
**Scoreable** = any page NOT excluded by any of:
|
||||
- frontmatter `type: meta` or `type: fold`
|
||||
- filename in `{_index.md, index.md, log.md, hot.md, overview.md, dashboard.md, Wiki Map.md, getting-started.md}`
|
||||
- path prefix in `wiki/folds/` or `wiki/meta/`
|
||||
- symlinks or paths whose resolved target escapes the vault root (rejected at scan time)
|
||||
|
||||
**Code-block filtering**: triple-backtick AND triple-tilde fenced code blocks are skipped, with CommonMark-like length tracking so a longer opening fence is not closed by a shorter inner fence. Indented code blocks (4+ spaces) are NOT filtered because Obsidian bullet lists commonly use 4-space indentation and contain real wikilinks. See `scripts/boundary-score.py:RECENCY_HALFLIFE_DAYS` for the sole tunable constant.
|
||||
|
||||
**Honest labeling**: this mechanism is **agenda control**, not pure memory. It shapes what the agent researches next. It is included in DragonScale because it is a direct consequence of the dragon-curve boundary analogy, and because it pairs naturally with folds (freshly folded pages have low out-degree; frontier pages are pre-fold). But the "memory only, not reasoning" framing does not cover it. Users who want a strict memory-layer subset should omit this mechanism (simply do not invoke `/autoresearch` without a topic, or do not set up `scripts/boundary-score.py`).
|
||||
|
||||
**What is NOT included**:
|
||||
- No auto-triggering. `/autoresearch` is still user-invoked.
|
||||
- No persistent boundary-score cache. Scoring is O(N * avg_links) and runs on every invocation from fresh wiki/ state.
|
||||
- No integration with folds or addresses. Pure graph analysis on the wikilink graph.
|
||||
- No automatic topic selection without user confirmation. The helper presents choices; the user picks.
|
||||
|
||||
---
|
||||
|
||||
## Operational Policies (required before implementation)
|
||||
|
||||
Adversarial review flagged these gaps in v0.1. Each must be decided before the corresponding phase ships.
|
||||
|
||||
| Policy | Phase 0 position | Decision point |
|
||||
|---|---|---|
|
||||
| **Retention / GC** | No automatic deletion. Pages are permanent. | Revisit if vault exceeds ~5000 pages. |
|
||||
| **Tombstones** | None. Deleted pages are removed via git revert. | Revisit if delete events become common. |
|
||||
| **Versioning** | Relied on git history, not in-vault versioning. | Address-hash rotation policy doubles as a coarse version signal. |
|
||||
| **Conflict resolution for contradictory folds** | Meta-page must quote both sources with explicit "conflict" callout. No automatic resolution. | Phase 1 spec required. |
|
||||
| **Concurrency / atomicity** | Single-writer assumption (one Claude session at a time). PostToolUse auto-commit serializes. | Multi-writer case deferred. |
|
||||
| **Provenance for meta-pages** | Every fold page must include frontmatter listing children and fold level. | Phase 1 must enforce. |
|
||||
| **Access control** | Out of scope. This is a single-user vault. | Revisit only if shared. |
|
||||
|
||||
---
|
||||
|
||||
## Mapping to Claude-Obsidian
|
||||
|
||||
| Mechanism | Status | New | Extends |
|
||||
|---|---|---|---|
|
||||
| Fold operator | shipped (Phase 1, dry-run verified) | `skills/wiki-fold/` | reads `log.md`, writes `wiki/folds/`, updates `index.md` on commit |
|
||||
| Address anchors | shipped (Phase 2, opt-in) | `scripts/allocate-address.sh`, new frontmatter field | `wiki-ingest` (assignment), `wiki-lint` (validation) |
|
||||
| Semantic tiling | shipped (Phase 2/3, opt-in) | `scripts/tiling-check.py`, `.vault-meta/tiling-thresholds.json` | `wiki-lint` with banded thresholds, calibration procedure documented |
|
||||
| Boundary-first | shipped (Phase 4, opt-in) | `scripts/boundary-score.py`, `tests/test_boundary_score.py` | `skills/autoresearch/SKILL.md` Topic Selection section B; `commands/autoresearch.md` no-topic path |
|
||||
|
||||
The existing hot → index → domain → page hierarchy already implements self-similarity across scales. That's the one dragon-curve property this vault had before DragonScale.
|
||||
|
||||
---
|
||||
|
||||
## Why This Over Alternatives
|
||||
|
||||
| Pattern | What it gives | What DragonScale adds |
|
||||
|---|---|---|
|
||||
| MemGPT virtual context (two-tier paging) | Main context ↔ external context swap | More than two levels; explicit fold triggers; dedup lint |
|
||||
| Pure LSM compaction | Exponential write-path throughput | Semantic-layer mechanisms (tiling, boundary); additive rollups over destructive merges |
|
||||
| Ad-hoc `/save` | Human-triggered filing | Rule-based fold cadence |
|
||||
| Vector-only RAG | Retrieval | Canonical-home structure; lineage addresses |
|
||||
|
||||
DragonScale composes patterns validated in adjacent systems: LSM *batching* (databases), MemGPT *paging* (agents), Anthropic *cache ordering* (prompt engineering), and embedding *dedup* (knowledge graphs).
|
||||
|
||||
---
|
||||
|
||||
## Known Limitations (v0.3)
|
||||
|
||||
- **Unvalidated at scale.** All four mechanisms are theoretical; none tested on a multi-thousand-page vault.
|
||||
- **Fold cadence is a knob, not a theorem.** `k=4` is a starting guess. Adaptive triggers are likely better.
|
||||
- **Address stability is unsolved.** Hash rotation on edits is a known issue; deferred.
|
||||
- **Boundary-first crosses scope.** Included with a warning, not quietly.
|
||||
- **Calibration load.** Tiling requires a one-time labeling pass; without it, only defaults apply.
|
||||
|
||||
---
|
||||
|
||||
## Primary Sources
|
||||
|
||||
Verified against primary sources on 2026-04-23. **Scope of tagging**: the specific numeric values, formulas, and named patterns below are tagged **[sourced]** when directly citable, **[derived]** when derivable from sourced material, or **[conjecture]** when based on reasoning without a specific source. **Not tagged** (and readers should treat as interpretive synthesis): framing sentences in the body such as "composes patterns validated," "self-similarity already exists," and the design rationale tying the four mechanisms together. These are editorial, not source-backed.
|
||||
|
||||
**Dragon curve math [sourced]**
|
||||
- Boundary dimension `2·log₂(λ)` where `λ³ − λ² − 2 = 0`, giving 1.523627086: [Dragon curve, Wikipedia](https://en.wikipedia.org/wiki/Dragon_curve)
|
||||
- Paper-folding construction and OEIS A014577: [Regular paperfolding sequence, Wikipedia](https://en.wikipedia.org/wiki/Regular_paperfolding_sequence); [OEIS A014577](https://oeis.org/A014577)
|
||||
- Tiling and rep-tiles: [Wolfram Demonstrations: Tiling Dragons and Rep-tiles of Order Two](https://demonstrations.wolfram.com/TilingDragonsAndRepTilesOfOrderTwo/)
|
||||
|
||||
**LSM trees [sourced]**
|
||||
- Level size ratios and compaction semantics: [RocksDB Compaction wiki](https://github.com/facebook/rocksdb/wiki/Compaction), [RocksDB Tuning Guide](https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide), [How to Grow an LSM-tree? (2025)](https://arxiv.org/abs/2504.17178)
|
||||
- LevelDB 10× level ratio: referenced in the arXiv paper above. Treat as *typical*, not required.
|
||||
|
||||
**LLM memory architectures [sourced]**
|
||||
- OS-inspired paging: [MemGPT: Towards LLMs as Operating Systems (Packer et al. 2023)](https://arxiv.org/abs/2310.08560)
|
||||
- Position sensitivity: [Lost in the Middle (Liu et al. 2023)](https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long)
|
||||
- Note-based agentic memory: [A-Mem (2025)](https://arxiv.org/abs/2502.12110)
|
||||
|
||||
**Prompt caching [sourced]**
|
||||
- Byte-identical prefix requirement, breakpoint mechanics, TTL options: [Anthropic Prompt Caching docs](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)
|
||||
|
||||
**Embedding thresholds [sourced]**
|
||||
- Sentence Transformers defaults and calibration examples: [Sentence Transformers util](https://sbert.net/docs/package_reference/util.html), [SBERT evaluation docs](https://sbert.net/docs/package_reference/sentence_transformer/evaluation.html)
|
||||
|
||||
**Reasoning search (out of scope, cited only to justify the scope boundary) [sourced]**
|
||||
- [Tree of Thoughts (Yao et al. 2023)](https://arxiv.org/abs/2305.10601)
|
||||
|
||||
**Items marked [conjecture] in this doc:**
|
||||
- `k=4`/`k=5` starting value for fold cadence (needs empirical tuning)
|
||||
- `~30s` full-vault embedding-pass time (needs measurement)
|
||||
- `boundary_score` formula exact weighting (a plausible starting form; not validated against retrieval metrics)
|
||||
|
||||
**Items marked [derived]:**
|
||||
- `⌈log₂(N)⌉` fold-depth bound (trivially derivable from the entry-count trigger)
|
||||
- Default tiling bands `{≥0.90, 0.80-0.90, <0.80}` before calibration (interpolated from cited ranges in Sentence Transformers examples; not optimal by construction)
|
||||
|
||||
---
|
||||
|
||||
## Review History
|
||||
|
||||
**v0.1 (2026-04-23, initial draft)** — written after a verification pass against Wikipedia, arXiv, and Anthropic docs. Four mechanisms proposed.
|
||||
|
||||
**v0.4 (2026-04-24, Phase 4 shipped)** — Mechanism 4 (boundary-first autoresearch) implemented as `scripts/boundary-score.py` with `tests/test_boundary_score.py` covering parsing, recency weight, wikilink extraction (with fence-length + tilde + indented-block tests), graph construction (self-loop/unresolved/meta-target exclusion), symlink rejection, and CLI surface (`--top`, `--page`, `--json`). Integrated into `skills/autoresearch/SKILL.md` as an opt-in Topic Selection mode with explicit helper-failure fallback. Spec's "NOT IMPLEMENTED" marker removed; exact scoring formula (no recency floor), filename-stem-only resolution disclosure, scope, and "what is NOT included" section added. Phase 3.6 pre-Phase-4 hardening shipped concurrently (5 fixes: `--report` path confinement, rollout baseline, AGENTS.md consistency, wiki-ingest .raw contradiction, install-guide version).
|
||||
|
||||
**v0.3 (2026-04-23, Phase 2 alignment)** — Mechanism 2 rewritten to match the actual Phase 2 MVP shipped in `wiki-ingest` and `wiki-lint`. Renamed from "Content-Addressable Paths" to "Deterministic Page Addresses" (the MVP is a creation-order counter, not a content hash). Documented the extension path for fold-ancestry bits and content-hash suffix, both explicitly deferred.
|
||||
|
||||
**v0.2 (2026-04-23, post-adversarial review)** — after `codex exec` adversarial review. All 7 critiques accepted:
|
||||
|
||||
1. *LSM "structurally identical"* → weakened to "loosely analogous to hierarchical rollup"; non-inherited properties listed explicitly.
|
||||
2. *Prompt cache address benefit* → removed strong claim; narrowed to organizational convention.
|
||||
3. *0.85 threshold* → replaced with calibration procedure and banded defaults.
|
||||
4. *2^k cadence* → justified as implementation convenience; adaptive trigger flagged as preferred for production.
|
||||
5. *Scope boundary contradiction* → acknowledged; boundary-first explicitly labeled as agenda control.
|
||||
6. *Missing production mechanisms* → added Operational Policies section (retention, versioning, conflict resolution, concurrency, provenance).
|
||||
7. *Unverified claims* → tagged specific numeric values, formulas, and named patterns as [sourced], [derived], or [conjecture]. Editorial synthesis in the body explicitly flagged as not tagged (see scope note under Primary Sources).
|
||||
|
||||
---
|
||||
|
||||
## Connections
|
||||
|
||||
See [[LLM Wiki Pattern]] for the broader pattern this extends.
|
||||
See [[Compounding Knowledge]] for why persistent state is the precondition for DragonScale.
|
||||
See [[Hot Cache]] for the existing 500-word session context, which is a level-0 manual fold.
|
||||
See [[Andrej Karpathy]] for the intellectual lineage.
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Dynamic Buckling Analysis"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000037
|
||||
aliases:
|
||||
- dynamic buckling
|
||||
- parametric resonance buckling
|
||||
- 동적 좌굴
|
||||
- 매개 변수 공진
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- dynamic-buckling
|
||||
- shell-elements
|
||||
status: current
|
||||
related:
|
||||
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
|
||||
- "[[Dynamic Instability Region]]"
|
||||
- "[[Geometric Stiffness Matrix]]"
|
||||
- "[[MITC4 Shell Element]]"
|
||||
- "[[Direct Time Integration Methods]]"
|
||||
sources:
|
||||
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
|
||||
---
|
||||
|
||||
# Dynamic Buckling Analysis
|
||||
|
||||
## Definition
|
||||
|
||||
Dynamic buckling analysis evaluates instability that occurs when a structure is subjected to time-varying compressive loading, often expressed as a parametric resonance problem.
|
||||
|
||||
## How It Works
|
||||
|
||||
The thesis frames the dynamic load as an axial compressive load with static and harmonic components. The finite element model supplies stiffness, geometric stiffness, and mass matrices. Vibration and buckling eigenvalue analyses are then used to determine natural frequencies, critical buckling loads, and the excitation/load combinations that form instability boundaries.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
Thin shell structures can be vulnerable to buckling and vibration. For vehicles exposed to large dynamic axial loads, such as high-speed aircraft, missiles, launch vehicles, re-entry vehicles, or supercavitating underwater vehicles, static buckling checks alone can miss instability regions caused by dynamic loading.
|
||||
|
||||
## Validation Thread
|
||||
|
||||
The source validates dynamic buckling against beam theory, then compares plate and stiffened plate instability regions with experimental trends. The beam example reports a natural frequency of 10.7 Hz and a critical buckling load of 71.73 N, while the plate example reports a natural frequency of 5.17 Hz and a critical buckling load of 49.6 N.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Dynamic Instability Region"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000038
|
||||
aliases:
|
||||
- instability region
|
||||
- dynamic buckling boundary
|
||||
- 불안정 경계 영역
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- dynamic-buckling
|
||||
- stability
|
||||
status: current
|
||||
related:
|
||||
- "[[Dynamic Buckling Analysis]]"
|
||||
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
|
||||
- "[[Finite Element Eigenproblem Solvers]]"
|
||||
sources:
|
||||
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
|
||||
---
|
||||
|
||||
# Dynamic Instability Region
|
||||
|
||||
## Definition
|
||||
|
||||
A dynamic instability region is the region in loading and excitation-frequency space where a dynamically compressed structure becomes unstable.
|
||||
|
||||
## How It Works
|
||||
|
||||
In the thesis, the instability region is obtained by sweeping dynamic load and excitation frequency parameters in a finite element dynamic buckling formulation. For the beam example, when the static load component is zero, the instability frequency at zero dynamic load appears near twice the natural frequency. As dynamic load amplitude increases, the instability region widens.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
The instability region is a design-level output: it identifies combinations of load amplitude and excitation frequency that should be avoided or mitigated by changing stiffness, mass, damping, supports, or reinforcement layout.
|
||||
|
||||
## Source Comparisons
|
||||
|
||||
The plate and stiffened plate examples compare finite element instability regions with experimental trends. The stiffened plate comparison shows larger discrepancies than the flat plate, attributed in the source to structural imperfections introduced by real manufacturing and reinforcement.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Engineering Mathematical Models"
|
||||
complexity: intermediate
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- engineering model idealization
|
||||
- mathematical modeling
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000007
|
||||
tags:
|
||||
- concept
|
||||
- modeling
|
||||
- finite-element-method
|
||||
status: current
|
||||
related:
|
||||
- "[[Finite Element Method]]"
|
||||
- "[[Computational Mechanics]]"
|
||||
sources:
|
||||
- "[[Finite Element Procedures]]"
|
||||
---
|
||||
|
||||
# Engineering Mathematical Models
|
||||
|
||||
## Definition
|
||||
|
||||
Engineering mathematical models are idealized descriptions of physical systems, including geometry, material behavior, loads, boundary conditions, constraints, and the governing equations selected for analysis.
|
||||
|
||||
## How It Works
|
||||
|
||||
The analyst chooses a model that is simple enough to solve and rich enough to answer the engineering question. A finite element solution then approximates that selected model. If the model is poorly chosen, a numerically accurate result can still be physically misleading.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
The source positions finite element analysis as part of an iterative engineering process: define the model, solve it, assess the result, compare against expected physical behavior, and refine the model when needed.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Finite Element Method]] solves mathematical models after discretization.
|
||||
- [[Mixed Finite Element Formulations]] and [[Nonlinear Finite Element Analysis]] are needed when the chosen model includes constraints, incompressibility, contact, or nonlinear material response.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Finite Element Procedures]]
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Finite Element Eigenproblem Solvers"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- eigensystem solution
|
||||
- finite element eigenvalue analysis
|
||||
- modal analysis
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000015
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- eigenproblems
|
||||
status: current
|
||||
related:
|
||||
- "[[Finite Element Method]]"
|
||||
- "[[Direct Time Integration Methods]]"
|
||||
- "[[Static Equilibrium Equation Solvers]]"
|
||||
- "[[Dynamic Buckling Analysis]]"
|
||||
- "[[Geometric Stiffness Matrix]]"
|
||||
- "[[BLZPACK]]"
|
||||
sources:
|
||||
- "[[Finite Element Procedures]]"
|
||||
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
|
||||
---
|
||||
|
||||
# Finite Element Eigenproblem Solvers
|
||||
|
||||
## Definition
|
||||
|
||||
Finite element eigenproblem solvers compute eigenvalues and eigenvectors of matrix systems such as `K phi = lambda M phi`, commonly used for free vibration, buckling, modal reduction, and stability analysis.
|
||||
|
||||
## How It Works
|
||||
|
||||
The source introduces eigenvector properties, shifting, zero-mass effects, standard-form transformations, Rayleigh-Ritz approximations, component mode synthesis, error bounds, and solution methods including inverse iteration, forward iteration, Rayleigh quotient iteration, Jacobi transformations, Householder-QR, polynomial iteration, Sturm sequence techniques, Lanczos iteration, and subspace iteration.
|
||||
|
||||
The dynamic buckling thesis adds an implementation example: [[BLZPACK]], based on Block Lanczos, is used for vibration and buckling eigenvalue analyses in a shell dynamic buckling program.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
Large finite element models can have many degrees of freedom, but engineering decisions often require only selected modes or eigenvalues. Solver choice determines whether the analysis can efficiently find the physically relevant part of the spectrum.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Direct Time Integration Methods]] can be contrasted with mode superposition.
|
||||
- [[Static Equilibrium Equation Solvers]] shares matrix factorization and conditioning concerns.
|
||||
- [[Finite Element Program Implementation]] must support sparse matrix operations and vector iteration workflows.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Finite Element Procedures]]
|
||||
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Finite Element Heat Transfer and Field Problems"
|
||||
complexity: intermediate
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- finite element field problems
|
||||
- finite element heat transfer
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000012
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- heat-transfer
|
||||
- fluid-flow
|
||||
status: current
|
||||
related:
|
||||
- "[[Finite Element Method]]"
|
||||
- "[[Direct Time Integration Methods]]"
|
||||
sources:
|
||||
- "[[Finite Element Procedures]]"
|
||||
---
|
||||
|
||||
# Finite Element Heat Transfer and Field Problems
|
||||
|
||||
## Definition
|
||||
|
||||
Finite element heat transfer and field problems apply the finite element workflow to scalar or vector fields beyond structural displacement, including temperature, seepage, inviscid flow, torsion, acoustics, and viscous incompressible flow.
|
||||
|
||||
## How It Works
|
||||
|
||||
The governing field equation and boundary conditions are written in a weak or weighted residual form, discretized over elements, assembled into a global system, and solved under steady-state, transient, linear, or nonlinear assumptions. The source treats heat transfer first, then general field problems, then viscous incompressible fluid flow and fluid-structure interaction.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
The chapter shows that finite element procedures are not limited to solid mechanics. Similar discretization and assembly patterns can solve different physical laws when the governing equations and boundary terms are formulated correctly.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Engineering Mathematical Models]] determines which governing equation is appropriate.
|
||||
- [[Direct Time Integration Methods]] applies to transient heat transfer and flow problems.
|
||||
- [[Mixed Finite Element Formulations]] is relevant for incompressible flow and pressure-like fields.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Finite Element Procedures]]
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Finite Element Method"
|
||||
complexity: intermediate
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- FEM
|
||||
- finite element analysis
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000006
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
status: current
|
||||
related:
|
||||
- "[[Computational Mechanics]]"
|
||||
- "[[Engineering Mathematical Models]]"
|
||||
- "[[Displacement-Based Finite Element Formulation]]"
|
||||
- "[[Isoparametric Finite Elements]]"
|
||||
- "[[Solid Element Notes]]"
|
||||
- "[[Isoparametric Linear Solid Elements]]"
|
||||
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
sources:
|
||||
- "[[Finite Element Procedures]]"
|
||||
- "[[A Continuum Mechanics Based Four-Node Shell]]"
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
- "[[Solid Element Notes]]"
|
||||
---
|
||||
|
||||
# Finite Element Method
|
||||
|
||||
## Definition
|
||||
|
||||
The finite element method is a numerical procedure for approximating solutions to physical problems by replacing a continuous domain with connected finite elements, choosing interpolation functions over each element, assembling local equations into a global algebraic system, and solving for the unknown field variables.
|
||||
|
||||
## How It Works
|
||||
|
||||
The workflow starts with a physical problem and an idealized mathematical model. The domain is discretized into elements, field variables are approximated using nodal degrees of freedom, element equations are derived from differential, variational, virtual work, or weighted residual statements, and the assembled global system is solved after boundary conditions and constraints are applied.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
Finite element analysis lets engineers approximate complex geometries, material behavior, loads, and boundary conditions that are difficult to solve analytically. The source repeatedly emphasizes that solution quality depends as much on modeling choices as on numerical algorithms.
|
||||
|
||||
The shell element paper adds a focused example: a useful element is not only a mesh topology, but a formulation choice that controls locking, rigid-body behavior, nonlinear kinematics, and benchmark performance.
|
||||
|
||||
The shell FE review reinforces the same modeling-first point: shell results require simultaneous understanding of physical behavior, the selected shell mathematical model, and the finite element approximation.
|
||||
|
||||
[[Solid Element Notes]] adds a compact element-level derivation for 3D continuum elements: natural-coordinate shape functions, Jacobian derivative mapping, `B` and `D` matrices, stiffness integration, and incompatible mode enrichment.
|
||||
|
||||
## Key Connections
|
||||
|
||||
- [[Engineering Mathematical Models]] defines what is being solved.
|
||||
- [[Displacement-Based Finite Element Formulation]] gives the main solid mechanics derivation.
|
||||
- [[Isoparametric Finite Elements]] describes practical element construction.
|
||||
- [[Continuum Mechanics Based Four-Node Shell Element]] is a focused low-order shell formulation example.
|
||||
- [[Static Equilibrium Equation Solvers]], [[Direct Time Integration Methods]], and [[Finite Element Eigenproblem Solvers]] solve the resulting systems.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Finite Element Procedures]]
|
||||
- [[A Continuum Mechanics Based Four-Node Shell]]
|
||||
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
|
||||
- [[Solid Element Notes]]
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Finite Element Program Implementation"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- finite element code architecture
|
||||
- STAP
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000016
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- implementation
|
||||
status: current
|
||||
related:
|
||||
- "[[Finite Element Method]]"
|
||||
- "[[Isoparametric Finite Elements]]"
|
||||
- "[[Static Equilibrium Equation Solvers]]"
|
||||
- "[[OOFEM]]"
|
||||
- "[[MITC4 Shell Element]]"
|
||||
- "[[Dynamic Buckling Analysis]]"
|
||||
- "[[BLZPACK]]"
|
||||
- "[[ABAQUS]]"
|
||||
sources:
|
||||
- "[[Finite Element Procedures]]"
|
||||
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
|
||||
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
|
||||
---
|
||||
|
||||
# Finite Element Program Implementation
|
||||
|
||||
## Definition
|
||||
|
||||
Finite element program implementation is the software organization needed to read model data, compute element quantities, assemble global matrices, solve equations, recover stresses, and report results.
|
||||
|
||||
## How It Works
|
||||
|
||||
The source describes the implementation path through nodal and element input, element stiffness, mass, and equivalent nodal load calculation, matrix assembly, stress calculation, and an example program called STAP. The flow is element-local first, global-system second: each element contributes local matrices and vectors, which are mapped into global degrees of freedom and assembled.
|
||||
|
||||
The MITC4 source adds a concrete code-level example: a shell element formulation is implemented in [[OOFEM]], verified through patch tests, and then checked on the [[Scordelis-Lo Shell Benchmark]].
|
||||
|
||||
The dynamic buckling thesis adds a second program implementation pattern: a custom MITC4 shell code uses a lumped mass matrix and [[BLZPACK]] for eigenvalue problems, then validates results against theoretical solutions, experiments, and [[ABAQUS]] comparisons.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
The finite element method becomes useful only when the mathematical formulation is encoded into reliable data structures and algorithms. Implementation details determine whether element routines, sparse matrix storage, solver selection, boundary condition handling, and postprocessing remain consistent.
|
||||
|
||||
## Implementation Checklist
|
||||
|
||||
- Define node, element, material, load, and boundary condition input structures.
|
||||
- Map local element degrees of freedom to global equation numbers.
|
||||
- Compute element matrices using shape functions, Jacobians, constitutive laws, and quadrature.
|
||||
- Assemble global sparse matrices and vectors.
|
||||
- Apply constraints and solve the resulting system.
|
||||
- Recover stresses or other derived quantities from the solved nodal field.
|
||||
- Verify new element implementations with patch tests and benchmark problems before treating production results as reliable.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Finite Element Procedures]]
|
||||
- [[Four-Node-Quadrilateral-Shell-Element-MITC4]]
|
||||
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Geometric Stiffness Matrix"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000039
|
||||
aliases:
|
||||
- initial stress stiffness matrix
|
||||
- stress stiffness matrix
|
||||
- 기하 강성 행렬
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- nonlinear-analysis
|
||||
- buckling
|
||||
status: current
|
||||
related:
|
||||
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
|
||||
- "[[Dynamic Buckling Analysis]]"
|
||||
- "[[Green-Lagrange Strain Linearization]]"
|
||||
- "[[Total Lagrangian Shell Formulation]]"
|
||||
- "[[Finite Element Eigenproblem Solvers]]"
|
||||
sources:
|
||||
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
|
||||
---
|
||||
|
||||
# Geometric Stiffness Matrix
|
||||
|
||||
## Definition
|
||||
|
||||
The geometric stiffness matrix is a stiffness contribution that arises from the current stress state and geometry of a structure, and is essential in buckling and geometric nonlinear analysis.
|
||||
|
||||
## How It Works
|
||||
|
||||
In the dynamic buckling thesis, the geometric stiffness matrix is derived through a [[Total Lagrangian Shell Formulation]] for the [[MITC4 Shell Element]]. The nonlinear strain terms are separated so that material stiffness and initial-stress stiffness contributions can be assembled. Static buckling then appears as an eigenvalue problem involving structural stiffness and geometric stiffness, while dynamic buckling also involves mass and time-varying load parameters.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
Without geometric stiffness, a finite element model may predict ordinary elastic response but cannot capture the loss of stability associated with compressive pre-stress. It is the bridge from stress state to buckling load, mode shape, and dynamic instability boundary.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Green-Lagrange Strain Linearization]] explains how nonlinear strain terms feed tangent construction.
|
||||
- [[Finite Element Eigenproblem Solvers]] are needed once stiffness and geometric stiffness form a buckling eigenproblem.
|
||||
- [[Dynamic Buckling Analysis]] uses separate geometric stiffness terms for static and dynamic load components.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Green-Lagrange Strain Linearization"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000030
|
||||
aliases:
|
||||
- Green Lagrange strain expansion
|
||||
- nonlinear strain linearization
|
||||
- total Lagrangian tangent strain terms
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- nonlinear-analysis
|
||||
- shell-elements
|
||||
status: current
|
||||
related:
|
||||
- "[[MITC Study Notes]]"
|
||||
- "[[Total Lagrangian Shell Formulation]]"
|
||||
- "[[Nonlinear Finite Element Analysis]]"
|
||||
- "[[MITC Shell Kinematics]]"
|
||||
sources:
|
||||
- "[[MITC Study Notes]]"
|
||||
---
|
||||
|
||||
# Green-Lagrange Strain Linearization
|
||||
|
||||
## Definition
|
||||
|
||||
Green-Lagrange strain linearization separates the nonlinear strain measure into terms that can be used to form residual forces and tangent stiffness contributions during incremental nonlinear finite element analysis.
|
||||
|
||||
## How It Works
|
||||
|
||||
The study notes use Green-Lagrange strain with second Piola-Kirchhoff stress in a reference-configuration virtual work statement. The strain expression is expanded with respect to the current displacement state and an incremental displacement. This separates terms associated with the existing strain state, terms linear in the increment, and terms nonlinear in the increment. The variation of the strain then produces internal force and tangent terms for Newton-Raphson iteration.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
In nonlinear shell analysis, the element stiffness is not a fixed matrix. The tangent must account for both material response and geometry-dependent stress terms. Linearizing the Green-Lagrange strain is the step that turns the nonlinear virtual work equation into a solvable incremental system.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Total Lagrangian Shell Formulation]] provides the reference configuration and stress/strain pair.
|
||||
- [[MITC Shell Kinematics]] defines the displacement and director variables being linearized.
|
||||
- [[Nonlinear Finite Element Analysis]] supplies the Newton iteration context.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[MITC Study Notes]]
|
||||
@@ -1,95 +0,0 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Hot Cache"
|
||||
complexity: basic
|
||||
domain: knowledge-management
|
||||
aliases:
|
||||
- "hot.md"
|
||||
- "Session Cache"
|
||||
- "Context Cache"
|
||||
created: 2026-04-07
|
||||
updated: 2026-04-07
|
||||
tags:
|
||||
- concept
|
||||
- knowledge-management
|
||||
- context
|
||||
status: mature
|
||||
related:
|
||||
- "[[LLM Wiki Pattern]]"
|
||||
- "[[Compounding Knowledge]]"
|
||||
- "[[index]]"
|
||||
- "[[hot]]"
|
||||
- "[[concepts/_index]]"
|
||||
sources:
|
||||
---
|
||||
|
||||
# Hot Cache
|
||||
|
||||
A ~500-word summary of the most recent context in the wiki vault. Stored in `wiki/hot.md`. Updated at the end of every session and after every significant ingest or query.
|
||||
|
||||
The hot cache exists to answer one question: "where did we leave off?" A new session reads `hot.md` first. If the answer is there, it skips crawling the rest of the wiki.
|
||||
|
||||
---
|
||||
|
||||
## What It Stores
|
||||
|
||||
- What was most recently ingested or discussed
|
||||
- Key recent facts and takeaways
|
||||
- Pages recently created or updated
|
||||
- Active threads and open questions
|
||||
- What the user is currently focused on
|
||||
|
||||
---
|
||||
|
||||
## Format
|
||||
|
||||
```markdown
|
||||
---
|
||||
type: meta
|
||||
title: "Hot Cache"
|
||||
updated: YYYY-MM-DDTHH:MM:SS
|
||||
---
|
||||
|
||||
# Recent Context
|
||||
|
||||
## Last Updated
|
||||
YYYY-MM-DD — [what happened]
|
||||
|
||||
## Key Recent Facts
|
||||
- [Most important recent takeaway]
|
||||
- [Second]
|
||||
|
||||
## Recent Changes
|
||||
- Created: new wiki pages from this ingest
|
||||
- Updated: existing pages with new connections
|
||||
- Flagged: contradictions between sources where found
|
||||
|
||||
## Active Threads
|
||||
- User is researching [topic]
|
||||
- Open question: [thing being investigated]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Rules
|
||||
|
||||
- Keep it under 500 words. It is a cache, not a journal.
|
||||
- Overwrite it completely each time. Not append-only.
|
||||
- One file. Not split by date.
|
||||
- Updated after every ingest, significant query, and at the end of each session.
|
||||
|
||||
---
|
||||
|
||||
## Why It Matters
|
||||
|
||||
Without the hot cache, every session starts cold: read the index (1000 tokens), read several domain sub-indexes, read several individual pages. With the hot cache, the first 500 tokens often have everything needed.
|
||||
|
||||
In practice, adding `hot.md` to an executive assistant vault dramatically reduces the token cost of session startup compared to crawling multiple wiki pages.
|
||||
|
||||
The hot cache is especially valuable in cross-project setups: another Claude Code project can point at this vault and read `hot.md` first to get recent context at minimal token cost.
|
||||
|
||||
---
|
||||
|
||||
## Connections
|
||||
|
||||
The hot cache is part of the [[LLM Wiki Pattern]] token discipline strategy. See [[index]] for how the broader navigation works.
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Incompatible Mode Solid Elements"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- incompatible mode solid element
|
||||
- nonconforming solid element mode
|
||||
- internal mode solid element
|
||||
- static condensation of incompatible modes
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000053
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- solid-elements
|
||||
- locking
|
||||
status: current
|
||||
related:
|
||||
- "[[Solid Element Notes]]"
|
||||
- "[[Mixed Finite Element Formulations]]"
|
||||
- "[[Solid Element Stiffness Integration]]"
|
||||
- "[[Shell Locking Phenomenon]]"
|
||||
sources:
|
||||
- "[[Solid Element Notes]]"
|
||||
---
|
||||
|
||||
# Incompatible Mode Solid Elements
|
||||
|
||||
## Definition
|
||||
|
||||
Incompatible mode solid elements add internal, non-nodal displacement modes to a solid element to enrich its deformation field and reduce locking or overly stiff behavior.
|
||||
|
||||
## How It Works
|
||||
|
||||
The source introduces extra internal degrees of freedom for selected 6-node wedge and 8-node hexahedral elements. The standard displacement interpolation is augmented by additional mode functions, producing an expanded strain-displacement matrix:
|
||||
|
||||
```text
|
||||
B_tot = [ B B_inc ]
|
||||
```
|
||||
|
||||
The resulting stiffness is assembled from the expanded matrix. Because the incompatible mode degrees of freedom are internal to the element and are not global nodal unknowns, they are eliminated by static condensation before the global solve.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
Low-order displacement-based solid elements can be too stiff in deformation states their interpolation cannot represent well. Incompatible modes are a local enrichment strategy: they improve element flexibility without changing the global mesh topology or adding nodal unknowns.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Solid Element Stiffness Integration]] is modified because the `B` matrix is augmented before condensation.
|
||||
- [[Mixed Finite Element Formulations]] provides the broader reliability pattern of adding or altering fields to avoid locking and constraints.
|
||||
- [[Shell Locking Phenomenon]] is a shell-specific locking case; this page records the analogous solid-element enrichment strategy from the source.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Solid Element Notes]]
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Isoparametric Finite Elements"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- isoparametric elements
|
||||
- isoparametric formulation
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000009
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- numerical-integration
|
||||
status: current
|
||||
related:
|
||||
- "[[Finite Element Method]]"
|
||||
- "[[Displacement-Based Finite Element Formulation]]"
|
||||
- "[[Mixed Finite Element Formulations]]"
|
||||
- "[[Solid Element Notes]]"
|
||||
- "[[Isoparametric Linear Solid Elements]]"
|
||||
- "[[Solid Element Shape Functions]]"
|
||||
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
|
||||
- "[[Assumed Transverse Shear Strain Interpolation]]"
|
||||
sources:
|
||||
- "[[Finite Element Procedures]]"
|
||||
- "[[A Continuum Mechanics Based Four-Node Shell]]"
|
||||
- "[[Solid Element Notes]]"
|
||||
---
|
||||
|
||||
# Isoparametric Finite Elements
|
||||
|
||||
## Definition
|
||||
|
||||
Isoparametric finite elements use the same interpolation framework to represent both element geometry and field variables, mapping a simple natural-coordinate element to the physical element through shape functions and a Jacobian.
|
||||
|
||||
## How It Works
|
||||
|
||||
The element is defined in natural coordinates, shape functions interpolate geometry and unknown fields, the Jacobian maps derivatives and integration measures into physical coordinates, and numerical quadrature evaluates stiffness, mass, load, and other element matrices.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
The isoparametric framework is the practical bridge from finite element theory to general-purpose element routines. It supports quadrilateral, triangular, solid, beam, plate, and shell elements, while exposing key numerical choices such as quadrature order, reduced integration, selective integration, and element distortion sensitivity.
|
||||
|
||||
The four-node shell paper is an example of this bridge: a general quadrilateral shell can be economical and nonlinear-capable, but the interpolation must be modified to avoid shear locking in thin shell limits.
|
||||
|
||||
[[Solid Element Notes]] provides the direct 3D continuum example: 4-node tetrahedral, 5-node pyramid, 6-node wedge, and 8-node hexahedral elements interpolate both position and displacement with the same natural-coordinate functions before mapping derivatives through the Jacobian.
|
||||
|
||||
## Failure Modes
|
||||
|
||||
- Distorted elements can degrade accuracy or convergence.
|
||||
- Under-integration can introduce spurious mechanisms.
|
||||
- Overly constrained interpolation can cause locking.
|
||||
- Incompressible behavior often requires mixed displacement/pressure treatment.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Finite Element Procedures]]
|
||||
- [[A Continuum Mechanics Based Four-Node Shell]]
|
||||
- [[Solid Element Notes]]
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Isoparametric Linear Solid Elements"
|
||||
complexity: intermediate
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- linear solid elements
|
||||
- first-order solid elements
|
||||
- isoparametric solid elements
|
||||
- 3D solid elements
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000049
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- solid-elements
|
||||
- isoparametric-elements
|
||||
status: current
|
||||
related:
|
||||
- "[[Solid Element Notes]]"
|
||||
- "[[Isoparametric Finite Elements]]"
|
||||
- "[[Displacement-Based Finite Element Formulation]]"
|
||||
- "[[Solid Element Shape Functions]]"
|
||||
- "[[Solid Element Strain-Displacement Matrix]]"
|
||||
- "[[Solid Element Stiffness Integration]]"
|
||||
sources:
|
||||
- "[[Solid Element Notes]]"
|
||||
---
|
||||
|
||||
# Isoparametric Linear Solid Elements
|
||||
|
||||
## Definition
|
||||
|
||||
Isoparametric linear solid elements are first-order three-dimensional continuum finite elements that interpolate both geometry and displacement with the same nodal shape functions.
|
||||
|
||||
## How They Work
|
||||
|
||||
The source treats solid elements as volume elements with three translational displacement degrees of freedom per node: `u`, `v`, and `w`. They do not include rotational degrees of freedom, so connecting them directly to beam, plate, or shell elements can require care to avoid singular constraints.
|
||||
|
||||
The physical position and displacement field are both interpolated from nodal values:
|
||||
|
||||
```text
|
||||
x(xi) = sum N_i(xi) x_i
|
||||
u(xi) = sum N_i(xi) u_i
|
||||
```
|
||||
|
||||
The covered topologies are 4-node tetrahedron, 5-node pyramid, 6-node wedge, and 8-node hexahedron. In each case, the element is defined in natural coordinates and mapped to physical space through the Jacobian.
|
||||
|
||||
## Practical Notes
|
||||
|
||||
- Solid elements are suited to three-dimensional volume response rather than beam or shell idealizations.
|
||||
- Aspect ratios close to one are preferred because distortion degrades the shape-function mapping and numerical integration quality.
|
||||
- The absence of rotational degrees of freedom is a modeling interface issue when solid elements meet structural elements.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Solid Element Shape Functions]] defines the natural-coordinate interpolation for each covered topology.
|
||||
- [[Solid Element Strain-Displacement Matrix]] converts the displacement interpolation into engineering strain components.
|
||||
- [[Solid Element Stiffness Integration]] assembles the stiffness matrix from `B`, `D`, and the Jacobian.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Solid Element Notes]]
|
||||
@@ -1,97 +0,0 @@
|
||||
---
|
||||
type: concept
|
||||
title: "LLM Wiki Pattern"
|
||||
complexity: intermediate
|
||||
domain: knowledge-management
|
||||
aliases:
|
||||
- "LLM Knowledge Base"
|
||||
- "Karpathy Wiki"
|
||||
- "Persistent Wiki"
|
||||
created: 2026-04-07
|
||||
updated: 2026-04-07
|
||||
tags:
|
||||
- concept
|
||||
- knowledge-management
|
||||
- llm
|
||||
- obsidian
|
||||
status: mature
|
||||
related:
|
||||
- "[[Hot Cache]]"
|
||||
- "[[Compounding Knowledge]]"
|
||||
- "[[Andrej Karpathy]]"
|
||||
- "[[index]]"
|
||||
- "[[concepts/_index]]"
|
||||
sources:
|
||||
---
|
||||
|
||||
# LLM Wiki Pattern
|
||||
|
||||
A pattern for building persistent, compounding knowledge bases using LLMs. Originated by [[Andrej Karpathy]]. The key insight: instead of re-deriving knowledge from raw documents on every query (RAG), the LLM incrementally builds and maintains a structured wiki that gets richer with every source added.
|
||||
|
||||
---
|
||||
|
||||
## The Core Idea
|
||||
|
||||
Most AI knowledge tools work like RAG: index raw documents, retrieve chunks at query time, generate an answer. Nothing accumulates. Ask a question that needs five documents and the LLM reassembles fragments every time.
|
||||
|
||||
The wiki pattern is different. When a new source arrives, the LLM reads it, extracts what matters, and integrates it into the wiki: updating entity pages, noting contradictions, strengthening the synthesis. The cross-references are already there. The knowledge is compiled once and kept current.
|
||||
|
||||
**The wiki is a persistent, compounding artifact.** The human curates sources and asks questions. The LLM writes and maintains everything.
|
||||
|
||||
---
|
||||
|
||||
## Three Layers
|
||||
|
||||
```
|
||||
.raw/ Layer 1 — immutable source documents
|
||||
wiki/ Layer 2 — LLM-generated knowledge base
|
||||
CLAUDE.md Layer 3 — schema that tells the LLM how to maintain it
|
||||
```
|
||||
|
||||
The LLM owns Layer 2 entirely. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. The human reads; the LLM writes.
|
||||
|
||||
---
|
||||
|
||||
## Operations
|
||||
|
||||
**Ingest** — drop a source into `.raw/`, tell the LLM to process it. The LLM reads the source, discusses key takeaways, writes a summary page, updates entity and concept pages, and logs the operation. One source typically touches 8-15 wiki pages.
|
||||
|
||||
**Query** — ask a question. The LLM reads the index to find relevant pages, synthesizes an answer with citations. Good answers get filed back into the wiki.
|
||||
|
||||
**Lint** — periodic health check. Find orphan pages, dead links, stale claims, missing cross-references.
|
||||
|
||||
---
|
||||
|
||||
## Index and Log
|
||||
|
||||
**index.md** — content-oriented. A catalog of all pages with one-line summaries, organized by category. The LLM reads this first on every query to find relevant pages.
|
||||
|
||||
**log.md** — chronological. Append-only record of every ingest, query, and lint pass. Parseable: `grep "^## \[" log.md | head -10`
|
||||
|
||||
---
|
||||
|
||||
## Why It Works
|
||||
|
||||
The tedious part of maintaining a knowledge base is bookkeeping: updating cross-references, noting when new data contradicts old claims, keeping summaries current. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don't get bored. The wiki stays maintained because the cost of maintenance is near zero.
|
||||
|
||||
At small scale (~100 sources, ~hundreds of pages), the index file is sufficient. No vector database, no embeddings, no infrastructure. Just markdown files.
|
||||
|
||||
---
|
||||
|
||||
## Comparison to RAG
|
||||
|
||||
| Dimension | LLM Wiki | Semantic RAG |
|
||||
|-----------|----------|-------------|
|
||||
| Finding | Reads index, follows links | Similarity search over embeddings |
|
||||
| Infrastructure | Just markdown files | Embedding model + vector DB |
|
||||
| Cost | Tokens only | Ongoing compute + storage |
|
||||
| Maintenance | Run a lint | Re-embed when content changes |
|
||||
| Scale limit | Hundreds of pages | Millions of documents |
|
||||
|
||||
---
|
||||
|
||||
## Connections
|
||||
|
||||
See [[Compounding Knowledge]] for why the pattern produces more value over time.
|
||||
See [[Hot Cache]] for the session context optimization.
|
||||
See [[Andrej Karpathy]] for the pattern's origin.
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
type: concept
|
||||
title: "MITC Shell Kinematics"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000029
|
||||
aliases:
|
||||
- MITC kinematics
|
||||
- shell director kinematics
|
||||
- degenerated continuum shell kinematics
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- shell-elements
|
||||
- mitc
|
||||
status: current
|
||||
related:
|
||||
- "[[MITC Study Notes]]"
|
||||
- "[[MITC4 Shell Element]]"
|
||||
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
|
||||
- "[[Total Lagrangian Shell Formulation]]"
|
||||
sources:
|
||||
- "[[MITC Study Notes]]"
|
||||
---
|
||||
|
||||
# MITC Shell Kinematics
|
||||
|
||||
## Definition
|
||||
|
||||
MITC shell kinematics describe a shell element as a three-dimensional continuum degenerated through the shell thickness, with midsurface nodal positions and director vectors defining points inside the shell.
|
||||
|
||||
## How It Works
|
||||
|
||||
The study notes express reference and current shell positions using four-node shape functions plus a through-thickness coordinate multiplying nodal thickness and director vectors. The displacement field follows from the difference between current and reference positions. Incremental displacement is then split into nodal translation increments and director-vector increments caused by nodal rotations.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
This kinematic setup is the bridge between solid-like continuum measures and shell element degrees of freedom. It lets the element use three-dimensional strain and stress measures while keeping the computational cost close to a low-order shell element.
|
||||
|
||||
## Practical Frame
|
||||
|
||||
- Midsurface interpolation locates the shell surface.
|
||||
- Director vectors carry the through-thickness direction.
|
||||
- Nodal translations move the midsurface.
|
||||
- Nodal rotations update the directors.
|
||||
- The through-thickness coordinate connects director motion to bending behavior.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[MITC4 Shell Element]] uses this kinematic structure in a four-node quadrilateral element.
|
||||
- [[Continuum Mechanics Based Four-Node Shell Element]] is the broader Dvorkin-Bathe lineage for this shell description.
|
||||
- [[Total Lagrangian Shell Formulation]] supplies the reference-configuration viewpoint used later in the derivation.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[MITC Study Notes]]
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
type: concept
|
||||
title: "MITC4 Shell Element"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- MITC4
|
||||
- Mixed Interpolation of Tensorial Components shell element
|
||||
- four-node quadrilateral MITC shell
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000023
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- shell-elements
|
||||
- mitc
|
||||
- locking
|
||||
status: current
|
||||
related:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
- "[[Shell Locking Phenomenon]]"
|
||||
- "[[Uniform Optimal Convergence]]"
|
||||
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
|
||||
- "[[Dynamic Buckling Analysis]]"
|
||||
- "[[MITC Study Notes]]"
|
||||
- "[[MITC Shell Kinematics]]"
|
||||
- "[[Green-Lagrange Strain Linearization]]"
|
||||
- "[[Nonlinear Newmark-Beta Integration]]"
|
||||
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
|
||||
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
|
||||
- "[[Assumed Transverse Shear Strain Interpolation]]"
|
||||
- "[[Scordelis-Lo Shell Benchmark]]"
|
||||
- "[[OOFEM]]"
|
||||
sources:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
|
||||
- "[[MITC Study Notes]]"
|
||||
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
|
||||
---
|
||||
|
||||
# MITC4 Shell Element
|
||||
|
||||
## Definition
|
||||
|
||||
MITC4 is a four-node quadrilateral shell finite element that uses Mixed Interpolation of Tensorial Components to avoid transverse shear locking while retaining a low-order shell topology.
|
||||
|
||||
## How It Works
|
||||
|
||||
The element starts from a three-dimensional continuum description degenerated to shell behavior. Its displacement field uses four corner nodes, director vectors through the shell thickness, three translations, and two rotations at each node. Direct interpolation of this displacement field can create nonzero transverse shear strain under thin-shell bending, so MITC4 constructs assumed transverse shear strain components from edge-midpoint tying locations and transforms them through the convected coordinate basis.
|
||||
|
||||
The study notes expand the derivation path: [[MITC Shell Kinematics]] defines reference/current positions and director updates, [[Green-Lagrange Strain Linearization]] supplies the nonlinear tangent terms, and [[Nonlinear Newmark-Beta Integration]] shows how the dynamic residual is solved in time.
|
||||
|
||||
The dynamic buckling thesis uses MITC4 as the shell element for a full analysis program, then validates it through patch tests, linear shell benchmarks, geometric nonlinear response, static buckling, and dynamic buckling examples.
|
||||
|
||||
[[On-the-Finite-Element-Analysis-of-Shell-Structures]] places MITC in the broader shell FE reliability problem: mixed interpolation should reduce [[Shell Locking Phenomenon]] in bending and mixed-dominated shells while preserving consistency and ellipticity in membrane-dominated shells.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
Low-order shell elements are computationally attractive, but thin-shell bending exposes shear locking if the element cannot represent near-zero transverse shear strain. MITC4 preserves the economy of a four-node quadrilateral while making the element usable across thick and thin shells.
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
The source describes an [[OOFEM]] implementation. The element stiffness follows the standard `B^T D B` volume integral, with a shell-degenerated three-dimensional material matrix and a zero normal stress condition through the thickness.
|
||||
|
||||
## Validation
|
||||
|
||||
The paper reports patch-test verification for pure bending, pure shear, pure twist, and membrane stress states. It then uses the [[Scordelis-Lo Shell Benchmark]] to study convergence against a reference solution and an RDKT comparison.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Four-Node-Quadrilateral-Shell-Element-MITC4]]
|
||||
- [[MITC Study Notes]]
|
||||
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
|
||||
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Mixed Finite Element Formulations"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- mixed formulation
|
||||
- displacement-pressure formulation
|
||||
- inf-sup condition
|
||||
- assumed strain formulation
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000010
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- incompressibility
|
||||
status: current
|
||||
related:
|
||||
- "[[Displacement-Based Finite Element Formulation]]"
|
||||
- "[[Isoparametric Finite Elements]]"
|
||||
- "[[Nonlinear Finite Element Analysis]]"
|
||||
- "[[Assumed Transverse Shear Strain Interpolation]]"
|
||||
- "[[Shell Locking Phenomenon]]"
|
||||
- "[[Uniform Optimal Convergence]]"
|
||||
- "[[Incompatible Mode Solid Elements]]"
|
||||
sources:
|
||||
- "[[Finite Element Procedures]]"
|
||||
- "[[A Continuum Mechanics Based Four-Node Shell]]"
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
- "[[Solid Element Notes]]"
|
||||
---
|
||||
|
||||
# Mixed Finite Element Formulations
|
||||
|
||||
## Definition
|
||||
|
||||
Mixed finite element formulations approximate more than one primary field, such as displacement and pressure, instead of relying only on displacement unknowns.
|
||||
|
||||
## How It Works
|
||||
|
||||
Additional field variables are introduced to represent constraints or stress-like quantities directly. For incompressible or nearly incompressible media, displacement/pressure formulations separate volumetric constraint behavior from deviatoric deformation. Stability depends on compatible interpolation choices, often summarized by the inf-sup condition.
|
||||
|
||||
The four-node shell paper is not simply a displacement/pressure mixed formulation, but it uses the same reliability idea: a constrained or separately assumed field can remove locking when direct displacement interpolation is too restrictive.
|
||||
|
||||
[[On-the-Finite-Element-Analysis-of-Shell-Structures]] adds the shell-specific stability view: MITC-style mixed interpolation is useful because it can reduce locking, but the chosen strain field still has to retain consistency, ellipticity, and thickness-uniform convergence.
|
||||
|
||||
[[Solid Element Notes]] adds another local enrichment pattern: incompatible mode solid elements introduce internal deformation modes and statically condense them, improving element flexibility without adding global nodal unknowns.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
Mixed formulations are needed when displacement-only elements lock, produce spurious pressure modes, or fail to represent constrained fields accurately. The source treats the inf-sup condition as a central test of whether the chosen interpolation spaces are stable.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Isoparametric Finite Elements]] supplies the element construction machinery.
|
||||
- [[Nonlinear Finite Element Analysis]] uses mixed formulations for large deformation incompressible behavior.
|
||||
- [[Finite Element Heat Transfer and Field Problems]] uses analogous ideas when multiple fields interact.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Finite Element Procedures]]
|
||||
- [[A Continuum Mechanics Based Four-Node Shell]]
|
||||
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
|
||||
- [[Solid Element Notes]]
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Nonlinear Finite Element Analysis"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- nonlinear FEA
|
||||
- incremental finite element analysis
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000011
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- nonlinear-analysis
|
||||
status: current
|
||||
related:
|
||||
- "[[Finite Element Method]]"
|
||||
- "[[Mixed Finite Element Formulations]]"
|
||||
- "[[Static Equilibrium Equation Solvers]]"
|
||||
- "[[Direct Time Integration Methods]]"
|
||||
- "[[Total Lagrangian Shell Formulation]]"
|
||||
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
|
||||
- "[[Green-Lagrange Strain Linearization]]"
|
||||
- "[[Nonlinear Newmark-Beta Integration]]"
|
||||
- "[[Geometric Stiffness Matrix]]"
|
||||
- "[[Dynamic Buckling Analysis]]"
|
||||
sources:
|
||||
- "[[Finite Element Procedures]]"
|
||||
- "[[A Continuum Mechanics Based Four-Node Shell]]"
|
||||
- "[[MITC Study Notes]]"
|
||||
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
|
||||
---
|
||||
|
||||
# Nonlinear Finite Element Analysis
|
||||
|
||||
## Definition
|
||||
|
||||
Nonlinear finite element analysis solves models where the response is not a linear function of the unknowns because of geometry changes, nonlinear material behavior, contact, follower loads, or other state-dependent effects.
|
||||
|
||||
## How It Works
|
||||
|
||||
The response is advanced incrementally. At each load or time step, the equations are linearized about the current configuration, a tangent system is solved, the configuration or state variables are updated, and convergence is checked. The source organizes this through total Lagrangian and updated Lagrangian descriptions, material constitutive updates, contact conditions, and practical convergence criteria.
|
||||
|
||||
The four-node shell paper gives a focused structural example: a [[Total Lagrangian Shell Formulation]] is used for large displacement and rotation shell response under small strain assumptions, with benchmark problems that include snap-through, buckling, and elastoplastic plate response.
|
||||
|
||||
The MITC study notes add the algebraic bridge from nonlinear kinematics to solution: Green-Lagrange strain is linearized for tangent construction, and nonlinear Newmark-beta time integration embeds Newton iteration inside each dynamic time step.
|
||||
|
||||
The dynamic buckling thesis uses geometric nonlinearity to build the geometric stiffness terms required for buckling eigenvalue problems, then validates the resulting program against static, vibration, and dynamic buckling benchmarks.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
Many engineering failures, large deformation behaviors, buckling events, contact interactions, and elastoplastic responses cannot be captured by a single linear solve. Nonlinear analysis adds physical realism but also adds dependence on increments, tangent quality, convergence tests, and path-following strategy.
|
||||
|
||||
## Practical Questions
|
||||
|
||||
- What nonlinearity dominates: geometry, material, contact, or loading?
|
||||
- Is the tangent matrix consistent with the residual?
|
||||
- Are increments small enough to follow the equilibrium path?
|
||||
- Do convergence criteria reflect the physical quantity of interest?
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Finite Element Procedures]]
|
||||
- [[A Continuum Mechanics Based Four-Node Shell]]
|
||||
- [[MITC Study Notes]]
|
||||
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Nonlinear Newmark-Beta Integration"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000031
|
||||
aliases:
|
||||
- nonlinear Newmark method
|
||||
- Newmark-beta Newton iteration
|
||||
- implicit Newmark nonlinear dynamics
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- dynamics
|
||||
- nonlinear-analysis
|
||||
status: current
|
||||
related:
|
||||
- "[[MITC Study Notes]]"
|
||||
- "[[Direct Time Integration Methods]]"
|
||||
- "[[Nonlinear Finite Element Analysis]]"
|
||||
- "[[Static Equilibrium Equation Solvers]]"
|
||||
sources:
|
||||
- "[[MITC Study Notes]]"
|
||||
---
|
||||
|
||||
# Nonlinear Newmark-Beta Integration
|
||||
|
||||
## Definition
|
||||
|
||||
Nonlinear Newmark-beta integration combines Newmark time-discretization kinematics with Newton-Raphson iteration to solve nonlinear finite element dynamic equilibrium at each time step.
|
||||
|
||||
## How It Works
|
||||
|
||||
The study notes start from dynamic equilibrium with mass, stiffness, and external load terms. At the new time step, the residual depends on displacement, velocity, and acceleration. Newmark-beta relations express velocity and acceleration increments in terms of the unknown displacement increment, so the Newton system can be written as an effective tangent equation for that displacement increment.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
For nonlinear structural dynamics, a time step is not just a matrix update. Internal force and tangent stiffness depend on the current trial displacement, so each step requires repeated residual evaluation, tangent assembly, displacement correction, and velocity/acceleration update until convergence.
|
||||
|
||||
## Iteration Skeleton
|
||||
|
||||
- Predict or initialize the new-step displacement, velocity, and acceleration.
|
||||
- Assemble residual from external load, inertia, and internal force.
|
||||
- Form the effective tangent with mass and nonlinear tangent contributions.
|
||||
- Solve for the displacement correction.
|
||||
- Update displacement, velocity, and acceleration using Newmark-beta formulas.
|
||||
- Repeat until the residual and/or correction satisfies convergence criteria.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[MITC Study Notes]]
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Persistent Wiki Artifact"
|
||||
created: 2026-04-24
|
||||
updated: 2026-04-24
|
||||
tags:
|
||||
- llm-wiki
|
||||
- knowledge-management
|
||||
- agent-memory
|
||||
status: developing
|
||||
related:
|
||||
- "[[How does the LLM Wiki pattern work?]]"
|
||||
- "[[LLM Wiki Pattern]]"
|
||||
- "[[Compounding Knowledge]]"
|
||||
- "[[Source-First Synthesis]]"
|
||||
- "[[Query-Time Retrieval]]"
|
||||
---
|
||||
|
||||
# Persistent Wiki Artifact
|
||||
|
||||
A persistent wiki artifact is the maintained Markdown layer between raw sources and future questions. In Karpathy's LLM Wiki description, the agent reads source material, extracts key information, and integrates it into an interlinked wiki instead of only retrieving chunks at answer time: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
|
||||
## Boundary Filled
|
||||
|
||||
The selected question explains that an LLM Wiki compounds knowledge, but it does not isolate the artifact as the unit of memory. This page makes that boundary explicit: memory is stored in files that can be browsed, linked, reviewed, and revised.
|
||||
|
||||
## Extracted Claims
|
||||
|
||||
- The LLM Wiki pattern defines raw sources, the generated wiki, and a schema document as separate layers: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
- In that pattern, the raw source collection is treated as immutable, while the wiki layer is owned and maintained by the LLM: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
- The pattern frames the wiki as a compounding artifact whose cross-references, contradiction flags, and synthesis persist across later questions: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
- Obsidian supports Wikilinks such as `[[Three laws of motion]]`, which lets Markdown files form an internal network of notes: https://obsidian.md/help/links
|
||||
- Obsidian can automatically update internal links when a file is renamed, depending on the vault setting: https://obsidian.md/help/links
|
||||
|
||||
## Implications for This Vault
|
||||
|
||||
- The durable memory object is the page, not the chat turn.
|
||||
- The page needs frontmatter, stable title, wikilinks, and source URLs so later agents can inspect provenance.
|
||||
- The page should remain small enough to revise directly, because the LLM Wiki pattern depends on updating existing synthesis when new sources arrive: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
|
||||
## Primary Sources
|
||||
|
||||
- https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
- https://obsidian.md/help/links
|
||||
@@ -1,60 +0,0 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Pro Hub Challenge"
|
||||
created: 2026-04-14
|
||||
updated: 2026-04-14
|
||||
tags:
|
||||
- concept
|
||||
- community
|
||||
- ai-marketing-hub
|
||||
- claude-seo
|
||||
- open-source
|
||||
status: evergreen
|
||||
related:
|
||||
- "[[Claude SEO]]"
|
||||
- "[[2026-04-14-claude-seo-v190-session]]"
|
||||
- "[[Semantic Topic Clustering]]"
|
||||
- "[[Search Experience Optimization]]"
|
||||
---
|
||||
|
||||
# Pro Hub Challenge
|
||||
|
||||
A community challenge hosted in the [AI Marketing Hub Pro](https://www.skool.com/ai-marketing-hub-pro) Skool community where members build extensions for Claude SEO or Claude Blog, competing for $600 in Claude Credits.
|
||||
|
||||
## First Challenge (v1.9.0, April 2026)
|
||||
|
||||
**6 submissions, 5 scored Proficient or above**
|
||||
|
||||
| Contributor | Submission | Score | Integrated? |
|
||||
|------------|------------|-------|-------------|
|
||||
| Lutfiya Miller | Semantic Cluster Engine | Winner | Yes — `seo-cluster` |
|
||||
| Florian Schmitz | SXO Skill | Proficient | Yes — `seo-sxo` |
|
||||
| Dan Colta | SEO Drift Monitor | Proficient | Yes — `seo-drift` |
|
||||
| Chris Muller | Multi-lingual Blog | Proficient | Partial — SEO parts into `seo-hreflang` |
|
||||
| Matej Marjanovic | E-commerce + Cost Config | Proficient | Yes — `seo-ecommerce` + cost guardrails |
|
||||
| Benjamin Samar | SEO Dungeon | Reviewed | No — not integrated in v1.9.0 |
|
||||
|
||||
## Integration Pattern
|
||||
|
||||
Community submissions go through:
|
||||
1. **Full code review** — architecture, quality, security
|
||||
2. **Security audit** — SSRF, injection, credential handling
|
||||
3. **Cherry-pick** — only SEO-relevant parts for claude-seo, blog parts stay for claude-blog
|
||||
4. **De-brand** — remove contributor-specific branding (e.g., ScienceExperts.ai)
|
||||
5. **Attribution** — `original_author` in SKILL.md frontmatter, HTML comments in agents, CONTRIBUTORS.md
|
||||
|
||||
## Submission Guidelines (from CONTRIBUTING.md)
|
||||
|
||||
1. SKILL.md under 500 lines, references under 200 lines
|
||||
2. All scripts must import `validate_url()` for SSRF protection
|
||||
3. Include `original_author` in SKILL.md frontmatter metadata
|
||||
4. Submit via PR or post in AI Marketing Hub community
|
||||
|
||||
## Second Challenge (April 2026)
|
||||
|
||||
**Keyword**: LEADS
|
||||
**Prize pool**: $600 ($400 first place, $200 second place) in Claude Credits
|
||||
**Deadline**: April 28, 2026
|
||||
**Scope**: Anything touching lead generation — Claude Code skills, n8n workflows, MCP servers, scrapers, dashboards, pipelines. If it helps someone capture, qualify, nurture, or convert leads, it counts.
|
||||
**Rules**: GitHub repo or .zip file + 1-2 minute demo video. Must be functional (not a concept). Solo or team both welcome.
|
||||
**Previous winner**: Lutfiya Miller (seo-cluster, integrated in v1.9.0)
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Query-Time Retrieval"
|
||||
created: 2026-04-24
|
||||
updated: 2026-04-24
|
||||
tags:
|
||||
- rag
|
||||
- retrieval
|
||||
- llm-wiki
|
||||
status: developing
|
||||
related:
|
||||
- "[[How does the LLM Wiki pattern work?]]"
|
||||
- "[[Wiki vs RAG]]"
|
||||
- "[[LLM Wiki Pattern]]"
|
||||
- "[[Persistent Wiki Artifact]]"
|
||||
- "[[Source-First Synthesis]]"
|
||||
---
|
||||
|
||||
# Query-Time Retrieval
|
||||
|
||||
Query-time retrieval is the baseline memory pattern that LLM Wiki is contrasted against: relevant material is retrieved when the user asks a question, and the answer is generated from the retrieved context.
|
||||
|
||||
## Boundary Filled
|
||||
|
||||
The selected question contrasts wiki accumulation with RAG, but it does not define the retrieval side precisely. This page anchors the contrast in the original RAG paper and in the LLM Wiki gist.
|
||||
|
||||
## Extracted Claims
|
||||
|
||||
- The RAG paper defines retrieval-augmented generation as combining parametric memory with non-parametric memory for language generation: https://arxiv.org/abs/2005.11401
|
||||
- The RAG paper describes the non-parametric memory as a dense vector index of Wikipedia accessed with a neural retriever: https://arxiv.org/abs/2005.11401
|
||||
- The paper reports that RAG models generated more specific, diverse, and factual language than a parametric-only seq2seq baseline in its evaluated generation tasks: https://arxiv.org/abs/2005.11401
|
||||
- Karpathy's LLM Wiki gist describes common document workflows as uploading files, retrieving relevant chunks at query time, and generating an answer: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
- Karpathy's LLM Wiki gist states that this query-time pattern makes the model rediscover and assemble knowledge on each question instead of accumulating synthesis: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
- The MemGPT paper frames limited LLM context windows as a constraint for extended conversations and document analysis, then proposes virtual context management across memory tiers: https://arxiv.org/abs/2310.08560
|
||||
|
||||
## Contrast With Wiki Memory
|
||||
|
||||
Query-time retrieval can provide external evidence at answer time. The LLM Wiki pattern shifts part of the work earlier by compiling source material into maintained pages before later queries arrive: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
|
||||
## Primary Sources
|
||||
|
||||
- https://arxiv.org/abs/2005.11401
|
||||
- https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
- https://arxiv.org/abs/2310.08560
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
type: concept
|
||||
title: "SEO Drift Monitoring"
|
||||
created: 2026-04-14
|
||||
updated: 2026-04-14
|
||||
tags:
|
||||
- concept
|
||||
- seo
|
||||
- monitoring
|
||||
- change-detection
|
||||
status: evergreen
|
||||
related:
|
||||
- "[[Claude SEO]]"
|
||||
- "[[Pro Hub Challenge]]"
|
||||
---
|
||||
|
||||
# SEO Drift Monitoring
|
||||
|
||||
"Git for SEO" — captures baselines of SEO-critical page elements, then diffs against current state to detect regressions. Contributed to [[Claude SEO]] v1.9.0 by Dan Colta.
|
||||
|
||||
## What It Tracks
|
||||
|
||||
17 comparison rules across 3 severity levels:
|
||||
|
||||
| Severity | Examples |
|
||||
|----------|----------|
|
||||
| CRITICAL | Schema removed, canonical changed, noindex added, H1 removed |
|
||||
| WARNING | Title changed, CWV regression >20%, meta description changed |
|
||||
| INFO | H2 structure changed, content hash changed, image count changed |
|
||||
|
||||
## Architecture
|
||||
|
||||
- **SQLite persistence** at `~/.cache/claude-seo/drift/baselines.db`
|
||||
- **4 Python scripts**: `drift_baseline.py` (capture), `drift_compare.py` (diff), `drift_report.py` (HTML report), `drift_history.py` (timeline)
|
||||
- **Security-hardened**: uses only `fetch_page.py` for URL fetching (SSRF-protected). Original submission had a curl fallback that bypassed SSRF protection — completely removed during integration.
|
||||
|
||||
## Commands
|
||||
|
||||
```
|
||||
/seo drift baseline <url> # Capture current state
|
||||
/seo drift compare <url> # Compare against baseline
|
||||
/seo drift history <url> # Show all checks over time
|
||||
```
|
||||
@@ -1,159 +0,0 @@
|
||||
---
|
||||
type: concept
|
||||
title: "SVG Diagram Style Guide"
|
||||
created: 2026-04-14
|
||||
updated: 2026-04-14
|
||||
tags:
|
||||
- design
|
||||
- svg
|
||||
- brand
|
||||
- diagrams
|
||||
status: evergreen
|
||||
related:
|
||||
- "[[index]]"
|
||||
sources:
|
||||
- "claude-ads/assets/diagrams/ (17 SVGs, v1.5.0)"
|
||||
---
|
||||
|
||||
# SVG Diagram Style Guide
|
||||
|
||||
The canonical visual style for all diagrams across agricidaniel's Claude Code skill repos. Extracted from the 17 production SVGs in claude-ads. Use this as the reference when creating or updating diagrams for any skill repo.
|
||||
|
||||
## Font
|
||||
|
||||
```
|
||||
font-family: 'Space Grotesk', system-ui, -apple-system, sans-serif
|
||||
```
|
||||
|
||||
Space Grotesk is the only typeface. No fallback to serif or monospace.
|
||||
|
||||
## Color Palette
|
||||
|
||||
### Core (use these in every diagram)
|
||||
|
||||
| Token | Hex | Role |
|
||||
|-------|-----|------|
|
||||
| bg | #0A0A0A | Canvas background (near-black) |
|
||||
| card | #111111 | Card/container fill |
|
||||
| card-inner | #1A1A1A | Nested element fill |
|
||||
| border | #2D2D2D | Card borders, dividers |
|
||||
| text-primary | #F5F5F0 | Headings, labels (off-white) |
|
||||
| text-secondary | #888888 | Descriptions, captions |
|
||||
| text-tertiary | #6a6a6a | De-emphasized metadata |
|
||||
| accent | #E07850 | Primary accent, arrows, highlights (warm rust-orange) |
|
||||
| accent-bright | #FF6B35 | Secondary accent, hover states (brighter orange) |
|
||||
|
||||
### Platform/Category Colors (use for variety within a diagram)
|
||||
|
||||
| Token | Hex | Typical use |
|
||||
|-------|-----|-------------|
|
||||
| blue | #60A5FA | Google, data, information |
|
||||
| purple | #8b5cf6 | Meta, strategy, creative |
|
||||
| cyan | #06b6d4 | LinkedIn, networking |
|
||||
| green | #4ADE80 | Success, validation, TikTok |
|
||||
| rose | #F43F5E | YouTube, alerts |
|
||||
| orange | #FF6B35 | Microsoft, secondary accent |
|
||||
| gray | #888888 | Neutral, generic platforms |
|
||||
|
||||
### Status Colors (for pass/warn/fail indicators)
|
||||
|
||||
| Token | Hex | Role |
|
||||
|-------|-----|------|
|
||||
| pass | #16a34a | Pass, success |
|
||||
| warn | #f59e0b | Warning, attention |
|
||||
| fail | #dc2626 | Fail, critical |
|
||||
|
||||
## Typography Scale
|
||||
|
||||
| Element | Size | Weight | Color | Extra |
|
||||
|---------|------|--------|-------|-------|
|
||||
| Diagram title | 16-17px | 700 | #F5F5F0 | text-anchor: middle |
|
||||
| Subtitle | 11px | 400 | #888888 | text-anchor: middle |
|
||||
| Section label | 13px | 700 | accent color | letter-spacing: 2 |
|
||||
| Card heading | 12-15px | 600-700 | #F5F5F0 | text-anchor: middle |
|
||||
| Card subtext | 9-11px | 400 | accent color | Skill/agent name |
|
||||
| Body text | 10px | 400 | #888888 | Descriptions |
|
||||
| Tiny label | 9px | 400 | #6a6a6a | Metadata, counts |
|
||||
|
||||
## Layout Primitives
|
||||
|
||||
### Outer Container
|
||||
```xml
|
||||
<rect width="800" height="500" fill="#0A0A0A"/>
|
||||
```
|
||||
Standard canvas is 800x500. Some diagrams use 900x250 or 900x350 depending on content.
|
||||
|
||||
### Card
|
||||
```xml
|
||||
<rect x="40" y="20" width="720" height="120" rx="16" fill="#111111" stroke="#2D2D2D" stroke-width="1.5"/>
|
||||
```
|
||||
- Corner radius: `rx="16"` for outer containers
|
||||
- Border: `#2D2D2D`, `stroke-width="1.5"`
|
||||
|
||||
### Colored Top Bar (card accent)
|
||||
```xml
|
||||
<rect x="40" y="20" width="720" height="4" rx="2" fill="#E07850"/>
|
||||
```
|
||||
4px height, sits at the top edge of the card. Color indicates category.
|
||||
|
||||
### Inner Card (nested element)
|
||||
```xml
|
||||
<rect x="60" y="230" width="105" height="60" rx="6" fill="#1A1A1A" stroke="#2D2D2D" stroke-width="1"/>
|
||||
```
|
||||
- Corner radius: `rx="6"` for small inner cards, `rx="9"` for medium
|
||||
- Fill: `#1A1A1A` (slightly lighter than parent card)
|
||||
|
||||
### Numbered Circle (for sequences)
|
||||
```xml
|
||||
<circle cx="138" cy="60" r="14" fill="#0A0A0A" stroke="#60A5FA" stroke-width="1.5"/>
|
||||
<text x="138" y="60" font-size="12" fill="#60A5FA" text-anchor="middle" font-weight="bold" dominant-baseline="central">1</text>
|
||||
```
|
||||
Circle stroke color matches the step's category color.
|
||||
|
||||
### Arrow Connector
|
||||
```xml
|
||||
<line x1="400" y1="140" x2="400" y2="170" stroke="#E07850" stroke-width="1.5"/>
|
||||
<polygon points="394,167 400,177 406,167" fill="#E07850"/>
|
||||
```
|
||||
Always `#E07850`. Vertical for flow-down, horizontal for left-to-right pipelines.
|
||||
|
||||
### Horizontal Divider (title underline)
|
||||
```xml
|
||||
<line x1="380" y1="36" x2="520" y2="36" stroke="#E07850" stroke-width="2.5" stroke-linecap="round"/>
|
||||
```
|
||||
Short centered line under diagram title. Always accent color.
|
||||
|
||||
## Diagram Types (from claude-ads)
|
||||
|
||||
| # | Name | Layout | Size |
|
||||
|---|------|--------|------|
|
||||
| 01 | Architecture | 3-layer vertical stack | 800x500 |
|
||||
| 02 | Parallel Audit | Agent grid with flow | 800x500 |
|
||||
| 04 | Platform Checks | Checklist columns | 800x500 |
|
||||
| 05 | Quality Gates | Rule cards | 800x500 |
|
||||
| 06 | How It Works | Step sequence | 900x250 |
|
||||
| 07 | Data Flow | Horizontal pipeline | 900x250 |
|
||||
| 08 | Industry Templates | Card grid | 900x350 |
|
||||
| 10 | MCP Integration | Connection diagram | 800x500 |
|
||||
| 12 | Privacy Flow | Vertical flow | 800x500 |
|
||||
| 13 | Scoring Algorithm | Formula breakdown | 800x500 |
|
||||
| 14 | Creative Pipeline | 5-step horizontal | 900x250 |
|
||||
| 15 | Platform Grid | 2-row card grid | 900x350 |
|
||||
| 16 | PDF Pipeline | Process flow | 900x250 |
|
||||
| 17 | A/B Testing | Split comparison | 800x500 |
|
||||
| 18 | PPC Calculators | Tool cards | 900x350 |
|
||||
| 19 | Audit Lifecycle | Circular flow | 800x500 |
|
||||
| 20 | Install Methods | Option cards | 900x250 |
|
||||
|
||||
## Rules
|
||||
|
||||
1. Always dark theme. Never white or light backgrounds.
|
||||
2. Space Grotesk only. No other fonts.
|
||||
3. #E07850 is the signature accent. Use it for arrows, highlights, and the primary visual element.
|
||||
4. Cards always have #2D2D2D borders. Never borderless cards.
|
||||
5. Colored top bars (4px) identify categories. One color per category, consistent across the diagram.
|
||||
6. Text is always left-aligned or center-aligned. Never right-aligned.
|
||||
7. No gradients, shadows, or blur filters. Flat design only.
|
||||
8. Numbered circles for sequential steps. Color matches category.
|
||||
9. Arrow connectors are always #E07850 with triangle tips.
|
||||
10. File naming: zero-padded number prefix (01-, 02-, etc.) + kebab-case description.
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Scordelis-Lo Shell Benchmark"
|
||||
complexity: intermediate
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- Scordelis-Lo shell
|
||||
- cylindrical Scordelis-Lo shell
|
||||
- Scordelis Lo roof
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000024
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- shell-elements
|
||||
- benchmark
|
||||
status: current
|
||||
related:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
- "[[Shell Structure Asymptotic Behavior]]"
|
||||
- "[[Shell Element Benchmark Testing]]"
|
||||
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
|
||||
- "[[MITC4 Shell Element]]"
|
||||
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
|
||||
- "[[Static Equilibrium Equation Solvers]]"
|
||||
sources:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
|
||||
---
|
||||
|
||||
# Scordelis-Lo Shell Benchmark
|
||||
|
||||
## Definition
|
||||
|
||||
The Scordelis-Lo shell benchmark is a classical cylindrical shell problem used to evaluate shell finite elements under bending and membrane action.
|
||||
|
||||
## How It Is Used
|
||||
|
||||
In the MITC4 source, the shell is loaded by dead weight and symmetry allows one quarter of the structure to be modeled. The response quantity is the displacement at point B, and mesh refinement is used to compare MITC4 convergence with an RDKT reference element and an analytical reference.
|
||||
|
||||
[[On-the-Finite-Element-Analysis-of-Shell-Structures]] uses the Scordelis-Lo roof shell as an asymptotic-behavior example. The paper identifies it as a mixed-dominated shell benchmark with an approximate load scaling factor of `rho = 1.75`, which makes it useful for exposing locking and non-uniform convergence.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
The benchmark is useful because shell elements must couple membrane and bending behavior without becoming artificially stiff. Poor shell formulations can pass simple tests yet converge slowly or incorrectly on this curved-shell problem.
|
||||
|
||||
## Reported Trend
|
||||
|
||||
The source reports MITC4 displacement magnitudes converging from about 3.43 on a `4x4` quadrilateral mesh to about 3.61 on `32x32` and `64x64` meshes. The RDKT comparison converges to about 3.60 on the same refinement sequence.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[MITC4 Shell Element]] uses this benchmark as its primary performance demonstration.
|
||||
- [[Continuum Mechanics Based Four-Node Shell Element]] includes the benchmark family in the broader Dvorkin-Bathe shell validation thread.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Four-Node-Quadrilateral-Shell-Element-MITC4]]
|
||||
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Search Experience Optimization (SXO)"
|
||||
created: 2026-04-14
|
||||
updated: 2026-04-14
|
||||
tags:
|
||||
- concept
|
||||
- seo
|
||||
- ux
|
||||
- serp-analysis
|
||||
status: evergreen
|
||||
related:
|
||||
- "[[Claude SEO]]"
|
||||
- "[[Pro Hub Challenge]]"
|
||||
- "[[Semantic Topic Clustering]]"
|
||||
---
|
||||
|
||||
# Search Experience Optimization (SXO)
|
||||
|
||||
A methodology that reads SERPs backwards to detect page-type mismatches, derives user stories from search features, and scores pages from persona perspectives. Contributed to [[Claude SEO]] v1.9.0 by Florian Schmitz.
|
||||
|
||||
## Core Insight
|
||||
|
||||
> "Read SERPs backwards" — instead of optimizing content FOR the SERP, analyze WHAT the SERP tells you about user expectations, then check if your page meets them.
|
||||
|
||||
## Process
|
||||
|
||||
1. **Page-type detection** — classify the URL as one of 8 types (Landing, Blog, Product, Hybrid, Service, Comparison, Local, Tool)
|
||||
2. **SERP pattern matching** — compare what Google shows (featured snippets, PAA, ads, related searches) against what the page provides
|
||||
3. **Mismatch detection** — if SERP says "users want comparison" but page is "product page", that's a mismatch
|
||||
4. **User story derivation** — from SERP features, derive 4-7 personas with emotional states, barriers, goals
|
||||
5. **Persona scoring** — score the page from each persona's perspective (0-100 across 4 dimensions)
|
||||
6. **Wireframe generation** — IST (current) vs SOLL (ideal) wireframes with ultra-concrete placeholders
|
||||
|
||||
## Key Innovation
|
||||
|
||||
Most SEO tools analyze pages in isolation. SXO uses the SERP as a proxy for user intent — the SERP IS the research that Google already did about what users want. This makes the analysis data-driven without needing user testing.
|
||||
|
||||
## Command
|
||||
|
||||
```
|
||||
/seo sxo <url>
|
||||
/seo sxo wireframe <url>
|
||||
```
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Semantic Topic Clustering"
|
||||
created: 2026-04-14
|
||||
updated: 2026-04-14
|
||||
tags:
|
||||
- concept
|
||||
- seo
|
||||
- content-strategy
|
||||
- clustering
|
||||
status: evergreen
|
||||
related:
|
||||
- "[[Claude SEO]]"
|
||||
- "[[Pro Hub Challenge]]"
|
||||
- "[[Search Experience Optimization]]"
|
||||
---
|
||||
|
||||
# Semantic Topic Clustering
|
||||
|
||||
SERP-based keyword grouping that replaces paid tools ($50-200/month) with Claude's reasoning. Contributed to [[Claude SEO]] v1.9.0 by Lutfiya Miller (Pro Hub Challenge Winner).
|
||||
|
||||
## How It Works
|
||||
|
||||
1. **Seed keyword** provided by user
|
||||
2. **SERP fetching** — get Google results for the seed and related terms (via WebSearch or DataForSEO)
|
||||
3. **Overlap scoring** — compare top-10 results between keyword pairs:
|
||||
- 7-10 overlapping URLs = same post (keyword cannibalization)
|
||||
- 4-6 overlapping = same cluster (supporting content)
|
||||
- 2-3 overlapping = interlink opportunity
|
||||
- 0-1 overlapping = separate clusters
|
||||
4. **Hub-spoke architecture** — 1 pillar page (2500-4000 words) + 2-5 clusters + 2-4 posts each
|
||||
5. **Internal link matrix** — bidirectional linking plan with backward link injection
|
||||
6. **Visualization** — interactive cluster-map.html (SVG, dark mode, keyboard accessible)
|
||||
|
||||
## Key Design Decisions
|
||||
|
||||
- **No Python scripts** — clustering is prompt-driven (Claude's reasoning + WebSearch)
|
||||
- **Optional execution** — outputs content briefs when claude-blog isn't installed, full pipeline when it is
|
||||
- **Resume capability** — for long multi-post execution runs
|
||||
- **DataForSEO integration** — uses `serp_organic_live_advanced` for live SERP data when available (with cost check)
|
||||
|
||||
## Command
|
||||
|
||||
```
|
||||
/seo cluster <seed-keyword>
|
||||
```
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Shell Element Benchmark Testing"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- shell benchmark testing
|
||||
- shell element performance testing
|
||||
- shell finite element benchmarks
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000047
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- shell-elements
|
||||
- benchmark
|
||||
status: current
|
||||
related:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
- "[[Scordelis-Lo Shell Benchmark]]"
|
||||
- "[[Shell Locking Phenomenon]]"
|
||||
- "[[Uniform Optimal Convergence]]"
|
||||
- "[[MITC4 Shell Element]]"
|
||||
sources:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
---
|
||||
|
||||
# Shell Element Benchmark Testing
|
||||
|
||||
## Definition
|
||||
|
||||
Shell element benchmark testing is the structured evaluation of shell finite elements across basic element checks, convergence measures, shell geometries, asymptotic behavior classes, and mesh patterns.
|
||||
|
||||
## How It Works
|
||||
|
||||
The source argues that shell element performance should not be judged only from a displacement at one point. A useful test set should include zero-energy mode checks, membrane and bending patch tests, isotropy checks for triangular elements, convergence curves, and global error measures such as S-norm.
|
||||
|
||||
The test problems should also vary the shell's Gaussian curvature, thickness, layer behavior, asymptotic behavior, and element mesh shape. This exposes whether the element is only tuned for a narrow problem class or is robust enough for design analysis.
|
||||
|
||||
## Benchmark Dimensions
|
||||
|
||||
- Basic element checks: zero-energy modes, patch tests, and element isotropy.
|
||||
- Geometry: positive, zero, and negative Gaussian curvature.
|
||||
- Asymptotic behavior: bending-dominated, membrane-dominated, and mixed-dominated shell problems.
|
||||
- Error view: global error norms and field distributions, not only one output point.
|
||||
- Mesh sensitivity: element distortion, anisotropic meshes, and orientation effects.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Scordelis-Lo Shell Benchmark]] is one important benchmark in this family.
|
||||
- [[Shell Locking Phenomenon]] is a primary failure mode benchmark tests should reveal.
|
||||
- [[Uniform Optimal Convergence]] is the performance target.
|
||||
- [[MITC4 Shell Element]] uses benchmark evidence to support its practical reliability.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Shell Locking Phenomenon"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- shell locking
|
||||
- locking phenomenon
|
||||
- membrane locking
|
||||
- shear locking
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000045
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- shell-elements
|
||||
- locking
|
||||
status: current
|
||||
related:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
- "[[Assumed Transverse Shear Strain Interpolation]]"
|
||||
- "[[MITC4 Shell Element]]"
|
||||
- "[[Displacement-Based Finite Element Formulation]]"
|
||||
- "[[Shell Structure Asymptotic Behavior]]"
|
||||
- "[[Uniform Optimal Convergence]]"
|
||||
sources:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
---
|
||||
|
||||
# Shell Locking Phenomenon
|
||||
|
||||
## Definition
|
||||
|
||||
Shell locking is a thickness-dependent finite element error in which a shell element becomes artificially stiff as the shell becomes thin. It appears as underpredicted displacements, stresses, strains, and strain energy, and as poor convergence in thin-shell bending or mixed-dominated problems.
|
||||
|
||||
## How It Works
|
||||
|
||||
The source connects locking to [[Shell Structure Asymptotic Behavior]]. Displacement-based shell elements may fail to approximate the pure bending displacement space of the [[Basic Shell Mathematical Model]]. The result is parasitic membrane or transverse shear strain in states that should be nearly strain-free in those modes.
|
||||
|
||||
The paper distinguishes membrane locking from shear locking. Membrane locking appears in curved shells, while transverse shear locking can appear regardless of curvature when the interpolation cannot represent the thin-shell bending constraint.
|
||||
|
||||
## Remedies
|
||||
|
||||
Common remedies include reduced integration, incompatible or non-conforming modes, ANS, EAS, and MITC-style mixed interpolation. The source treats MITC as a particularly effective family because it interpolates selected tensorial strain components at tying points while trying to retain consistency and ellipticity.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Assumed Transverse Shear Strain Interpolation]] is the targeted shear-locking remedy used in the four-node shell thread.
|
||||
- [[MITC4 Shell Element]] is the practical low-order shell element thread that uses mixed interpolation to control locking.
|
||||
- [[Uniform Optimal Convergence]] is the desired behavior after locking has been controlled.
|
||||
- [[Shell Element Benchmark Testing]] describes how locking should be exposed using convergence curves and thickness variation.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Shell Structure Asymptotic Behavior"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- shell asymptotic behavior
|
||||
- bending-dominated shell behavior
|
||||
- membrane-dominated shell behavior
|
||||
- mixed-dominated shell behavior
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000044
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- shell-elements
|
||||
- asymptotics
|
||||
status: current
|
||||
related:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
- "[[Basic Shell Mathematical Model]]"
|
||||
- "[[Shell Locking Phenomenon]]"
|
||||
- "[[Uniform Optimal Convergence]]"
|
||||
- "[[Scordelis-Lo Shell Benchmark]]"
|
||||
sources:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
---
|
||||
|
||||
# Shell Structure Asymptotic Behavior
|
||||
|
||||
## Definition
|
||||
|
||||
Shell structure asymptotic behavior is the limiting response class of a shell as the thickness ratio becomes small. The source classifies thin-shell behavior into bending-dominated, membrane-dominated, and mixed-dominated regimes.
|
||||
|
||||
## How It Works
|
||||
|
||||
The paper writes the simplified shell variational problem in terms of a thickness ratio and separates bending energy from membrane and shear energy. A load scaling factor `rho` indicates how the shell stiffness scales with thickness. Values near `rho = 1` indicate membrane-dominated behavior, values near `rho = 3` indicate bending-dominated behavior, and intermediate values indicate mixed-dominated behavior.
|
||||
|
||||
The classification depends on geometry, boundary conditions, and loading. The key mathematical object is the pure bending displacement space: if pure bending is available and the loading excites it, bending-dominated behavior can appear; if not, membrane or mixed behavior controls.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
The same shell element can appear reliable in one shell problem and lock or converge slowly in another. Shell asymptotic behavior explains why benchmark problems must vary thickness, curvature, boundary conditions, and loading rather than relying on one fixed-thickness result.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Basic Shell Mathematical Model]] supplies the bending and membrane energy terms.
|
||||
- [[Shell Locking Phenomenon]] is strongly tied to whether an element can approximate the pure bending space.
|
||||
- [[Uniform Optimal Convergence]] asks whether convergence remains optimal across thickness and asymptotic regimes.
|
||||
- [[Scordelis-Lo Shell Benchmark]] is cited as a shell problem whose asymptotic behavior can be evaluated numerically.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Solid Element Shape Functions"
|
||||
complexity: intermediate
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- solid element interpolation functions
|
||||
- linear solid shape functions
|
||||
- tetrahedral wedge pyramid hexahedral shape functions
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000050
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- solid-elements
|
||||
- interpolation
|
||||
status: current
|
||||
related:
|
||||
- "[[Solid Element Notes]]"
|
||||
- "[[Isoparametric Linear Solid Elements]]"
|
||||
- "[[Isoparametric Finite Elements]]"
|
||||
- "[[Solid Element Strain-Displacement Matrix]]"
|
||||
sources:
|
||||
- "[[Solid Element Notes]]"
|
||||
---
|
||||
|
||||
# Solid Element Shape Functions
|
||||
|
||||
## Definition
|
||||
|
||||
Solid element shape functions interpolate three-dimensional element geometry and displacement from nodal values in natural coordinates.
|
||||
|
||||
## Covered Topologies
|
||||
|
||||
The notes give first-order interpolation for four common solid element shapes:
|
||||
|
||||
- 4-node tetrahedron with barycentric-style coordinates.
|
||||
- 5-node pyramid connecting a quadrilateral base to an apex.
|
||||
- 6-node wedge, or triangular prism, using triangular interpolation through a two-node thickness direction.
|
||||
- 8-node hexahedron with trilinear interpolation in `xi`, `eta`, and `zeta`.
|
||||
|
||||
## Why They Matter
|
||||
|
||||
Shape functions are the starting point for every later element calculation. They define the displacement approximation, the geometry mapping, the Jacobian, the derivative transformation, and ultimately the strain-displacement matrix. Because the same functions interpolate geometry and field variables, the source is a concrete example of [[Isoparametric Finite Elements]].
|
||||
|
||||
## Modeling Implications
|
||||
|
||||
Low-order solid shape functions are economical but sensitive to distortion and limited in bending-dominated response. This is why element aspect ratio and topology selection matter before any solver choice is considered.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Isoparametric Linear Solid Elements]] gives the element-level context.
|
||||
- [[Solid Element Strain-Displacement Matrix]] differentiates these functions after Jacobian mapping.
|
||||
- [[Solid Element Stiffness Integration]] integrates the resulting `B^T D B` expression over the element volume.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Solid Element Notes]]
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Solid Element Stiffness Integration"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- solid element stiffness matrix
|
||||
- solid element Gauss integration
|
||||
- 3D element quadrature
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000052
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- solid-elements
|
||||
- numerical-integration
|
||||
status: current
|
||||
related:
|
||||
- "[[Solid Element Notes]]"
|
||||
- "[[Solid Element Strain-Displacement Matrix]]"
|
||||
- "[[Isoparametric Finite Elements]]"
|
||||
- "[[Displacement-Based Finite Element Formulation]]"
|
||||
sources:
|
||||
- "[[Solid Element Notes]]"
|
||||
---
|
||||
|
||||
# Solid Element Stiffness Integration
|
||||
|
||||
## Definition
|
||||
|
||||
Solid element stiffness integration evaluates the element stiffness matrix for a three-dimensional continuum element by numerically integrating `B^T D B` over the element volume.
|
||||
|
||||
## How It Works
|
||||
|
||||
The source uses the standard displacement-based stiffness form:
|
||||
|
||||
```text
|
||||
K = integral_V B^T D B dV
|
||||
= integral B^T D B |J| dxi deta dzeta
|
||||
```
|
||||
|
||||
Here `B` is the [[Solid Element Strain-Displacement Matrix]], `D` is the three-dimensional Hooke-law constitutive matrix, and `|J|` is the determinant of the Jacobian that maps the natural-coordinate integration region to physical volume.
|
||||
|
||||
The notes list quadrature schemes for the first-order solid topologies: one-point integration for the 4-node tetrahedron, eight-point integration for the 5-node pyramid, six-point integration for the 6-node wedge, and eight-point integration for the 8-node hexahedron.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
The stiffness integral is where interpolation, material law, element distortion, and numerical quadrature meet. Incorrect quadrature or a poor Jacobian can produce inaccurate stiffness, spurious mechanisms, or poor convergence even when the symbolic formulation is correct.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Isoparametric Finite Elements]] supplies the natural-coordinate integration framework.
|
||||
- [[Solid Element Shape Functions]] and [[Solid Element Strain-Displacement Matrix]] define the integrand.
|
||||
- [[Incompatible Mode Solid Elements]] modifies the displacement field and therefore expands the stiffness matrix before static condensation.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Solid Element Notes]]
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Solid Element Strain-Displacement Matrix"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- solid element B matrix
|
||||
- 3D strain-displacement matrix
|
||||
- Jacobian derivative mapping
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000051
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- solid-elements
|
||||
- strain-displacement
|
||||
status: current
|
||||
related:
|
||||
- "[[Solid Element Notes]]"
|
||||
- "[[Displacement-Based Finite Element Formulation]]"
|
||||
- "[[Isoparametric Finite Elements]]"
|
||||
- "[[Solid Element Shape Functions]]"
|
||||
- "[[Solid Element Stiffness Integration]]"
|
||||
sources:
|
||||
- "[[Solid Element Notes]]"
|
||||
---
|
||||
|
||||
# Solid Element Strain-Displacement Matrix
|
||||
|
||||
## Definition
|
||||
|
||||
The solid element strain-displacement matrix, usually called the `B` matrix, maps nodal translational degrees of freedom to the six small-strain components of a three-dimensional continuum element.
|
||||
|
||||
## How It Works
|
||||
|
||||
The notes use the standard small-strain components:
|
||||
|
||||
- normal strains: `epsilon_xx`, `epsilon_yy`, `epsilon_zz`
|
||||
- engineering shear terms derived from `epsilon_xy`, `epsilon_yz`, and `epsilon_xz`
|
||||
|
||||
Each node contributes a block of derivatives of its shape function with respect to physical coordinates:
|
||||
|
||||
```text
|
||||
[ dN_i/dx 0 0 ]
|
||||
[ 0 dN_i/dy 0 ]
|
||||
[ 0 0 dN_i/dz ]
|
||||
[ dN_i/dy dN_i/dx 0 ]
|
||||
[ 0 dN_i/dz dN_i/dy]
|
||||
[ dN_i/dz 0 dN_i/dx]
|
||||
```
|
||||
|
||||
Because [[Solid Element Shape Functions]] are defined in natural coordinates, their derivatives must be mapped into physical coordinates through the Jacobian. This derivative mapping is the core computational step between interpolation and stiffness assembly.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Displacement-Based Finite Element Formulation]] supplies the general `epsilon = B u` path.
|
||||
- [[Isoparametric Finite Elements]] explains why the Jacobian appears.
|
||||
- [[Solid Element Stiffness Integration]] uses this `B` matrix in `K = integral B^T D B dV`.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Solid Element Notes]]
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Source-First Synthesis"
|
||||
created: 2026-04-24
|
||||
updated: 2026-04-24
|
||||
tags:
|
||||
- llm-wiki
|
||||
- synthesis
|
||||
- provenance
|
||||
status: developing
|
||||
related:
|
||||
- "[[How does the LLM Wiki pattern work?]]"
|
||||
- "[[LLM Wiki Pattern]]"
|
||||
- "[[Compounding Knowledge]]"
|
||||
- "[[Persistent Wiki Artifact]]"
|
||||
- "[[Query-Time Retrieval]]"
|
||||
---
|
||||
|
||||
# Source-First Synthesis
|
||||
|
||||
Source-first synthesis is the LLM Wiki practice of keeping raw sources separate from the generated wiki while requiring the wiki to cite and integrate those sources. Karpathy's pattern describes raw sources as the source of truth and the generated wiki as the maintained synthesis layer: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
|
||||
## Boundary Filled
|
||||
|
||||
The selected question says the wiki pattern integrates sources, but it does not spell out the provenance discipline. This page records the rule: synthesis is allowed to be rewritten, but source material remains the cited anchor.
|
||||
|
||||
## Extracted Claims
|
||||
|
||||
- Karpathy's LLM Wiki pattern says raw sources can include articles, papers, images, and data files, and that the LLM reads them without modifying them: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
- The same source describes the wiki as summaries, entity pages, concept pages, comparisons, overview, and synthesis maintained by the LLM: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
- The ingest operation can create a source summary, update indexes, update relevant entity and concept pages, and append a log entry: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
- The query operation reads relevant wiki pages and synthesizes answers with citations, and useful answers can be filed back into the wiki: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
- The RAG paper identifies provenance and updating world knowledge as open problems for knowledge-intensive generation systems: https://arxiv.org/abs/2005.11401
|
||||
|
||||
## Operating Rule
|
||||
|
||||
Source-first synthesis is stricter than unsourced summarization. A new concept page should identify the sources it used, state what was extracted from them, and avoid treating the generated page as a replacement for the source document.
|
||||
|
||||
## Primary Sources
|
||||
|
||||
- https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||
- https://arxiv.org/abs/2005.11401
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Static Equilibrium Equation Solvers"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- static finite element solvers
|
||||
- finite element equation solution
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000013
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- linear-solvers
|
||||
status: current
|
||||
related:
|
||||
- "[[Finite Element Method]]"
|
||||
- "[[Nonlinear Finite Element Analysis]]"
|
||||
- "[[Geometric Stiffness Matrix]]"
|
||||
- "[[Dynamic Buckling Analysis]]"
|
||||
- "[[Finite Element Program Implementation]]"
|
||||
sources:
|
||||
- "[[Finite Element Procedures]]"
|
||||
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
|
||||
---
|
||||
|
||||
# Static Equilibrium Equation Solvers
|
||||
|
||||
## Definition
|
||||
|
||||
Static equilibrium equation solvers compute the unknown finite element degrees of freedom for time-independent systems, usually after assembly of stiffness and load terms.
|
||||
|
||||
## How It Works
|
||||
|
||||
For linear systems, the source covers direct methods based on Gauss elimination, LDL^T, Cholesky factorization, active-column storage, static condensation, substructuring, and frontal solution. For large sparse systems, iterative methods such as Gauss-Seidel and preconditioned conjugate gradient are discussed. For nonlinear static systems, Newton-Raphson, BFGS, load-displacement-constraint methods, and convergence criteria enter.
|
||||
|
||||
The dynamic buckling thesis uses static nonlinear formulation to produce geometric stiffness for buckling analysis, so static equilibrium solution is part of the route to instability prediction.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
The finite element method produces algebraic systems whose solution cost and numerical stability can dominate the analysis. Solver choice depends on matrix symmetry, definiteness, sparsity, conditioning, model size, and whether the equations are linear or nonlinear.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Nonlinear Finite Element Analysis]] uses nonlinear static solvers inside incremental equilibrium.
|
||||
- [[Finite Element Program Implementation]] handles storage, assembly, and equation solution.
|
||||
- [[Finite Element Eigenproblem Solvers]] uses related matrix factorizations and definiteness concepts.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[Finite Element Procedures]]
|
||||
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Total Lagrangian Shell Formulation"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- total Lagrangian shell analysis
|
||||
- large displacement shell formulation
|
||||
- large rotation shell formulation
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000021
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- shell-elements
|
||||
- nonlinear-analysis
|
||||
status: current
|
||||
related:
|
||||
- "[[MITC Study Notes]]"
|
||||
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
|
||||
- "[[MITC Shell Kinematics]]"
|
||||
- "[[Green-Lagrange Strain Linearization]]"
|
||||
- "[[Geometric Stiffness Matrix]]"
|
||||
- "[[A Continuum Mechanics Based Four-Node Shell]]"
|
||||
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
|
||||
- "[[Nonlinear Finite Element Analysis]]"
|
||||
- "[[Static Equilibrium Equation Solvers]]"
|
||||
sources:
|
||||
- "[[A Continuum Mechanics Based Four-Node Shell]]"
|
||||
- "[[MITC Study Notes]]"
|
||||
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
|
||||
---
|
||||
|
||||
# Total Lagrangian Shell Formulation
|
||||
|
||||
## Definition
|
||||
|
||||
A total Lagrangian shell formulation writes the nonlinear shell equilibrium equations with respect to the initial reference configuration, even while the shell undergoes large displacement and rotation response.
|
||||
|
||||
## How It Works
|
||||
|
||||
The formulation tracks kinematic measures, stress resultants, and virtual work using the original configuration as the reference. In the four-node shell paper, this framework is used for large displacement and rotation analysis under the assumption of small strains, with shell director behavior and thickness assumptions built into the element kinematics.
|
||||
|
||||
The MITC study notes make the tangent path explicit by writing Green-Lagrange strain in the reference configuration, pairing it with second Piola-Kirchhoff stress, and separating strain terms for incremental Newton solution.
|
||||
|
||||
The dynamic buckling thesis uses the total Lagrangian formulation to derive the [[Geometric Stiffness Matrix]] needed for static and dynamic buckling analysis of MITC4 shell models.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
Large shell rotations, snap-through behavior, buckling paths, and elastoplastic response require incremental nonlinear analysis. A total Lagrangian statement gives a consistent reference frame for deriving residuals and tangent stiffness terms in such problems.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Nonlinear Finite Element Analysis]] is the broader incremental equilibrium framework.
|
||||
- [[Continuum Mechanics Based Four-Node Shell Element]] uses this formulation for nonlinear shell examples.
|
||||
- [[Green-Lagrange Strain Linearization]] is the local strain expansion used to build residual and tangent terms.
|
||||
- [[Static Equilibrium Equation Solvers]] solve the load-step equilibrium equations that result from the formulation.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[A Continuum Mechanics Based Four-Node Shell]]
|
||||
- [[MITC Study Notes]]
|
||||
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
type: concept
|
||||
title: "Uniform Optimal Convergence"
|
||||
complexity: advanced
|
||||
domain: computational-mechanics
|
||||
aliases:
|
||||
- uniform optimal convergence
|
||||
- thickness-uniform convergence
|
||||
- optimal shell convergence
|
||||
created: 2026-05-28
|
||||
updated: 2026-05-28
|
||||
address: c-000046
|
||||
tags:
|
||||
- concept
|
||||
- finite-element-method
|
||||
- shell-elements
|
||||
- convergence
|
||||
status: current
|
||||
related:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
- "[[Shell Locking Phenomenon]]"
|
||||
- "[[Shell Structure Asymptotic Behavior]]"
|
||||
- "[[Shell Element Benchmark Testing]]"
|
||||
- "[[Mixed Finite Element Formulations]]"
|
||||
sources:
|
||||
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
|
||||
---
|
||||
|
||||
# Uniform Optimal Convergence
|
||||
|
||||
## Definition
|
||||
|
||||
Uniform optimal convergence means that a shell finite element converges at its expected approximation rate and that this behavior remains stable as shell thickness changes and as the problem moves between membrane, bending, and mixed-dominated regimes.
|
||||
|
||||
## How It Works
|
||||
|
||||
For shell elements, optimal convergence alone is not enough if it holds only for one fixed thickness or one convenient benchmark. The paper frames the ideal shell element as one that keeps optimal convergence uniformly across shell shapes, boundary conditions, loads, and asymptotic behavior classes.
|
||||
|
||||
For mixed shell formulations, this requirement is closely related to the inf-sup condition. For practical benchmarking, the source uses convergence curves and S-norm style global error measurement rather than only point displacement comparisons.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
A shell element can pass simple checks and still fail in thin-shell bending because of locking. Uniform optimal convergence is the stronger standard that separates a generally reliable shell element from one that only works in selected examples.
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Shell Locking Phenomenon]] is the failure mode this criterion detects.
|
||||
- [[Shell Element Benchmark Testing]] describes the evidence needed to evaluate the criterion.
|
||||
- [[Mixed Finite Element Formulations]] provides the stability context, including inf-sup reasoning.
|
||||
- [[MITC4 Shell Element]] is a practical element family whose value is judged by convergence under locking-prone problems.
|
||||
|
||||
## Sources
|
||||
|
||||
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
|
||||
+43
-16
@@ -6,37 +6,64 @@ tags:
|
||||
- meta
|
||||
- index
|
||||
- concept
|
||||
domain: knowledge-management
|
||||
domain: computational-mechanics
|
||||
status: evergreen
|
||||
related:
|
||||
- "[[index]]"
|
||||
- "[[dashboard]]"
|
||||
- "[[Wiki Map]]"
|
||||
- "[[Hot Cache]]"
|
||||
- "[[LLM Wiki Pattern]]"
|
||||
- "[[Compounding Knowledge]]"
|
||||
- "[[LLM Wiki Pattern]]"
|
||||
- "[[Hot Cache]]"
|
||||
- "[[Compounding Knowledge]]"
|
||||
- "[[Computational Mechanics]]"
|
||||
- "[[Finite Element Method]]"
|
||||
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
|
||||
- "[[MITC4 Shell Element]]"
|
||||
- "[[MITC Shell Kinematics]]"
|
||||
- "[[Dynamic Buckling Analysis]]"
|
||||
- "[[Shell Structure Asymptotic Behavior]]"
|
||||
- "[[Isoparametric Linear Solid Elements]]"
|
||||
---
|
||||
|
||||
# Concepts Index
|
||||
|
||||
Navigation: [[index]] | [[entities/_index|Entities]] | [[sources/_index|Sources]]
|
||||
|
||||
All concept pages — ideas, patterns, and frameworks extracted from sources.
|
||||
All concept pages: finite-element and computational-mechanics concepts extracted from sources.
|
||||
|
||||
---
|
||||
|
||||
## Knowledge Management
|
||||
## Computational Mechanics
|
||||
|
||||
- [[LLM Wiki Pattern]] — the core architecture for persistent, compounding knowledge bases
|
||||
- [[Hot Cache]] — ~500-word session context file, updated after every ingest
|
||||
- [[Compounding Knowledge]] — why the wiki grows more valuable over time, unlike RAG
|
||||
- [[DragonScale Memory]] — memory-layer spec: fold operator, deterministic page addresses, semantic tiling, boundary-first autoresearch (status: shipped v0.4, all four mechanisms opt-in)
|
||||
- [[Persistent Wiki Artifact]]: durable Markdown page as the LLM's memory object (developing)
|
||||
- [[Source-First Synthesis]]: provenance discipline for LLM wiki layers (developing)
|
||||
- [[Query-Time Retrieval]]: query synthesis with citations, complementary to Obsidian search (developing)
|
||||
- [[Finite Element Method]] - numerical procedure for solving discretized engineering and physics models
|
||||
- [[Engineering Mathematical Models]] - idealized physical models selected before finite element solution
|
||||
- [[Displacement-Based Finite Element Formulation]] - primary solid mechanics formulation using nodal displacements
|
||||
- [[Isoparametric Finite Elements]] - shape-function framework for geometry mapping and element matrix calculation
|
||||
- [[Isoparametric Linear Solid Elements]] - first-order 3D continuum elements using isoparametric interpolation
|
||||
- [[Solid Element Shape Functions]] - interpolation functions for tetrahedral, pyramid, wedge, and hexahedral solid elements
|
||||
- [[Solid Element Strain-Displacement Matrix]] - 3D solid element `B` matrix and Jacobian derivative mapping
|
||||
- [[Solid Element Stiffness Integration]] - numerical integration of `B^T D B` over element volume
|
||||
- [[Incompatible Mode Solid Elements]] - internal-mode enrichment and static condensation for solid elements
|
||||
- [[Mixed Finite Element Formulations]] - multi-field formulations for incompressibility, constraints, and pressure-like variables
|
||||
- [[Nonlinear Finite Element Analysis]] - incremental solution of geometric, material, contact, and load nonlinearities
|
||||
- [[Continuum Mechanics Based Four-Node Shell Element]] - low-order shell element derived from continuum mechanics for nonlinear analysis
|
||||
- [[Assumed Transverse Shear Strain Interpolation]] - shell locking remedy using a separately interpolated transverse shear field
|
||||
- [[Total Lagrangian Shell Formulation]] - reference-configuration formulation for large displacement and rotation shell response
|
||||
- [[MITC4 Shell Element]] - four-node quadrilateral shell element using mixed interpolation of tensorial components
|
||||
- [[MITC Shell Kinematics]] - director-vector kinematic model for MITC shell elements
|
||||
- [[Green-Lagrange Strain Linearization]] - nonlinear strain expansion for internal force and tangent stiffness terms
|
||||
- [[Nonlinear Newmark-Beta Integration]] - implicit Newmark time stepping with Newton-Raphson nonlinear iterations
|
||||
- [[Dynamic Buckling Analysis]] - instability analysis of structures under time-varying compressive loading
|
||||
- [[Dynamic Instability Region]] - load-frequency instability boundary for parametric buckling
|
||||
- [[Geometric Stiffness Matrix]] - initial stress stiffness contribution used in nonlinear and buckling analysis
|
||||
- [[Scordelis-Lo Shell Benchmark]] - cylindrical shell benchmark for shell element convergence and locking behavior
|
||||
- [[Basic Shell Mathematical Model]] - midsurface/director shell model underlying continuum shell finite elements
|
||||
- [[Shell Structure Asymptotic Behavior]] - bending, membrane, and mixed thin-shell response classes
|
||||
- [[Shell Locking Phenomenon]] - membrane and shear locking as artificial stiffness in thin-shell FE solutions
|
||||
- [[Uniform Optimal Convergence]] - thickness-uniform optimal convergence target for shell elements
|
||||
- [[Shell Element Benchmark Testing]] - structured performance testing for shell finite elements
|
||||
- [[Finite Element Heat Transfer and Field Problems]] - finite element treatment of heat transfer, field equations, flow, and coupled problems
|
||||
- [[Static Equilibrium Equation Solvers]] - direct, iterative, and nonlinear solvers for static FE equations
|
||||
- [[Direct Time Integration Methods]] - transient finite element dynamics and first-order field integration
|
||||
- [[Finite Element Eigenproblem Solvers]] - modal and eigenvalue algorithms for FE matrices
|
||||
- [[Finite Element Program Implementation]] - software data flow for FE codes and STAP-style implementation
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user