Paper deep dive

InfEngine: A Self-Verifying and Self-Optimizing Intelligent Engine for Infrared Radiation Computing

Kun Ding, Jian Xu, Ying Wang, Peipei Yang, Shiming Xiang

Year: 2026Venue: arXiv preprintArea: cs.AIType: PreprintEmbeddings: 115

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%

Last extracted: 7/20/2026, 8:52:37 PM

Summary

The paper introduces InfEngine, an autonomous intelligent computational engine for infrared radiation computing that utilizes a multi-agent architecture to achieve self-verification and self-optimization. It integrates four specialized agents (Problem Analyzing, Problem Solving, Evaluator Generation, and Code Evolution) to generate, debug, and optimize code for 200 tasks in the InfBench benchmark, powered by a library of 270 tools (InfTools). InfEngine achieves a 92.7% pass rate, outperforming manual expert effort by 21x in speed and demonstrating superior generalization and robustness compared to baseline code generation methods.

Entities (11)

InfEngine · software-system · 98%InfBench · dataset · 95%InfTools · software-library · 95%Self-optimization · mechanism · 93%Self-verification · mechanism · 93%Code Evolution Agent · ai-agent · 92%Evaluator Generation Agent · ai-agent · 92%Problem Analyzing Agent · ai-agent · 92%Problem Solving Agent · ai-agent · 92%Qwen3-8b · model · 90%MapCoder · baseline-method · 88%

Relation Signals (11)

InfEngine → achieves → 92.7% pass rate

confidence 95% · InfEngine achieves a 92.7% pass rate

InfEngine → uses → InfTools

confidence 95% · powered by InfTools with 270 curated tools

InfEngine → uses → InfBench

confidence 95% · Evaluated on InfBench with 200 infrared-specific tasks

InfEngine → comprises → Evaluator Generation Agent

confidence 92% · the Evaluator Generation Agent for defining validation criteria

InfEngine → comprises → Code Evolution Agent

confidence 92% · and the Code Evolution Agent for iteratively refining solutions.

InfEngine → comprises → Problem Analyzing Agent

confidence 92% · InfEngine adopts a multi-agent architecture consisting of four specialized agents: the Problem Analyzing Agent

InfEngine → comprises → Problem Solving Agent

confidence 92% · the Problem Solving Agent for generating solution code

Self-verification → enabledby → joint solver-evaluator debugging

confidence 90% · self-verification, enabled by joint solver-evaluator debugging

InfEngine → →

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:Infrared radiation computing underpins advances in climate science, remote sensing and spectroscopy but remains constrained by manual workflows. We introduce InfEngine, an autonomous intelligent computational engine designed to drive a paradigm shift from human-led orchestration to collaborative automation. It integrates four specialized agents through two core innovations: self-verification, enabled by joint solver-evaluator debugging, improves functional correctness and scientific plausibility; self-optimization, realized via evolutionary algorithms with self-discovered fitness functions, facilitates autonomous performance optimization. Evaluated on InfBench with 200 infrared-specific tasks and powered by InfTools with 270 curated tools, InfEngine achieves a 92.7% pass rate and delivers workflows 21x faster than manual expert effort. More fundamentally, it illustrates how researchers can transition from manual coding to collaborating with self-verifying, self-optimizing computational partners. By generating reusable, verified and optimized code, InfEngine transforms computational workflows into persistent scientific assets, accelerating the cycle of scientific discovery. Code: this https URL

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

114,047 characters extracted from source content.

Expand or collapse full text

InfEngine: A Self-Verifying and Self-Optimizing Intelligent Engine for Infrared Radiation Computing Kun Ding 1 , Jian Xu 1 , Ying Wang 1* , Peipei Yang 1 , Shiming Xiang 1 1 State Key Laboratory of Multimodal Artificial Intelligence Systems, Institute of Automation, Chinese Academy of Sciences, Beijing, China. *Corresponding author(s). E-mail(s): ywang@nlpr.ia.ac.cn; Contributing authors: kun.ding@ia.ac.cn; jian.xu@ia.ac.cn; ppyang@nlpr.ia.ac.cn; smxiang@nlpr.ia.ac.cn; Abstract Infrared radiation computing underpins advances in climate science, remote sens- ing and spectroscopy but remains constrained by manual workflows. We introduce InfEngine, an autonomous intelligent computational engine designed to drive a paradigm shift from human-led orchestration to collaborative automation. It inte- grates four specialized agents through two core innovations: self-verification, enabled by joint solver-evaluator debugging, improves functional correctness and scientific plausibility; self-optimization, realized via evolutionary algo- rithms with self-discovered fitness functions, facilitates autonomous performance optimization. Evaluated on InfBench with 200 infrared-specific tasks and pow- ered by InfTools with 270 curated tools, InfEngine achieves a 92.7% pass rate and delivers workflows 21× faster than manual expert effort. More fun- damentally, it illustrates how researchers can transition from manual coding to collaborating with self-verifying, self-optimizing computational partners. By generating reusable, verified and optimized code, InfEngine transforms computa- tional workflows into persistent scientific assets, accelerating the cycle of scientific discovery. Keywords: Infrared radiation computing, Intelligent computational engine, Multi-agent system, Code generation 1 arXiv:2602.18985v1 [cs.AI] 22 Feb 2026 1 Introduction Infrared radiation constitutes a critical segment of the electromagnetic spectrum, from 780 nm to 1 m. The computational modeling, simulation and analysis of this radiation, termed infrared radiation computing, constitutes a foundational technical area that underpins progress across diverse scientific and engineering disciplines. It enables screening of novel photodetector materials [1, 2] and supports elucidation of molecular structures from spectral fingerprints [3, 4]. It also facilitates atmospheric remote sensing [5] and drives development of advanced thermal imaging systems [6]. A complete infrared radiation computing workflow comprises a multi-stage pipeline (Fig. 1b), which starts with source modeling and spectroscopic analysis, proceeds through radiative transfer simulation in various media, and ends with data process- ing and physical interpretation. Currently, constructing such integrated workflows is predominantly a manual task. Researchers must act as the central “orchestrator and validator” (Fig. 1c) and manually integrate disparate software packages [7, 8], numer- ical solvers [9] and physical models [10]. This labor-intensive process requires deep domain expertise for coding, integration and validation. It creates a significant bot- tleneck that impedes rapid iteration and limits scalability. Ultimately, it hinders the transformative potential of infrared radiation computing across its broad applications, highlighting an urgent need for intelligent automation. Recent advances in large language models (LLMs) [11] offer promising avenues for automation in related domains. Two dominant approaches have emerged. The first is tool calling [12, 13], which empowers LLMs to select and sequence tools from a pre- defined library. This paradigm has been successfully applied across multiple domains, including scientific reasoning (SciAgent [14], AWL [15]), chemistry (ChemCrow [16], ChatMOF [17]), genomics (GeneGPT [18]) and differential equation solving (PDE- Agent [19]). The second is code generation. It produces executable scripts and offers greater flexibility for composing complex operations. This paradigm has advanced general programming through methods like CodeCoT [20]. It has even facilitated automated algorithm discovery, as seen in works such as FunSearch [21], EoH [22], EvoVLMA [23] and Evo-MCTS [24]. Despite their successes in other domains, both paradigms have significant limita- tions for infrared radiation computing. Tool-calling approaches rely on a fixed set of atomic operations. This restricts their ability to express intricate algorithmic logic, integrate domain-specific tools with general-purpose libraries seamlessly, and gener- ate reusable software artifacts. Code-generation approaches are more expressive but often prioritize syntactic correctness over functional and scientific validity. They may produce error-free code that nonetheless yields physically implausible results—a per- ilous silent failure in computational science. Furthermore, they lack mechanisms for iterative self-optimization towards performance objectives. To accelerate the paradigm shift in infrared radiation computing, we introduce InfEngine, an intelligent computational engine inherently designed for self- verification and self-optimization. Our work builds on two foundational resources. The first is InfTools, a curated suite of 270 domain-specific tools covering the full spectrum of infrared radiation computing tasks. The second is InfBench, a new benchmark of 200 tasks tailored to evaluate both assistant-type and optimization-type 2 problem-solving capabilities. To realize its core functionalities, InfEngine adopts a multi-agent architecture consisting of four specialized agents: the Problem Analyzing Agent for formalizing user queries, the Problem Solving Agent for generating solution code, the Evaluator Generation Agent for defining validation criteria and the Code Evolution Agent for iteratively refining solutions. This well-structured design enables two key innovations. The first is self-verification, achieved through a joint debugging process. The system generates both a solver and a corresponding evaluator. A dedicated referee diagnoses discrepancies and prevents spurious co-optimization, ensuring fixes maintain generalizability and fidelity to the true task constraints. This elevates validation from mere executability to semantically meaningful correctness assessment. The second is self-optimization, bootstrapped from this verified foundation. For optimization- type tasks, the validated evaluator is repurposed as a trustworthy fitness function within an evolutionary algorithm. Unlike prior work such as FunSearch [21], which requires manually-specified objectives, our system autonomously synthesizes optimiza- tion goals from problem descriptions. This enables truly autonomous performance improvement. Evaluated on InfBench, InfEngine demonstrates a practical step toward a new collaborative paradigm for scientific computing, where researchers interact not with passive toolkits but with autonomous, self-optimizing partners. This paradigm pro- vides a blueprint for intelligent agents capable of accelerating discovery across diverse computational domains. 2 Results 2.1 Experimental Setup As shown in Fig. 1e, InfEngine takes a text-described problem and generates code via multi-agent interactions. We compare against state-of-the-art baselines on InfBench. Since existing methods lack native tool support and are optimized for programming/- math tasks, we augmented their prompts with retrieved tool descriptions and output formats, leaving their core algorithms unchanged. For InfEngine, we set evolutionary iterations N = 10 and population size m = 5. We also evaluate across different LLMs. 2.2 Performance on InfBench 2.2.1 Comparison with Different Methods We benchmark InfEngine against established code generation methods: Direct that prompts LLM directly, FewShot that augments Direct with two examples, Code- CoT [20], SelfDebug [25], Reflexion [26] and MapCoder [27]. We adopt retrieval- augmented generation (RAG) to supply each approach with the top-15 most relevant tools. All experiments are conducted on Qwen3-8B, deployed via vLLM. Fig. 2 shows the results, where Direct and FewShot establish baseline perfor- mance, but are outperformed by more advanced methods. SelfDebug and Reflexion outperform these baselines, with particular effectiveness on assistant-type tasks. How- ever, these two methods struggle with optimization scenarios and exhibit significant 3 Problem-Analyzing Agent PlanningGenerationExecutionDebuggingVerification Task Problem-Solving Agent PlanningGenerationExecutionJoint Debugging Evaluator Generation Agent Task + Goal + Answer Code Evolution Agent Crossover Evaluation Given a hemispherical background blackbody source and a test source, compute the total current through the detector. The test source's ... e b objectatmospheredetector reflected radiation object radiation air radiation process & analysis C H H H H C H H H H O O C O O C O O C O O C C H H H H souce modeling (1) spectrum (19) radiative transfer (3) detector modeling (6) registration (4) inversion (2) mosaicking (1) generation (15) fusion (16) simulation (2) basic (23) calibration (2) enhancement (11) super-resolution (3) depth (18) saliency (3) keypoint (5) counting (1) classification (3) detection (53) segmentation (22) evaluation (35) dataset (22) f InfTools: Problem-Solving & Evaluation Tools DescriptionInputs OutputsMetadata NameSouce Tool Definition gh General Tools scikit Tool Retrieval planning solution code evaluation code initial code Top-K Tools evaluation code evaluation result planning solution code solution result evaluation code debugging loop re-planning debugging loop re-planning solution result E1 E2 M1 M2 M3 a Autonomous SystemsPublic Safety Agriculture Biomedical Materials Science Astronomy Molecular Spectroscopy Atmospheric Science temperature field simulationatmospheric spectroscopy computationoptical system simulationradiometric calibrationtarget recognition 3D geometric modelingmolecular structure elucidationmaterial property calculationimage translationformat conversion radiative transfer equation solvingphotosensor modeling and analysisradiative property calculationimage enhancementimage understanding Learn Tools Write Solver Scientific Computing Toolset Intelligent Computational Engine Scientific Computing Toolset cd UserUser Exported Project Dependencies Necessary Tools Solution Code Main FuncReadMe Engine Dependencies Task Solution Code Call Tool Tool Result Mutation re-planning Fig. 1: Overview. a, Related applications. b, Workflow of infrared radiation comput- ing with core computational components at each stage. c, Scientific computing based on manual coding. d, Scientific computing based on intelligent computing engine. e, The flowchart of InfEngine. f, The InfTools has 270 tools for infrared radiation computing. g, Standardized fields defined for each tool. h, Some of the general tools that can be used in InfEngine. Icon credit: Freepik.com. overfitting behavior. CodeCoT achieves a strong Overall Score of 0.528. Its balanced scores (Train Score=0.443, Test Score=0.303) indicate consistent performance across tasks. MapCoder achieves the strongest performance among baseline methods with 4 d bc e gf a Fig. 2: Comparison with baselines. a, Performance on assistant-type tasks (left), optimization-type tasks (mid), overall performance (right). b, Win rate comparison of InfEngine and MapCoder on assistant-type tasks. c, Train Score scatter plot of InfEngine and MapCoder on optimization-type tasks, Test Score scatter plot of them on optimization-type tasks, correlation analysis between training and test scores of InfEngine, correlation analysis between training and test scores of MapCoder. d, Win rate comparison of InfEngine and InfEngine-evo on assistant-type tasks. e, Per-task Train Score comparison of InfEngine, InfEngine-evo and InfEngine-eval-evo. f, Win rate comparison of InfEngine-evo and InfEngine-eval-evo on assistant-type tasks. g, Per-task Test Score comparison of InfEngine, InfEngine-evo and InfEngine-eval-evo. an Overall Pass@1 of 0.921. Its normalized ranking scores (Train Rank=0.573, Test Rank=0.624) demonstrate strong performance relative to other baselines, supported 5 by its raw scores (Train Score=0.448, Test Score=0.378). Its superior performance in assistant-type tasks (Pass@1=0.842) further confirms the value of emulating human development processes. Our proposed InfEngine establishes a new state-of-the-art across all evaluation dimensions. As shown in Fig. 2a, it achieves a remarkable Overall Pass@1 of 0.949 and an Overall Score of 0.733, representing an absolute improvement of 2.8% and a relative improvement of 16.0% over MapCoder, respectively. This superiority is partic- ularly pronounced in the more challenging optimization-type tasks, where InfEngine attains near-perfect Pass@1 (0.991) while simultaneously achieving the best train- ing (Train Rank=0.749) and test (Test Rank=0.710) performance—an exceptional combination indicating both effectiveness and generalization capability. This is fur- ther evidenced by its strong raw performance (Train Score=0.679, Test Score=0.532). Notably, InfEngine maintains strong performance on assistant-type tasks with a Pass@1 of 0.907, surpassing MapCoder by 6.5%. For assistant-type tasks, the win-rate analysis (Fig. 2b) reveals that InfEngine matches or outperforms MapCoder in the vast majority (88.4%) of tasks, with a clear win rate of 23.6% against a loss rate of only 11.5%. For optimization-type tasks, the per-task superiority is even more pronounced. The pairwise comparisons (Fig. 2c) show that the majority of data points fall below the diagonal line, indicating that InfEngine achieves higher training and test scores than MapCoder on most tasks. The consistent distribution of points below the diagonal in the test score comparison (Fig. 2c) provides direct visual evidence of InfEngine’s superior generalization at the task level. A critical comparison of generalization behavior is shown in Fig. 2c. InfEngine exhibits a strong positive correlation between training and test scores (R 2 = 0.699), indicating that optimization success reliably predicts generalization. MapCoder, by contrast, shows markedly weaker correlation (R 2 = 0.496), reflecting poorer transfer and higher overfitting risk. These results demonstrate that InfEngine’s evolution with self-verification inherently yields more robust and generalizable solutions. In summary, InfEngine’s consistent superiority across both task types demon- strates its multi-agent evolutionary architecture fundamentally enhances the code generation process, producing robust and generalizable solutions that outperform existing methods. 2.2.2 Comparison with Different LLMs To evaluate InfEngine’s generality, we test it across seven LLMs of varying scale and specialization. Results in Fig. 3 reveal two key findings. First, InfEngine delivers a strong performance floor even with small models. Qwen3-4B achieves an Overall Pass@1 of 0.840, a result competitive with or surpassing MapCoder on Qwen3-8B. This shows our framework better leverages base model capacity. Second, performance scales clearly with model capability. Test Rank improves from 0.419 (Qwen3-4B) to 0.595 (Qwen3-Coder), and Train Rank from 0.398 to 0.610. InfEngine thus exploits stronger reasoning and generalization in larger models via its evolutionary loop. 6 abc de Fig. 3: Comparison of InfEngine with different LLMs and human baseline. a, Performance on assistant-type tasks. b, Performance on optimization-type tasks. c, Aggregate performance across all tasks. d, Computational time comparison for assistant-type (left) and optimization-type (right) tasks. e, Win/Tie/Loss rate of dif- ferent LLM-based InfEngine instances against the human baseline on the training set (left) and test set (right) for optimization-type tasks. 2.2.3 Comparison with Human We benchmark InfEngine against a human expert following a conventional manual coding workflow (Fig. 1c). Efficiency is measured by average task completion time and solution quality by evaluation scores. InfEngine delivers substantial efficiency gains (Fig. 3d). For assistant-type tasks, human experts required approximately 50 minutes per task, whereas InfEngine completed these tasks in 2.2 to 5.8 minutes, achieving 8.6-22.7× acceleration. For optimization-type tasks, human researchers averaged 70 minutes per task, while InfEngine finished in 16 to 60 minutes, achieving 1.2-4.4× speedup. This acceleration enables rapid hypothesis testing and parameter exploration at scales previously infeasible due to manual overhead. Beyond efficiency, InfEngine demonstrates strong capability in autonomously dis- covering objectives and iteratively improving solution quality. Fig. 3e compares agent and human performance on optimization-type tasks. The combined win and 7 tie rate indicates solutions at least as effective as human counterparts. On train- ing set, this rate exceeded 50% for all models, peaking at 65.7% with Qwen3-32B. On test set, models including Qwen3-Coder-480B-A35B-Inst, DeepSeek-v3.2 and Gemini-2.5-Flash-Lite also surpassed 50%, demonstrating robust generalization and performance consistently matching or exceeding human levels. These results con- firm that InfEngine-generated solutions maintain, and often surpass, the quality of manually crafted code. 2.2.4 Effectiveness of Components To evaluate core component contributions of InfEngine, we conduct an ablation study with two variants: (1) InfEngine-evo removes Code Evolution, retaining self- verification; (2) InfEngine-eval-evo further removes Evaluator Generation, reducing to baseline. The overall performance profile in Fig. 2a establishes a clear performance gra- dient. On optimization-type tasks, performance follows: InfEngine > InfEngine-evo > InfEngine-eval-evo, demonstrating that each autonomous capability cumulatively enhances system performance in scenarios requiring refinement and objective pursuit. On assistant-type tasks, the ordering is InfEngine ≈ InfEngine-evo > InfEngine- eval-evo. While both InfEngine and InfEngine-evo achieve comparable results for assistant-type tasks, the consistent superiority of the full system in optimization scenarios and overall metrics underscores the synergistic value of integrating both self-verification and self-optimization. The value of self-verification is evident in Fig. 2e-g. On optimization-type tasks, verification alone (InfEngine-evo) confers a clear advantage over InfEngine-eval-evo: it achieves higher training scores in 40.0% of tasks versus 31.4% losses (Fig. 2e) and higher test scores in 37.1% versus 34.3% losses (Fig. 2g). This advantage also holds for assistant-type tasks (18.2% wins vs. 12.1% losses; Fig. 2f). These results confirm that the Evaluator Generation Agent establishes a reliable correctness criterion, yielding more accurate solutions even without iterative refinement. Self-optimization contributes most decisively in optimization-type tasks (Fig. 2e,g). InfEngine substantially outperforms the verification-only variant (InfEngine-evo), achieving 71.4% wins versus 22.9% losses on training scores and 54.3% wins versus 34.3% losses on test scores. This demonstrates that the Code Evolution Agent, bootstrapped with a verified fitness function, effectively explores the solution space and iteratively improves performance while preserving general- ization. On assistant-type tasks, the marginal win differential (15.2% vs. 12.1%; Fig. 2d) reflects that such tasks demand correct execution rather than quantitative optimization. In summary, self-verification ensures correctness and self-optimization drives improvement, transforming InfEngine from a static generator into an adaptive engine that autonomously pursues and verifies higher-quality outcomes. 8 2.3 Case Analysis 2.3.1 Case 1: High-Throughput Screening of Infrared Photodetector Materials The development of advanced infrared detectors demands efficient screening of semi- conductors across multidimensional parameter spaces [1, 2]. Traditional approaches require expertise in radiative transfer, solid-state physics and numerical methods, creating steep barriers to rapid material assessment. This case illustrates how InfEngine accelerates detector performance evaluation through autonomous workflow generation. Faced with a complex photocurrent calculation problem (Fig. 4a), InfEngine’s Problem Analyzing Agent first classified the task as deterministic computational pipeline rather than iterative optimization. The Problem Solving Agent then formu- lated a seven-step workflow (Fig. 4c), sequencing temperature-dependent bandgap modelling to photocurrent integration. The explicit stepwise reasoning reflects the sys- tem’s grasp of causal dependencies in optoelectronic systems. The generated Python code (Fig. 4d) faithfully implements this plan, handling unit conversion, spectral inte- gration and interface effects. Its parameterized design with defaults matching the test case enables high-throughput screening: material parameters, device geometry and illumination conditions can be systematically varied while maintaining physical con- sistency. Crucially, InfEngine also autonomously produces a validation suite (Fig. 4e). The Evaluator Generation Agent embeds scientific constraints including current posi- tivity, realistic amplitude spanning picoampere to microampere ranges, and numerical robustness directly into the evaluation pipeline, enhancing reliability in automated scientific computing. By packaging complex optoelectronic physics into a parameterized, self-validating function, InfEngine transforms expert-led detector analysis into an automated and reproducible workflow. This capability accelerates the exploration of candidate mate- rials across broad design spaces, advancing the discovery cycle for next-generation infrared sensing technologies. 2.3.2 Case 2: Autonomous Cross-Validation of Computational Infrared Spectroscopy Methods Computational infrared spectroscopy relies on diverse methods [28, 29] with dis- tinct approximations and trade-offs. Directly comparing spectra predicted by different approaches, such as physics based molecular dynamics versus data driven structural inference, offers essential qualitative validation and reveals systematic biases. However, manually coordinating such comparative workflows across multiple simulation pack- ages presents a substantial barrier. This case demonstrates how InfEngine automates this process by generating integrated pipelines that highlight spectral consistency and divergence across techniques. The task, as specified in Fig. 5a, involves a qualitative comparison of IR spectra for ethanol generated via two pathways: all atom molecular dynamics with LAMMPS and a machine learning prediction from the 3D molecular structure alone. The goal 9 Givenaphotodetectionsystemconsistedofa testradiationsourceandasemiconductor detector,yo u rtaskistocomputeth eto ta l currentthroughthedetector. radiation source detector a current? Thetestsource's information: •emissivity:1.0 •surface temperature: 2000K •area:33m^2 •distancefrom thedetector: 100m Thedetector'sinformation: •area:(200e-6)**2m^2 •thepa ra me te rsfo rth eVarshnimodel: Eg(0)=0.24,A=0.00 06,B=50 0.0 •absorptioncoefficienta0:1.9e4*10 0m^-1 •absorptioncoefficienta0p:800*100m^-1 •temperature80K •thestartofthedetectordepletionlayer:0m •theendofthedetectordepletionlayer:5e-6m •therefractionindexofthesemiconductor:3.42 Otherinformation: •Therefractionindexoftheair is1.0 •Theradiationincidentan g le inradiansis0.0 •Considerthewavelength rangelinspace(1,5.5,20 0)in micrometer Returnth ecu rre n tasafloat number. ProblemClassification:assistant-ty p e. Explanation:Thetaskrequiresex ec utingafixedcomputationalproceduretocalculatethetotalcurrentthroughaphotodetectorusinggiven physicalparametersandformulas.Thisinvolvesadefinedprocessingflowwithclearcompletioncriteria(computingandreturningafloatvalue), withoutrequiringiterativeoptimizationtomaximize/minimizeanymetrics. Problem Analyzing Agent b Problem Solving Agent Planning: Step1:Calculatethebandgapenergyandcutoffwavelengthatdetectortemper atureus ingVa rs h n imodel.Toolsneeded:[Vars hni_Model_Tool]. Packagesneeded:[].Rationale:... Step2:Calculatespectralabsorptioncoefficientforthesemiconductormaterial.Toolsneeded:[Calc_Spectral_Absorp_Coeff_Tool].Packages needed:[].Rationale:... Step3:Calculatespectralquantumefficiencyofthedetector.Toolsneeded:[Calc_Quantum_Efficiency_Tool].Packagesneeded:[].Rationale:... Step4:Calculatespectralresponsivityfromquantumefficiency.Toolsneeded:[Calc_Spectral_Responsivity_Tool].Packagesneeded:[]. Rationale:... Step5:CalculatePlanckspectralexitanceforthesourceatgiventemperature.Toolsneeded:[Planck _Law_Tool].Packagesneeded:[]. Rationale:... Step6:Calculateirradianceonthedetectorfromsourceexitance.Toolsneeded:[Calc_Irradiance_Tool].Packagesneeded:[].Rationale:... Step7:Calculatetotalcurrentthroughthedetector.Toolsneeded:[Calc_Current_Tool].Packagesneeded:[].Rationale:... c importnumpyasnp defsolve(tools,emissivity:float=1.0, source_temp:float=2000.0, source_area:float=33e-6,distance:float=0.1, det_area:float=(200e-6)**2,Eg0:float=0.24,A:float=0.0006,B:float=500.0,a0:float=1.9e4*100,a0p:float= 800*100,det_temp:float=80.0,d1:float=0.0,d2:float=5e-6,n_material:float=3.42,n_air:float=1.0,theta:float =0.0,wavelength_start:float=1.0,wavelength_end:float=5.5,num_points:int=200): varshni_result=tools["Varshni_Model_Tool"].execute(Eg0=Eg 0,A=A,B=B,temperature=det_temp) bandgap_energy=varshni_result["bandgap_energy"] wavelength_um=np.linspace(wavelength_start,wavelength_end,num_points) wavelength_m=wavelength_um/1e6 absorption_result=tools["Calc_Spectral_Absorp_Coeff_Tool"].execute(wavelength=wavelength_m, Eg=bandgap_energy,tempDet=det_temp,a0=a0,a0p=a0p) absorption =absorption_result["absorption"] qe_result=tools["Calc_Quantum_Efficiency_Tool"].execute(absorption=absorption,d1=d1,d2=d2, theta1=theta,nFront=n_ air,nMaterial=n_material) quantum_effic=qe_result["qu an tumEffic"] responsivity_result=tools["Calc_Spectral_Responsivity_Tool"].execute(wavelength=wavelength_m, quantumEffic=qu an tum_ e ffic) responsivity =responsivity_result["responsivity"] planck_result=tools["Planck_Law_Tool"].execute(spectral=wavelength_um,temperature=source_temp,type='el’) exitance =planck_result["exitance"] irradiance_result=tools["Calc_Irradiance_Tool"].execute(exitance=exitance,emisSource=emissivity, areaSource=source_area,distance=distance) irradiance =irradiance_result["irradiance"] current_result=tools["Calc_Current_Tool"].execute(irradiance=irradiance,areaDet=det_area, wavelength=wavelength_um,type='radiant’,responsivity=responsivity) returncurrent_result["current"] Input Parameters Varshni Model Tool Generate Wavelength Array Calc Spectral AbsorpCoeff Tool Calc Quantum Efficiency Tool Planck Law Tool Calc Spectral Responsivity Tool Calc Irradiance Tool Calc Current Tool Total Current bandgap_energy absorption QuantumEfficexitance irradiance responsivity Problem Solving Agent d Evaluator Generation Agent defevaluate(result): importnumpyasnp assertisinstance(result,(float,np.floating)),f"Resultmust be a float, got type(result)" assertresult >0,f"Currentmust be positive, got result" assertresult <1e-3,f"Currentseems unrealistically large (>1mA), got result" assertnp.isfinite(result),f"Currentmust be a finite number, got result" assertnotnp.isnan(result),f"Currentcannot be NaN" try: float_result=float(result) except(ValueError,TypeError): raiseException(f"Cannotconvert result to float: result") ifresult <1e-12:# Less than 1 pA-suspiciously small raiseException(f"Currentresultseems too small (<1pA) for given parameters") ifresult >1e-6: raiseException(f"Currentresultseems too large (>1μA) for given parameters") return1 e Fig. 4: Question and result of Case 1. a, The query question with an illustration explaining the task. b, The result of Problem Analyzing Agent. c, The planning generated by Problem Solving Agent. d, The solution code and the corresponding flowchart. e, Evaluation function generated by Evaluator Generation Agent. Credit: agent icon, Freepik.com. is not experimental benchmarking but automated workflow execution that visualizes and contrasts spectral features from both methods. 10 Hereisamolecule,whoseSMILESstringisCCO. Its3Dmolecularstructureisgiveninthefile tasks/task120/mol.xyz.Thechargeofthis moleculeis0.0,themultiplicityis1.0.Visually comparetheIRspectrumcomputedbymolecular dynamicssimulationandpredictedby3D structure-basedIRpredictiontool.Returnthepath ofthevisualizationimage.Normalizethemaximal valueoftheIRspectrumsto1.0.Onlyvisualize thewavenumberrangefrom4000cm^-1to400 cm^-1. a C 1.220343 -0.222935 0.000024 C -0.081802 0.547782 -0.000017 O -1.151595 -0.395419 -0.000045 H 2.069020 0.463431 -0.000250 H 1.287441 -0.858499 -0.884085 H 1.287681 -0.858104 0.884394 H -0.137682 1.193007 0.885836 H -0.137619 1.192976 -0.885897 H -1.987329 0.081456 0.000324 tasks/task120/mol.xyz: e ProblemClassification:assistant-type. Explanation:Thetaskinv olv esex ec u t in gafixedprocessingflow:loadingmoleculardata,computing/predictingIRspectra,normalizingthem, creatingavisualcomparisonwithinaspec ifiedwav enumberrange,andsavingthevisualization.Thisfollowsadefinedpr oc e d ur ewithclear completioncriteria(visualizationimagecreatedandpathreturned),withoutrequiringiterativ eoptimizationtomaximize/minimizeanymetrics. Problem Analyzing Agent b Problem Solving Agent Planning: Step 1: Generate LAMMPS simulation input files from SMILES string using EMC setup. Tools needed:[EMC_Setup_Tool]. Packages needed:[]. Rationale:... Step 2: Run LAMMPS molecular dynamics simulation to generate dipole moment time-series data. Tools needed:[LAMMPS_Simulation_Tool]. Packages needed: []. Rationale:... Step 3: Calculate IR spectrum from LAMMPS dipole moment data using autocorrelation and Fourier transform. Tools needed: [LAMMPS_Dipole_IRSpectra_Tool]. Packages needed:[]. Rationale:... Step 4: Predict IR spectrum from 3D molecular structure using machine learning models. Tools needed: [IRspectrum_Predictor_Use_3D_Structure_Tool]. Packages needed:[]. Rationale:... Step 5: Load and process both IR spectra, normalize to maximum value of 1.0, and filter to 400-4000 cm^-1 range. Tools needed:[]. Packages needed:[numpy,pandas]. Rationale:... Step 6: Create comparative visualization of both IR spectra with proper labeling and save as image. Tools needed:[]. Packages needed: [matplotlib]. Rationale:... c Problem Solving Agent d Input Parameters Molec ular s t ruc t ure, computational settings, simulation and visualization parameters ir_spectra_compar ison.png EMC_Setup_Tool Generate MD simulation files LAMMPS_Simulatio n_Tool Run molec ular dynamics simulation LAMMPS_Dipole_IR Spectra_Tool Calc ulat e I R f rom dipole data IRspectrum_Predictor_Use_3D_Structu re_Tool Predicttionfrom XYZ Data Processing & Visulization Load, normalize, filter both spectra Comparat iv e plot t ing with mat plot lib setup_data_path setup_params_path dipole_path predicted_spectrum.csv md_spectrum.csv Fig. 5: Question and result of Case 2. a, The query question requesting comparison of IR spectra from MD simulation and 3D structure-based prediction for ethanol (CCO). b, The result of Problem Analyzing Agent. c, The planning generated by Problem Solving Agent. d, The automated tool-chain and code execution flowchart of final solution code. e, The generated comparative visualization of normalized IR spectra by the solution code. InfEngine constructed a workflow integrating four computational tools, autonomously linking a structure based IR predictor with a three stage MD simula- tion pipeline covering force field parameterization, trajectory generation and spectral postprocessing (Fig. 5d). This orchestration reflects the system’s ability to translate a high-level comparative objective into a sequence of domain specific operations bridging distinct computational paradigms. The generated code applies preprocessing steps including spectral filtering and intensity normalization to enable direct qualitative comparison. The resulting visu- alization (Fig. 5e) juxtaposes the two spectral traces in a publication ready format, allowing immediate assessment of peak positions, relative intensities and bandwidths as indicators of methodological agreement on the molecular vibrational fingerprint. This case illustrates InfEngine’s capacity to facilitate cross-validation of com- putational methods. By automating the setup, execution and analysis required for comparative spectroscopy, the system transforms a labor intensive process into a reproducible one click operation. The workflow delivers an immediate visual assess- ment of method consistency, serving as a vital sanity check and making qualitative validation routine and accessible in computational chemistry. 11 ProblemClassification:optimization-type. Explanation:Thetaskexplicitlyrequiresmaximizingthetop-10exactmatchingaccuracy,whichisaspecificmetric.Itinvolvesdevelopingapredictivemodelandoptimizingits performancebasedonground-truthSMILESdata.Thisfallsunderoptimization_taskasitaimstoimproveaspecificmetricthroughiterativetrainingortuning. Problem Analyzing Agent b Problem Solving Agent Planning: Step1:Loadthespectrumdata,wavenumberdata,andformulasdatafromtheprovidedfiles.Toolsneeded:[].Packagesneeded:[numpy].Rationale:NumPyissuitableforloading .npyfilesandhandlingarray-baseddataoperations. Step2:ProcesstheloadedspectrumdataandformulasdataintotherequiredformatfortheNMT_Formula_IRSpectrum_To_Smiles_Tooltool.Toolsneeded:[].Packagesneeded: [numpy].Rationale:Needtomanipulateandformatthedataappropriatelyforthetoolinput;NumPysupportsefficientarrayoperations. Step3:UsetheNMT_Formula_IRSpectrum_To_Smiles_TooltooltopredictSMILESfromtheformattedspectrumdataandformulas.Toolsneeded: [NMT_Formula_IRSpectrum_To_Smiles_Tool].Packagesneeded:[].Rationale:Thistoolspecificallytranslatesformula+IRspectrumdatatoSMILESusingatrainedmodel,which matchesthetaskrequirement. c Code Evolution Agent f Herearesomemolecules,theirspectrumsarerecordedinanpyfile:tasks/task231/spectra_train.npy, wherecolumnscorrespondtowavenumbers,rowscorrespondtomolecules.Thecorresponding wavenumbersarestoredinthewavenumber.npyfile,whichisa1-darray.Thespectrumsareobtainedby moleculardynamicssimulationwith300Ktemperature. Thecorrespondingformulasofthesemoleculesarestoredinthetasks/task231/formulas_train.txtfile, whereeachrowcorrespondstoonemolecule. WriteacodetopredicttheSMILESfromthesespectrums.Theground-truthSMILESaregiven,you shouldconsidertomaximizethetop-10exactmatchingaccuracy.Returnalistoftxtfilepathstopredicted SMILES.Ineachtxtfile,thereare10rows,eachrowcontainsoneofthetop-10predictedSMILES. Theground-truthSMILESarestoredinthetasks/task231/smiles_train.txtfile,whereeachrow correspondstoonemolecule. a Herearesomemolecules,theirspectrumsarerecordedinanpyfile: tasks/task231/spectra_test.npy,wherecolumnscorrespondtowavenumbers,rows correspondtomolecules.Thecorrespondingwavenumbersarestoredinthe wavenumber.npyfile,whichisa1-darray.Thespectrumsareobtainedbymolecular dynamicssimulationwith300Ktemperature. Thecorrespondingformulasofthesemoleculesarestoredinthe tasks/task231/formulas_test.txtfile,whereeachrowcorrespondstoonemolecule. WriteacodetopredicttheSMILESfromthesespectrums.Theground-truthSMILES aregiven,youshouldconsidertomaximizethetop-10exactmatchingaccuracy.Return alistoftxtfilepathstopredictedSMILES.Ineachtxtfile,thereare10rows,eachrow containsoneofthetop-10predictedSMILES. traintest Evaluator Generation Agent d importnumpyasnp defevaluate(tools,result): gt_smiles_path="tasks/task231/smiles_train.txt" withopen(gt_smiles_path,"r")asf: gt_smiles=[line.strip()forline inf.readlines()] withopen("gt_smiles_temp.txt","w")asf: forsmile ingt_smiles: f.write(smile +" ") execution =tools["Molecular_Structure_Elucidation_Metric_Tool"].execute( target_file="gt_smiles_temp.txt”, predicted_files=result) final_score=execution["exact_match_top10"] returnfinal_score defevaluate(result,smile_file="tasks/task231/smiles_train.txt"): """ Evalutethe result. Args: -result (list[str]): List of paths to predicted SMILES files -smile_file(str): Path to the GT smile file Returns: -float: top-10 exact matching accuracy, larger is better """ frominfagent.tools.evaluation.molecular_structure_elucidation_metric_tool import Molecular_Structure_Elucidation_Metric_Tool assertlen(result)>0 execution =Molecular_Structure_Elucidation_Metric_Tool().execute( target_file=smile_file,predicted_files=result,) returnexecution["exact_match_top10"] e Load spectrums, wavenumbers, formulas Createspectrum files (n*2 arrays: wavenumber + spectrum value) NMT_Formula_IRSpectrum_ To_Smiles_Tool formulas=formulas, spectrum_files=spectrum_files, beam_size=10, n_best=10, min_length=5 Input Parameters Prediction File spectra_data spectrum_files wavenumbers formulas iteration=0 Obj=0.27 Load spectrums, wavenumbers, formulas Createspectrum files (n*2 arrays: wavenumber + spectrum value) NMT_IRSpectrum_To_Smile s_Tool spectrum_files=spectrum_files, beam_size=10, n_best=10, min_length=5 Input Parameters Prediction File spectra_data spectrum_files wavenumbers iteration=3 Obj=0.475 Load spectrums, wavenumbers, formulas Createspectrum files (n*2 arrays: wavenumber + spectrum value) NMT_IRSpectrum_To_Smile s_Tool spectrum_files=spectrum_files, beam_size=20, n_best=20, min_length=10 Input Parameters Prediction File spectra_data spectrum_files wavenumbers iteration=7 Obj=0.535 Fig. 6: Question and result of Case 3. a, The query question (train+test). b, The output of Problem Analyzing Agent. c, The planning generated by Problem Solving Agent. d, The evaluation function generated by Evaluator Generation Agent. e, The evaluation code defined by human expert. f, Curves of generated evaluation metric on train set (as well as human evaluation metric on train set) and human evaluation metric on test set. Corresponding flowcharts of the solution code at iteration 0, 3, 7 are also included. 12 2.3.3 Case 3: Autonomous Optimization of Molecular Structure Elucidation from Infrared Spectra Infrared spectra encode molecular vibrational fingerprints, yet reconstructing molec- ular structure from spectral data remains a long-standing inverse problem [3, 4, 30]. Traditional workflows require manual orchestration of preprocessing, feature extrac- tion, and chemical space exploration through trial and error. This case demonstrates how InfEngine automates this optimization via autonomous workflow evolution. Presented with the task of predicting SMILES from simulated IR spectra under a top-10 accuracy metric (Fig. 6a), InfEngine’s Problem Analyzing Agent correctly identified an optimization-type task (Fig. 6b). The system generated a structured plan outlining data preparation and model prediction steps (Fig. 6c), and the Evaluator Generation Agent autonomously produced a tailored evaluation function to compute exact top-10 accuracy (Fig. 6d). The initial solution employed a formula-integrated neural machine translation tool that required both spectra and molecular formulas as inputs, achieving an objective value of 0.270. Guided by iterative feedback, the Code Evolution Agent systematically refined the pipeline. By Iteration 3, the system autonomously discovered that molecu- lar formulas provided limited utility and transitioned to a spectrum-only architecture, substantially improving performance to 0.475. Further optimization by Iteration 7 increased the beam size from 10 to 20 and minimum translation length from 5 to 10 to encourage more complete predictions, elevating the objective value to 0.535. This represents a relative improvement of 98% from the initial solution (Fig. 6f). This case illustrates InfEngine’s capacity for autonomous methodological discov- ery. Through systematic search guided by objective evaluation, it transforms static spectroscopy workflows into adaptive, problem-specific solutions, identifying when to discard input modalities and how to adjust decoding parameters for optimal per- formance. This enables rapid domain adaptation without manual intervention and accelerates method development in molecular structure elucidation. 2.4 Case 4: Evolutionary Optimization of Image Translation Pipeline Developing robust image-to-image translation systems for specialized domains like visible-to-thermal conversion requires navigating a vast space of algorithms and hyper- parameters. Conventional approaches use fixed model selection or manual tuning, limiting adaptability. This case demonstrates how InfEngine autonomously discovers, evaluates and synthesizes an optimal translation pipeline through evolutionary code optimization, transitioning from tool invocation to adaptive system design. As presented in Fig. 7a, the task required translating five RGB images into real- istic thermal representations while maximizing SSIM against co-registered references. The Problem Solving Agent generated an initial plan (Fig. 7e) that established a 13 WehavefiveRG Bimagesloc atedat\"tasks/task212/v is _ im1.jpg\",\"tasks/task212/v is _ im2.jpg\", \"tasks/task212/v is _ im3.jpg\",\"tasks/task212/v is _ im4.jpg\",\"tasks/task212/vis_im5.jpg\".Writea Pythoncodetotr a ns la t etheseimagestofakethermalimages ,whichshouldreturnthepathlis tof thegeneratedthermalimages. Wealsoprovidetheco-registeredthermalimagesasreference: tasks/task212/ir_im1.jpg tasks/task212/ir_im2.jpg tasks/task212/ir_im3.jpg tasks/task212/ir_im4.jpg tasks/task212/ir_im5.jpg YoushouldoptimizetheSSIMmetricofthefakethermalimagesbasedonthereferenceimages. ProblemClassification:optimization-type. Explanation:Theta skex p lic it lyrequiresoptimizingtheSSIMme t r icbetweenthegeneratedfakethermalimagesandtheprovidedreference thermalimages.Thisinv olv esiterativ eimprovementtomaximizetheSSIMmetricvalue,withgr o u n d-truthreferenceimagespr ov id e dforthe optimizationprocess. Problem Analyzing Agent d Problem Solving Agent Planning: Step 1: Generate fake thermal images from the five RGB images using an RGB-to-thermal translation tool. Process all images in a loop. Tools needed:[PearlGAN_FLIR_RGB2T_Generation_Tool]. Packages needed: []. Rationale:The PearlGAN_FLIR_RGB2T_Generation_Tool is specifically designed for RGB to thermal image style transfer and supports arbitrary image sizes. It's trained on FLIR dataset which is relevant for thermal imagery. The tool can process each RGB image to generate corresponding fake thermal images. Step 2: Collect and return the paths of all generated thermal images as a list. Tools needed:[]. Packages needed:[]. Rationale:After generating all thermal images, we need to compile their file paths into a list to meet the output format requirement. This isa simple data collection step that doesn't require specific tools or packages. e Problem Solving Agent f importos defsolve(tools,rgb_image_paths:lis t=["tasks/task212/vis_im1.jpg","tasks/task212/vis_im2.jpg","tasks/task212/vis_im3.jpg", "tasks/task212/vis_im4.jpg","tasks/task212/vis_im5.jpg"],seed:int=1234): generated_paths=[] forrgb_pathinrgb_image_paths: execution =tools["PearlGAN_FLIR_RGB2T_Generation_Tool"].execute(input_image_path=rgb_path,seed=seed) generated_paths.append(execution["ou t p u t _ im a g e_ p a t h"]) returngenerated_paths importnumpyasnp defextract_gt_paths(answer_str): paths =answer_str.split(": ")[1].split() returnpaths defevaluate(tools,result): answer_str="The co-registered thermal images as reference: tasks/task212/ir_im1.jpg tasks/task212/ir_im2.jpg tasks/task212/ir_im3.jpg tasks/task212/ir_im4.jpg tasks/task212/ir_im5.jpg" gt_paths=extract_gt_paths(answer_str) ssim_scores=[] forgt_path,gen_pathinzip(gt_paths,result): execution =tools["SSIM_Metric_Tool"].execute(image_true=gt_path,image_tes t=gen_path,data_range=255.0) ssim_scores.append(execution["metric"]) avg_ssim=np.mean(ssim_scores) final_score=avg_ssim returnfinal_score Evaluator Generation Agent g a RGBGT Infrared Infrared (iteration=0)Infrared (iteration=9) RGB GT Infrared RGB GT Infrared Infrared (iteration=0)Infrared (iteration=9) Infrared (iteration=0)Infrared (iteration=9) c Code Evolution Agent h iteration=0 (obj: 0.4182) Input Parameters PearlGAN_FLIR_RGB2T _Generation_Tool generated_paths iteration=2 (obj: 0.4474) Input Parameters FoalGAN_FLIR_RGB2T _Generation_Tool generated_thermal _paths iteration=3 (obj: 0.5052) Input Parameters PID_FLIR_RGB2T_Gene ration_Tool steps=500 generated_thermal _paths iteration=9 (obj: 0.5078) Input Parameters calculate_image_complexity generated_thermal _paths PID_FLIR_RGB2T_Generation_Tool FoalGAN_FLI R_RGB2T_Ge neration_Tool We have five RGB images located at \"tasks/task212/vis_im6.jpg\", \"tasks/task212/vis_im7.jpg\", \"tasks/task212/vis_im8.jpg\", \"tasks/task212/vis_im9.jpg\", \"tasks/task212/vis_im10.jpg\". Translate these images to fake thermal images. Please return the path list of the generated thermal images. train test defevaluate(fake_ir_paths,true_ir_paths=["tasks/task212/ir_im1.jpg","tasks/task212/ir_im2.jpg", "tasks/task212/ir_im3.jpg","tasks/task212/ir_im4.jpg","tasks/task212/ir_im5.jpg"]): """ Evalutethe result. Args: -fake_ir_paths(list[str]): Path list of generated IR images -true_ir_paths(list[str]): Path list of ground truth IR images Returns: -float: SSIM score, higher is better, value range is [0,1] """ importnumpyasnp frominfagent.tools.evaluation.SSIM_metric_toolimportSSIM_Metric_Tool ssims=[] forimage_true,image_tes tinzip(true_ir_paths,fake_ir_paths): execution =SSIM_Metric_Tool().execute(image_true,image_tes t) ssims.append(execution["metric"]) returnnp.mean(ssims).item() b tasks/task212/*_im1.jpg tasks/task212/*_im2.jpg tasks/task212/*_im3.jpg Fig. 7: Question and result of case 4. a, The query question (train+test). b, The eval- uation code written by human expert. c, Comparison of generated fake infrared images by solution code at iteration 0 and 9. d, The output of Problem Analyzing Agent. e, Planning generated by the Problem Solving Agent. f, The solution code generated by Problem Solving Agent. g, The generated evaluation code by Code Evolution Agent. h, Curves of generated evaluation metric on train set, human evaluation metric on train set and human evaluation metric on test set. Corresponding flowcharts of the solution code across different iterations are also included. scaffold for evolutionary refinement. The initial solution (Fig. 7f) employed Pearl- GAN_FLIR_RGB2T_Generation_Tool uniformly across images, achieving moder- ate SSIM (0.4182). Concurrently, the Evaluator Generation Agent autonomously pro- duced code to compute SSIM (Fig. 7g), enabling quantitative feedback for optimiza- tion. Evolutionary search yielded progressive gains: replacing PearlGAN with Foal- GAN raised SSIM to 0.4474, and adopting PID_FLIR_RGB2T_Generation_Tool 14 with steps=500 further improved it to 0.5052. By iteration 9, the system synthesized an adaptive pipeline achieving 0.5078 SSIM. It introduced a content-aware module estimating edge density to dynamically adjust diffusion steps, and a fallback mecha- nism ensuring robustness when preferred tools failed. The resulting thermal images exhibited superior contrast, texture fidelity and structural preservation (Fig. 7c). This case illustrates InfEngine’s capacity for autonomous methodology discovery and adaptive workflow synthesis. Through closed-loop evolution integrating solution generation, automated evaluation and iterative refinement, the system learned to tailor pipelines to both data characteristics and performance objectives. Such capa- bilities hold transformative potential for multimodal imaging, remote sensing and computational photography, where optimal algorithm selection is inherently instance dependent. 3 Discussion Infrared radiation computing is gated by the manual effort of generating executable computational workflows. While LLMs have unlocked new forms of automation, existing paradigms fail to provide the reusable, reliable, scientifically grounded and optimized intelligence needed for complex domain-specific computational challenges. We introduce InfEngine, an intelligent computational engine that fundamentally reimagines this process. By orchestrating a collaborative network of specialized agents for analysis, solving, evaluation and evolution, InfEngine embodies a new paradigm in computational science: the transition from human-driven orchestration of passive tools to collaboration with an autonomous computational partner. Extensive evaluation on InfBench demonstrates that InfEngine significantly outperforms state-of-the-art methods. By generating well-structured, reusable code rather than one-off outputs, InfEngine effectively encapsulates and perpetuates scientific and engineering expertise, turning ad-hoc computational experiments into shareable, extensible research assets. While InfEngine advances toward a new paradigm for autonomous scientific computing, several limitations highlight clear pathways for future research and devel- opment. First, the scope of InfTools, while curated for breadth, is necessarily limited compared to the vast, often proprietary toolchains of real-world scientific and engi- neering practice. A critical next step is to demonstrate how this framework enables domain experts to encapsulate their own specialized tools using the provided interface standard, thereby orchestrating previously isolated capabilities. Second, our validation is currently centered on infrared radiation computing. Extending the benchmark and evaluating the core architecture’s efficacy in adjacent fields (e.g., computational chem- istry, materials informatics) is a vital direction to prove its generalizability. Finally, the evolutionary process can be computationally intensive. Future work will explore more efficient search strategies to reduce the optimization cost. Addressing these lim- itations will transition InfEngine from a powerful prototype into a robust, scalable engine for automated scientific discovery. Looking forward, the architectural principles of InfEngine point toward an even more transformative future: the evolution of intelligent computational engine into intelligent computational platform. Such a platform would aggregate and orchestrate 15 domain-specific tools, both from curated public repositories and encapsulated private libraries across institutions, through a unified interface standard. Researchers could pose complex problems to this platform, which would then synthesize verified, opti- mized solver tailored to their specific computational environment and resources. The user would receive and execute this portable code locally, seamlessly bridging the platform’s intelligence with private data and hardware. This vision of a federated, tool-agnostic platform transcends individual scientific domains, integrating diverse computational capabilities into a cohesive ecosystem for discovery. This paradigm shift, from isolated tools to intelligent platforms, has the potential to fundamentally recalibrate the scientific research cycle. By dramatically accelerating the translation of conceptual ideas into executable, validated computational proce- dures, it augments scientific creativity and productivity. The platform democratizes access to advanced computational methods, liberating researchers from routine imple- mentation burdens and refocusing human intellect on high-level problem formulation, interpretative reasoning, and strategic decision-making—the quintessential elements of breakthrough. We envision a future where such collaborative intelligence becomes a ubiquitous pillar of the scientific method, forming a symbiotic partnership between human intuition and machine execution to accelerate discovery across disciplines. 4 Method 4.1 Method Overview Our work introduces a new paradigm for autonomous scientific computing in the infrared domain, realized through a multi-agent architecture that translates user prob- lems into verified, optimized and deployable code solutions. As illustrated in Fig. 1, our work is built upon three synergistic and foundational pillars. First, InfTools (Fig. 1f) provides the essential computational primitives. This curated suite of 270 domain-specific tools, encapsulated in a standardized format for unified description and invocation (Fig. 1g), constitutes the executable knowledge base that grounds InfEngine in the infrared radiation computing domain. Second, InfBench establishes the rigorous evaluation ground. Comprising 200 well-defined tasks across assistant and optimization types, this benchmark supplies the diverse and challenging scenarios necessary to validate the autonomous capabilities of InfEngine, ensuring its robustness and generality. Third, the core innovation is InfEngine itself (Fig. 1e), the intelligent computational engine proposed in this work. Users inter- act with InfEngine as a computational partner, posing complex problems in natural language. The system orchestrates a collaborative network of specialized agents to analyze, plan, solve, evaluate, and iteratively optimize the problem by dynamically integrating tools from both private tools and public libraries (ref. Fig. 1h). Critically, its final output is not a transient answer but a production-ready, reusable solver code delivered to the user. This addresses a key limitation of the tool-calling paradigm, which typically yields only specific, non-reusable outputs. Our approach provides a generalizable and executable solution procedure that encapsulates the entire solved workflow. 16 In summary, the proposed InfEngine provides a unified solution to the diverse computational challenges across the infrared radiation computing pipeline, as depicted in Fig. 1b. It automates the process from problem description to the generation of validated and optimized code, thereby powering the wide range of applications in domains shown in Fig. 1a. 4.2 InfTools The creation of a comprehensive, machine-executable knowledge base is foundational to InfEngine’s code generation paradigm. We present InfTools, a systematically curated collection of 270 interoperable tools for infrared radiation computing. To our knowledge, this represents the first large-scale assembly of computational resources specifically designed for LLM-driven automation in this domain. While broader col- lections exist for other sciences (e.g., SciToolAgent’s [31] 500 tools for biology and chemistry, ChemCrow [16] and ChatMOF [17] operate with 18 and 4 tools respectively for chemical problems), InfTools is distinguished by its exclusive domain focus and its design for seamless integration into generated code, contrasting with frameworks built for rigid tool invocation. Tool Collection and Curation. Adhering to principles of reproducibility and open science, we sourced tools exclusively from public repositories (primarily GitHub), using targeted queries (“radiative transfer”, “infrared spectrum analysis”, etc.). Can- didate codebases underwent stringent filtering to exclude projects with incomplete implementations, missing trained models, or obsolete dependencies, ensuring a robust foundation. Standardized Tool Encapsulation. Each tool was encapsulated using a rigor- ous, consistent schema capturing: name, description, input/output specification (formatted as “type - explanation”), usage examples, dependencies, source link, build command (a shell script to reconstruct the runnable package from source), and user metadata (limitations, related papers). Crucially, our schema supports rich output types, including strings, NumPy arrays, and class instances, which overcomes a common restriction in tool-calling frameworks that only permit hashable types. Encapsulation employed a tiered strategy based on complexity. For simple scripts, an LLM-assisted extraction process efficiently isolated core logic. For complex, multi- file projects, manual refactoring was necessary to produce clean, modular Python interfaces. This process transformed disparate codebases into a unified, callable library. Validation and Quality Assurance. Each encapsulated tool was validated against original functionality through a battery of test cases with known expected outputs. Discrepancies triggered iterative debugging until computational fidelity was guaranteed. This labor-intensive process, requiring approximately five person- months of expert effort, underscores the significant investment needed to create production-ready, trustworthy resources for AI-driven science. The resulting InfTools suite provides a reliable, scalable substrate that enables InfEngine to reason over and compose complex infrared radiation computing workflows. 17 4.3 InfBench To rigorously evaluate InfEngine’s capabilities, we constructed InfBench, a domain- specific benchmark with a key innovation in its dual problem taxonomy. This taxonomy differentiates between two core task types central to our study: assistant- type tasks, which require correct, one-pass solutions, and optimization-type tasks, which demand iterative refinement to meet user-specified objectives. In total, Inf- Bench comprises 200 distinct test tasks, split into 165 assistant-type tasks and 35 optimization-type tasks. This tailored design directly addresses a critical gap in exist- ing benchmark evaluations such as GAIA [32], which overwhelmingly prioritize the assessment of assistant-style capabilities while largely neglecting the optimization competencies essential for advanced scientific computing scenarios. Each task in InfBench is a structured quadruplet: (i) a natural language ques- tion describing the computational problem; (i) a solve(tools, **kwargs) function that provides a reference solver, where tools is a dictionary of instantiated tool objects accessible during execution, and kwargs are keyword arguments represent- ing the problem’s default input parameters; (i) a candidate tool list enumerating all tools from the InfTools repository that are potentially applicable, which serves as the basis for evaluating an agent’s tool selection accuracy; and (iv) a standard- ized evaluate(result, **kwargs) function for solver assessment. For assistant-type tasks, evaluate returns a binary score (1 for success, 0 for failure), typically imple- mented via assertions. For optimization-type tasks, it returns a normalized quality score (higher values indicate better solutions), scaled to concentrate near 1 for con- sistent cross-task comparison. The evaluate function may itself call upon tools from InfTools, enabling complex, domain-aware validation. InfBench was constructed entirely through manual curation by domain experts to ensure the high standards of quality, correctness, and relevance. For each task, experts performed the following steps: First, they formulated a natural language question that captures a realistic computational challenge related to infrared radiation computing. Second, they manually implemented the reference solve function, ensuring it correctly utilizes the appropriate tools from InfTools to produce a valid solution. Third, they curated the candidate tool list, carefully selecting tools that are both relevant and plausible for solving the given problem. Fourth, they authored the evaluate function, embedding precise success criteria for assistant-type tasks or designing robust scoring rubrics for optimization-type tasks. This rigorous, hands-on process guaranteed that every benchmark task is well-specified, executable and grounded in authentic domain expertise. Constructing InfBench required a substantial investment of expert effort, with approximately 1.5 hours devoted to the manual creation and validation of each task. This deliberate approach prioritizes benchmark reliability and fidelity over scale, resulting in a high-quality evaluation framework. The resulting benchmark, with its explicit tool lists and standardized dual-mode evaluation, enables precise measurement of an AI system’s ability to select appropriate tools, generate functionally correct code, and optimize solutions against quantifiable goals, providing the comprehensive framework needed to validate scientific computing agents. 18 4.4 InfEngine The InfEngine materializes the two core capabilities outlined in the introduction: self-verification and self-optimization. As shown in Fig. 1e, it is orchestrated by a multi-agent architecture in which specialized agents collaborate to transform a user’s natural-language problem into verified and optimized code. The workflow begins with a Problem Analyzing Agent that classifies the query and retrieves relevant tools. For an assistant-type task, a Problem Solving Agent and an Evaluator Gener- ation Agent work in tandem to achieve self-verification, producing executable code that is jointly debugged against a context-aware evaluation script. For an optimiza- tion problem, the verified solution is passed to a Code Evolution Agent to perform self-optimization, iteratively refining the code against the auto-generated evaluator. The final output is a standalone, packaged solution with all dependencies. 4.4.1 Problem Analyzing Agent The Problem Analyzing Agent initiates the workflow by interpreting the natural-language problem and structuring it into a well-defined specification. Its core task is to formalize an ambiguous user query into a clear specification comprising three key components: the formal task description T, the optimization goal G, and a reference answer A ref . This separation is crucial: T defines what the solver must do, G provides the metric for how well it should perform, and A ref serves as a verification standard. Crucially, isolating A ref prevents potential cheating by ensuring it is used only for final validation and not prematurely revealed during the solution process. Formally, the agent maps a natural-language query q to a structured specification tuple (T,G,A ref ) and a set of relevant tools T solve : A ana : q 7→ (T,G,A ref ), T solve . The agent first classifies q into a task type τ ∈assist, opt using an LLM with a classification prompt p cls : τ = LLM(q;p cls ). For assistant-type tasks (τ = assist), the specification is defined directly from the original query: T = q, G = ∅, A ref = ∅. For optimization-type tasks (τ = opt), the agent parses q into five structured elements using a formalization prompt p fm : I in ,I out ,I inst ,g raw ,a gt = LLM(q;p fm ), where I in denotes the input description, I out the output format, I inst the step-by-step instructions, g raw the explicit optimization goal, and a gt the ground-truth answer. These elements are then programmatically synthesized into the final three-component specification: T = “Inputs: I in Output Format: I out Instructions: I inst ”, G = g raw , A ref = a gt . 19 This decompose-then-recompose approach proves more reliable than direct task generation, as it ensures each component is explicitly defined. Concurrently, the agent retrieves a relevant set of candidate tools from the InfTools repository using a RAG strategy. The query q is encoded into a dense vector e q ∈ R 768 using the all-mpnet-base-v2 sentence-transformer model: e q = Encoder(q). For each tool description d j in the database with pre-computed embedding d j , the similarity score is computed as the cosine similarity: s j = cos(e q , d j ). The top-k tools with the highest scores are retrieved to form the candidate set: T solve = top-k j∈[1,M] s j , where M is the total number of tools. 4.4.2 Problem Solving Agent The Problem Solving Agent translates the formalized task description T into exe- cutable code through an iterative process of planning, generation, execution and validation. Formally, the agent maps the task and retrieved tools to an executable code: A sol : (T,T solve )7→ c code . The process begins with a planning phase, where the agent decomposes T into a structured plan π using a planning prompt p plan : π = LLM(T,T solve ;p plan ), where the plan π is a JSON structure specifying sub-tasks, required tools, Python packages, and a rationale for the decomposition. Using a predefined code template τ tmpl , the agent then generates the initial solution code by instantiating the plan within the template with a generation prompt p gen : c 0 = LLM(T,T solve ,π,τ tmpl ;p gen ). The generated code is executed in a strictly controlled Python environment. Let the execution function be Exec(·). The result and any error are obtained as: r i , ε i = Exec(c i ). 20 If an error occurs (ε i ̸= ∅), a debugging step is invoked to produce a corrected version using a debugging prompt p dbg : c i+1 = LLM(T,T solve ,c i ,ε i ;p dbg ). This execution-debugging loop repeats until either (1) the code runs successfully (ε i = ∅), or (2) a maximum debugging iteration limit is reached. If the debugging limit is reached without producing error-free code, the entire process reverts to the planning phase to generate a fundamentally new solution strategy. Upon successful execution, the result r res is validated by an evaluator E generated by the Evaluator Generation Agent. The validation yields a score s that quantifies correctness or quality: s = E(r res ,A ref ). For assistant-type tasks, the score is binary, s ∈ 0, 1; for optimization-type tasks, it is a normalized continuous value, s ∈ [0, 1]. If the above validation process meets failure, the entire cycle is re-initiated unless a maximum iteration limit is reached. 4.4.3 Evaluator Generation Agent The Evaluator Generation Agent produces a robust evaluation function that enables self-verification. Formally, it constructs an evaluator E from the problem specification (T,G,A ref ), the available evaluation-related tools T eval , the candidate solution c code , and its execution result r res : A eval : (T,G,A ref ,T eval ,c code ,r res )7→ E. For optimization-type tasks, the agent first employs a planner to decompose the validation objective into manageable sub-tasks. Using a planning prompt p plan_eval , it produces a structured validation plan π eval : π eval = LLM(T,G,A ref ,T eval ,c code ;p plan_eval ). This plan is then instantiated into executable evaluator code with a generation prompt p gen_eval : E init = LLM(T,G,A ref ,T solve ,T eval ,c code ,π eval ;p gen_eval ). For assistant-type tasks, whose verification logic is typically simpler, the planning phase is omitted, and the evaluator is generated directly from the output format using a dedicated prompt p gen_eval_assist : E init = LLM(T,T solve ,T eval ,c code ;p gen_eval_assist ). A critical innovation is the joint solver-evaluator debugging mechanism. If the exe- cution of E init raises an error ε E while evaluating the current solver c code , a dedicated referee module performs a dual diagnostic to isolate the root cause. The referee deter- mines whether the error originates from the solver’s implementation, the evaluator’s rule specification, or an ill-defined interaction between them. Guided by a carefully 21 designed prompt p ref , the referee produces corrected versions of both the solution code and the evaluator: (c ′ code ,E ′ ) = LLM(T,c code ,r res ,T solve ,T eval ,E init ,ε E ;p ref ). Throughout this correction, integrity constraints are applied to prevent spurious co- optimization, enforcing that modifications preserve the solver’s generalizability and the evaluator’s fidelity to the original problem constraints. The process iterates until the evaluator executes successfully or maximum iteration limit is reached. This iter- ative debugging process helps to improve the solver’s functional correctness and scientific plausibility. 4.4.4 Code Evolution Agent The Code Evolution Agent introduces the self-optimization capability by autonomously refining solution codes through an evolutionary process. Formally, the agent evolves an initial code c over N generations, using the auto-generated evaluator E as a fitness function, to produce an optimized solution: A evol : (c,E,N)7→ c ∗ . The fitness of a code individual c is defined as the normalized score returned by the evaluator on its execution result: f(c) = E(Exec(c),A ref ). At each generation t, the agent maintains a population P t whose size may vary during the evolutionary cycle. Initially, the population size is 1. Let c (t) r denote the individual with rank r in generation t, where individuals are sorted by fitness value. Rank-based selection probabilities are computed to favor higher-ranked individuals while maintaining diversity: P(c (t) r ) = 1/(r +|P t |) P |P t | i=1 1/(i +|P t |) , where r ∈1,...,|P t | denotes the rank of the individual (with rank 1 for the highest fitness). Selected parents undergo variation through a suite of genetically inspired opera- tors. Each operator works by prompting the LLM to perform strategic reasoning that produces both an algorithmic description and its implementation in a single step. The LLM generates a blueprint, a high-level description of the algorithm’s strategy, and instantiates this blueprint into executable code, guided by the system’s structural template. Crossover operators (E1 and E2) synthesize novel algorithms by recombining multiple parent solutions. Letc parents ⊂ P t denote the set of parent code individuals 22 selected from the current population. Each prompt instructs the LLM to first articu- late the core algorithmic idea (or, for E2, to identify a common backbone idea), and then to implement it. The output is a unified response containing both the strategic description and the runnable code: (description,c child ) = LLM(T,T solve ,c parents ,τ tmpl ;p cross ). Mutation operators (M1, M2, M3) generate variants from a single parent, each targeting a different level of modification. Let c parent ∈ P t denote the parent code individual selected from the current population for mutation. The prompts similarly require the LLM to first describe the modified strategy (e.g., architectural change, tool reconfiguration, or parameter tuning) and then produce the corresponding code. This single-step generation guarantees that the strategic blueprint is faithfully translated into a syntactically correct solution: (description,c mut ) = LLM(T,T solve ,c parent ,τ tmpl ;p mut ). All operators thus operate at the strategic level, using the algorithmic description as a blueprint for immediate code generation. The output code is structured according to the predefined template τ tmpl , ensuring interface compatibility. After evaluating the fitness of all offspring, the population is managed to preserve quality and diversity. Invalid individuals with undefined fitness are removed. Duplicate solutions with identical fitness values are deduplicated. Finally, elitist selection retains at most m individuals with the highest fitness to form the next generation, ensuring the population size does not exceed the predefined limit. This cycle of selection, variation, evaluation and population management repeats for N generations. The algorithm converges by returning the highest-fitness individual from the final population: c ∗ = arg max c∈P N f(c). Through this evolutionary process, the system autonomously discovers and opti- mizes computational solutions against a machine-synthesized objective, closing the loop from informal problem description to high-performance code artifact. 4.4.5 Project Construction Upon completing the core multi-agent workflow, InfEngine can further package the validated solution into a directly deployable and reusable software module. The pro- cess begins with a dependency analysis of the final solution code to identify all required tools from the InfTools repository. The system then copies these tools along with their associated resource files into a structured project directory. Next, it aggregates depen- dency specifications from all involved tools to generate comprehensive environment configuration files, ensuring the solution can be reliably reproduced across different computing environments. The validated solve function is then packaged as an instal- lable Python module. Through automated code restructuring, appropriate metadata, API documentation and entry points are added. 23 Through this project construction process, InfEngine yields not just executable code but a reusable artifact: each packaged solve function constitutes a new, stand- alone composite tool. This artifact embodies a dual pathway to reusability. First, from the user’s perspective, the delivered solver is not merely a terminal answer but a modi- fiable and integrable software component. Users can directly deploy it, inspect its logic, adapt it to new inputs, or embed it within their own projects. Second, from the sys- tem’s perspective, these synthesized solvers can themselves be formalized and added back to the computational tool repository. This creates a virtuous cycle: InfEngine not only consumes a foundational set of tools but also produces higher-level, task-specific tools, progressively enriching its own capabilities and reducing the complexity of solv- ing future, related problems. This self-enhancing mechanism transforms the paradigm from a static toolbox to a dynamic, learning ecosystem that continuously expands the frontier of automated computational science. 5 Acknowledgements This work was supported by the Strategic Priority Research Program of Chinese Academy of Sciences (Grant No. XDA0480200) and the National Natural Science Foundations of China (Grant No.62306310). 6 Competing Interests The authors declare no competing interests. 7 Data Availability The infrared radiation computing benchmark (InfBench) dataset supporting the find- ings of this study is openly available in the repository: https://github.com/kding1225/ infengine. 8 Code Availability The InfEngine framework and its associated toolset are publicly available as open- source software in the repository at https://github.com/kding1225/infengine. References [1] Yin, J., Tan, Z., Hong, H., Wu, J., Yuan, H., Liu, Y., Chen, C., Tan, C., Yao, F., Li, T., et al.: Ultrafast and highly sensitive infrared photodetectors based on two-dimensional oxyselenide crystals. Nature communications 9(1), 3311 (2018) [2] Cheng, Z., Zhao, T., Zeng, H.: 2d material-based photodetectors for infrared imaging. Small Science 2(1), 2100051 (2022) [3] Alberts, M., Laino, T., Vaucher, A.C.: Leveraging infrared spectroscopy for automated structure elucidation. Commun. Chem. 7, 268 (2024) 24 [4] Ottomano, F., Li, Y., Ganose, A.M.: NMIRacle: Multi-modal Generative Molec- ular Elucidation from IR and NMR Spectra. Preprint at https://arxiv.org/abs/ 2512.19733 (2025) [5] Clough, S.A., Shephard, M.W., Mlawer, E.J., Delamere, J.S., Iacono, M.J., Cady-Pereira, K., Boukabara, S., Brown, P.D.: Atmospheric radiative transfer modeling: a summary of the aer codes. Journal of Quantitative Spectroscopy and Radiative Transfer 91(2), 233–244 (2005) [6] Wilson, A.N., Gupta, K.A., Koduru, B.H., Kumar, A., Jha, A., Cenkeramaddi, L.R.: Recent advances in thermal imaging and its applications using machine learning: A review. IEEE Sensors Journal 23(4), 3395–3407 (2023) [7] Leroy, V., Nollet, Y., Schunke, S., Misk, N., Marton, N., Emde, C., Govaerts, Y.: Eradiate Radiative Transfer Model. https://github.com/eradiate/eradiate. Software available at https://github.com/eradiate/eradiate (2025) [8] Emde, C., Buras-Schnell, R., Kylling, A., Mayer, B., Gasteiger, J., Hamann, U., Kylling, J., Richter, B., Pause, C., Dowling, T., et al.: The libradtran software package for radiative transfer calculations (version 2.0. 1). Geoscientific Model Development 9(5), 1647–1672 (2016) [9] Du, S., Stechmann, S.N.: Fast, low-memory numerical methods for radiative transfer via hp-adaptive mesh refinement. Journal of Computational Physics 480, 112021 (2023) [10] Marzano, F.S.: In: Njoku, E.G. (ed.) Radiative Transfer, Theory, p. 624–634. Springer, New York, NY (2014) [11] Brown, T., Mann, B., Ryder, N., Subbiah, M., Kaplan, J.D., Dhariwal, P., Nee- lakantan, A., Shyam, P., Sastry, G., Askell, A., Agarwal, S., Herbert-Voss, A., Krueger, G., Henighan, T., Child, R., Ramesh, A., Ziegler, D., Wu, J., Winter, C., Hesse, C., Chen, M., Sigler, E., Litwin, M., Gray, S., Chess, B., Clark, J., Berner, C., McCandlish, S., Radford, A., Sutskever, I., Amodei, D.: Language models are few-shot learners. In: Advances in Neural Information Processing Systems, vol. 33, p. 1877–1901 (2020) [12] Qu, C., Dai, S., Wei, X., Cai, H., Wang, S., Yin, D., Xu, J., Wen, J.: Tool learning with large language models: a survey. Frontiers Comput. Sci. 19(8), 198343 (2025) [13] Lu, P., Chen, B., Liu, S., Thapa, R., Boen, J., Zou, J.: Octotools: An agentic framework with extensible tools for complex reasoning. In: ICLR 2025 Workshop on Foundation Models in the Wild (2025) [14] Ma, Y., Gou, Z., Hao, J., Xu, R., Wang, S., Pan, L., Yang, Y., Cao, Y., Sun, 25 A.: SciAgent: Tool-augmented language models for scientific reasoning. In: Pro- ceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, Miami, Florida, USA, p. 15701–15736 (2024) [15] Lyu, B., Cao, Y., Watson-Parris, D., Bergen, L., Berg-Kirkpatrick, T., Yu, R.: Adapting while learning: Grounding LLMs for scientific problems with tool usage adaptation. In: Forty-second International Conference on Machine Learning (2025) [16] Bran, A.M., Cox, S., Schilter, O., Baldassari, C., White, A.D., Schwaller, P.: Augmenting large language models with chemistry tools. Nat. Mac. Intell. 6(5), 525–535 (2024) [17] Kang, Y., Kim, J.: Chatmof: An artificial intelligence system for predicting and generating metal-organic frameworks using large language models. Nat. Commun. 15, 4705 (2024) [18] Jin, Q., Yang, Y., Chen, Q., Lu, Z.: Genegpt: augmenting large language models with domain tools for improved access to biomedical information. Bioinformatics 40(2) (2024) [19] Liu, J., Zhu, R., Xu, J., Ding, K., Zhang, X.-Y., Meng, G., Liu, C.-L.: PDE- Agent: A toolchain-augmented multi-agent framework for PDE solving. Preprint at https://arxiv.org/abs/2512.16214 (2025) [20] Huang, D., Bu, Q., Qing, Y., Cui, H.: CodeCoT: Tackling Code Syntax Errors in CoT Reasoning for Code Generation. Preprint at https://arxiv.org/abs/2308. 08784 (2024) [21] Romera-Paredes, B., Barekatain, M., Novikov, A., Balog, M., Kumar, M.P., Dupont, E., Ruiz, F.J.R., Ellenberg, J.S., Wang, P., Fawzi, O., Kohli, P., Fawzi, A.: Mathematical discoveries from program search with large language models. Nat. 625(7995), 468–475 (2024) [22] Liu, F., Tong, X., Yuan, M., Lin, X., Luo, F., Wang, Z., Lu, Z., Zhang, Q.: Evolution of heuristics: towards efficient automatic algorithm design using large language model. In: Proceedings of the 41st International Conference on Machine Learning (2024) [23] Ding, K., Wang, Y., Xiang, S.: Evovlma: Evolutionary vision-language model adaptation. In: Proceedings of the 33rd ACM International Conference on Multimedia, p. 4619–4628 (2025) [24] Wang, H., Zeng, L.: Automated Algorithmic Discovery for Scientific Computing through LLM-Guided Evolutionary Search: A Case Study in Gravitational-Wave Detection. Preprint at https://arxiv.org/abs/2508.03661 (2025) 26 [25] Chen, X., Lin, M., Schärli, N., Zhou, D.: Teaching large language models to self- debug. In: The Twelfth International Conference on Learning Representations (2024) [26] Shinn, N., Cassano, F., Gopinath, A., Narasimhan, K., Yao, S.: Reflexion: Lan- guage agents with verbal reinforcement learning. Advances in Neural Information Processing Systems 36, 8634–8652 (2023) [27] Islam, M.A., Ali, M.E., Parvez, M.R.: Mapcoder: Multi-agent code generation for competitive problem solving. In: Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics, p. 4912–4944 (2024) [28] Stienstra, C.M., Hebert, L., Thomas, P., Haack, A., Guo, J., Hopkins, W.S.: Graphormer-ir: Graph transformers predict experimental ir spectra using highly specialized attention. Journal of chemical information and modeling 64(12), 4613–4629 (2024) [29] Bhatia, N., Rinke, P., Krejčí, O.: Leveraging active learning-enhanced machine- learned interatomic potential for efficient infrared spectra prediction. npj Computational Materials 11(1), 324 (2025) [30] Bhatia, N., Krejci, O., Botti, S., Rinke, P., Marques, M.A.L.: MACE4IR: A foun- dation model for molecular infrared spectroscopy. Preprint at https://arxiv.org/ abs/2508.19118 (2025) [31] Ding, K., Yu, J., Huang, J., Yang, Y., Zhang, Q., Chen, H.: Scitoolagent: a knowledge-graph-driven scientific agent for multitool integration. Nat. Comput. Sci. (2025) [32] Mialon, G., Fourrier, C., Swift, C., Wolf, T., LeCun, Y., Scialom, T.: GAIA: a benchmark for General AI Assistants. Preprint at https://arxiv.org/abs/2311. 12983 (2023) 27 28 Appendix A Evaluation Method Performance assessment relied on a suite of metrics derived from human-defined evalu- ation code. This code encodes task-specific success criteria explicitly. It validates both functional correctness, e.g. output format and file existence, and scientific plausibility, including physically reasonable value ranges and adherence to domain constraints. For assistant-type tasks, the evaluation function validates solution outputs and returns a binary score: 0 for incorrect results and 1 for correct ones. For optimization-type tasks, it computes a floating-point score to quantify solution quality. Higher values indicate better performance. Reported metrics capture different dimensions of solution quality. For assistant- type problems, we report three metrics. First, Pass@1 accuracy measures syntactic executability by checking if generated code runs without errors. Second, Tool Acc. evaluates tool selection accuracy. Third, Accuracy serves as the primary metric. It is calculated by running human-defined evaluation code on solution outputs, distinguishing merely executable code from functionally correct solutions. For optimization-type problems, each task is split into training and test subsets. This design evaluates both optimization efficacy and generalization ability. We report six metrics: Pass@1, Tool Acc., Train Score, Test Score, Train Rank, and Test Rank. Train Score and Test Score are averages of scores from human-defined eval- uation code executed on the respective subsets. Train Score quantifies how well the solution optimizes the objective using given data. Test Score specifically measures generalization to unseen inputs within the same problem class, assessing robustness. Train Rank and Test Rank are normalized ranking scores. They mitigate scale dis- crepancies across different tasks, making them the primary metrics for evaluating optimization performance. Aggregated metrics, Overall Pass@1, Overall Score, and Overall Tool Acc., provide a holistic summary across all tasks. Overall Score is a weighted mean of Accuracy, Train Rank and Test Rank. Detailed formulations of all metrics are provided below. We conducted three independent trials per task. Results are reported as means with corresponding standard deviations. Notation. Let N a and N o denote the number of assistant-type and optimization- type tasks respectively. For task i, T pred i represents the set of tools predicted by the solution code, T ref i the reference tool set, o i the generated outputs, and o ref i the reference outputs. For optimization-type tasks with training-test splits, M train j and M test j denote the number of training and test instances for problem j, with o train jk and y train jk representing outputs and targets for training instance k, and o test jl and y test jl for test instance l. Evaluation functions f a i and f o j compute task-specific quality scores, normalized around 1. Assistant Task Metrics. For assistant-type problems, three metrics are reported. Pass@1 accuracy (A a pass ) validates solution executability, where I execution_success (i) = 29 1 if the solution code executes without critical errors and 0 otherwise: A a pass = 1 N a N a X i=1 I execution_success (i).(A1) Tool selection accuracy (A a tool ) measures tool identification accuracy through intersection-over-prediction: A a tool = 1 N a N a X i=1 |T pred i ∩ T ref i | |T pred i | .(A2) Solution output accuracy (A a accuracy ) quantifies output correctness through task- specific evaluation: A a accuracy = 1 N a N a X i=1 f a i (o i , o ref i ).(A3) Optimization Task Metrics: For performance optimization problems with training-test splits, six metrics are reported. Pass@1 accuracy (A o pass ) assesses solution executability: A o pass = 1 N o N o X j=1 I execution_success (j).(A4) Tool selection accuracy (A o tool ) evaluates tool identification: A o tool = 1 N o N o X j=1 |T pred j ∩ T ref j | |T pred j | .(A5) Training score (S o train ) measures optimization performance on training data: S o train = 1 N o N o X j=1 1 M train j M train j X k=1 f o j (o train jk , y train jk ).(A6) Test accuracy (S o test ) quantifies generalization capability on unseen instances: S o test = 1 N o N o X j=1 1 M test j M test j X l=1 f o j (o test jl , y test jl ).(A7) Besides, we also compute the averaged ranking score of the training score on each case: R o train = 1 N o N o X j=1 Rank 1 M train j M train j X k=1 f o j (o train jk , y train jk ) ,(A8) 30 where Rank() denote the function computes the normalized rank, which is defined as: Rank(s) = K− r(s) K− 1 .(A9) Here r(s) is the rank of score s among all K compared methods, with rank 1 assigned to the best (highest) score and rank K to the worst (lowest) score. When multiple methods achieve identical scores, they are assigned the average rank of their tied positions. The normalized rank Rank(s) then maps the raw rank r(s) to the range [0, 1], where 1 represents the best performance and 0 represents the worst performance among all K methods. The averaged ranking score of the test score is defined similarly: R o test = 1 N o N o X j=1 1 M test j Rank M test j X l=1 f o j (o test jl .y test jl ) .(A10) Composite Performance Scores. The evaluation framework employs distinct metric compositions for assistant and optimization-type tasks while providing cross- task averages for comparability. The overall solution quality score (S quality ) integrates performance across task types: S quality = 0.5· A a accuracy + 0.25· R o train + 0.25· R o test ,(A11) where A a accuracy represents assistant-type task output accuracy, R o train denotes the normalized ranking score of the training score, and R o test indicates the normalized ranking score of the test score. The Overall Pass@1 rate across two task types is defined as: A pass = 0.5· A a pass + 0.5· A o pass ,(A12) where A a pass and A o pass denote the Pass@1 rate on assistant-type and optimization-type tasks, respectively. The overall tool selection performance is evaluated by: A tool = 0.5· A a tool + 0.5· A o tool ,(A13) where A a tool and A o tool denote the tool selection accuracy on assistant-type and optimization-type tasks, respectively. Prompt Template for Parameter Parsing. During evaluation of optimization- type tasks, proper parameter initialization for the solve function is essential for exe- cuting solution code on test subset. Manual parameter specification proves impractical at scale, prompting the adoption of an automated parsing approach using DeepSeek- V3.2. This method employs the structured prompt shown below, which accepts test question descriptions and solution code as inputs, then extracts a JSON-formatted 31 keyword parameter dictionary (kwargs). The parsed parameters enable automated test execution via solve(tools, **kwargs), facilitating systematic evaluation across diverse optimization problems without manual intervention. Here is a query question and a python code solving it. The optional arguments of this code should be determined based on the question. Help me extract the needed optional arguments. The query problem: question The python solution code: solution_code Return a python dictionary containing your extracted optional parameters. The keys are the optional parameter names in the code, the values should be set according to the question. Your result should be enclosed between```python and```. For example (do not directly copy): ```python "arg_name1": arg1_value, "arg_name2": arg2_value ``` Notice: * Do not give extra explaination * There should be only one line between```python and``` * Keys should match the optional argument names * Do not consider the positional arguments * If some optional argument values cannot be determined by the question directly, do not include them. For example, if the image_size parameter is not mentioned, do not set it by yourself. Prompt 1: Prompt for parameter parsing. Appendix B More Results Case 2. The solution code of case 2 is given in Code 1 and the generated evaluation code is given in Code 2. 1 # import Python packages 2 import numpy as np 3 import pandas as pd 4 import matplotlib.pyplot as plt 5 6 # define helper function1: load and process IR spectrum data 7 def load_and_process_spectrum(file_path , source_type="lammps"): 8 """ 9 Load IR spectrum data from file and process it. 10 11 Args: 12 file_path (str): Path to the spectrum file 13 source_type (str): Type of spectrum source - "lammps" or "ml" 14 15 Returns: 16 tuple: (frequencies , intensities) arrays 17 """ 18 if source_type == "lammps": 19 # Load LAMMPS spectrum CSV 20 df = pd.read_csv(file_path) 21 frequencies = df[’Frequency(cm^-1)’]. values 22 intensities = df[’Spectra ’]. values 23 else: # ml prediction 24 # Load ML predicted spectrum CSV 25 df = pd.read_csv(file_path) 26 frequencies = df[’Frequency ’]. values 27 intensities = df[’Intensity ’]. values 28 29 return frequencies , intensities 30 31 # define main solve function 32 def solve(tools , smiles="CCO", xyz_file_path="tasks/task120/mol.xyz", 33 charge =0.0, multiplicity =1.0, steps =500000 , box_dim =15.0, 34 temperature =300.0 , data_points =8339 , average =1): 35 """ 36 Compare IR spectrum from molecular dynamics simulation with ML prediction. 37 38 Args: 39 - tools (dict): Dictionary containing available tools 40 - smiles (str): SMILES string of the molecule (default: "CCO") 41 - xyz_file_path (str): Path to the 3D molecular structure file (default: "tasks/task120/mol.xyz") 42 - charge (float): Charge of the molecule (default: 0.0) 32 43 - multiplicity (float): Multiplicity of the molecule (default: 1.0) 44 - steps (int): Number of MD simulation steps (default: 500000) 45 - box_dim (float): Size of cubic simulation box in Angstroms (default: 15.0) 46 - temperature (float): Temperature in Kelvin for IR calculation (default: 300.0) 47 - data_points (int): Number of data points for IR analysis (default: 8339) 48 - average (int): Whether to use average parameters for ML prediction (default: 1) 49 50 Returns: 51 - str: Path to the saved visualization image comparing both IR spectra 52 """ 53 54 # Step 1: Generate LAMMPS simulation input files from SMILES string using EMC setup 55 emc_result = tools["EMC_Setup_Tool"]. execute(smiles=smiles , field="pcff") 56 setup_data_path = emc_result["setup_data_path"] 57 setup_params_path = emc_result["setup_params_path"] 58 59 # Step 2: Run LAMMPS molecular dynamics simulation to generate dipole moment time -series data 60 lammps_result = tools["LAMMPS_Simulation_Tool"]. execute( 61 setup_data_path=setup_data_path , 62 setup_params_path=setup_params_path , 63 steps=steps , 64 box_dim=box_dim 65 ) 66 dipole_path = lammps_result["dipole_path"] 67 68 # Step 3: Calculate IR spectrum from LAMMPS dipole moment data 69 lammps_ir_result = tools["LAMMPS_Dipole_IRSpectra_Tool"]. execute( 70 dipole_file_path=dipole_path , 71 temperature=temperature , 72 data_points=data_points 73 ) 74 lammps_spectrum_path = lammps_ir_result["ir_spectra_file"] 75 76 # Step 4: Predict IR spectrum from 3D molecular structure using machine learning models 77 ml_ir_result = tools["IRspectrum_Predictor_Use_3D_Structure_Tool"]. execute( 78 input_file_name=xyz_file_path , 79 charge=charge , 80 multiplicity=multiplicity , 81 average=average 82 ) 83 ml_spectrum_path = ml_ir_result["ir_spectrum_path"] 84 85 # Step 5: Load and process both IR spectra 86 # Load LAMMPS spectrum 87 lammps_freq , lammps_int = load_and_process_spectrum(lammps_spectrum_path , "lammps") 88 89 # Load ML predicted spectrum 90 ml_freq , ml_int = load_and_process_spectrum(ml_spectrum_path , "ml") 91 92 # Filter to 400 -4000 cm^-1 range 93 lammps_mask = (lammps_freq >= 400) & (lammps_freq <= 4000) 94 ml_mask = (ml_freq >= 400) & (ml_freq <= 4000) 95 96 lammps_freq_filtered = lammps_freq[lammps_mask] 97 lammps_int_filtered = lammps_int[lammps_mask] 98 99 ml_freq_filtered = ml_freq[ml_mask] 100 ml_int_filtered = ml_int[ml_mask] 101 102 # Normalize to maximum value of 1.0 103 if len(lammps_int_filtered) > 0: 104 lammps_int_normalized = lammps_int_filtered / np.max(lammps_int_filtered) 105 else: 106 lammps_int_normalized = np.array ([]) 107 108 if len(ml_int_filtered) > 0: 109 ml_int_normalized = ml_int_filtered / np.max(ml_int_filtered) 110 else: 111 ml_int_normalized = np.array ([]) 112 113 # Step 6: Create comparative visualization 114 plt.figure(figsize =(10, 6)) 115 116 if len(lammps_freq_filtered) > 0 and len(lammps_int_normalized) > 0: 117 plt.plot(lammps_freq_filtered , lammps_int_normalized , label=’MD Simulation ’, linewidth=2, alpha =0.8) 118 119 if len(ml_freq_filtered) > 0 and len(ml_int_normalized) > 0: 120 plt.plot(ml_freq_filtered , ml_int_normalized , label=’ML Prediction ’, linewidth=2, alpha =0.8, linestyle=’-- ’) 121 122 plt.xlabel(’Wavenumber (cm$^-1$)’, fontsize =12) 123 plt.ylabel(’Normalized Intensity ’, fontsize =12) 124 plt.title(’Comparison of IR Spectra: MD Simulation vs ML Prediction ’, fontsize =14) 125 plt.legend(fontsize =11) 126 plt.grid(True , alpha =0.3) 127 plt.xlim (400, 4000) 128 plt.ylim(0, 1.1) 129 130 # Save the visualization 131 output_image_path = "ir_spectra_comparison.png" 132 plt.tight_layout () 33 133 plt.savefig(output_image_path , dpi=300, bbox_inches=’tight’) 134 plt.close() 135 136 return output_image_path 137 Code 1: Case 2’s solution code. 1 def evaluate(result): 2 """ 3 Evaluate whether the solution result meets the problem requirements. 4 5 Args: 6 - result (str): Path to the visualization image comparing IR spectra 7 8 Returns: 9 - int: Return 1 if result is correct; otherwise , an error will be raised 10 """ 11 # IMPORTS 12 import os 13 import cv2 14 import numpy as np 15 import pandas as pd 16 17 # DATA PREPARATION 18 # Check if result is a valid file path 19 assert isinstance(result , str), f"Result must be a string file path , got type(result)" 20 assert os.path.exists(result), f"Image file does not exist: result" 21 22 # Read the image 23 img = cv2.imread(result) 24 assert img is not None , f"Failed to read image from path: result" 25 26 # VALIDATION LOGIC 27 # 1. Validate the returned image file 28 assert os.path.isfile(result), f"Result must be a file path , not a directory: result" 29 assert result.lower().endswith ((’.png’, ’.jpg’, ’.jpeg’, ’.tiff’, ’.bmp’)), \ 30 f"Result must be an image file , got: result" 31 32 # 2. Validate image content and properties 33 assert img.shape [0] > 0 and img.shape [1] > 0, "Image must have non -zero dimensions" 34 assert len(img.shape) == 3, "Image must be a 3-channel color image" 35 assert img.shape [2] == 3, "Image must have 3 color channels (BGR)" 36 37 # 3. Check that the image is not completely empty/black 38 img_mean = np.mean(img) 39 assert img_mean > 10, "Image appears to be mostly empty or black" 40 41 # 4. Check that input structure file exists 42 assert os.path.exists("tasks/task120/mol.xyz"), \ 43 "Input molecular structure file not found: tasks/task120/mol.xyz" 44 45 # 5. Validate the image filename matches expected pattern 46 # The solution returns "ir_spectra_comparison.png" by default 47 # But we accept any valid image filename 48 print(f"Successfully validated IR spectra comparison image: result") 49 50 return 1 51 Code 2: Case 2’s generated evaluation code. Case 3. The best solution codes at iteration 0, 3, 7 are given in Code 3, Code 4 and Code 5, respectively. 1 import numpy as np 2 3 # define main solve function 4 def solve( 5 tools , 6 spectra_path="tasks/task231/spectra_train.npy", 7 wavenumber_path="tasks/task231/wavenumber.npy", 8 formulas_path="tasks/task231/formulas_train.txt", 9 beam_size =10, 10 n_best =10, 11 min_length =5 12 ): 13 """ 14 Predict SMILES from IR spectra and molecular formulas using a trained NMT model. 15 16 Args: 34 17 - tools (dict): Dictionary containing available tools 18 - spectra_path (str): Path to the spectra npy file (rows=molecules , cols=wavenumbers) 19 - wavenumber_path (str): Path to the wavenumber npy file (1-d array) 20 - formulas_path (str): Path to the formulas txt file (one formula per line) 21 - beam_size (int): Beam size for beam search (default: 10) 22 - n_best (int): Number of best translations to output (default: 10) 23 - min_length (int): Minimum length of translation (default: 5) 24 25 Returns: 26 - list[str]: Paths to the predicted SMILES txt files 27 """ 28 29 # Step 1: Load the spectrum data , wavenumber data , and formulas data from the provided files. 30 # Tools needed: []. Packages needed: [numpy]. 31 spectra = np.load(spectra_path) # Shape: (n_molecules , n_wavenumbers) 32 wavenumbers = np.load(wavenumber_path) # Shape: (n_wavenumbers ,) 33 with open(formulas_path , ’r’) as f: 34 formulas = [line.strip() for line in f.readlines ()] 35 36 # Step 2: Process the loaded spectrum data and formulas data into the required format for the NMT_Formula_IRSpectrum_To_Smiles_Tool tool. 37 # Tools needed: []. Packages needed: [numpy]. 38 # Create spectrum files (n*2 arrays: wavenumber + spectrum value) 39 spectrum_files = [] 40 for i in range(len(formulas)): 41 spectrum_data = np.column_stack (( wavenumbers , spectra[i])) # Combine wavenumbers and spectrum values 42 spectrum_file = f"spectrum_i.npy" 43 np.save(spectrum_file , spectrum_data) 44 spectrum_files.append(spectrum_file) 45 46 # Step 3: Use the NMT_Formula_IRSpectrum_To_Smiles_Tool tool to predict SMILES from the formatted spectrum data and formulas. 47 # Tools needed: [NMT_Formula_IRSpectrum_To_Smiles_Tool ]. Packages needed: []. 48 execution = tools["NMT_Formula_IRSpectrum_To_Smiles_Tool"]. execute( 49 formulas=formulas , 50 spectrum_files=spectrum_files , 51 beam_size=beam_size , 52 n_best=n_best , 53 min_length=min_length 54 ) 55 56 return execution["output_files"] 57 Code 3: Case 3’s solution code at iteration 0. 1 import numpy as np 2 3 # define main solve function 4 def solve( 5 tools , 6 spectra_path="tasks/task231/spectra_train.npy", 7 wavenumber_path="tasks/task231/wavenumber.npy", 8 formulas_path="tasks/task231/formulas_train.txt", 9 beam_size =10, 10 n_best =10, 11 min_length =5 12 ): 13 """ 14 Predict SMILES from IR spectra using a trained NMT model that only requires spectrum (no formula). 15 16 Args: 17 - tools (dict): Dictionary containing available tools 18 - spectra_path (str): Path to the spectra npy file (rows=molecules , cols=wavenumbers) 19 - wavenumber_path (str): Path to the wavenumber npy file (1-d array) 20 - formulas_path (str): Path to the formulas txt file (one formula per line) - used here just for counting number of molecules 21 - beam_size (int): Beam size for beam search (default: 10) 22 - n_best (int): Number of best translations to output (default: 10) 23 - min_length (int): Minimum length of translation (default: 5) 24 25 Returns: 26 - list[str]: Paths to the predicted SMILES txt files 27 """ 28 29 # Step 1: Load the spectrum data and wavenumber data from the provided files. 30 # Tools needed: []. Packages needed: [numpy]. 31 spectra = np.load(spectra_path) # Shape: (n_molecules , n_wavenumbers) 32 wavenumbers = np.load(wavenumber_path) # Shape: (n_wavenumbers ,) 33 34 # We don’t actually need the formulas themselves , but we do need the count of molecules 35 with open(formulas_path , ’r’) as f: 36 formulas = [line.strip() for line in f.readlines ()] 37 38 # Ensure the number of spectra matches the number of formulas 39 assert len(spectra) == len(formulas), "Mismatch between number of spectra and formulas" 40 35 41 # Step 2: Process the loaded spectrum data into the required format for the NMT_IRSpectrum_To_Smiles_Tool tool. 42 # Tools needed: []. Packages needed: [numpy]. 43 # Create spectrum files (n*2 arrays: wavenumber + spectrum value) 44 spectrum_files = [] 45 for i in range(len(spectra)): 46 spectrum_data = np.column_stack (( wavenumbers , spectra[i])) # Combine wavenumbers and spectrum values 47 spectrum_file = f"spectrum_i.npy" 48 np.save(spectrum_file , spectrum_data) 49 spectrum_files.append(spectrum_file) 50 51 # Step 3: Use the NMT_IRSpectrum_To_Smiles_Tool tool to predict SMILES from the formatted spectrum data. 52 # This tool does not require formulas. 53 # Tools needed: [NMT_IRSpectrum_To_Smiles_Tool ]. Packages needed: []. 54 execution = tools[" NMT_IRSpectrum_To_Smiles_Tool "]. execute( 55 spectrum_files=spectrum_files , 56 beam_size=beam_size , 57 n_best=n_best , 58 min_length=min_length 59 ) 60 61 return execution [" output_files "] 62 Code 4: Case 3’s solution code at iteration 3. 1 import numpy as np 2 3 # define main solve function 4 def solve( 5 tools , 6 spectra_path="tasks/task231/spectra_train.npy", 7 wavenumber_path="tasks/task231/wavenumber.npy", 8 formulas_path="tasks/task231/formulas_train.txt", 9 beam_size =20, 10 n_best =20, 11 min_length =10 12 ): 13 """ 14 Predict SMILES from IR spectra using a trained NMT model that only requires spectrum (no formula). 15 16 Args: 17 - tools (dict): Dictionary containing available tools 18 - spectra_path (str): Path to the spectra npy file (rows=molecules , cols=wavenumbers) 19 - wavenumber_path (str): Path to the wavenumber npy file (1-d array) 20 - formulas_path (str): Path to the formulas txt file (one formula per line) - used here just for counting number of molecules 21 - beam_size (int): Increased beam size for beam search to explore more candidates (default: 20) 22 - n_best (int): Increased number of best translations to output for better diversity (default: 20) 23 - min_length (int): Increased minimum length of translation to avoid short predictions (default: 10) 24 25 Returns: 26 - list[str]: Paths to the predicted SMILES txt files 27 """ 28 29 # Step 1: Load the spectrum data and wavenumber data from the provided files. 30 # Tools needed: []. Packages needed: [numpy]. 31 spectra = np.load(spectra_path) # Shape: (n_molecules , n_wavenumbers) 32 wavenumbers = np.load(wavenumber_path) # Shape: (n_wavenumbers ,) 33 34 # We don’t actually need the formulas themselves , but we do need the count of molecules 35 with open(formulas_path , ’r’) as f: 36 formulas = [line.strip() for line in f.readlines ()] 37 38 # Ensure the number of spectra matches the number of formulas 39 assert len(spectra) == len(formulas), "Mismatch between number of spectra and formulas" 40 41 # Step 2: Process the loaded spectrum data into the required format for the NMT_IRSpectrum_To_Smiles_Tool tool. 42 # Tools needed: []. Packages needed: [numpy]. 43 # Create spectrum files (n*2 arrays: wavenumber + spectrum value) 44 spectrum_files = [] 45 for i in range(len(spectra)): 46 spectrum_data = np.column_stack (( wavenumbers , spectra[i])) # Combine wavenumbers and spectrum values 47 spectrum_file = f"spectrum_i.npy" 48 np.save(spectrum_file , spectrum_data) 49 spectrum_files.append(spectrum_file) 50 51 # Step 3: Use the NMT_IRSpectrum_To_Smiles_Tool tool to predict SMILES from the formatted spectrum data. 52 # This tool does not require formulas. 53 # Tools needed: [NMT_IRSpectrum_To_Smiles_Tool ]. Packages needed: []. 54 execution = tools[" NMT_IRSpectrum_To_Smiles_Tool "]. execute( 55 spectrum_files=spectrum_files , 56 beam_size=beam_size , 57 n_best=n_best , 58 min_length=min_length 59 ) 36 60 61 return execution [" output_files "] 62 Code 5: Case 3’s solution code at iteration 7. Case 4. The best solution codes at iteration 0, 2, 3, 9 are given in Code 6, Code 7, Code 8, Code 9, respectively. 1 # import Python packages 2 import os 3 4 # define main solve function 5 def solve(tools , rgb_image_paths: list = ["tasks/task212/vis_im1.jpg","tasks/task212/vis_im2.jpg", "tasks/ task212/vis_im3.jpg","tasks/task212/vis_im4.jpg","tasks/task212/vis_im5.jpg"], seed: int = 1234): 6 """ 7 Generate fake thermal images from RGB images using PearlGAN style transfer. 8 9 Args: 10 - tools (dict): Dictionary containing available tools 11 - rgb_image_paths (list[str]): Paths to the input RGB image files 12 - seed (int): Seed for random number generator 13 14 Returns: 15 - list[str]: Paths to the generated fake thermal images 16 """ 17 18 # Step 1: Generate fake thermal images from the five RGB images using an RGB -to -thermal translation tool 19 generated_paths = [] 20 21 for rgb_path in rgb_image_paths: 22 # Use PearlGAN tool to generate fake thermal image 23 execution = tools["PearlGAN_FLIR_RGB2T_Generation_Tool"]. execute( 24 input_image_path=rgb_path , 25 seed=seed 26 ) 27 generated_paths.append(execution["output_image_path"]) 28 29 # Step 2: Collect and return the paths of all generated thermal images as a list 30 return generated_paths 31 Code 6: Case 4’s solution code at iteration 0. 1 # import Python packages 2 import os 3 4 # define main solve function 5 def solve(tools , rgb_image_paths: list = ["tasks/task212/vis_im1.jpg", "tasks/task212/vis_im2.jpg", "tasks /task212/vis_im3.jpg", "tasks/task212/vis_im4.jpg", "tasks/task212/vis_im5.jpg"], seed: int = 1234): 6 """ 7 Generate fake thermal images from RGB images using FoalGAN style transfer. 8 9 This function translates RGB images to thermal -style images using the FoalGAN model 10 trained on FLIR dataset , which is specifically designed for thermal image generation 11 with feedback -based object appearance learning. 12 13 Args: 14 - tools (dict): Dictionary containing available tools 15 - rgb_image_paths (list[str]): Paths to the input RGB image files 16 - seed (int): Seed for random number generator for reproducible results 17 18 Returns: 19 - list[str]: Paths to the generated fake thermal images in PNG format 20 """ 21 22 # Validate that the required tool is available 23 if "FoalGAN_FLIR_RGB2T_Generation_Tool" not in tools: 24 raise ValueError("Required tool ’FoalGAN_FLIR_RGB2T_Generation_Tool ’ not available") 25 26 # Initialize list to store generated thermal image paths 27 generated_thermal_paths = [] 28 29 # Process each RGB image to generate corresponding thermal image 30 for rgb_path in rgb_image_paths: 31 # Check if input file exists 32 if not os.path.exists(rgb_path): 33 raise FileNotFoundError(f"RGB image not found: rgb_path") 34 35 # Apply FoalGAN style transfer to convert RGB to thermal 36 execution_result = tools["FoalGAN_FLIR_RGB2T_Generation_Tool"]. execute( 37 37 input_image_path=rgb_path , 38 seed=seed 39 ) 40 41 # Extract the output path from the execution result 42 thermal_output_path = execution_result["output_image_path"] 43 generated_thermal_paths.append(thermal_output_path) 44 45 return generated_thermal_paths 46 Code 7: Case 4’s solution code at iteration 2. 1 # import Python packages 2 import os 3 4 # define main solve function 5 def solve(tools , rgb_image_paths: list = ["tasks/task212/vis_im1.jpg","tasks/task212/vis_im2.jpg", "tasks/ task212/vis_im3.jpg","tasks/task212/vis_im4.jpg","tasks/task212/vis_im5.jpg"], steps: int = 500, seed: int = 1234): 6 """ 7 Generate fake thermal images from RGB images using Physics -Informed Diffusion model. 8 9 This function translates RGB images to thermal -style images using the PID model 10 trained on FLIR dataset , which incorporates physical constraints for more accurate 11 thermal image generation compared to purely data -driven approaches. 12 13 Args: 14 - tools (dict): Dictionary containing available tools 15 - rgb_image_paths (list[str]): Paths to the input RGB image files 16 - steps (int): Number of steps for the diffusion process (higher = better quality) 17 - seed (int): Seed for random number generator for reproducible results 18 19 Returns: 20 - list[str]: Paths to the generated fake thermal images in PNG format 21 """ 22 23 # Validate that the required tool is available 24 if "PID_FLIR_RGB2T_Generation_Tool" not in tools: 25 raise ValueError("Required tool ’PID_FLIR_RGB2T_Generation_Tool ’ not available") 26 27 # Initialize list to store generated thermal image paths 28 generated_thermal_paths = [] 29 30 # Process each RGB image to generate corresponding thermal image 31 for rgb_path in rgb_image_paths: 32 # Check if input file exists 33 if not os.path.exists(rgb_path): 34 raise FileNotFoundError(f"RGB image not found: rgb_path") 35 36 # Apply PID diffusion model to convert RGB to thermal 37 execution_result = tools["PID_FLIR_RGB2T_Generation_Tool"]. execute( 38 input_image_path=rgb_path , 39 steps=steps , 40 seed=seed 41 ) 42 43 # Extract the output path from the execution result 44 thermal_output_path = execution_result["output_image_path"] 45 generated_thermal_paths.append(thermal_output_path) 46 47 return generated_thermal_paths 48 Code 8: Case 4’s solution code at iteration 3. 1 # import Python packages 2 import os 3 import cv2 4 import numpy as np 5 6 # define helper function: calculate image complexity based on edge density 7 def calculate_image_complexity(image_path): 8 """ 9 Calculate image complexity based on edge density using Canny edge detection. 10 11 Args: 12 image_path (str): Path to the input image 13 14 Returns: 15 float: Complexity score between 0 and 1 16 """ 38 17 try: 18 # Read image in grayscale 19 img = cv2.imread(image_path , cv2.IMREAD_GRAYSCALE) 20 if img is None: 21 return 0.5 # Default medium complexity if image cannot be read 22 23 # Calculate edge density using Canny edge detection 24 edges = cv2.Canny(img , 100, 200) 25 edge_density = np.sum(edges > 0) / (img.shape [0] * img.shape [1]) 26 27 # Normalize to 0-1 range 28 complexity = min(1.0, max(0.1, edge_density * 10)) 29 return complexity 30 except Exception: 31 return 0.5 # Default on error 32 33 # define main solve function 34 def solve(tools , rgb_image_paths: list = ["tasks/task212/vis_im1.jpg","tasks/task212/vis_im2.jpg", "tasks/ task212/vis_im3.jpg","tasks/task212/vis_im4.jpg","tasks/task212/vis_im5.jpg"], seed: int = 1234, base_steps: int = 200): 35 """ 36 Generate fake thermal images from RGB images using Physics -Informed Diffusion model. 37 38 This function translates RGB images to thermal -style images using the PID model 39 trained on FLIR dataset , which incorporates physical constraints for more accurate 40 thermal image generation. Image complexity is used to adapt diffusion steps. 41 42 Args: 43 - tools (dict): Dictionary containing available tools 44 - rgb_image_paths (list[str]): Paths to the input RGB image files 45 - seed (int): Seed for random number generator for reproducible results 46 - base_steps (int): Base number of steps for diffusion process 47 48 Returns: 49 - list[str]: Paths to the generated fake thermal images in PNG format 50 """ 51 52 # Initialize list to store generated thermal image paths 53 generated_thermal_paths = [] 54 55 # Check for available tools in order of preference 56 preferred_tool = "PID_FLIR_RGB2T_Generation_Tool" 57 fallback_tool = "FoalGAN_FLIR_RGB2T_Generation_Tool" 58 59 # Determine which tool to use 60 if preferred_tool in tools: 61 selected_tool = preferred_tool 62 elif fallback_tool in tools: 63 selected_tool = fallback_tool 64 else: 65 raise ValueError(f"Neither preferred_tool nor fallback_tool available in tools") 66 67 # Process each RGB image to generate corresponding thermal image 68 for rgb_path in rgb_image_paths: 69 # Check if input file exists 70 if not os.path.exists(rgb_path): 71 raise FileNotFoundError(f"RGB image not found: rgb_path") 72 73 # Calculate image complexity to adapt diffusion steps 74 complexity = calculate_image_complexity(rgb_path) 75 76 # Adjust steps based on complexity (more complex images need more steps) 77 adaptive_steps = int(base_steps * (0.8 + 0.4 * complexity)) 78 79 try: 80 if selected_tool == "PID_FLIR_RGB2T_Generation_Tool": 81 # Apply PID diffusion model for RGB -to -thermal translation 82 execution_result = tools[selected_tool ]. execute( 83 input_image_path=rgb_path , 84 steps=adaptive_steps , 85 seed=seed 86 ) 87 else: 88 # Apply fallback GAN -based tool 89 execution_result = tools[selected_tool ]. execute( 90 input_image_path=rgb_path , 91 seed=seed 92 ) 93 94 # Extract the output path from the execution result 95 thermal_output_path = execution_result["output_image_path"] 96 97 # Verify output file was created and has content 98 if os.path.exists(thermal_output_path) and os.path.getsize(thermal_output_path) > 0: 99 generated_thermal_paths.append(thermal_output_path) 100 else: 101 raise RuntimeError(f"Generated thermal image is empty or not created: thermal_output_path") 102 103 except Exception as e: 104 # If primary tool fails and we haven’t tried fallback , try fallback 105 if selected_tool == preferred_tool and fallback_tool in tools: 39 106 try: 107 execution_result = tools[fallback_tool ]. execute( 108 input_image_path=rgb_path , 109 seed=seed 110 ) 111 thermal_output_path = execution_result [" output_image_path "] 112 if os.path.exists(thermal_output_path) and os.path.getsize(thermal_output_path) > 0: 113 generated_thermal_paths.append(thermal_output_path) 114 else: 115 raise RuntimeError(f"Fallback tool also failed for: rgb_path ") 116 except Exception as fallback_error: 117 raise RuntimeError(f"Both primary and fallback tools failed for rgb_path : fallback_error ") 118 else: 119 raise RuntimeError(f"Tool execution failed for rgb_path : e") 120 121 return generated_thermal_paths 122 Code 9: Case 4’s solution code at iteration 9. 40

Instant research discovery