Photonics device reverse design method and system

Abstract

The present disclosure provides a photonic device reverse design method and system, relating to the technical field of automatic design. The method comprises: generating a configuration package according to a design request; performing pre-run verification on the configuration package, and performing a first rollback operation to correct the error step and its downstream dependent step in the configuration package generation process in the case that the pre-run verification fails; performing photonic device reverse optimization according to the configuration package in the case that the pre-run verification passes, and recording the checkpoint state in the optimization process; performing a second rollback operation to recover from the local rollback point in the case that an optimization anomaly is detected; and encapsulating the optimization result as a design result package of the photonic device in the case that the photonic device reverse optimization is completed. The present disclosure sets a rollback mechanism, reduces repeated calculation and resource consumption, and improves design efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of automated design technology, and in particular to a method and system for reverse design of photonic devices. Background Technology

[0002] Reverse engineering of photonic devices enables the search for non-intuitive structures in a high-dimensional design space, facilitating functions such as beam splitting, wavelength splitting, mode splitting, mode multiplexing, polarization conversion, resonant filtering, and port routing. However, in related technologies, reverse engineering of photonic devices relies on manually defined simulation configurations and optimization parameters. This leads to problems such as unstable mapping between natural language requirements and simulation configurations, delayed detection of configuration errors, reliance on manual parameter tuning for optimization anomalies, and difficulty in reproducing failures, resulting in low design efficiency and a lack of traceability. Summary of the Invention

[0003] To overcome the problems existing in related technologies, this disclosure provides a method and system for reverse design of photonic devices.

[0004] According to a first aspect of the present disclosure, a method for reverse engineering a photonic device is provided, comprising: Obtain design requests for photonic devices; A configuration package is generated based on the design request. The configuration package is used to define the simulation environment, optimization objectives, and operating rules of the photonic device. The configuration package is pre-run verified. If the pre-run verification fails, a first rollback operation is performed to correct the steps in the configuration package generation process that have errors and their downstream dependent steps. If the pre-run verification passes, reverse optimization of the photonic device is performed according to the configuration package, and the checkpoint status during the optimization process is recorded; If an optimization anomaly is detected, a second rollback operation is performed to resume execution from a local rollback point; wherein, the local rollback point is determined based on the checkpoint status, and the determined local rollback point is a historical execution phase in the design process or a historical checkpoint in the optimization process; Once the reverse optimization of the photonic device is completed, the optimization results are packaged into a design result package for the photonic device.

[0005] In some embodiments, generating the configuration package according to the design request includes: The design request is semantically parsed to obtain a structured requirement object; Based on the structured requirement object, historical design scenarios and repair records are retrieved from the knowledge base to generate a task context; Based on the structured requirement object and the task context, a configuration package containing simulation parameters, optimization parameters, and runtime parameters is generated.

[0006] In some embodiments, performing the first rollback operation includes: Identify the types of configuration errors that caused the configuration package to fail pre-run verification; Based on the configuration error type, corresponding candidate rollback steps are selected from multiple historical execution stages included in the configuration package generation process; The rollback confidence of each candidate rollback step is calculated based on preset multi-dimensional evaluation factors, including at least one of causal proximity, evidence consistency, memory hit, historical success rate, and change risk. The candidate rollback step with the highest rollback confidence is identified as the step where the error occurred, and the process is rolled back to that step and its downstream dependent steps for correction.

[0007] In some embodiments, performing the second rollback operation includes: The optimization anomalies are diagnosed to determine the cause of the anomalies; When the cause of the anomaly is an abnormal optimization parameter, the local rollback point is determined as a historical checkpoint in the optimization process. The contribution of each optimization control parameter to the optimization anomaly is analyzed using a parameter evaluation model pre-trained based on historical optimization data. Parameter correction instructions are generated based on the contribution, and execution resumes from the determined historical checkpoint. The optimization control parameters include at least one of the following: learning rate, projection parameter, penalty term weight, objective function weight, and optimizer restart strategy. If the cause of the anomaly is a simulation configuration error, the local rollback point is identified as a historical execution stage in the design process, and the corresponding simulation configuration parameters are repaired to resume execution from the identified historical execution stage; wherein, the historical execution stage includes a configuration generation stage or a configuration verification stage.

[0008] In some embodiments, the step of retrieving historical design scenarios and repair records from a knowledge base based on the structured requirement object to generate a task context includes: Retrieval is performed based on a preset multi-level memory state, which includes short-term episodic memory, medium-term working memory, and long-term task memory. When recalling historical design scenarios from the multi-level memory state, the failure signature and scenario fingerprint of the current design request are matched with the corresponding identifier of the historical design scenario. In the event of no match, the comprehensive similarity between the current design request and the historical design scenario is determined based on vector similarity, keyword overlap, and recentity. If the comprehensive similarity meets the preset conditions, the corresponding historical design scenario is used as the basis for repair to generate the task context.

[0009] In some embodiments, the pre-run verification of the configuration package includes: The configuration package is subjected to basic physical logic verification, which includes at least one of the following: source and monitor coverage verification, port direction verification, boundary distance verification, mode quantity verification, and objective function direction verification.

[0010] In some embodiments, the method includes: Obtain the expected mode mapping relationship between the input port and the output port of the photonic device; In the basic physical logic verification, it is verified whether the number of target response cases and the number of pattern unfoldings under different excitation source configurations match the expected pattern mapping relationship.

[0011] In some embodiments, performing photonic device inverse optimization according to the configuration package includes: The optimization process is advanced according to a preset heartbeat stage, which includes a forward simulation stage, a follow-up simulation stage, and a post-processing stage. If no state update event is detected within a preset time during the post-processing stage following the completion of the accompanying simulation stage, failure evidence is recorded and duplicate submissions are blocked through an event-free monitoring mechanism.

[0012] In some embodiments, recording the checkpoint status during the optimization process includes: During the optimization iteration process, the current design variable distribution, objective function evaluation results, and optimizer internal state are saved according to the preset checkpoint interval to construct the historical checkpoints.

[0013] According to a second aspect of this disclosure, a reverse design system for photonic devices is provided, comprising: A configuration generation module is used to obtain design requests for photonic devices and generate configuration packages based on the design requests. The configuration packages are used to define the simulation environment, optimization objectives, and operating rules of the photonic devices. The configuration verification module is used to perform pre-run verification on the configuration package. If the pre-run verification fails, a first rollback operation is performed to correct the steps that erroneously occurred during the configuration package generation process and their downstream dependent steps. The reverse design execution module is used to perform reverse optimization of photonic devices according to the configuration package after the pre-run verification is passed, and to record the checkpoint status during the optimization process; The diagnostic recovery module is used to perform a second rollback operation when an optimization anomaly is detected, so as to resume execution from a local rollback point; wherein the local rollback point is determined according to the checkpoint status, and the determined local rollback point is a historical execution stage in the design process or a historical checkpoint in the optimization process; The result encapsulation module is used to encapsulate the optimization results into a design result package for the photonic device after the reverse optimization of the photonic device is completed.

[0014] The solution provided in this disclosure can obtain design requests for photonic devices; A configuration package is generated based on the design request. The configuration package is used to define the simulation environment, optimization objectives, and operating rules of the photonic device. The configuration package is pre-run verified. If the pre-run verification fails, a first rollback operation is performed to correct the steps in the configuration package generation process that have errors and their downstream dependent steps. If the pre-run verification passes, reverse optimization of the photonic device is performed according to the configuration package, and the checkpoint status during the optimization process is recorded; If an optimization anomaly is detected, a second rollback operation is performed to resume execution from a local rollback point; wherein, the local rollback point is determined based on the checkpoint status, and the determined local rollback point is a historical execution phase in the design process or a historical checkpoint in the optimization process; Once the reverse optimization of the photonic device is completed, the optimization results are packaged into a design result package for the photonic device.

[0015] The solution provided in this disclosure can obtain the design request of a photonic device; generate a configuration package based on the design request; perform pre-run verification on the configuration package; if the pre-run verification fails, perform a first rollback operation to correct the steps that erroneously occurred during the configuration package generation process and their downstream dependent steps; if the pre-run verification passes, perform reverse optimization of the photonic device based on the configuration package and record the checkpoint status during the optimization process; if an optimization anomaly is detected, perform a second rollback operation to resume execution from a local rollback point; wherein, the local rollback point is determined based on the checkpoint status, and the determined local rollback point is a historical execution stage in the design process or a historical checkpoint in the optimization process; and if the reverse optimization of the photonic device is completed, encapsulate the optimization results into a design result package of the photonic device.

[0016] This disclosure addresses the issues of delayed configuration error detection, reliance on manual parameter tuning for optimization anomalies, and difficulty in reproducing failures by establishing a full-link state machine and a partial rollback mechanism. Performing configuration package verification before formal optimization allows for the early detection of various configuration errors, reducing unnecessary simulation tasks. By utilizing checkpoints to trigger partial rollbacks and local replanning during the optimization process, redundant calculations and cloud resource consumption are reduced, resulting in highly traceable and reproducible design processes. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a reverse design method for a photonic device according to an embodiment of the present disclosure; Figure 2 This is a schematic diagram of the semantic requirement parsing and reflection mechanism closed loop and configuration package generation process in the embodiments of this disclosure; Figure 3 This is a detailed flowchart illustrating the multi-level memory state retrieval and semantic parsing reflection in the embodiments of this disclosure; Figure 4 This is a flowchart illustrating the pre-run verification and pattern mapping verification method in an embodiment of this disclosure; Figure 5 This is a flowchart illustrating the pre-running error correction rollback repair closed loop and the first rollback operation in an embodiment of this disclosure; Figure 6 This is a detailed flowchart illustrating the pre-run error correction rollback repair closed loop in the embodiments of this disclosure; Figure 7 This is a flowchart illustrating the reverse optimization execution and checkpoint recording method in the embodiments of this disclosure; Figure 8 This is a schematic diagram of the reverse optimization design of the blocked recovery closed loop and the second rollback operation in the embodiments of this disclosure; Figure 9 This is a detailed flowchart illustrating the reverse optimization design of the hindered recovery closed loop in the embodiments of this disclosure; Figure 10 This is a schematic diagram of the design result package in the embodiments of this disclosure; Figure 11 This is a schematic diagram of the generative artificial intelligence system structure in an embodiment of this disclosure; Figure 12 This is a schematic diagram of the structure of a reverse design system for photonic devices according to an embodiment of this disclosure. Detailed Implementation

[0018] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0019] First, the core concepts and basic principles involved in this disclosure are explained. Reverse engineering of photonic devices is a technique that defines target optical performance and uses optimization algorithms to automatically search for device geometries that meet performance requirements within a vast design space. Unlike traditional forward design, reverse engineering can discover non-intuitive topological structures that are difficult for humans to intuitively conceive of, thereby significantly improving the conversion efficiency, bandwidth, and compactness of devices. However, reverse engineering is highly dependent on electromagnetic simulation software and accompanying optimization algorithms, and its configuration process is extremely complex, involving mesh generation, boundary condition setting, excitation source definition, monitor placement, objective function construction, and optimizer hyperparameter tuning. Even a minor error in any step can cause a cloud simulation task that can last for days or even weeks to completely fail, and the cause of the failure is difficult to pinpoint.

[0020] To address the aforementioned issues, this disclosure provides a reverse design method for photonic devices. Specifically, this disclosure first obtains a design request for the photonic device; then, a configuration package is generated based on the design request, which defines the simulation environment, optimization objectives, and operating rules for the photonic device; next, the configuration package undergoes pre-run verification; if the pre-run verification fails, a first rollback operation is performed to correct the steps that erroneously occurred during the configuration package generation process and their downstream dependencies; if the pre-run verification passes, reverse optimization of the photonic device is performed based on the configuration package, and the checkpoint status during the optimization process is recorded; if an optimization anomaly is detected, a second rollback operation is performed to resume execution from a local rollback point; wherein, the local rollback point is determined based on the checkpoint status, and the determined local rollback point is a historical execution stage in the design process or a historical checkpoint in the optimization process; finally, after the reverse optimization of the photonic device is completed, the optimization results are encapsulated into a design result package for the photonic device.

[0021] The specific implementation methods of this disclosure will be described in detail below.

[0022] Figure 1 This diagram illustrates a flowchart of a reverse design method for photonic devices according to an embodiment of the present disclosure. This method can be executed by any electronic device. Figure 1 As shown, the method includes the following steps S101 to S106.

[0023] S101, Obtain design requests for photonic devices.

[0024] In some embodiments, a design request serves as the trigger for initiating the entire reverse design process. This design request can be input by the user through a graphical user interface, command-line interface, or application programming interface. The design request can be in the form of a natural language description, such as "Design a 1×2 power splitter with a center wavelength of 1550nm, requiring an insertion loss of less than 0.5dB and a size not exceeding 10×10 micrometers"; or it can be semi-structured form data containing key fields such as device type, operating wavelength, and number of ports. Upon receiving the design request, the system performs preliminary format validation and completeness checks to ensure that the request contains the minimum set of information necessary to perform subsequent steps. If information is missing, the system generates prompts to guide the user in supplementing it. Through a unified design request access method, the system can mask differences in user expression habits, providing a standardized input basis for subsequent automated parsing.

[0025] S102, Generate configuration package based on design request.

[0026] The configuration package is used to define the simulation environment, optimization objectives, and operating rules for photonic devices.

[0027] In some embodiments, the configuration package serves as the single source of truth for the entire reverse engineering task, determining how the simulation engine constructs the physical model and how the optimizer updates design variables. Simulation environment parameters include, but are not limited to, the 3D dimensions of the computational domain, the refractive index of the background material, the thickness and number of perfectly matched layers, the accuracy of the mesh generation, and boundary conditions. Optimization objective parameters define the performance metrics the device needs to achieve, such as maximizing transmittance, minimizing reflectivity, maximizing mode purity, or minimizing crosstalk at a specific port, and include the weighting of each objective. Runtime rule parameters control the execution logic of the optimization process, such as the maximum number of iterations, convergence threshold, checkpoint saving frequency, and computational resource allocation strategy. The generation of the configuration package transforms abstract design intent into a concrete, executable set of machine instructions, ensuring a high degree of consistency between the simulation and optimization processes.

[0028] S103, perform pre-run verification on the configuration package. If the pre-run verification fails, perform the first rollback operation to correct the steps that erroneously occurred during the configuration package generation process and their downstream dependent steps.

[0029] In some embodiments, pre-run verification is a series of static and quasi-static logical and physical rule checks performed on the configuration package before the formal invocation of the high-cost electromagnetic simulation engine. Its core purpose is to intercept fatal errors that will inevitably lead to simulation failure or meaningless results early in the task, such as excitation sources placed outside the computational region, monitors and ports not aligned, or material refractive indices set to negative values.

[0030] If the pre-run verification discovers a defect in the configuration package, the system will not directly terminate the task, but will trigger the first rollback operation. The first rollback operation is an intelligent error correction mechanism that can accurately pinpoint the specific step in the configuration package generation pipeline that caused the error based on its nature, and roll back the system state to that step. It only re-executes that step and its downstream dependent steps, while keeping the upstream verified correct configuration unchanged. This partial rollback strategy avoids rerunning the entire process, significantly improving the efficiency of configuration repair.

[0031] S104. If the pre-run verification is successful, perform reverse optimization of photonic devices according to the configuration package and record the checkpoint status during the optimization process.

[0032] In some embodiments, once the configuration package successfully passes all pre-run verifications, the system submits it to the computing cluster to formally initiate the reverse optimization process for the photonic device. Reverse optimization typically employs the adjoint variable method, which calculates the gradient of the objective function with respect to all design variables through one forward simulation and one adjoint simulation, thereby efficiently updating the device's topology.

[0033] Since reverse optimization often requires hundreds or even thousands of iterations, which is extremely time-consuming, recording checkpoint states during the optimization process is crucial. Checkpoint states are complete snapshots of the optimization process at a specific iteration step, including but not limited to the current distribution of design variables, the evaluation results of the objective function, electromagnetic field distribution data, and the internal state of the optimizer. By periodically persisting these checkpoints, the system can seamlessly recover from the most recent checkpoint in the event of hardware failures, network outages, or software crashes, avoiding a huge waste of computational resources.

[0034] S105, if an optimization anomaly is detected, a second rollback operation is performed to resume execution from the local rollback point.

[0035] The local rollback point is determined based on the checkpoint status, and the determined local rollback point is a historical execution phase in the design process or a historical checkpoint in the optimization process.

[0036] In some embodiments, optimization anomalies refer to unexpected behaviors that occur during reverse optimization. When these anomalies are detected, the system triggers a second rollback operation. Unlike the first rollback operation, which targets configuration errors, the second rollback operation primarily targets dynamic anomalies or deep configuration defects during the optimization process. The system determines a reasonable local rollback point based on the currently recorded checkpoint status and anomaly type. This local rollback point can be a historical checkpoint in the optimization process or a historical execution phase in the design process. When resuming execution from the local rollback point, the system synchronously adjusts the optimizer's hyperparameters or repairs the simulation configuration to guide the optimization process out of local optima or eliminate anomalies.

[0037] S106, after the reverse optimization of the photonic device is completed, the optimization results are packaged into a design result package for the photonic device.

[0038] In some embodiments, the system determines that the reverse optimization is complete when the optimization process reaches a preset convergence condition or exhausts the maximum number of iterations. At this point, the result encapsulation module standardizes and packages all relevant inputs, intermediate processes, and output products to generate a design result package.

[0039] The design outcome package not only includes the final device topology, but also the objective function evolution curves during the optimization process, electromagnetic field distribution diagrams for each iteration step, and a performance evaluation report of the final structure. More importantly, the package also encapsulates a complete execution log, checkpoint records, failure diagnostic reports, and recovery evidence. This comprehensive encapsulation mechanism ensures that the design outcome is not merely a geometric file, but a fully traceable and reproducible digital asset, facilitating subsequent process fabrication verification and algorithm iteration analysis.

[0040] Through the aforementioned independent methodology, this disclosure constructs an automated design pipeline from requirement input to result output. The following sections will provide a detailed explanation of the configuration package generation process and the historical scenario retrieval mechanism.

[0041] Figure 2 This diagram illustrates the flow of the semantic requirement parsing and reflection mechanism closed-loop and configuration package generation in an embodiment of this disclosure. Figure 2 As shown, the configuration package generation process and historical scenario retrieval mechanism include the following steps S201 to S203.

[0042] S201, perform semantic parsing on the design request to obtain a structured requirement object.

[0043] In some embodiments, since user-input design requests are mostly in natural language, the system needs to perform semantic parsing using natural language processing techniques or large language models. The semantic parsing process includes entity recognition, intent classification, and slot filling. The system extracts key photonic entities from the natural language text, such as device type (e.g., at least one of power splitter, wavelength splitter, mode splitter, mode multiplexer, mode demultiplexer, ring resonator, directional coupler, cross waveguide, grating coupler, polarization rotator), operating wavelength, port configuration, and target optical parameters (e.g., at least one of conversion efficiency, insertion loss, crosstalk, target mode purity, operating bandwidth, and port power ratio). The extracted entities are mapped to a predefined ontology library, transforming them into machine-readable structured requirement objects. If ambiguity or conflict is found during parsing, the system generates reflective prompts, requiring the user to clarify or provide priority weights, thereby ensuring the physical rationality and logical rigor of the structured requirement objects.

[0044] S202, based on structured requirement objects, retrieves historical design scenarios and repair records from the knowledge base to generate task context.

[0045] Before generating the configuration package, the system needs to fully understand the background and potential risks of the current task. To this end, the system retrieves relevant historical design scenarios and repair records from a pre-built knowledge base based on structured requirement objects. Specifically, based on structured requirement objects, the system retrieves historical design scenarios and repair records from the knowledge base to generate task context, including: searching based on preset multi-level memory states, which include short-term contextual memory, medium-term working memory, and long-term task memory; when recalling historical design scenarios from multi-level memory states, matching the failure signature and scenario fingerprint of the current design request with the corresponding identifier of the historical design scenario; in the case of no match, determining the comprehensive similarity between the current design request and the historical design scenario based on vector similarity, keyword overlap, and recentity, and if the comprehensive similarity meets preset conditions, using the corresponding historical design scenario as the basis for repair to generate task context.

[0046] In some embodiments, the design of multi-level memory states mimics the human cognitive memory mechanism. Short-term episodic memory is used to store the inputs, outputs, and diagnostic events of the steps that have just occurred in the current design task; medium-term working memory is used to store the constraints, configuration candidates, and intermediate verification results of the current task across steps; and long-term task memory persistently stores a massive amount of historical design scenarios and their repair solutions.

[0047] During retrieval, the system first extracts the features of the current design request, namely the structured requirement object, generates a failure signature and a scenario fingerprint, and attempts to perform an exact match in long-term task memory. If no exact match is found, the system calculates the comprehensive similarity using a multi-feature fusion approach. The formula for calculating the comprehensive similarity can be expressed as:

[0048] in, For query With candidate history The overall similarity; and These are vector representations of the query and candidate records, respectively, typically obtained through pre-trained text or graph embedding models, used to characterize deep semantic features; and These are sets of keywords for the query and candidate records, used to capture explicit terminology matches; The recentity factor for candidate records is used to assign higher weight to more recent historical records. , and These are the weighting coefficients for vector similarity, keyword overlap, and proximity, respectively. To prevent positive numbers with a denominator of zero, when the overall similarity exceeds a preset threshold, the historical scene will be recalled and used as the basis for repair.

[0049] Understandably, in this embodiment, the failure signature is a structured and standardized feature representation of anomalies, errors, or failures that occur during system operation. The failure signature can be a multi-dimensional feature set, mainly including the following dimensions: First, anomaly type identifier, such as objective function stagnation, FDTD (finite-difference time-domain) simulation divergence, memory overflow, pattern mismatch, or non-numerical (NaN) errors in gradient calculation; Second, occurrence stage identifier, used to accurately record whether the anomaly occurred during configuration generation, pre-run verification, forward simulation, accompanying simulation, or post-processing; Third, key state snapshot, i.e., key operational indicators within a preset time window before the anomaly occurred, such as the moving average variance of the objective function, the mutation rate of the gradient norm, and the evolution slope of the structure binarization ratio. When the system detects an anomaly or verification failure, the log parser and status monitoring probe automatically capture the above information, and after data cleaning and normalization, generate a structured failure signature vector or hash string. Through the failure signature, the system can accurately characterize the superficial and deep numerical features of the current fault.

[0050] Accordingly, a scenario fingerprint is a comprehensive and unique identifier of the contextual features of the current photonic device design task, including the physical environment, geometric constraints, material properties, and optimization objectives. Since the performance of photonic devices is highly sensitive to physical parameters, discussing fault repair without considering the specific scenario is meaningless. The dimensions of a scenario fingerprint include: First, physical and geometric constraints, such as device type (e.g., MMI, microring resonator), three-dimensional dimensions of the design area, operating center wavelength, and refractive index distribution of the background and waveguide materials; Second, topology and port configuration, such as the number of input and output ports and waveguide width, spatial distribution of excitation sources and monitors, order of the target mode (e.g., TE0 to TE4), and port mode mapping constraints between multiple ports; Third, the optimization objective space, such as the specific type of objective function (e.g., maximizing mode purity, minimizing crosstalk) and the weight allocation vectors of each sub-objective. When generating scene fingerprints, the system first concatenates the high-dimensional discrete category features and continuous numerical features, and then maps them into a dense feature vector of fixed length through a feature hashing algorithm or a pre-trained embedding model (such as a multilayer perceptron MLP), or calculates its SHA-256 hash value as a unique identifier.

[0051] S203 generates a configuration package containing simulation parameters, optimization parameters, and runtime parameters based on the structured requirement object and task context.

[0052] After obtaining accurate structured requirements and rich task context, the configuration generation module combines the two to generate the final configuration package. Specifically, the simulation configuration includes device type, simulation region, materials, sources, ports, monitors, boundary conditions, and mesh; the optimization configuration includes objective function, variable boundaries, objective weights, manufacturing constraints, and optimizer hint parameters; and the runtime configuration includes maximum number of iterations, checkpoint interval, checkpoint warm-up window, whether to enable failure diagnostics, whether to enable parameter attribution, and recovery budget.

[0053] The structured requirement objects provide the hard constraints and objectives of the design, while the task context provides soft suggestions and pitfall avoidance guidelines. The system transforms high-level requirements into low-level simulation parameters (such as mesh size and PML layer number), optimization parameters (such as optimizer type, initial learning rate, and projection threshold), and runtime parameters (such as maximum number of iterations and checkpoint interval) by calling generative artificial intelligence models or rule-based expert systems. The generated configuration package undergoes internal format validation to ensure it conforms to the interface specifications of the underlying simulation engine.

[0054] Figure 3 A detailed flowchart illustrating the multi-level memory state retrieval and semantic parsing reflection in an embodiment of this disclosure is shown. The flowchart demonstrates the complete closed-loop process of the system performing semantic parsing, content extraction and inspection, and reflection and correction on the natural language design request input by the user.

[0055] like Figure 3 As shown, the user first inputs a natural language design request, such as: "Design a 1x5 MMI mode divider multiplexer, modes TE0-TE4, operating wavelength 1550nm, maximizing transmission rate." This request enters the parser prompt module. The parser prompt module defines the role of the photonics reverse design requirement parser, receiving the natural language reverse design request as input. Its task is to parse the request into structured data with a strict JSON format, including fields such as component type (component_type), wavelength (wavelength_nm), wavelength list (wavelengths_nm), objective (including subfields such as metric, goal, comparator, target_value, unit, description, etc.), constraints, and routing targets (routing_targets), and finally outputs structured JSON data.

[0056] The JSON data output by the parser is validated by the content extraction and inspection module. If the inspection finds unresolved or invalid fields, the system generates a reflection prompt, initiating a closed-loop reflection mechanism. The reflection prompt module defines the role of the photonics requirement correction parser, whose context input includes the original request and output, the correctly extracted fields, and the unresolved or invalid fields. The reflection task requires correcting only unresolved fields, without re-outputting already corrected fields, ultimately outputting a corrected natural language request. The corrected request re-enters the parser prompt module for semantic parsing again, forming a closed-loop mechanism of "parsing-inspection-re-parsing" until all fields are correctly extracted and validated.

[0057] Figure 3 It has been further clarified Figure 2 The specific implementation details of the semantic requirement parsing reflection mechanism include the role definition of the parser prompts, the JSON structured output format, the verification logic of content extraction checks, and the correction strategy of reflection prompts. This reflects the system's ability to automatically correct and perform closed-loop verification during the natural language requirement parsing process, ensuring the accuracy and completeness of structured requirement objects.

[0058] Next, we will provide a detailed explanation of the pre-run verification and pattern mapping verification mechanisms.

[0059] Figure 4 This diagram illustrates a flowchart of the pre-run verification and pattern mapping verification method in an embodiment of this disclosure. Figure 4 As shown, the pre-run verification and pattern mapping verification mechanism includes the following steps S401 to S403.

[0060] S401 performs basic physical logic verification on the configuration package. The basic physical logic verification includes at least one of the following: source and monitor coverage verification, port direction verification, boundary distance verification, mode quantity verification, and objective function direction verification.

[0061] In some embodiments, the core of pre-run verification is basic physical logic verification. Source and monitor coverage verification checks whether the spatial location of the excitation source completely covers the cross-section of the input port and whether the monitor is accurately placed at the expected location of the output port, preventing energy leakage or measurement inaccuracies due to source or monitor misalignment. Port orientation verification ensures that the propagation direction of the excitation source is aligned with the waveguide axis and that the normal vectors of the input and output ports point correctly. Boundary distance verification checks whether the minimum distance of the device structure from the perfectly matched layer or periodic boundary satisfies the rule of thumb of more than half a wavelength, preventing non-physical interactions between evanescent waves and the boundary. Mode quantity verification confirms whether the number of modes supported by the simulation region meets the design requirements of multimode devices. Objective function direction verification checks whether the optimization objective is to find a maximum or minimum value, preventing the optimizer from updating in the opposite direction due to incorrect direction settings.

[0062] S402, obtain the expected mode mapping relationship between the input port and the output port of the photonic device.

[0063] For complex photonic devices (such as mode multiplexers and mode splitters), their core function is to map specific input modes to specific output modes. Therefore, during pre-run verification, the system needs to explicitly obtain this expected mode mapping relationship. This expected mode mapping relationship can be obtained by resolving port mode mapping constraints in the design request, such as "the TE0 mode of input port 1 maps to the TE1 mode of output port 1." This mapping relationship defines the device's transmission matrix under ideal conditions and serves as the benchmark for subsequently constructing the objective function and evaluating device performance.

[0064] S403, in the basic physical logic verification, verifies whether the number of target response cases and the number of pattern unfoldings under different excitation source configurations match the expected pattern mapping relationship.

[0065] In some embodiments, to ensure that the simulation setup fully covers the expected pattern mapping, the system performs deep matching verification. Specifically, the system counts the number of different stimulus source configurations (i.e., different source switching cases) defined in the configuration package and compares them with the total number of input patterns defined in the expected pattern mapping to ensure that the number of target response cases is consistent. Simultaneously, the system checks whether the number of pattern expansions of the output port monitor (i.e., the number of orthogonal patterns that the monitor can decompose and monitor) is greater than or equal to the total number of output patterns involved in the expected pattern mapping. If the number of target response cases is insufficient, or the number of pattern expansions is inadequate, the system determines that the verification has failed and generates an error report containing specific missing items. This deep logical verification effectively prevents the phenomenon of "mapping constraint drift," where the simulation setup unintentionally degenerates into a simpler single-pattern or single-case test, thereby ensuring that the optimization process strictly adheres to the complex contract of multi-port, multi-pattern operation.

[0066] The following section will explain the detailed execution process of the first rollback operation.

[0067] Figure 5 This diagram illustrates the flow chart of the pre-running error correction rollback repair closed loop and the first rollback operation in an embodiment of this disclosure. Figure 5 As shown, the detailed execution process for the first rollback operation includes the following steps S501 to S504.

[0068] S501 identifies the types of configuration errors that cause the configuration package to fail pre-run verification.

[0069] When pre-run verification fails, the system first categorizes the errors. Configuration error types typically include requirement extraction errors (e.g., misidentifying "TE1" as "TE0"), context retrieval errors (e.g., retrieving historical experience with a mismatched material system), configuration generation errors (e.g., generating a mesh size exceeding the simulation engine's allowable range), and physical verification errors (e.g., source and monitor space overlap). Accurately identifying the error type is a prerequisite for subsequent precise rollback. The system analyzes the error codes and stack information returned by the verification module, combining natural language processing techniques to semantically classify the error descriptions, thereby determining the specific configuration error type.

[0070] S502, based on the configuration error type, selects the corresponding candidate rollback steps from multiple historical execution stages included in the configuration package generation process.

[0071] The generation of the configuration package is a multi-stage pipeline process, including semantic parsing, context retrieval, parameter mapping, and format conversion. The system maintains a directed acyclic graph (DAG) to record these execution stages and their dependencies. Once the configuration error type is determined, the system traces backwards in the DAG to filter out candidate rollback steps that may have caused the error. For example, if the error type is "material refractive index anomaly" in physical verification, the system might consider "parameter mapping" and "context retrieval" as candidate rollback steps, because these two stages are most likely to introduce incorrect material parameters.

[0072] S503, calculate the rollback confidence of each candidate rollback step based on preset multi-dimensional evaluation factors.

[0073] The multi-dimensional assessment factors include at least one of causal proximity, evidence consistency, memory hit rate, historical success rate, and change risk.

[0074] To select the optimal rollback step from multiple candidate rollback steps, the system introduces a multi-dimensional evaluation mechanism. The formula for calculating the rollback confidence can be expressed as:

[0075] in, Candidate rollback steps The rollback confidence level reflects the overall likelihood and rollback value of this step as the root cause of the error. For causal proximity, it represents the probability that this step will lead to the current error in the logical chain; For consistency of evidence, this indicates the degree to which the output log of this step matches the current error characteristics; Memory hit rate indicates the frequency with which similar errors in historical memory roll back to this step; Historical success rate represents the probability that a rollback to this step in the past will successfully fix the error. The risk of change indicates the amount of calculations that need to be redone to roll back to this step and the risk of introducing new errors; to represents the corresponding non-negative weighting coefficient. Using this formula, the system can quantitatively evaluate the overall value of each candidate step.

[0076] S504, identify the candidate rollback step with the highest rollback confidence as the step where the error occurred, and roll back to that step and its downstream dependent steps for correction.

[0077] After calculating the rollback confidence of all candidate steps, the system selects the step with the highest confidence as the root cause step of the error. The system then clears the cache and output state of this step and all its downstream dependent steps, and rolls the system pointer back to the entry point of this step. When this step is re-executed, the system injects repair instructions or adjusts the generation strategy (e.g., introducing stricter boundary constraints during the parameter mapping phase) to correct the previous error. The corrected output will automatically trigger the re-execution of downstream dependent steps until the configuration package is resubmitted for pre-run verification.

[0078] Through the first rollback operation described above, this disclosure implements an intelligent, evidence-based local error correction mechanism, avoiding blind retries or full-link resets, and significantly improving the efficiency and success rate of configuration repair.

[0079] Figure 6 This diagram illustrates a detailed flow chart of the pre-run error correction and rollback repair closed loop in an embodiment of this disclosure. The diagram shows the detailed process of error diagnosis and repair performed by the system based on Retrieval Enhanced Generation (RAG) and a multi-level memory mechanism after the configuration package is intercepted during the pre-run verification phase.

[0080] like Figure 6As shown, the process is divided into two parts. The first part is the memory retrieval and matching mechanism: the system obtains static constraint information and variable PDK requirements through the RAG (Retrieval Enhanced Generation) module, where static constraints include the constraint package from step 4 (component type, target metric, semantic rules, hard constraints, physical gates, etc.). Simultaneously, the system maintains working memory (MTM), which includes scene markers (FINGERPRINT) and segments (SEGMENT). When the matching score of the scene markers... Exceeding the preset threshold At that time, the system retrieves relevant historical repair records from the Scene Memory (STM), including key points, failure signatures, summaries, evidence, issues, suggested repair solutions, candidate IDs, target steps, patch actions and reasons, and inserts them into the Working Memory (MTM) to provide a basis for subsequent repairs.

[0081] The second half describes the pre-run error classification and repair process: After the configuration package undergoes pre-run verification, if errors are found, the system classifies them into three categories—configuration errors, setup errors, and physical errors. For configuration errors, the system executes step 2 to retrieve and review repair instructions; for setup errors, the system executes step 3 to verify the configuration and target function selection; for physical errors, the system executes step 4 to re-examine the geometry and port nodes. Through this classification and repair mechanism, the system can accurately locate the root cause of errors and perform targeted repairs, avoiding a complete rerun and significantly improving the efficiency and success rate of configuration repair.

[0082] Figure 6 It has been further clarified Figure 5 The memory retrieval mechanism and error classification and repair process of the pre-run error correction rollback repair closed loop, including RAG constraint retrieval, multi-level memory matching, and classification and processing of setting errors, configuration errors, and physical errors, demonstrate the system's intelligent diagnosis and precise repair capabilities in the configuration verification phase.

[0083] Next, we will provide a detailed explanation of the reverse optimization execution process and the checkpoint recording mechanism.

[0084] Figure 7 This diagram illustrates a flowchart of the reverse optimization execution and checkpoint recording method in an embodiment of this disclosure. Figure 7 As shown, the reverse optimization execution process and checkpoint recording mechanism include the following steps S701 to S703.

[0085] S701, proceeds the optimization process according to the preset heartbeat stage.

[0086] The preset heartbeat stage includes a forward simulation stage, a companion simulation stage, and a post-processing stage.

[0087] In some embodiments, reverse optimization of photonic devices is a computationally intensive and time-consuming process, typically deployed on cloud computing clusters. To monitor the task's running status in real time and prevent the task from "silently dying," the system divides the optimization process into multiple preset heartbeat stages. Specifically, the heartbeat stages include: pre-check completed, forward simulation submitted, forward simulation completed, accompanying simulation submitted, accompanying simulation completed, post-processing started, post-processing completed, product packaging started, product packaging completed, and execution return ready. In the forward simulation stage, the system solves Maxwell's equations based on the finite-difference time-domain (FDTD) method or the finite element method (FEM) to obtain the electromagnetic field distribution under the current structure. In the accompanying simulation stage, the system introduces an accompanying source and calculates the gradient of the objective function with respect to the design variables. In the post-processing stage, the system uses the gradient information to update the design variables. The system sends a heartbeat signal to the monitoring center at the beginning and end of each stage, enabling the system to accurately grasp the current execution progress of the task.

[0088] S702, during the optimization iteration process, saves the current design variable distribution, objective function evaluation results, and optimizer internal state according to the preset checkpoint interval, in order to construct historical checkpoints.

[0089] To support task resumption from breakpoints and recovery from anomalies, the system triggers checkpoint saving operations at preset checkpoint intervals (e.g., every 10 iterations or every hour of operation). Checkpoint data includes not only macroscopic objective function evaluation results but also microscopic design variable distributions (e.g., a dielectric constant matrix of millions of pixels) and optimizer internal states (e.g., the first and second momentum matrices of the Adam optimizer). This data is serialized and compressed and stored in a highly reliable distributed file system. Building a historical checkpoint sequence is equivalent to capturing a series of "time slices" of the optimization process, enabling the system to accurately recreate the optimization state at any past point in time.

[0090] S703, in the post-processing stage following the completion of the simulation stage, if no state update event is detected within a preset time, records failure evidence and blocks duplicate submissions through an event-free monitoring mechanism.

[0091] In cloud simulation environments, task "deadlocks" frequently occur due to underlying file system hangs, network congestion, or shared library deadlocks. Specifically, the simulation may have completed, but during the post-processing phase, the process becomes unresponsive for an extended period, failing to generate any state update events. To address this, the system introduces a watchdog mechanism. If no state update events are detected within a preset time (e.g., 30 minutes) after the post-processing phase begins, the watchdog determines the task is dead, immediately records the current stack snapshot, memory usage, and system logs as evidence of failure, and forcibly terminates the process. More importantly, the system blocks automatic resubmission of the task, preventing infinite restart loops caused by underlying environment failures, thus protecting the computing cluster's resources from unnecessary consumption.

[0092] Next, we will provide a detailed explanation of the second rollback operation and parameter evaluation model.

[0093] Figure 8 This diagram illustrates the flow chart of the reverse optimization design hindered recovery closed loop and the second rollback operation in an embodiment of this disclosure. Figure 8 As shown, the second rollback operation includes the following steps S801 to S803.

[0094] S801 performs failure diagnosis on optimization anomalies to determine the cause of the anomalies.

[0095] When the optimization process fails to converge as expected, the system triggers failure diagnosis to determine the cause of the anomaly. Common optimization anomalies include objective function stagnation, objective function regression, optimization direction deviation, and objective function oscillation. Objective function stagnation usually means that the optimizer is trapped in a local optimum or the learning rate is too small; objective function regression may be due to an excessively large step size causing it to cross the minimum point, or an overly aggressive projection function that disrupts structural connectivity; optimization direction deviation is often due to numerical errors in the gradient calculation of the objective function or the failure of physical constraints to take effect; objective function oscillation is mostly caused by improper learning rate settings or conflicting penalty term weights. The system analyzes the evolution curve of the objective function, the trend of gradient norm changes, and the evolution history of the structural topology, combined with a pre-set expert rule base, to determine the specific cause of the anomaly and classify it as an optimization parameter anomaly or a simulation configuration anomaly.

[0096] S802, when the cause of the anomaly is the abnormality of the optimization parameters, the local rollback point is determined as a historical checkpoint in the optimization process. The parameter evaluation model, which is pre-trained based on historical optimization data, is used to analyze the contribution of each optimization control parameter to the optimization anomaly. Based on the contribution, parameter correction instructions are generated, and execution is resumed from the determined historical checkpoint.

[0097] The optimization control parameters include at least one of the following: learning rate, projection parameters, penalty term weights, objective function weights, and optimizer restart strategy.

[0098] To scientifically adjust optimization parameters, this disclosure introduces a parameter evaluation model. This model is not generated out of thin air, but rather is a lightweight machine learning proxy model trained by the system during daily operation by continuously mining massive historical photonic device reverse optimization task logs accumulated in the cloud computing cluster, followed by automated cleaning and feature engineering. Specifically, the system collects static optimization control parameters from historical tasks (such as initial learning rate, projection threshold, filter radius, penalty term weight, pixel size, etc.) and dynamic temporal features (such as the objective function value, gradient norm, and structure binarization ratio for each iteration), and an automated script annotates the final convergence state of the task. During the feature engineering stage, the system uses a sliding window mechanism to extract temporal features, such as calculating the moving average of the objective function and the gradient norm decay rate for the most recent N iterations, concatenating them with static parameters to form high-dimensional input features. Regarding model structure selection, this disclosure preferentially uses random forest regression models, ridge regression models, gradient boosting regression models, or Gaussian process regression models as the base. Taking random forest as an example, the number of trees is configured to be 100 to 500, and the maximum depth is 5 to 15 layers; when using Gaussian process regression model, radial basis function is used as the kernel function. The model is validated through 5-fold cross-validation to ensure that the prediction accuracy meets the requirements, thereby learning the complex nonlinear mapping relationship between optimized control parameters and optimized trajectory and the occurrence of various anomalies.

[0099] When the system detects an anomaly in the optimization parameters during the current task, it first identifies the local rollback point as a historical checkpoint in the optimization process (e.g., a checkpoint where the objective function has significantly improved or the gradient has stabilized in the most recent instance). Subsequently, the system extracts real-time features of the current task up to the moment the anomaly occurred, constructs the current input feature vector, and inputs it into a pre-trained parameter evaluation model. To accurately analyze the specific contribution of each optimization control parameter to the current anomaly, this disclosure employs the permutation importance method for attribution analysis. The formula for calculating permutation importance can be expressed as:

[0100] in, For the first The influence of an adjustable parameter (such as the learning rate or projection parameter), that is, its contribution to the current anomaly; To evaluate the model based on pre-trained parameters; This is a hyperparameter sample matrix containing feature vectors of the current task and similar historical tasks; For the first The sample matrix obtained by randomly permuting (shuffling) the parameter columns is used to disrupt the association between the feature and the target variable; This corresponds to the true value of the objective function; This is the loss function, used to measure the deviation between the model's predicted values ​​and the actual values. The larger the value, the more significant the first... The higher the contribution of each optimized control parameter to the current anomaly.

[0101] Based on the calculated contribution ranking, the system selects one or more parameters with the highest contribution as the target optimization control parameters and generates specific parameter correction instructions according to the anomaly type. For example, if the anomaly is objective function oscillation and the learning rate has the highest contribution, the correction instruction might be "decay the learning rate by 50%"; if the anomaly is structural fragmentation and the projection parameter has the highest contribution, the correction instruction might be "reduce the projection threshold or increase the filter radius". Finally, the system loads the state data of the determined historical checkpoints, applies the generated parameter correction instructions, and resumes the optimization process from that historical checkpoint.

[0102] S803, when the cause of the anomaly is an abnormal simulation configuration, identifies the local rollback point as a historical execution stage in the design process, repairs the corresponding simulation configuration parameters, and resumes execution from the identified historical execution stage.

[0103] The historical execution phase includes either the configuration generation phase or the configuration verification phase.

[0104] If the failure diagnosis determines that the anomaly is not caused by optimization parameters, but rather by defects in the underlying simulation configuration (e.g., insufficient mesh resolution to resolve fine structures leading to numerical noise in gradient calculations, or improper boundary condition settings causing non-physical reflections), then the anomaly is due to a simulation configuration error. In this case, the system traces the local rollback point upstream to identify a historical execution phase in the design process. Specifically, this historical execution phase includes either the configuration generation phase or the configuration verification phase. The system extracts the corrected simulation configuration parameters (e.g., refining the mesh size from 20nm to 10nm, or increasing the thickness of the perfect-match layer), regenerates or corrects the configuration package, and re-executes the pre-run verification. After successful verification, the system resumes execution from the identified historical execution phase (i.e., the entry point of the configuration generation or configuration verification phase), reinitializes the optimization process using the updated simulation configuration parameters, thereby fundamentally eliminating optimization anomalies caused by simulation configuration defects.

[0105] For example, during reverse engineering, the system continuously monitors the objective function trajectory, monitor readings, and manufacturability metrics. When optimization is detected to be hindered, the system generates a failure snapshot and performs deterministic error classification. Subsequently, based on the cause of the anomaly, it precisely selects to roll back to a historical checkpoint or a historical execution phase. This closed-loop mechanism enables the system to autonomously adjust optimization strategies or repair underlying configurations without blindly restarting the entire optimization task, significantly improving the robustness of reverse engineering.

[0106] In addition, such as Figure 9 The figure shown is a detailed flowchart illustrating the reverse optimization design of the hindered recovery closed loop in this embodiment of the present disclosure. This figure further illustrates... Figure 8 The specific implementation details of optimizer parameter tuning and rollback execution. For example... Figure 9 As shown, when the system detects an optimization anomaly, it first obtains the current optimizer status through checkpoint triggering and reporting mechanisms, including information such as target tracking, update norm, and current hints. Simultaneously, the system reviews previous repair records, matches fault signatures with past patch results, infers patch_file details, and generates patch actions for the target step configuration.

[0107] In the optimizer parameter module, the system first classifies anomaly types using a sub-classifier, including stagnation, target regression, direction error, and oscillation. Subsequently, the policy selector chooses the appropriate repair policy based on the anomaly type, and the patch action builder generates specific parameter correction instructions. Adjustable optimizer parameters include learning rate, beta, penalty, maximum number of iterations, and weights.

[0108] Based on the above analysis and parameter adjustments, the system determines the rollback target, performs verification and reruns, and finally records the repair results. Throughout the process, the configuration bundle (including optimizer hints, learning rate, beta, penalty weights, maximum number of iterations, etc.) is continuously updated and maintained to ensure the traceability and reproducibility of the repair actions.

[0109] Figure 9 It has been further clarified Figure 8 The specific implementation details of the closed loop recovery from the obstructed reverse optimization design include real-time monitoring of the optimizer status, automatic classification of anomaly types, intelligent selection of repair strategies, and precise execution of parameter correction, demonstrating the system's autonomous diagnosis and recovery capabilities when optimization anomalies occur.

[0110] To more clearly illustrate the practical application effects of this disclosure, a detailed explanation is provided below using a specific design example of a 1×5 multimode interferometry (MMI) mode multiplexer. This example will comprehensively demonstrate the flow of the system state machine and the coordinated operation of various mechanisms.

[0111] In this example, the system state machine includes the following states: Idle, Requirement Parsed, Context Retrieved, Configuration Generated, Five-Case Mapping Verification, Configuration Verified, Five-Case Optimization Run, Checkpoint Passed, Checkpoint Failed, Recovery Diagnosis, Rollback Selection, Local Replanning, Recovery Execution, Result Encapsulation, and Termination. State transitions are driven by structured events. Each event record includes the event type, step number, task identifier, timestamp, five-case configuration summary, last heartbeat stage, input summary, output summary, issue item, evidence reference, and artifact path.

[0112] The user entered the following natural language design request: "Design a 1×5 MMI mode multiplexer with a center wavelength of 1550nm and a design area size of 10μm×6μm. The device includes one multimode trunk output port and five single-mode input ports. The waveguide width of the output port is 3000nm, used to support and monitor five target modes: TE0, TE1, TE2, TE3, and TE4; the waveguide width of each of the five single-mode input ports is 500nm, and each input port only excites the TE0 mode." The system transitions from an idle state to a request parsed state, performing semantic parsing to transform the aforementioned request into a structured requirement object. The system generates five source switching target cases: the first target case maps the TE0 mode of input port 1 to the TE0 mode of the output port; the second target case maps the TE0 mode of input port 2 to the TE1 mode of the output port, and so on, until the fifth target case maps to the TE4 mode. These five target cases constitute the fixed port mode mapping constraint for subsequent optimization.

[0113] Subsequently, the system enters the context-retrieved state and retrieves historical scenarios based on multi-level memory states. If there are failure records in the long-term task memory such as "the pattern multiplexer configuration has degraded to a 1×2 device" or "the number of output port modes is unobservable", the system will write these records into the task context as preventative constraints.

[0114] With the configuration already generated, the system generates a configuration package, setting the objective function type to pattern multiplexing routing, the number of objective cases to 5, and the number of output port pattern expansions to 5. The optimization objectives include both objective pattern purity, transmission efficiency, and non-target pattern crosstalk penalties. For different objective patterns, the coupling efficiency weights are set decreasing in order of modulus (TE0 to TE4 are set to 1.00, 0.90, 0.80, 0.70, and 0.60 respectively) to balance the optimization difficulty of higher-order patterns.

[0115] Upon entering the five-case mapping verification state (pre-run verification), the system performs strong verification. Assume that during the configuration generation phase, due to the illusion of a large model, the number of output port pattern expansions was incorrectly generated as 2. The configuration verification module, during verification, finds that the "whether the number of output port pattern expansions equals 5" check fails, identifying a "1×5 mapping constraint drift" error. The system triggers the first rollback operation, calculates the rollback confidence, and then rolls back to the configuration generation phase (local replanning state). The repair action is "restore the number of output port pattern expansions to 5." After repair, verification is repeated until the configuration package satisfies the five-way pattern reuse contract, at which point the system transitions to the configuration verified state.

[0116] After successful verification, the system enters the five-case optimization runtime state. The reverse design execution module performs accompanying reverse optimization with five source-switching target cases as a complete iterative unit. Each iteration contains five input cases, and the system calculates the target mode purity, transmission efficiency, and crosstalk respectively, summarizing them into the objective function of the current iteration. During the optimization process, the system progresses according to preset heartbeat stages and saves the checkpoint state every 50 iterations.

[0117] Suppose that in the 200th iteration, the system detects a purity stagnation in higher-order modes TE3 and TE4, and crosstalk exceeds the threshold, indicating an optimization anomaly. The state machine transitions to the checkpoint failure state and then enters the recovery diagnostic state. The diagnostic recovery module generates a failure snapshot, determining the cause of the anomaly to be abnormal optimization parameters. The system identifies the local rollback point as the historical checkpoint of the 150th iteration and inputs the current features into the pre-trained parameter evaluation model. By calculating the importance of permutations, model analysis reveals that the projection parameters and learning rate contribute the most, with the projection parameters contributing significantly, indicating that the current projection threshold is too high, causing premature binarization of the structure and limiting the evolution space of higher-order modes. The system enters the rollback selection state and the local replanning state, generating a parameter correction instruction: "Reduce the projection parameters to slow down the binarization speed and fine-tune the learning rate." The system resumes execution from the historical checkpoint of the 150th iteration (resumption execution state). After applying the correction instruction, the optimization process successfully exits the stagnation zone.

[0118] After final optimization, the system enters the result encapsulation state and outputs the design result package. For example... Figure 10The diagram shows a schematic of the design result package in this embodiment. This result package comprehensively demonstrates the optimization results and physical characteristics of the 1×5 MMI mode multiplexer. Specifically, (a) shows the objective function (FOM) optimization process, reflecting the convergence trajectory under multi-objective weight balancing; (b) shows the mode conversion rate optimization process, proving that the purity of each objective mode generally increases with iteration; (c) shows the topology of the final design scheme, presenting a non-intuitive, efficient optical routing topology; (d) shows the insertion loss and crosstalk characteristics of the target modes, verifying the low loss and high isolation of the device over a wide wavelength range; (e) shows the three-dimensional structure and port layout view of the device independently modeled by artificial intelligence, reflecting the deep integration of data-driven and physical simulation; (f) shows the simulated mode distribution curve at the five-channel output multimode waveguide at a wavelength of 1550nm, intuitively reflecting the good separation of the five modes from TE0 to TE4; and (g) shows the simulation results of the optical propagation process at a wavelength of 1550nm, verifying the lossless transmission and mode conversion process of the optical signal inside the device. The system then enters the termination state. This results package allows users to comprehensively evaluate device performance and the reliability of the optimization process.

[0119] It should be noted that this example uses a 1×5 MMI mode multiplexer, but this disclosure is not limited to this. For other types of photonic devices such as power splitters, wavelength splitters, mode splitters, mode multiplexers, ring resonators, directional couplers, cross waveguides, grating couplers, and polarization rotators, the same parametric analysis, search-enhanced configuration generation, pre-run verification, adjoint optimization, and failure recovery process can be adopted. For different device types or different material systems, only the device structure template, material parameters, port width, number of target modes, and target optical indicators (such as conversion efficiency, insertion loss, crosstalk, target mode purity, operating bandwidth, and port power ratio) need to be replaced to obtain the optimized structure and process parameters for the corresponding device type, demonstrating the universality and transferability of this disclosure.

[0120] Next, we will combine Figure 11 The modular architecture of this disclosure is described. Figure 11 A schematic diagram of the generative artificial intelligence system structure in an embodiment of this disclosure is shown.

[0121] like Figure 11As shown, the system includes a requirement parsing module 101, a document context retrieval module 102, a configuration generation module 103, a configuration verification module 104, a reverse design execution module 105, a failure diagnosis and recovery module 106, a result encapsulation module 107, and a memory management module 108. The requirement parsing module 101 receives natural language design requests; the document context retrieval module 102 retrieves simulation rules and historical repair records based on the parsing results; the configuration generation module 103 outputs a configuration package; the configuration verification module 104 performs semantic and physical checks before execution; the reverse design execution module 105 calls the photon simulation and accompanying optimization backend; the failure diagnosis and recovery module 106 performs diagnosis, rollback, replanning, and recovery upon failure or stall; the result encapsulation module 107 outputs a complete evidence package for the current design task; and the memory management module 108 runs through all the above modules, used to save and recall structured records of the current and historical tasks.

[0122] Specifically, the requirement parsing module 101 is used to receive natural language design requests and parse them to obtain structured requirement objects. The structured requirement objects include device type, operating wavelength or band, input port, output port, target mode, target optical specifications, simulation conditions, physical constraints, and manufacturing constraints.

[0123] The document context retrieval module 102 is used to retrieve and generate task context from the knowledge base based on the structured requirement object by calling the generative artificial intelligence model. The task context includes device design examples, simulation rules, physical thresholds, manufacturing limitations, and historical repair records.

[0124] The configuration generation module 103 is used to generate a configuration package based on the structured requirement object and the task context. The configuration package includes simulation configuration, optimization configuration and runtime configuration.

[0125] The configuration verification module 104 is used to perform pre-run physical verification on the configuration package, identify error types and perform partial rollback correction, that is, only roll back to the identified step and its direct downstream dependencies for correction, keeping the verified upstream configuration unchanged.

[0126] The reverse design execution module 105 is used to perform reverse optimization of photonic devices according to the configuration package when the verification result meets the preset conditions, and to record the iteration trajectory, objective function value, monitor reading, checkpoint report and optimizer status.

[0127] The failure diagnosis and recovery module 106 is used to detect anomalies in the optimization process. When an anomaly is detected, it generates parameter correction instructions based on historical optimization logs, failure diagnoses, and similar scenario recalls, and recovers the optimization process from the local rollback point according to the parameter correction instructions.

[0128] The result encapsulation module 107 is used to encapsulate the optimization results, simulation products, layout products, checkpoint records, and recovery evidence into a design result package.

[0129] The memory management module 108 is used to save and recall structured records during the execution of the above steps. The memory management module includes short-term contextual memory, medium-term working memory and long-term task memory. The historical repair records are stored in the long-term task memory. The short-term contextual memory is used to save the input, output and diagnostic events of the current step. The medium-term working memory is used to save cross-step constraints and repair evidence in a design task. The long-term task memory is used to save historical design scenarios and their repair solutions.

[0130] Based on the same inventive concept, this disclosure also provides a photonic device reverse design system, as shown in the following embodiment. Since the principle of solving the problem in this photonic device reverse design system embodiment is the same as that described above... Figure 1 The method embodiments shown are similar, therefore, the implementation of this photonic device reverse design system embodiment can be found above. Figure 1 The implementation of the method embodiments shown will not be repeated here.

[0131] Figure 12 A schematic diagram of a reverse design system for photonic devices according to an embodiment of this disclosure is shown. Figure 12 As shown, the photonic device reverse design system 1200 includes: a configuration generation module 1201, a configuration verification module 1202, a reverse design execution module 1203, a diagnostic recovery module 1204, and a result encapsulation module 1205.

[0132] The configuration generation module 1201 is used to obtain the design request of the photonic device and generate a configuration package according to the design request. The configuration package is used to define the simulation environment, optimization objectives and operating rules of the photonic device. The configuration verification module 1202 is used to perform pre-run verification on the configuration package. If the pre-run verification fails, a first rollback operation is performed to correct the steps in the configuration package generation process that have errors and their downstream dependent steps. The reverse design execution module 1203 is used to perform reverse optimization of photonic devices according to the configuration package after the pre-run verification is passed, and to record the checkpoint status during the optimization process; The diagnostic recovery module 1204 is used to perform a second rollback operation when an optimization anomaly is detected, so as to resume execution from a local rollback point; wherein the local rollback point is determined according to the checkpoint status, and the determined local rollback point is a historical execution stage in the design process or a historical checkpoint in the optimization process; The result encapsulation module 1205 is used to encapsulate the optimization results into a design result package for the photonic device after the reverse optimization of the photonic device is completed.

[0133] In some embodiments, the configuration generation module 1201 is used to perform semantic parsing on the design request to obtain a structured requirement object; based on the structured requirement object, retrieve historical design scenarios and repair records from the knowledge base to generate a task context; and generate the configuration package containing simulation parameters, optimization parameters, and running parameters according to the structured requirement object and the task context.

[0134] In some embodiments, the configuration verification module 1202 is configured to identify configuration error types that cause the configuration package to fail pre-run verification; based on the configuration error type, select corresponding candidate rollback steps from multiple historical execution stages included in the configuration package generation process; calculate the rollback confidence of each candidate rollback step based on preset multi-dimensional evaluation factors, the multi-dimensional evaluation factors including at least one of causal proximity, evidence consistency, memory hit, historical success rate, and change risk; determine the candidate rollback step with the highest rollback confidence as the step where the error occurred, and roll back to that step and its downstream dependent steps for correction.

[0135] In some embodiments, the diagnostic recovery module 1204 is used to perform failure diagnosis on the optimization anomaly to determine the cause of the anomaly; if the cause of the anomaly is an abnormal optimization parameter, the local rollback point is determined as a historical checkpoint in the optimization process, and the contribution of each optimization control parameter to the optimization anomaly is analyzed using a parameter evaluation model pre-trained based on historical optimization data, and a parameter correction instruction is generated according to the contribution, and execution is resumed from the determined historical checkpoint; wherein, the optimization control parameters include at least one of learning rate, projection parameter, penalty term weight, objective function weight, and optimizer restart strategy; if the cause of the anomaly is an abnormal simulation configuration, the local rollback point is determined as a historical execution stage in the design process, and the corresponding simulation configuration parameters are repaired, and execution is resumed from the determined historical execution stage; wherein, the historical execution stage includes a configuration generation stage or a configuration verification stage.

[0136] In some embodiments, the configuration generation module 1201 is used to perform retrieval based on a preset multi-level memory state, which includes short-term contextual memory, medium-term working memory, and long-term task memory; when recalling historical design scenarios from the multi-level memory state, it matches the corresponding identifier of the historical design scenario based on the failure signature and scenario fingerprint of the current design request; in the case of no match, it calculates the comprehensive similarity between the current design request and the historical design scenario by combining vector similarity, keyword overlap, and recentity; when the comprehensive similarity reaches a preset threshold, it uses the corresponding historical design scenario as the basis for repair to generate the task context.

[0137] In some embodiments, the configuration verification module 1202 is used to perform basic physical logic verification on the configuration package. The basic physical logic verification includes at least one of source and monitor coverage verification, port direction verification, boundary distance verification, mode number verification, and objective function direction verification.

[0138] In some embodiments, the configuration verification module 1202 is further configured to obtain the expected mode mapping relationship between the input port and the output port of the photonic device; in the basic physical logic verification, verify whether the number of target response cases and the number of mode unfoldings under different excitation source configurations match the expected mode mapping relationship; if a mismatch is found during verification, it is identified as a mapping relationship configuration error, and the first rollback operation is triggered.

[0139] In some embodiments, the reverse design execution module 1203 is used to advance the optimization process according to a preset heartbeat stage, the preset heartbeat stage including a forward simulation stage, a companion simulation stage and a post-processing stage; if no state update event is detected within a preset time in the post-processing stage after the completion of the companion simulation stage, failure evidence is recorded and duplicate submissions are blocked through an event-free monitoring mechanism.

[0140] In some embodiments, the reverse design execution module 1203 is used to save the current design variable distribution, objective function evaluation results, and optimizer internal state according to a preset checkpoint interval during the optimization iteration process, so as to construct the historical checkpoints.

[0141] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

Claims

1. A method for reverse engineering photonic devices, characterized in that, include: Obtain design requests for photonic devices; A configuration package is generated based on the design request. The configuration package is used to define the simulation environment, optimization objectives, and operating rules of the photonic device. The configuration package is pre-run verified, which includes at least matching and verifying the number of target response cases and the number of mode unfoldings under different excitation source configurations based on the expected mode mapping relationship between the input port and output port of the photonic device. If the pre-run verification fails, the first rollback operation is performed to correct the steps in the configuration package generation process that resulted in errors and their downstream dependencies. If the pre-run verification passes, reverse optimization of the photonic device is performed according to the configuration package, and the checkpoint status during the optimization process is recorded; If an optimization anomaly is detected, a second rollback operation is performed to resume execution from a local rollback point; wherein, the local rollback point is determined based on the checkpoint status, and the determined local rollback point is a historical execution phase in the configuration package generation process or a historical checkpoint in the optimization process; Once the reverse optimization of the photonic device is completed, the optimization results are packaged into a design result package for the photonic device.

2. The method according to claim 1, characterized in that, The step of generating a configuration package based on the design request includes: The design request is semantically parsed to obtain a structured requirement object; Based on the structured requirement object, historical design scenarios and repair records are retrieved from the knowledge base to generate a task context; Based on the structured requirement object and the task context, a configuration package containing simulation parameters, optimization parameters, and runtime parameters is generated.

3. The method according to claim 1, characterized in that, The execution of the first rollback operation includes: Identify the types of configuration errors that caused the configuration package to fail pre-run verification; Based on the configuration error type, corresponding candidate rollback steps are selected from multiple historical execution stages included in the configuration package generation process; The rollback confidence of each candidate rollback step is calculated based on preset multi-dimensional evaluation factors, which include at least two of causal proximity, evidence consistency, memory hit, historical success rate, and change risk. The candidate rollback step with the highest rollback confidence is identified as the step where the error occurred, and the process is rolled back to that step and its downstream dependent steps for correction.

4. The method according to claim 1, characterized in that, The execution of the second rollback operation includes: The optimization anomalies are diagnosed to determine the cause of the anomalies; When the cause of the anomaly is an abnormal optimization parameter, the local rollback point is determined as a historical checkpoint in the optimization process. The contribution of each optimization control parameter to the optimization anomaly is analyzed using a parameter evaluation model pre-trained based on historical optimization data. Parameter correction instructions are generated based on the contribution, and execution resumes from the determined historical checkpoint. The optimization control parameters include at least one of the following: learning rate, projection parameter, penalty term weight, objective function weight, and optimizer restart strategy. If the cause of the anomaly is a simulation configuration anomaly, the local rollback point is determined to be a historical execution stage in the configuration package generation process, and the corresponding simulation configuration parameters are repaired to resume execution from the determined historical execution stage; wherein, the historical execution stage includes the configuration generation stage or the configuration verification stage.

5. The method according to claim 2, characterized in that, The step of retrieving historical design scenarios and repair records from the knowledge base based on the structured requirement object to generate a task context includes: Retrieval is performed based on a preset multi-level memory state, which includes short-term episodic memory, medium-term working memory, and long-term task memory. When recalling historical design scenarios from the multi-level memory state, the failure signature and scenario fingerprint of the current design request are matched with the corresponding identifier of the historical design scenario. In the case of a match, the matched historical design scenario will be used as the basis for repair to generate the task context; In the event of no match, the comprehensive similarity between the current design request and the historical design scenario is determined based on vector similarity, keyword overlap, and recentity. If the comprehensive similarity meets the preset conditions, the corresponding historical design scenario is used as the basis for repair to generate the task context.

6. The method according to claim 1, characterized in that, The pre-run verification of the configuration package includes: The configuration package is subjected to basic physical logic verification, which includes at least one of the following: source and monitor coverage verification, port direction verification, boundary distance verification, mode quantity verification, and objective function direction verification.

7. The method according to claim 6, characterized in that, The method further includes: Obtain the expected mode mapping relationship between the input port and the output port of the photonic device; In the basic physical logic verification, based on the expected pattern mapping relationship, the number of target response cases and the number of pattern unfoldings under different excitation source configurations are verified to be consistent.

8. The method according to claim 1, characterized in that, The step of performing photonic device inverse optimization according to the configuration package includes: The optimization process is advanced according to a preset heartbeat stage, which includes a forward simulation stage, a follow-up simulation stage, and a post-processing stage. If no state update event is detected within a preset time during the post-processing stage following the completion of the accompanying simulation stage, failure evidence is recorded and duplicate submissions are blocked through an event-free monitoring mechanism.

9. The method according to claim 1, characterized in that, The checkpoint status during the record optimization process includes: During the optimization iteration process, the current design variable distribution, objective function evaluation results, and optimizer internal state are saved according to the preset checkpoint interval to construct the historical checkpoints.

10. A reverse design system for photonic devices, characterized in that, include: A configuration generation module is used to obtain design requests for photonic devices and generate configuration packages based on the design requests. The configuration packages are used to define the simulation environment, optimization objectives, and operating rules of the photonic devices. The configuration verification module is used to perform pre-run verification on the configuration package. If the pre-run verification fails, a first rollback operation is performed to correct the steps that erroneously occurred during the configuration package generation process and their downstream dependent steps. The reverse design execution module is used to perform reverse optimization of photonic devices according to the configuration package after the pre-run verification is passed, and to record the checkpoint status during the optimization process; The diagnostic recovery module is used to perform a second rollback operation when an optimization anomaly is detected, so as to resume execution from a local rollback point; wherein the local rollback point is determined according to the checkpoint status, and the determined local rollback point is a historical execution stage in the configuration package generation process or a historical checkpoint in the optimization process; The result encapsulation module is used to encapsulate the optimization results into a design result package for the photonic device after the reverse optimization of the photonic device is completed.

Images