Convert the supplied reference images into a single-file, browser-based generative design and scientific discovery platform for hierarchical materials and fracture, exploring the design space of hierarchical metamaterials. The images may show different scales, views, abstractions, structures, or design ideas. They are not necessarily clean projections of one object, mutually registered, geometrically consistent, or directly reconstructable. Infer a coherent hierarchical material concept from them. Extract transferable design principles—such as topology, branching, interfaces, redundancy, anisotropy, defects, scale transitions, and load paths—rather than attempting a literal image trace. Clearly state the interpretation you adopted and expose it in an editable panel in the application. ────────────────────────────────────────────────────────────────────────────── REFERENCE-IMAGE INTERPRETATION ────────────────────────────────────────────────────────────────────────────── Interpret the supplied images as inspiration for: - A hierarchical network or lattice with multiple structural length scales. - Make sure to include completely ordered and more organic, disordered options. The generator must be able to consider highly ordered lattice-like structures transitioning to organic shapes. - Coarse structural members that divide into finer load-bearing branches. - Tunable redundancy, disorder, connectivity, and hierarchy depth. - Interfaces between hierarchical levels that can be stronger or weaker than members within a level. - Progressive fracture through member rupture, interface failure, load redistribution, and damage localization. - A structure whose mechanical behavior can transition between abrupt brittle failure and distributed, damage-tolerant failure. If multiple interpretations are plausible, choose the interpretation that supports the most scientifically meaningful and computationally defensible fracture study. Record alternative interpretations and explain the choice. ────────────────────────────────────────────────────────────────────────────── PHYSICS TO MODEL ────────────────────────────────────────────────────────────────────────────── Model the quasi-static tensile fracture of a hierarchical beam or spring network, accounting for an accurate material behavior especially fracture. The primary scientific question is: How do hierarchy depth, order vs. disordere, branching redundancy, geometric disorder, and interlevel strength govern stiffness, peak load, energy absorption, damage localization, and the transition between abrupt and progressive fracture when the total amount of material is controlled? Use a physically interpretable structural model that can run reliably on a local machine with visualization output in a browser. Prefer a beam-network or continuum mechanics formulation if computationally feasible, but make sure its physically realistic. A spring-network approximation is acceptable only if its assumptions and limitations are made explicit. Include: - translational nodal degrees of freedom; - axial deformation and, where feasible, bending deformation; - physically meaningful stiffness and strength parameters; - incremental displacement-controlled tensile loading; - equilibrium solution at every loading step; - an explicit member or interface failure criterion; - irreversible element removal or stiffness degradation after failure; - re-equilibration and load redistribution after each failure event; - reproducible geometric disorder controlled by a random seed; - conservation checks, convergence checks, and solver diagnostics. Do not use animation behavior, visual effects, or an unconstrained generic rigid-body engine as a substitute for the mechanics solver. Three.js may be used for geometry and visualization, but the mechanical response must come from an explicit, documented numerical model. Clearly distinguish normalized model quantities from dimensional physical units. Do not claim continuum-level fracture properties unless the model supports them. ────────────────────────────────────────────────────────────────────────────── APPLICATION ────────────────────────────────────────────────────────────────────────────── Create a polished, self-contained browser application that includes: 1. REFERENCE INTERPRETATION - Display all supplied images. - Show the inferred structural hierarchy and design principles. - Provide an editable text panel containing the adopted interpretation. - Allow regeneration of the structure after the interpretation is changed. - Do not assume that the images correspond pixel-by-pixel or depict the same object from registered viewpoints. 2. GEOMETRY GENERATION Provide controls for: - hierarchy depth (across many levels, no hierarchy to 10 or more hierarcies); - branching ratio; - connectivity and redundancy; - geometric disorder (wide range from completely ordered rectangular to disordered with varying design languages); - random seed; - relative density or total material volume; - member slenderness; - interface placement; - within-level and interlevel strength; - defect location and severity; - specimen dimensions and boundary conditions. Permit comparison of several generated designs while controlling total material volume. Preserve the undeformed geometry for STL or another suitable geometry export when the generated structure is physically printable. For STL generation allow an option to thicken think members before exported to ensure printability that a user or the agent can control. 3. MECHANICS AND FRACTURE Provide controls for: - elastic modulus or normalized member stiffness; - member and interface failure thresholds; - bending-to-axial stiffness ratio; - load increment; - maximum displacement; - numerical tolerance; - maximum equilibrium iterations; - damping or stabilization, if used. Expose the governing equations, assumptions, boundary conditions, failure rules, and numerical method in an expandable Physics panel. 4. VISUALIZATION Use Three.js or an equivalent browser-native renderer to show: - the undeformed structure; - deformed geometry; - displacement magnitude; - axial force, strain, or stress proxy; - intact, damaged, and failed members; - failure sequence; - current load step; - load paths and damage localization. Include orbit, pan, zoom, reset-view, standard-view, and fit-to-structure controls. Keep essential controls visible and reliably operable. 5. RESULTS AND EXPORT Calculate and display: - reaction force versus applied displacement; - initial stiffness; - peak force; - displacement at first failure; - displacement at final failure; - work to failure; - number and sequence of failed members; - fraction of failed members; - a defined damage-localization index; - numerical residual and convergence status. Allow export of: - raw step-by-step results; - per-member histories; - complete experiment metadata; - parameter values and random seeds; - geometry; - plots; - screenshots; - CSV and JSON data; - Movies as MP4 of the entire simulation run. ────────────────────────────────────────────────────────────────────────────── VALIDATION ────────────────────────────────────────────────────────────────────────────── Before conducting the discovery study, validate the simulator. At minimum: - compare a single axial member with its analytical stiffness; - verify that identical parameters and seeds reproduce identical results; - verify that increasing elastic stiffness changes the initial slope correctly; - verify that changing strength affects failure without incorrectly changing the elastic response; - verify symmetry for a symmetric specimen and loading condition; - check force balance and equilibrium residuals; - check sensitivity to load-step size; - verify that exported results match values displayed in the application. Create a Validation panel showing pass/fail status, numerical error, expected result, observed result, and tolerance. If essential validation tests fail, repair the implementation and rerun them. Do not proceed to scientific discovery with a failed solver. ────────────────────────────────────────────────────────────────────────────── AUTONOMOUS SCIENTIFIC STUDY ────────────────────────────────────────────────────────────────────────────── After the validated simulator is complete, use it to conduct a computational study. The objective is to discover a reproducible and mechanistically interpretable relationship governing fracture in the generated hierarchical material family. Do not assume that hierarchy improves performance. A null result, tradeoff, or counterexample is scientifically acceptable. Maintain a machine-readable experiment log containing every simulated design, including unsuccessful and unexpected results. Conduct the study in the following stages: 1. Establish a nonhierarchical or minimally hierarchical baseline. 2. Perform a small reconnaissance study across hierarchy depth, redundancy, disorder, and interlevel strength. 3. Formulate multiple competing, falsifiable hypotheses concerning fracture behavior that deeply investigate the scientific question at hand. 4. Select further simulations that efficiently distinguish those hypotheses. 5. Identify representative examples of localized brittle failure and distributed progressive failure. 6. Search for non-monotonic effects and stiffness–toughness tradeoffs rather than only maximizing a single score, searching for complex trade-offs and mechanisms. 7. Repeat important designs using at least three random seeds for proper statistics. 8. Before running the final set of at least 10 simulations, record explicit predictions for their qualitative behavior and quantitative metrics. Treat these as unseen holdout cases. 9. Run the holdout simulations and compare predictions with observations to ensure your scientific hypothesis is sound. Use approximately 80 primary simulations unless additional runs are necessary to resolve a numerical or scientific ambiguity. Keep total material volume or relative density fixed for comparisons intended to reveal the effect of hierarchy. Record for every experiment: - unique run identifier; - full parameter set; - random seed; - reason for choosing the experiment; - hypothesis being tested; - validation and convergence status; - all mechanical metrics; - qualitative fracture mode; - paths to exported results and images; - interpretation and next decision. Do not discard outliers silently. Distinguish numerical failure, stochastic variation, and genuine mechanical behavior. ────────────────────────────────────────────────────────────────────────────── ANALYSIS AND FIGURES ────────────────────────────────────────────────────────────────────────────── Analyze the collected data and generate publication-quality figures showing: 1. the interpreted images, inferred hierarchy, and generated specimen; 2. coverage of the investigated design space; 3. stiffness versus work to failure, including any Pareto frontier; 4. representative load–displacement curves; 5. snapshots contrasting localized and distributed fracture; 6. effects of hierarchy, redundancy, disorder, and interlevel strength; 7. holdout predictions compared with observed results. Show individual observations as well as means and variability. Report the number of seeds. Avoid unsupported claims of statistical significance. Every figure must have labeled axes, units or normalized units, readable legends, and a complete caption. Save figures in PDF or SVG and high-resolution PNG formats. ────────────────────────────────────────────────────────────────────────────── LATEX SCIENTIFIC REPORT ────────────────────────────────────────────────────────────────────────────── Write and compile a self-contained LaTeX report containing: - title; - abstract; - scientific question; - interpretation of the reference images; - generated material family; - governing equations and assumptions; - numerical method; - validation results; - experimental protocol; - competing hypotheses; - results; - fracture mechanisms; - holdout predictions and outcomes; - limitations and threats to validity; - conclusions; - complete experiment table in an appendix. The report must distinguish clearly among: - facts directly observed in the simulations; - interpretations inferred from those observations; - predictions tested on holdout designs; - hypotheses that were rejected; - behavior of this computational model; - identify the pareto front of optimal designs, including a wide set of designs for which STL files are generated; - claims that would require higher-fidelity or physical validation. Do not describe the simulator results as physical experiments or as proof of real-material behavior. Compile the LaTeX successfully and inspect the rendered PDF for overlapping content, clipped plots, missing references, unreadable labels, and blank pages. Repair all visible defects. ────────────────────────────────────────────────────────────────────────────── FINAL DELIVERABLES ────────────────────────────────────────────────────────────────────────────── Deliver together: - the working browser application; - its complete source; - a description of the numerical solver; - validation results; - raw experiment data; - processed data; - complete experiment log; - all figures; - representative screenshots; - report.tex; - compiled report.pdf; - Geometries and STL files ready for 3D printing; - an experiment manifest recording application version, model configuration, dates, parameter ranges, random seeds, and file checksums. The task is complete only after the application works, validation passes, the scientific study has been executed using actual simulator outputs, the holdout predictions have been evaluated, and the final PDF has been compiled and visually checked. /goal Build, validate, and use a complete browser-based scientific simulator derived from the supplied reference images. Conduct a reproducible computational study with the simulator, discover and test a nontrivial relationship governing hierarchical fracture, collect and export all data, generate publication-quality plots, and deliver a compiled LaTeX PDF report, and produce geometry files for manufacturing. Continue until the simulator, dataset, plots, source files, and PDF have all been created and verified and printable designs are available. Export the set of STL files for a user to print; in different thickening levels to make sure that finer details can be physically printed. Mark them clearly so we can see the original design as optimized and the thickened variants. Propose around 10 designs and associated STL files that I should print to explore the design space. Explain why.