Optical fiber communication system modeling and simulation method based on graph native modeling programming

Abstract

The invention provides an optical fiber communication system modeling and simulation method based on graph native modeling programming. According to the method, a DSL standard and specification system with a graph structure as a core is constructed, and devices, signal paths and transmission relations in the system are abstracted into the graph structure in a unified mode. The DSL comprises a data structure type, an entity and function classification mechanism, a parameter configuration mode and a modular expansion interface. The system operation architecture comprises a front-end analysis module and a rear-end execution module. The front-end analysis module analyzes a user modeling script into a graph intermediate representation. And the rear-end module performs optimization, byte code compilation and virtual machine execution on the graph intermediate representation to obtain a simulation result. In the implementation level, a function mapping modeling method is adopted, input, output and configuration parameters of equipment are in mapping association with an optical fiber communication assembly, and a hierarchical simulation model from a device to a system is constructed through function combination and nesting. The method has the intuition of graph structure modeling and the flexibility of a programming interface, and can efficiently support the simulation requirements of multi-level users.

Description

Technical Field

[0001] This invention relates to the field of optical fiber communication technology, and in particular to a method for modeling and simulating optical fiber communication systems based on graph native modeling programming. Background Technology

[0002] Directed acyclic graphs (DAGs) are widely used in graph algorithms, data flow analysis, program optimization, and machine learning tasks, and also play an important role in industrial modeling and simulation. Representing DAGs using a general-purpose programming language (GPL) or data serialization format (DSF) can lead to complex and obscure expressions, making it difficult to understand and manage the codebase.

[0003] A Domain Specific Language (DSL) is a computer programming language designed for a specific domain. DSLs provide a highly abstract way of expressing concepts, operations, and business logic by creating language structures that are highly relevant to the concepts, operations, and business logic of that domain. Compared to general-purpose programming languages, DSLs have more concise and abstract syntax. Within a specific application domain, DSLs enable clearer, more precise, and more systematic program descriptions, significantly reducing the difficulty of learning and using them, thereby improving development and usage efficiency.

[0004] Directed Acyclic Graphs (DAGs) have wide applications across various fields. In graph algorithms, DAGs help solve problems such as shortest paths and longest paths, providing efficient computational solutions. Because DAGs are cycle-free, algorithms can leverage this characteristic to simplify computation, significantly improving efficiency in many scenarios. In data flow analysis, DAGs clearly represent the dependencies between data processing steps, optimizing the data processing flow. They can be used to build data pipelines, ensuring data is processed in a predetermined order, thereby improving the efficiency and accuracy of data processing. In compiler optimization, DAGs are crucial for optimizing program code execution order and reducing redundant computations. Compilers can use DAGs to analyze data dependencies in program code, rearrange instruction order, reduce unnecessary computations and memory accesses, and effectively improve program execution efficiency.

[0005] In recent years, with the explosive growth of Artificial Intelligence Generative Content (AIGC) technology, more and more people have begun to pay attention to the principles, techniques, and progress in the field of machine learning. It is worth noting that Directed Acyclic Graphs (DAGs) are also used as computational graphs in machine learning. They describe in detail the topological logical relationships between data and operators in a model and are widely used in well-known deep learning frameworks such as TensorFlow and PyTorch. Currently, many experts and scholars are dedicated to research on deep learning compiler technology, with the main goal of improving the execution efficiency of AI models by analyzing and optimizing computational graphs. Through DAG modeling and optimization, complex computational processes can be decomposed into simpler operations, thereby enabling parallel computing and accelerating training, greatly simplifying the training process of deep learning models. It is easy to foresee that DAGs will play an increasingly important role in various fields in the future.

[0006] In recent years, simulation research on fiber optic communication systems has become a key tool for evaluating and optimizing design schemes, analyzing performance, and planning networks. With the rapid advancement of fiber optic communication technology, this method of testing system operation and performance through computer simulation is receiving increasing attention. Fiber optic communication spans multiple disciplines and involves complex computational analysis, placing high demands on human and material resources in both system planning and design and the development of new transmission technologies. To ensure system performance meets standards, repeated experimental testing is typically required. However, directly building experimental models is not only costly and time-consuming but also extremely resource-intensive. Therefore, using computer software for simulation is particularly efficient. By constructing models from components to the overall system and leveraging the powerful computing capabilities of computers, rapid analysis, design, optimization, and performance evaluation of fiber optic communication equipment and systems can be achieved at low cost. Developing an efficient fiber optic communication simulation software platform can not only improve R&D efficiency and shorten product time-to-market but also significantly reduce investment costs and effectively promote the development of fundamental theories in fiber optic communication.

[0007] Currently, most existing fiber optic communication simulation platforms adopt a graphical user interface (GUI) approach. By providing a visual interactive space similar to a "canvas," users can easily arrange optical devices and establish connections between them through dragging, clicking, and other methods. This approach is intuitive and easy to understand, making it extremely user-friendly for novice users.

[0008] The shortcomings of existing fiber optic communication simulation platforms include: for advanced users with higher demands for automated modeling and batch simulation, graphical interfaces suffer from significant limitations such as low interaction efficiency, poor reusability, and difficulty in automated programming. To meet the needs of such users, some traditional simulation platforms provide low-level programming interfaces, such as C-language APIs. However, these interfaces typically have a low level of abstraction, a steep learning curve, and are difficult to learn quickly. Especially when dealing with communication systems with complex topologies, using general-purpose programming languages ​​for graph structure modeling is not only complex and error-prone, but also has poor readability and maintainability. Summary of the Invention

[0009] This invention provides a modeling and simulation method for optical fiber communication systems based on graph native modeling programming, offering an innovative solution for efficient modeling and simulation of optical fiber communication systems.

[0010] To achieve the above objectives, the present invention adopts the following technical solution.

[0011] A method for modeling and simulating fiber optic communication systems based on graph-native modeling programming, comprising: Design standards and specifications for domain-specific DSLs based on graph structures; Based on the standards and specifications of the DSL language, a front-end parsing module and a back-end execution module for the DSL language runtime are designed. The front-end parsing module and the back-end execution module are trained using a modeling script of an optical fiber communication system that conforms to the DSL language specifications, resulting in a trained front-end parsing module and a back-end execution module. Based on the standards and specifications of the DSL language, a simulation script for the optical fiber communication system is written. The simulation script for the optical fiber communication system is run using the trained front-end parsing module and back-end execution module, and the optical fiber communication simulation system is output.

[0012] Preferably, the design is based on the standards and specifications of graph-structured DSL languages, including: The graph-based DSL language uses optical devices as nodes and signal transmission paths as edges to construct a unified graph representation model. The standards and specifications of the DSL language include data structure definitions, basic syntax, modeling semantics, connection relationship expression methods, and parameter configuration mechanisms. The data structure definition of the DSL language includes referring to data as entities and entities with operation definitions as functors. An entity is a general term for all data or objects, including text, scalars, vectors, and structured data. A functor receives ordinary input parameters and context input parameters, processes them, and returns the calculation results. Users are allowed to define custom functors to encapsulate custom operations on entity data.

[0013] Preferably, the step of designing the front-end parsing module and back-end execution module for the DSL language runtime based on the standards and specifications of the DSL language, and training the front-end parsing module and back-end execution module using a modeling script of an optical fiber communication system conforming to the DSL language specifications to obtain trained front-end parsing modules and back-end execution modules includes: Write a certain number of modeling scripts for optical fiber communication systems that conform to the standards and specifications of the DSL language, and use all the modeling scripts to build a script database; Based on the standards and specifications of the DSL language, a front-end parsing module and a back-end execution module for the DSL language runtime are designed. The front-end parsing module and the back-end execution module are trained using the script database. The modeling scripts from the script database are input into the front-end parsing module, which performs lexical analysis on the input modeling scripts to obtain a word stream. Then, the word stream undergoes syntactic analysis to generate a concrete syntax tree and an abstract syntax tree. Further semantic analysis is performed on the concrete syntax tree and the abstract syntax tree to obtain a graph construction tree. Finally, type checking and intermediate representation generation are performed on the graph construction tree to obtain an intermediate data structure representation of the graph structure. This intermediate data structure representation of the graph structure is transmitted to the back-end execution module. The back-end execution module performs multiple rounds of graph optimization on the input intermediate data structure representation of the graph structure to obtain an optimized intermediate graph representation. Then, the optimized intermediate graph representation is compiled and optimized into bytecode, resulting in bytecode executable by the underlying virtual machine. The bytecode is interpreted and executed using the bytecode virtual machine built into the DSL language runtime to obtain the calculation results. Based on the deviation between the calculated result and the expected result, the parameters of the front-end parsing module and the back-end execution module are adjusted accordingly, and the above process is repeated to obtain the trained front-end parsing module and back-end execution module.

[0014] Preferably, the simulation script for the optical fiber communication system, written based on the standards and specifications of the DSL language, is run using the trained front-end parsing module and back-end execution module to output the optical fiber communication simulation system, including: A simulation script for an optical fiber communication system is written based on the standards and specifications of the DSL language. In this simulation script, the type, parameter configuration, and signal port of each optical device are expressed through node definitions, and the transmission path of the signal between different devices is characterized by edge definitions. The simulation script is input into a trained front-end parsing module, which parses the simulation script into an intermediate data structure representation of a graph. The back-end execution module parses, optimizes, and executes the intermediate data structure representation of the graph generated by the front-end parsing module, and outputs the optical fiber communication simulation system, as well as the performance indicators of the optical signal power change, link loss, and dispersion affecting the amplifier gain characteristics of the optical fiber communication simulation system. In the simulated fiber optic communication system, functors are used to describe the simulated devices. The input and output of the functors correspond to the input and output signals of the devices. The ordinary input parameters of the functors correspond to the signal inputs of each simulated device, while the context input parameters of the functors represent the settings of the devices themselves. The calling relationship between the functors is used to express the real topology and data flow of the entire fiber optic communication simulation system. The nested calling of functors is used to express the simulation behavior of components, modules, and even the entire fiber optic communication simulation system composed of basic components.

[0015] As can be seen from the technical solutions provided by the embodiments of the present invention above, the present invention provides an innovative solution for efficient modeling and simulation of optical fiber communication simulation systems by introducing a graph-native domain modeling language. It retains the intuitiveness of graph structure modeling and also has the flexibility of programming interface, which can effectively meet the diverse needs of users at different levels.

[0016] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and will become apparent from the description or may be learned by practice of the invention. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a modeling and simulation method for an optical fiber communication system based on graph native modeling programming, provided in an embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the definition syntax of a custom functor provided in an embodiment of the present invention; Figure 3 A schematic diagram illustrating a syntax example provided in an embodiment of the present invention; Figure 4 This is an example diagram illustrating an entity construction syntax provided in an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating a simple directed acyclic graph provided in an embodiment of the present invention. Figure 6 This is a schematic diagram of a concrete syntax tree partial structure provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of a partial structure of an abstract syntax tree provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of a graph-constructed tree structure provided in an embodiment of the present invention; Figure 9 A visual representation diagram provided for an embodiment of the present invention; Figure 10 This is a schematic diagram of a visualization obtained by compiling a simulation case according to an embodiment of the present invention. Detailed Implementation

[0019] Embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0020] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. The term “and / or” as used herein includes any and all combinations of one or more of the associated listed items.

[0021] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless defined as herein.

[0022] To facilitate understanding of the embodiments of the present invention, the following will provide further explanation and description with reference to the accompanying drawings and several specific embodiments. These embodiments do not constitute a limitation on the embodiments of the present invention.

[0023] This invention abstracts an optical fiber communication system as a directed acyclic graph (DAG) structure composed of multiple optical device nodes and their connections. Different optical devices serve as nodes in the graph, and the data flow between devices is represented by directed edges, thus forming a transmission system model with a well-defined topology. Modeling and simulating an optical fiber communication system is essentially modeling and simulating the behavior of this type of directed acyclic graph.

[0024] This invention proposes and implements a graph-native domain-specific modeling language (DSL). Based on graph theory, this language constructs a dedicated syntax, semantics, and execution model around the modeling needs of optical fiber communication systems. It can efficiently and intuitively express various device nodes and their connections within the system, thereby enabling automated modeling and simulation of optical communication systems. Through this language, advanced users can quickly define system structure, parameter configurations, and operational logic programmatically without a graphical interface, greatly improving modeling efficiency and simulation automation. Furthermore, the language's high degree of abstraction and encapsulation of graph structure modeling semantics makes the modeling process more consistent with the logical expression habits of communication systems, lowering the user threshold and improving system maintainability and scalability.

[0025] This invention relates to a graph-native modeling method for optical fiber communication simulation, specifically including three aspects: the formulation of modeling language standards, runtime implementation, and the development of simulation calculation cases, aiming to improve the efficiency, programmability, and automation level of optical communication system modeling and simulation.

[0026] The processing flow of a modeling and simulation method for optical fiber communication systems based on graph native modeling programming provided in this embodiment of the invention is as follows: Figure 1 As shown, the processing steps include the following: Step S10: Design the standard and specification for a graph-based DSL language.

[0027] This invention establishes a domain-specific language (DSL) standard and specification system centered on graph structures. By abstracting devices, signal paths, and transmission relationships in fiber optic communication systems into a unified graph structure, it achieves structured representation and unified language-level definition between system components. This standard and specification covers data structure types, entity and functor classification mechanisms, parameter configuration methods, and modular extension interface definitions, thereby ensuring the consistency and scalability of the language across different simulation platforms and runtime environments. Through this design, the modeling process of fiber optic systems can be directly unfolded with the support of graph semantics, clearly describing the system topology and providing a unified intermediate representation for subsequent computations.

[0028] This invention first designs a standard and specification for a graph-based DSL language for formal modeling of optical fiber communication systems. This DSL standard and specification treats optical devices in the system as graph nodes and signal transmission paths as graph edges, constructing a unified graph representation model to achieve a structured description of device topology and signal flow.

[0029] The DSL language standard and specification define the basic syntax rules, data structure types, classification methods for entities and functors, and parameter configuration mechanisms. Entities are used to represent various data objects, including scalar and structured data; functors are used to represent functional components that can process entities, accepting both ordinary input parameters and context parameters related to device configuration, thereby accurately expressing the operating state of the device.

[0030] The DSL language standard and specification also define modular modeling and connection relationship expression methods, enabling users to directly reflect the real topology of the optical fiber communication system by describing the logical connections between nodes. The semantic design ensures the language has good readability, extensibility, and portability, and can adapt to various complex system structures. Step S20: Based on the DSL language standard and specification, design the front-end parsing module for the DSL language runtime. The front-end parsing module parses the input modeling script conforming to the DSL language specification into an intermediate data structure representation of a graph structure.

[0031] Based on the standards and specifications of the DSL language, this invention develops a front-end parsing module for the DSL language runtime, used to receive and parse user-written modeling scripts that conform to the standards and specifications of the DSL language. The front-end parsing module first performs lexical analysis on the modeling script, segmenting the input source code into a token stream; then, it performs syntax analysis on the token stream to generate a concrete syntax tree and an abstract syntax tree; finally, it constructs a graph tree by performing semantic analysis on the concrete syntax tree and the abstract syntax tree, ensuring that the model structure is consistent with the system semantics.

[0032] The type checking phase verifies the matching of signal types and connection relationships in the script to prevent incompatible or logically flawed models from entering the simulation calculation. Finally, the front-end parsing module generates an intermediate data structure representation of the graph structure that conforms to DSL semantics. This intermediate data structure representation contains node parameters, edge connection information, and the overall topology, and is the sole input to the back-end execution module.

[0033] This front-end parsing module adopts a modular design, supporting operation as a standalone tool or integration into existing simulation platforms. Its cross-platform capability ensures stable operation under different hardware and operating system environments, achieving efficient conversion from the language layer to the data structure layer.

[0034] Step S30: Design the backend execution module for the DSL language runtime based on the DSL language standard and specification. The backend execution module parses, optimizes, and executes the intermediate data structure representation of the graph structure generated by the frontend parsing module. The frontend parsing module and backend execution module are trained using a modeling script for an optical fiber communication system conforming to the DSL language specification, resulting in trained frontend parsing and backend execution modules.

[0035] This invention further develops a backend execution module for the DSL language runtime. This backend execution module is used to interpret and execute the intermediate data structure representation generated by the frontend parsing module. The backend execution module first performs multiple optimizations on the intermediate data structure representation of the input graph structure, including simplifying redundant nodes and inlining function calls, to improve runtime efficiency.

[0036] The optimized intermediate data structure will be compiled into bytecode, and the bytecode format is compatible with the virtual machine execution engine that comes with this invention. This virtual machine execution engine supports calling the corresponding functors sequentially according to the traversal order of the graph structure to realize the transmission and processing of signals in the system, and records the calculation results of various simulation indicators.

[0037] The backend execution module can not only accurately reproduce the physical behavior of fiber optic communication systems, but also quickly achieve multi-scenario simulations at the device, link, and system levels by modifying functor parameters. Its scalable execution architecture allows users to insert custom optimization algorithms or result processing modules during runtime, thereby meeting the needs of different research and engineering environments.

[0038] A certain number of modeling scripts for optical fiber communication systems conforming to the standards and specifications of the DSL language are compiled, and a script database is constructed using all the modeling scripts. The front-end parsing module and the back-end execution module are trained using the script database. The modeling scripts in the script database are input into the front-end parsing module, which performs lexical analysis on the input modeling scripts to obtain a token stream; then, it performs syntactic analysis on the token stream to generate a concrete syntax tree and an abstract syntax tree; further, it performs semantic analysis on the concrete syntax tree and the abstract syntax tree to obtain a graph construction tree; finally, it performs type checking and intermediate representation generation on the graph construction tree to obtain an intermediate data structure representation of the graph structure, which is then transmitted to the back-end execution module. The back-end execution module performs multiple graph optimizations on the input intermediate data structure representation of the graph structure to obtain an optimized intermediate graph representation; then, it performs bytecode compilation and optimization on the optimized intermediate graph representation to obtain bytecode executable by the underlying virtual machine. The bytecode virtual machine built into the DSL language runtime is used to interpret and execute the bytecode to obtain the calculation results. Based on the deviation between the calculated result and the expected result, the parameters of the front-end parsing module and the back-end execution module are adjusted accordingly, and the above process is repeated to obtain the trained front-end parsing module and back-end execution module.

[0039] Step S40: Based on the standards and specifications of the DSL language, write a simulation script for the optical fiber communication system, run the simulation script of the optical fiber communication system using the trained front-end parsing module and back-end execution module, and output the optical fiber communication simulation system.

[0040] With the support of the aforementioned components, users can write simulation scripts for fiber optic communication systems using the DSL language. The simulation script uses node definitions to express the type, parameter configuration, and signal ports of each optical device, and edge definitions to depict the transmission path of signals between different devices.

[0041] When this simulation script is run, the front-end parsing module converts it into a standardized intermediate graph structure representation, which is then optimized and executed by the back-end execution module. The entire process, from script input to result output, is automated, requiring no manual configuration from the user in any intermediate steps.

[0042] Ultimately, the results will include key performance indicators such as system optical signal power variation, link loss, dispersion effects, and amplifier gain characteristics, which can be used to verify the effectiveness of the design scheme. Based on the method of this invention, the script can be repeatedly executed and quickly generate comparison results under different parameters, providing efficient simulation support for the design and optimization of optical fiber communication systems.

[0043] The above step S10 specifically includes: The concept of the DSL language and the design and definition of its syntax are as follows: 1) Entities and Functors Data and operations are fundamental concepts in programming languages. Data is typically described using terms like objects, instances, and properties, while operations are described using terms like functions, procedures, and methods. In the DSL language of this invention, data is called an entity, and entities with operation definitions are called functors.

[0044] An entity is a collective term for all data or objects in the DSL language of this invention. Entities in the DSL language of this invention mainly include text, scalars, vectors, structured data, and other data types. In the DSL language of this invention, entities can be referenced by name; entities without names are called anonymous entities.

[0045] In the DSL language of this invention, functors are also considered entities and are the primary means of manipulating entity data. A functor receives input parameters, processes them, and returns the calculation result. Unlike functions in other languages, in the DSL language of this invention, functors also have data called hyperparameters. In the field of simulation systems, functors can be used to describe simulation devices. The input and output of a functor correspond to the input and output signals of the device, while the hyperparameters of the functor represent the settings of the device itself.

[0046] The DSL language of this invention allows users to define custom functors to encapsulate custom operations on entity data. The definition of a custom functor begins with the keyword `func`, followed by the functor name, parameter list, return type, and detailed operation definition. Functor modifiers can be added to modify certain default behaviors of user-defined functors. In the DSL language of this invention, functors can be anonymous (also known as lambda functors). Lambda functors can be defined without the `func` keyword and a functor name.

[0047] In the DSL language of this invention, functors have their own data, and users can add context parameters to functors using the with keyword. These context parameters can be defined by a parameter list enclosed in angle brackets.

[0048] The present invention provides a syntax for defining a custom functor, as follows: Figure 2 As shown (angle brackets indicate required syntax elements, square brackets indicate optional syntax elements): 2) Types and Aliases The DSL language of this invention provides a simple type system.

[0049] In the DSL language of this invention, users can use the `type` keyword to declare the type of an entity. Furthermore, users can use the `let` and `use` keywords to assign names to entities (regardless of whether they are anonymous). There are some subtle differences in the usage of the two keywords: the `let` keyword attempts to directly copy the entity (for structured entities, only a shallow copy is performed, not a deep copy), while the `use` keyword simply creates a new alias for the entity.

[0050] In the DSL language of this invention, a colon can be used for type annotation, specifying the expected type of the entity in the entity declaration. The DSL language of this invention supports composite types, such as List. <number>A list, or array, containing only numbers as its elements.<Number, 5> This represents a fixed-length array with 5 numbers. Alternatively, a Map can be used. <String,Map<Int, Any> > is used to represent a compound dictionary with string keys and dictionary values, etc.

[0051] The DSL language of this invention provides mandatory type checking. If a type mismatch occurs, the DSL language of this invention will immediately raise an error at runtime. Figure 3 This is a schematic diagram illustrating a syntax example provided in an embodiment of the present invention.

[0052] 3) Construction and Unpacking

[0053] The DSL language of this invention provides two built-in structured data types: lists and dictionaries. It also provides a concise syntax for constructing and unpacking data.

[0054] In the DSL language of this invention, construction refers to the process of combining multiple entities into a list or dictionary, while unpacking is the reverse process of construction, in which data entities are extracted from the list or dictionary.

[0055] During the construction process, the DSL language of this invention generates anonymous entities by default. This means that it is not necessary to specify a name for the newly constructed entity. However, during the unpacking process, it is necessary to explicitly provide an entity name for referencing the extracted entity.

[0056] In the DSL language of this invention, dictionary literals can be created using curly braces {}. Inside the curly braces, key-value pairs can be defined to represent the data elements of the dictionary. On the other hand, list literals can be created using square brackets []. Inside the square brackets, the individual data elements that will form the list (arranged sequentially) can be specified.

[0057] This concise syntax makes it easy to efficiently assemble and decompose structured data. Figure 4 This is an example diagram illustrating an entity construction syntax provided by an embodiment of the present invention. In this example, a dictionary named Power is constructed with two key-value pairs and can be used as a type in the following code. Then, an anonymous list is constructed by combining the entities linearSignal and dcSource, which will be passed as input parameters to the function AddSignalsEl.

[0058] This example extracts an anonymous dictionary from the phot / el module and assigns the extracted entities to the names AmpSysEl and DC Source. Then, it extracts a list from the result of calling input → PowerMeter on the entities and assigns the extracted entities to the variables dcSource and power.

[0059] 4) References and calls

[0060] In the DSL language of this invention, entity references are implemented through entity names. For structured entity data, such as vectors, tensors, lists, and dictionaries, the DSL language of this invention provides specific syntax for referencing their internal entities.

[0061] To reference a specific element in a vector or matrix, you can use the syntax a[0] or m[1][2], respectively. For dictionaries, use the syntax d[key] to access the referenced element.

[0062] The DSL language of this invention provides a flexible syntax for functor calls, which can be divided into two forms: regular calls and entity calls, both of which support chained operations.

[0063] Regular calls (or functor calls) follow syntax similar to mainstream languages. For example, print(result) means calling the functor print with the parameter result passed in.

[0064] Entity invocation is an innovation of the DSL language in this invention. The initiator of an entity invocation is a specific entity, that is, the entity passed as an input parameter to the called functor. For example, `result → print` represents an invocation of an entity, where `result` is passed as input to the `print` functor. This method aims to concisely express the data dependencies between functors in a directed acyclic graph (DAG).

[0065] In the field of fiber optic analog, the DSL language of this invention allows users to describe the signal propagation relationship between devices using a concise syntax, such as... Figure 5 As shown. For example, the expression signals → comp1 → comp2 → analyzer represents the process by which a signal passes through two components and is ultimately delivered to the visualization analyzer. This feature allows users to accurately describe the signal propagation path and data dependencies, which is invaluable for modeling and analyzing DAGs.

[0066] The above step S20 specifically includes: Based on the DSL standard and specification, this invention designs a language runtime front-end parsing module implementation scheme for parsing standard-compliant modeling script source code and outputting an intermediate graph representation. This scheme sequentially implements the following in the compilation process: fast lexical / syntax parsing and double prediction fallback mechanism, Graph Constructing Tree (GCT) intermediate representation and module dependency consistency resolution, and global semantic analysis and Graph In-Representation (GIR) generation under statically strongly typed conditions. By advancing type evaluation and dependency resolution to the graph constructing tree stage and performing comprehensive type and symbol consistency verification during the semantic analysis stage, this invention ensures the type safety and executability of the computation graph structure at compile time, significantly reduces runtime error risks, and improves system scalability and execution efficiency. The specific implementation steps are as follows: 1) Lexical analysis and syntax tree construction In this implementation, the input source text is first subjected to lexical analysis. Based on predefined lexical rules, the system scans and divides the continuous character stream into a series of lexical units (tokens) with type and positional markers. These lexical rules can be automatically converted into an efficient matching program using an ANTLR generator. Each lexical unit records its row and column information in the source text for subsequent processing and diagnostics. At this stage, the source text is only linearly traversed and pattern matched; semantic judgment is not involved.

[0067] After lexical analysis, these lexical units are sequentially passed to the syntax analysis module. During syntax analysis, a fast parsing strategy based on the SLL prediction mode is prioritized. This mode uses shallow prediction to determine whether the input symbol sequence conforms to predefined grammatical rules, thereby reducing parsing latency. When the prediction mode cannot match complex nested rules, the system automatically switches to the LL prediction mode for complete parsing, and attaches an error listener to capture, record, and output all syntax error information generated during parsing. This two-stage prediction and fallback mechanism balances processing speed and grammatical coverage, effectively handling complex grammatical structures.

[0068] The result of the parsing is represented as a Concrete Syntax Tree (CST). Figure 6 This demonstrates a partial structure of a CST (Concrete Syntax Tree). This structure fully preserves all the syntactic details of the input text, including the hierarchical relationships between terminal and non-terminal symbols and the arrangement of the original symbols. In subsequent steps, the system further transforms this concrete syntax tree into an abstract syntax tree (AST), removing irrelevant syntactic nodes and retaining only the structure directly related to language semantics, thus forming a more compact and easily analyzable internal representation. A partial structure is shown below. Figure 7 As shown. If an error is detected during syntax analysis or abstract syntax tree construction, the system will immediately interrupt the relevant steps to prevent error propagation and output the error record in structured data form, making it easy to integrate into subsequent diagnostic or debugging toolchains.

[0069] This process ensures that lexical and syntax analysis is not merely a static decomposition of text structure, but also forms a crucial foundation for subsequent semantic analysis, optimization, and code generation. By using the lexical and syntax analyzers generated by ANTLR, combined with a phased prediction mode, automatic fallback mechanism, and error collection interface, the parsing process can maintain stability and scalability even in complex language environments, guaranteeing high-performance compilation or interpretation execution for the system.

[0070] 2) Module parsing and graph construction tree construction

[0071] In this implementation, to simplify the process of generating a computation graph directly from an abstract syntax tree, the system introduces an intermediate representation called a Graph Construction Tree (GCT) in the compilation flow, such as... Figure 8 As shown. The significance of the graph construction tree lies in the fact that it not only carries the construction instructions for the computation graph, but also completes preliminary semantic analysis, compile-time constant resolution, and type expression evaluation in advance during the generation phase. By obtaining definite data and type information at this stage, subsequent computation graph generation no longer needs to handle complex syntax parsing and type inference, significantly improving construction efficiency and stability.

[0072] During the actual construction process, the system traverses the abstract syntax tree, translating each syntax node into a corresponding construction instruction node. For example, a function definition generates a node containing the function signature and evaluated type information; a variable or function reference generates a reference node with parameter counts, type bindings, and dependency chains; and literals generate data nodes after being evaluated at compile time, with their values ​​and types stored directly within the node rather than as reserved expressions. For type-related syntax structures, the system performs type inference and evaluation during construction, ensuring that type nodes represent the computed type structure, thus guaranteeing the integrity and usability of type information from the source.

[0073] At this stage, since the evaluation of type expressions may depend on type definitions provided by external modules, if the source text contains module import statements, the system must perform module resolution simultaneously with the construction of the graph construction tree. Module resolution locates and loads the imported module files, translates them into the corresponding graph construction tree structure, and extracts complete type definitions and compile-time constants. This import information is directly written to the type nodes or data nodes of the current graph construction tree, enabling the type calculation of this module to seamlessly reference cross-module information. To achieve this process, the system introduces a global index and dependency resolution mechanism during the resolution phase to ensure consistency in type binding and to mark errors and record dependency links in the construction tree nodes when circular dependencies or missing definitions are detected, facilitating subsequent diagnosis and optimization.

[0074] In this way, the graph construction tree becomes a highly deterministic intermediate layer in the compilation process. Once generated, the entire tree possesses structured graph construction instructions, computed compile-time constants, and directly usable type structures. This not only provides a solid foundation for type checking but also allows subsequent computational graph construction work to rely directly on this deterministic information for efficient generation and optimization, thus forming a stable and scalable compilation architecture.

[0075] 3) Semantic analysis and graph intermediate representation generation

[0076] After the graph construction tree is generated, the compilation process enters the semantic analysis and Graph Intermediate Representation (GIR) generation phase. The task of this phase is to perform global semantic verification of the entire construction tree under statically strongly typed rules, ensuring that the program fully conforms to the language specification in terms of logic, type, and scope. Compared to the type resolution in the previous phase, the checks here are more rigorous and comprehensive, involving not only the consistency of variable and expression types, but also symbol declaration rules, scope constraints, module interface visibility, the correct use of data structures, and the matching of return types with control flow.

[0077] Regarding types, the system utilizes established type information to perform consistency verification on all variables and function calls. When a function supports overloading, it selects the implementation that perfectly matches the call signature, ensuring that the input and output types of all nodes in the computation graph conform to their definitions. Simultaneously, semantic analysis verifies that identifier declarations within each scope are not duplicated, prohibits the use of internally reserved identifiers, and prevents unresolved references or types from entering the final graph representation. For nodes involving module imports, the system confirms that the imported symbols are indeed exported in the target module, avoiding interface mismatches or missing dependencies.

[0078] In addition to type and symbol constraints, semantic analysis also verifies language-specific structural rules, such as the number matching of tuple destructors, the uniqueness of dictionary keys, the static nature of parameter data, the consistency of set element types, the validity of subscript access, and the uniformity of return types for branch structures. At this stage, the compiler identifies potential errors or non-standard usages and generates warning messages as necessary to indicate discouraged or unsupported language features, thus ensuring that the final intermediate representation conforms to both the type system and the language's design principles.

[0079] After this stage, the graph construction tree is transformed into a Graph Intermediate Representation (GIR). This representation is a computation graph with strictly matched types. All nodes have undergone type checking, symbol resolution, and semantic constraint verification, maintaining structural consistency and executability. It not only eliminates potential runtime type errors but also provides a stable and high-precision data foundation for subsequent computation graph optimization, code generation, and execution, thereby achieving the design goal of statically typed languages ​​to guarantee program correctness at compile time. Figure 9 This displays the visualization result of the front-end parsing module parsing a sample code, shown in the middle of the image.

[0080] Through the above steps, this invention achieves efficient parsing of complex syntax, compile-time determination of type information, and automatic parsing and consistency verification of cross-module dependencies during the compilation process of DSL language, thereby ensuring comprehensive optimization of the generated computation graph in terms of type safety, structural integrity, and execution efficiency.

[0081] Step S30 specifically includes: To meet the requirements of high-performance execution, scalable architecture, and accurate calculation in optical fiber communication system simulation, this invention proposes a dedicated execution platform oriented towards graph intermediate representation in the backend of the language runtime. This backend execution module directly receives the computational graph structure generated by the frontend, with optical devices as nodes and signal transmission paths as edges. Through multi-stage optimization, bytecode compilation, memory management, and operator expansion mechanisms, it achieves rapid conversion from graph optimization to executable instruction streams, while balancing runtime efficiency and computational accuracy during execution. Unlike traditional general-purpose language backends, the backend of this invention fully integrates the professional needs of the optical fiber communication field in its architectural design. For example, it includes topology optimization strategies for large-scale signal stream transmission, memory management mechanisms adapted to high-frequency computation tasks, and pluggable operator interfaces that support cross-language ecosystem reuse. This significantly improves the system's scalability and cross-platform deployment capabilities while ensuring the accuracy of simulation results. The specific implementation steps are as follows: 1) Multi-stage graph optimization The runtime of this invention supports dynamically specifying the sequence of graph rewrite passes required at runtime. Since this language is essentially a graph-centric description language, its execution process is uniformly viewed as a continuous transformation or rewriting of the graph structure. Therefore, graph rewrite passes become a flexible connection mechanism between the front-end and back-end. This mechanism can be divided into the following three categories based on behavior: (a) Graph optimization pass The system receives an input graph and returns a new graph that is semantically equivalent but performs better. Optimization strategies can include subgraph inlining, operator fusion, constant folding, and redundant node elimination to improve instruction execution efficiency and data throughput. Among these, subgraph inlining is the most representative optimization technique: for subgraphs treated as "functions" or "components," the system expands them during optimization and directly merges them into the call location. This operation eliminates the scheduling overhead caused by multiple function calls, reduces the cost of context switching and parameter passing, and thus significantly shortens the overall execution time, especially in high-frequency operator chains where the optimization effect is more significant.

[0082] (b) Graph scheduling pass

[0083] The input graph is executed according to a specific scheduling strategy. The scheduling method can be linear sequential execution, multi-threaded execution, or distributed concurrent execution. This invention does not restrict the scheduling mode; users can freely choose the scheduling scheme. After each scheduled pass is completed, an empty graph is returned to indicate the completion of the computation process. This invention implements a linear scheduled pass for sequential execution of graph nodes by default.

[0084] (c) Translate the diagram

[0085] The input graph can be converted into other codes or formats to achieve different output goals. For example, the graph can be translated into DOT language for graph structure visualization; translated into C++ code for efficient execution on a local compiler; directly generated into a binary executable file to bypass the virtual machine interpretation process; or only the bytecode content of the graph during the compilation process can be output for analysis and debugging.

[0086] This rewrite mechanism gives the runtime backend extremely high flexibility: user-written fiber optic simulation scripts can not only be directly interpreted and executed by the language runtime, but also the graph intermediate representation generated by the front end can be directly connected to other mature computing engines to complete the calculation through a custom backend, thus having significant advantages in performance, scalability and cross-platform deployment.

[0087] 2) Bytecode compilation and optimization

[0088] After the graph optimization pass, the backend of this invention will hand over the intermediate representation of the input graph to the default graph scheduling pass (also commonly referred to as a virtual machine) for execution. This virtual machine adopts a linear execution architecture, and the running process includes extracting the node execution order from the graph, generating bytecode, optimizing and linking the bytecode, and finally executing the instruction stream sequentially.

[0089] First, the system performs a linear topological sort based on the dependencies between nodes in the graph, resulting in a definite execution sequence. Then, each graph and its subgraphs are treated as function units, and bytecode is compiled at the function level to generate a set of instructions that precisely describes operator types, input-output relationships, and parameters. Compared to graph-based direct interpretation, the bytecode format offers advantages such as compact structure and fast parsing, significantly reducing runtime scheduling overhead and providing a unified abstraction layer for subsequent instruction optimization and linking, thereby improving overall execution efficiency.

[0090] After compilation, the system optimizes the generated bytecode, such as eliminating redundant instructions, to further improve execution speed and resource utilization. The optimized bytecode is then integrated into a continuous execution flow during the linking stage, where instructions from all function units are linked to the same code segment, and a unified entry address and jump relationship are established, making cross-function calls almost costless.

[0091] Ultimately, the virtual machine executes the linked instruction stream linearly, with each instruction being parsed and triggering its corresponding operator operation in sequence. Since data dependencies are fully resolved during the topology sorting phase, no additional dependency checks are required during execution, enabling the virtual machine to complete computational tasks in a stable and predictable manner. This design simplifies the runtime structure while maximizing execution efficiency while ensuring correctness.

[0092] 3) Memory management mechanism

[0093] To meet the massive data throughput and real-time computing demands of fiber optic communication systems, this invention introduces a customized memory management mechanism in the backend virtual machine. This mechanism organically combines generational garbage collection with optional manual memory control to achieve fine-grained optimization of object allocation and release processes, minimizing runtime allocation overhead and memory fragmentation. When implementing generational garbage collection, the virtual machine adopts a typical "young generation-old generation" memory partitioning strategy, introducing a double-buffered structure of Eden and Survivor spaces in the young generation. A copying algorithm is used to quickly reclaim short-lived temporary objects. In a single garbage collection operation, only the young generation is scanned and copied; surviving objects are promoted to the old generation according to the promotion strategy, thus avoiding frequent full-heap memory traversal. When collecting old generation objects, the system employs a mark-compact algorithm. First, surviving data is marked through object reachability analysis, then fragmentation is eliminated through a relocation process, ensuring the compactness and continuity of the memory structure. Under high load conditions, an adaptive trigger threshold is used to reduce unnecessary GC pauses.

[0094] To further enhance controllability in specific computing scenarios, this invention provides a manual memory management interface, enabling users to proactively invoke the release operation when data is no longer needed, thereby bypassing the latency and scanning overhead of automatic garbage collection. For simulation tasks involving frequent object creation and destruction, the system pre-establishes a memory pool, reducing the number of system allocation calls and effectively lowering the fragmentation rate by reusing existing memory blocks. Furthermore, the virtual machine allows adjustment of allocation strategies based on object type or lifecycle tags; for example, large data can be directly placed in the large object allocation area, avoiding multiple copies between the young and old generations and effectively reducing memory migration costs.

[0095] This mechanism, combining generational recycling with precise manual release, demonstrates significant advantages in fiber optic communication simulation environments involving long-term, high-density object creation and destruction. Automated, short-lifecycle data recycling ensures stable throughput for routine tasks, while adjustable manual management provides the necessary flexibility for high-performance computing tasks, enabling the system to maintain stable operation for extended periods when handling complex computational logic. In multiple rounds of performance testing, this memory management architecture achieved levels comparable to mature high-performance virtual machines (such as CPython) in terms of recycling efficiency, fragmentation control, and operational stability, providing robust memory management guarantees for long-running fiber optic communication system simulations.

[0096] 4) Pluggable operator mechanism

[0097] This invention introduces a pluggable operator mechanism in its runtime design, allowing users to dynamically load operator modules during system operation without recompiling or restarting the virtual machine. Users can implement operators independently according to predefined interface specifications, and the operators can directly participate in the virtual machine's instruction execution flow after being loaded, enabling flexible functional expansion and customization.

[0098] To improve the efficiency and reusability of operator development, this language also provides an operator interface that interoperates with the Python language. This interface allows direct calling of Python functions or methods within the virtual machine, and also exposes operators implemented in this language to the Python environment. Through this bidirectional interoperability mechanism, users can directly reuse Python's mature basic libraries and ecosystem without migrating code, thereby significantly reducing development costs and maintenance difficulty in complex computing tasks, data processing, or third-party library integration scenarios.

[0099] This pluggable and cross-language interoperable operator mechanism gives the present invention a high advantage in terms of scalability, ecosystem reuse and runtime flexibility, and can better meet the ever-changing application needs and rapid iteration scenarios.

[0100] In summary, the language runtime backend execution module of this invention forms a complete high-performance execution framework in terms of multi-stage graph optimization, bytecode compilation and linking, a memory management mechanism combining generational and manual methods, and pluggable operators and cross-language interoperability. Through tight integration between compile-time and runtime, this architecture can quickly transform the intermediate graph representation generated by the front end into a compact, low-scheduling-cost, and type-safe instruction stream, and flexibly handle fiber optic communication simulation tasks of different scales and characteristics during execution. This solution not only improves the throughput and predictability of simulation computation but also provides open interfaces for system functional expansion and ecosystem integration, thus demonstrating excellent performance stability and long-term operational reliability in fiber optic communication system simulation and other graph computation-intensive fields.

[0101] The above step S40 specifically includes: After preparing the system operating environment and parameters, this step aims to simulate and verify the entire signal processing flow of the optical fiber communication system using the DSL language runtime provided by this invention. By calling the built-in optical communication simulation module, users can complete the entire process from raw data generation to final visualization output in a single script, thereby achieving efficient link modeling and performance evaluation in a unified language environment.

[0102] The following is a specific example of a fiber optic system simulation. The compiled result is shown in the middle of the figure, which represents the visualization result. Figure 10 As shown, system-level simulation is a core task in the research and development of optical fiber communication systems, highly dependent on modeling capabilities and the flexibility of operator invocation. This case study fully simulates the entire process from bit generation, modulation, upsampling, pulse shaping to visualization analysis. It can be considered representative because the process almost covers the typical stages of digital optical communication link simulation: data source generation, baseband signal transformation, sampling rate adjustment, filtering shaping, and performance demonstration. This is not only a standard operating procedure in the field of optical communication but also an important reference for evaluating the usability of a language system.

[0103]

[0104] In this case, the runtime state is first initialized using `config`, and key parameters such as the number of symbols, modulation order, roll-off factor, total baud rate, upsampling factor, and reference optical frequency are centrally configured into a unified structure to ensure consistency of conditions when operators are called at each stage. Then, the `gen_bits` module is called to generate a random bit sequence matching the configuration, which serves as the input for subsequent symbol mapping. The resulting bit stream is then mapped to a complex symbol sequence using the `modulation` operator, achieving signal generation under the preset modulation scheme. To meet the requirements of link bandwidth and sampling accuracy, the `up_sample` operator is called to increase the time-domain sampling rate, enabling the signal to maintain higher resolution in subsequent filtering and shaping. Next, `pulse_shaper` is used to perform pulse shaping filtering on the signal, precisely adjusting the filter response according to the roll-off factor and baud rate to suppress inter-symbol interference and optimize spectral performance. After the link simulation is complete, `constellation_diagram` is directly called to draw a constellation diagram of the shaped signal, visually demonstrating the modulation quality and noise impact, thus providing a visual basis for performance analysis.

[0105] This scripted execution process demonstrates the fully automated construction and operation of a fiber optic communication simulation pipeline. Users only need to organize operators in a chained call manner to complete all aspects of complex signal processing. The runtime framework handles data flow management, instruction scheduling, and memory optimization behind the scenes, ensuring that each script execution reproduces real transmission conditions in a high-performance environment and produces repeatable and verifiable simulation results. This approach effectively reduces development and debugging costs while improving the accuracy and scalability of experiments, providing a unified, efficient, and maintainable solution for the research and engineering applications of optical communication systems.

[0106] In summary, this invention proposes and implements a graph-native domain-specific modeling language (DSL). Based on graph theory structures as its core design concept, this language constructs a dedicated syntax, semantics, and execution model around the modeling needs of optical fiber communication systems. It can efficiently and intuitively express various device nodes and their connections within the system, thereby achieving automated modeling and simulation of optical communication systems. Through this language, advanced users can quickly define system structure, parameter configurations, and operational logic programmatically without a graphical interface, greatly improving modeling efficiency and simulation automation. Furthermore, the language's high degree of abstraction and encapsulation of graph structure modeling semantics makes the modeling process more consistent with the logical expression habits of communication systems, lowering the user threshold and improving system maintainability and scalability.

[0107] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of one embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing the present invention.

[0108] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that the present invention can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of the present invention.

[0109] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for apparatus or system embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. The apparatus and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0110] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.< / number>

Claims

1. A method for modeling and simulating optical fiber communication systems based on graph-native modeling programming, characterized in that, include: Design standards and specifications for domain-specific DSLs based on graph structures; Based on the standards and specifications of the DSL language, a front-end parsing module and a back-end execution module for the DSL language runtime are designed. The front-end parsing module and the back-end execution module are trained using a modeling script of an optical fiber communication system that conforms to the DSL language specifications, resulting in a trained front-end parsing module and a back-end execution module. Based on the standards and specifications of the DSL language, a simulation script for the optical fiber communication system is written. The simulation script for the optical fiber communication system is run using the trained front-end parsing module and back-end execution module, and the optical fiber communication simulation system is output.

2. The method according to claim 1, characterized in that, The design is based on the standards and specifications of graph-based DSL languages, including: The graph-based DSL language uses optical devices as nodes and signal transmission paths as edges to construct a unified graph representation model. The standards and specifications of the DSL language include data structure definitions, basic syntax, modeling semantics, connection relationship expression methods, and parameter configuration mechanisms. The data structure definition of the DSL language includes referring to data as entities and entities with operation definitions as functors. An entity is a general term for all data or objects, including text, scalars, vectors, and structured data. A functor receives ordinary input parameters and context input parameters, processes them, and returns the calculation results. Users are allowed to define custom functors to encapsulate custom operations on entity data.

3. The method according to claim 1, characterized in that, The aforementioned design of the front-end parsing module and back-end execution module for the DSL language runtime, based on the standards and specifications of the DSL language, involves training the front-end parsing module and back-end execution module using a modeling script for an optical fiber communication system conforming to the DSL language specifications, resulting in trained front-end parsing and back-end execution modules, including: Write a certain number of modeling scripts for optical fiber communication systems that conform to the standards and specifications of the DSL language, and use all the modeling scripts to build a script database; Based on the standards and specifications of the DSL language, a front-end parsing module and a back-end execution module for the DSL language runtime are designed. The front-end parsing module and the back-end execution module are trained using the script database. The modeling scripts from the script database are input into the front-end parsing module, which performs lexical analysis on the input modeling scripts to obtain a word stream. Then, the word stream undergoes syntactic analysis to generate a concrete syntax tree and an abstract syntax tree. Further semantic analysis is performed on the concrete syntax tree and the abstract syntax tree to obtain a graph construction tree. Finally, type checking and intermediate representation generation are performed on the graph construction tree to obtain an intermediate data structure representation of the graph structure. This intermediate data structure representation of the graph structure is transmitted to the back-end execution module. The back-end execution module performs multiple rounds of graph optimization on the input intermediate data structure representation of the graph structure to obtain an optimized intermediate graph representation. Then, the optimized intermediate graph representation is compiled and optimized into bytecode, resulting in bytecode executable by the underlying virtual machine. The bytecode is interpreted and executed using the bytecode virtual machine built into the DSL language runtime to obtain the calculation results. Based on the deviation between the calculated result and the expected result, the parameters of the front-end parsing module and the back-end execution module are adjusted accordingly, and the above process is repeated to obtain the trained front-end parsing module and back-end execution module.

4. The method according to claim 3, characterized in that, The simulation script for the optical fiber communication system, based on the standards and specifications of the DSL language, is written and executed using the trained front-end parsing module and back-end execution module to output the optical fiber communication simulation system, including: A simulation script for an optical fiber communication system is written based on the standards and specifications of the DSL language. In this simulation script, the type, parameter configuration, and signal port of each optical device are expressed through node definitions, and the transmission path of the signal between different devices is characterized by edge definitions. The simulation script is input into a trained front-end parsing module, which parses the simulation script into an intermediate data structure representation of a graph. The back-end execution module parses, optimizes, and executes the intermediate data structure representation of the graph generated by the front-end parsing module, and outputs the optical fiber communication simulation system, as well as the performance indicators of the optical signal power change, link loss, and dispersion affecting the amplifier gain characteristics of the optical fiber communication simulation system. In the simulated fiber optic communication system, functors are used to describe the simulated devices. The input and output of the functors correspond to the input and output signals of the devices. The ordinary input parameters of the functors correspond to the signal inputs of each simulated device, while the context input parameters of the functors represent the settings of the devices themselves. The calling relationship between the functors is used to express the real topology and data flow of the entire fiber optic communication simulation system. The nested calling of functors is used to express the simulation behavior of components, modules, and even the entire fiber optic communication simulation system composed of basic components.

Images