A method and device for constructing a numerical weather prediction software component and a running instance

Abstract

This application provides a method and apparatus for constructing componentized and operational instances of numerical weather prediction software. The method includes: dividing the numerical weather prediction software into components; defining metadata, including general operational parameters describing the system's general operational configuration and component-specific parameters distinguishing component-specific configurations; writing standardized scripts to implement metadata settings and invocations, and to support independent component operation and job submission; organizing the file directory in a standardized manner to categorize and store scripts, executable programs, and instance operation-related data; and constructing operational instances based on the aforementioned steps. These instances include standard scenarios and / or custom scenarios, with standard scenarios at least including independent component operation scenarios. This approach reduces software development and maintenance costs, improves software operational efficiency and flexibility, enhances system standardization and reliability, and effectively supports the efficient application of numerical weather prediction software in operational system upgrades and scientific research iteration and innovation.

Description

Technical Field

[0001] This invention relates to the field of computer software, and more specifically, to a method and apparatus for constructing componentized and running instances of numerical weather forecasting software. Background Technology

[0002] Numerical weather prediction is a core support for modern meteorological operations and scientific research. By solving atmospheric dynamic equations to simulate atmospheric motion, it generates forecasts of meteorological elements for the next few hours to days, providing crucial decision-making support for disaster prevention and mitigation, agricultural production, aviation safety, and other fields. With the improvement of observational data accuracy, the increasing complexity of the physical processes in forecast models, and the growing demand for high-resolution forecasts, the scale and complexity of numerical weather prediction software have increased significantly, highlighting the limitations of traditional development and testing models.

[0003] Currently, most mainstream numerical weather prediction software adopts a "modular integrated architecture," which is divided into large modules such as assimilation, model preprocessing, model calculation, and post-processing according to function. Information is exchanged between modules through fixed data interfaces. The operating parameters are scattered in the module source code or dedicated configuration files. Experiments rely on customized scripts and manual intervention, requiring manual configuration of parameter paths, triggering of module operation, and manual monitoring of the operation status.

[0004] This technology suffers from key drawbacks: "components cannot be independently iterated and tested" and "experiments outside of existing scenarios cannot be conducted." Deep coupling between modules, the assimilation module's output depending on the format conversion of the pattern preprocessing module, and the hard binding between the initial field of the pattern calculation module and the assimilation module's output prevent each module from being compiled, run, and tested independently. For example, when optimizing the assimilation module algorithm, it is necessary to first ensure compatibility with other modules, then fully compile the software, and wait for the entire process to complete before verifying the effect. This significantly extends the iteration cycle of new algorithms and hinders the efficiency of software feature upgrades. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a method and apparatus for constructing componentized and operational instances of numerical weather prediction software, which significantly reduces software development and maintenance costs, improves the efficiency and flexibility of software operation, enhances the standardization and reliability of the system, effectively supports the efficient application of numerical weather prediction software in operational iteration and scientific research innovation, and provides strong support for accurate forecasting and technological breakthroughs in the meteorological field.

[0006] In a first aspect, embodiments of this application provide a method for constructing componentized and runtime instances of numerical weather prediction software, including the following steps:

[0007] S1: Divide the numerical weather prediction software into components so that each component can be compiled and run independently;

[0008] S2: Define metadata, which includes general business parameters for describing the general operating configuration of the system and component-specific parameters for distinguishing component characteristic configurations;

[0009] S3: Write a standardized script, which is used to set and call the metadata and support the independent operation of the component and job submission;

[0010] S4: Organize the file directory in a standardized manner. The file directory is used to classify and store scripts, executable programs and instance running related data.

[0011] S5: Construct a running instance based on steps S1-S4. The running instance includes standard scenarios and / or custom scenarios. The standard scenario includes at least a scenario where components run independently.

[0012] Secondly, embodiments of this application provide an apparatus for constructing componentized and running instances of numerical weather prediction software, the apparatus comprising:

[0013] The component partitioning module is used to perform step S1: partitioning the numerical weather prediction software into components so that each component can be compiled and run independently;

[0014] The metadata definition module is used to perform step S2: define metadata, which includes general business parameters for describing the general operating configuration of the system and component-specific parameters for distinguishing component characteristic configurations;

[0015] The script writing module is used to execute step S3: writing a standardized script, which is used to set and call the metadata and support the independent operation of the component and job submission;

[0016] The directory organization module is used to perform step S4: to organize the file directory in a standardized manner, wherein the file directory is used to classify and store scripts, executable programs and instance running related data;

[0017] The instance building module is used to execute step S5: build a running instance based on steps S1-S4. The running instance includes standard scenarios and / or custom scenarios. The standard scenario includes at least a component-independent running scenario.

[0018] The technical solution provided in this application includes, but is not limited to, the following beneficial effects:

[0019] Step S1 breaks through the limitations of deep coupling of traditional software functional units by dividing the numerical weather prediction software into components and enabling each component to be compiled and run independently at the architectural level. Each component can be developed, tested, and optimized independently of other functional units without relying on the overall software's compilation environment and logic, significantly shortening the functional iteration cycle—for example, only the component that needs optimization needs to be compiled separately, without compiling the entire software, reducing unnecessary time and resource consumption; at the same time, component-based decomposition makes the scope of fault diagnosis more focused, allowing direct location of problems for specific components, avoiding cross-functional unit tracing, significantly reducing the difficulty of software maintenance, and improving development and debugging efficiency.

[0020] Step S2 establishes a unified parameter management system by defining metadata that includes general business parameters and component-specific parameters, solving the problem of scattered parameter management in traditional technologies. General business parameters enable centralized control of system-level configurations, ensuring consistency in the basic configuration for the entire software operation; component-specific parameters precisely match the personalized needs of different components, ensuring that the characteristic configurations of each component do not interfere with each other. This clearly categorized metadata design avoids configuration chaos and errors caused by mixed parameters, simplifies the parameter adjustment process, and allows configuration updates without code modification, providing fundamental support for flexible switching of experimental scenarios and improving the standardization and efficiency of parameter management.

[0021] The standardized script developed in step S3 establishes an efficient bridge between metadata and component operation, achieving standardization and automation of the experimental process. The script automatically sets and calls metadata, ensuring parameters are accurately transmitted to the corresponding components without manual configuration. Simultaneously, the script directly supports independent component operation and job submission without additional customization, reducing manual intervention. This standardized design not only reduces the risk of experimental failure due to human error but also improves process repeatability, ensuring that experiments conducted by different personnel at different times adhere to a unified standard, thus enhancing the reliability and comparability of experimental results.

[0022] Step S4, the standardized organization of the file directory, achieves orderly storage and efficient management of software resources, solving the problem of resource clutter in traditional technologies. Scripts, executable programs, and experimental data are stored according to their functions, and the location paths of various resources are clear, avoiding confusion during searching and retrieval. The classified storage of experimental run-related data effectively prevents data overwriting and confusion in scenarios with multiple experimental instances. This structured directory design facilitates quick retrieval of required resources, simplifies the traceability and review of experimental results, and supports the parallel execution of multiple experimental instances, improving resource utilization efficiency and the orderliness of experimental management.

[0023] Step S5 builds upon the preceding steps to construct running instances containing both standard and custom scenarios, significantly enhancing the flexibility and applicability of the experiments. Standard scenarios directly meet routine needs such as basic functional verification (e.g., independent component testing) without requiring additional setup processes; custom scenarios support flexible component combinations based on actual requirements, breaking the limitations of traditional fixed experimental modes. The combination of these two scenarios covers both routine experimental needs and rapidly responds to personalized research and business requirements, enabling the software to adapt to diverse experimental objectives, expanding its application scope, and improving its practicality in different scenarios.

[0024] In summary, this application forms a complete technology chain through steps S1 to S5, comprehensively optimizing the development and testing mode of numerical weather prediction software from software architecture, parameter management, process execution, resource storage to experimental application.

[0025] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 A flowchart illustrating the construction method of a componentized numerical weather prediction software and its operational instance provided in Embodiment 1 of the present invention is shown.

[0028] Figure 2 The flowchart of a method for constructing a component-independent operation scenario provided in Embodiment 1 of the present invention is shown;

[0029] Figure 3 The diagram shows a structural schematic of a device for constructing and running a numerical weather forecast software component according to Embodiment 2 of the present invention. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0031] Example 1

[0032] To facilitate understanding of this application, the following is combined with... Figure 1 The flowchart illustrating the method for constructing a componentized and operational example of numerical weather forecasting software according to Embodiment 1 of the present invention provides a detailed description of Embodiment 1 of this application.

[0033] See Figure 1 As shown, Figure 1 The flowchart illustrates a method for constructing a component-based runtime instance of numerical weather prediction software according to Embodiment 1 of the present invention, which includes the following steps:

[0034] S1: Divide the numerical weather prediction software into components so that each component can be compiled and run independently.

[0035] Specifically, the core objective of step S1 is to break the original highly coupled structure of the numerical weather prediction software, and through reasonable component decomposition, realize the independent compilation and operation of each functional unit, laying the foundation for subsequent flexible experiments. In practical operation, the logical division needs to closely align with the business process of numerical weather prediction, gradually breaking down the software from high-level functions to low-level execution units: First, clarify the core business areas of the software, at least covering two major subsystems: assimilation-related functions (responsible for processing observation data and optimizing the initial forecast field) and model-related functions (responsible for performing numerical calculations and generating forecast results); then, further subdivide each subsystem into module-level units. For example, the model-related subsystem can be divided into a model preprocessing module (for data preparation) and a model calculation module (for forecast calculations), while the assimilation-related subsystem can be divided into an observation preprocessing module (for observation data quality control) and an assimilation calculation module (for initial field optimization); finally, further break down the modules into the smallest functional units—components. These components must meet the requirement of "being able to independently implement specific functions." For example, the assimilation calculation module can be divided into assimilation core calculation components (executing the core assimilation algorithm) and boundary update components (updating the boundary conditions of the forecast area), while the model preprocessing module can be divided into background field processing components (processing initial background data) and initialization components (generating the initial forecast field). This layered split ensures that each component can complete the compilation process independently of other components and rely only on explicit input data and configuration at runtime, reducing the coupling between components and facilitating subsequent functional testing, performance optimization, or version replacement for individual components.

[0036] S2: Define metadata, which includes general business parameters for describing the general operating configuration of the system and component-specific parameters for distinguishing component characteristic configurations.

[0037] Specifically, step S2 aims to establish a unified parameter management framework. By defining metadata, it achieves standardized control over the operational configuration of numerical weather prediction software. The metadata comprises two core categories: First, general operational parameters. These parameters are the basic configurations supporting the entire software system's operation, derived from preset configuration scripts, and must cover three dimensions: process scheduling, overall control, and regional parameters. Process scheduling configuration specifies key location information such as the software source code storage path, instance working path, and data storage path to ensure the program can correctly locate resources. Overall control configuration defines time-dimensional parameters such as instance start time, forecast cycle interval, and total forecast duration to control the timing of forecast instances. Regional parameter configuration determines spatial attributes such as the spatial resolution, latitude and longitude range, and number of grid points of the forecast area, limiting the geographical scope of numerical calculations. Second, component-specific parameters. These parameters are used to differentiate the functional characteristics of different components and meet the personalized operational needs of components. Based on flexibility, they can be further subdivided into dynamically adjustable console parameters and relatively fixed configuration file parameters. Console parameters can be modified in real time during instance runtime, such as the runtime of the homogenized instance, the prediction duration of the mode component, and the data input / output paths. Configuration file parameters, on the other hand, are predefined in the configuration file, including system-wide characteristics (such as the number of parallel computing cores), component start / stop switches (controlling whether a component participates in the instance), component-specific runtime attributes (such as the observation error parameters of the homogenized component), and job submission information (such as the supercomputing cluster queue configuration). By defining metadata, parameters scattered throughout the software code are centrally managed, avoiding the cumbersome modification problems caused by hard-coding parameters and providing parameter support for flexible component invocation and rapid switching of experimental scenarios.

[0038] S3: Write a standardized script, which is used to set and call the metadata and support the independent operation of components and job submission.

[0039] Specifically, step S3 builds a bridge between metadata and component execution by writing standardized scripts, including configuration scripts, component execution scripts, job submission scripts, and utility scripts, to achieve effective parameter transmission and standardized component execution, while supporting automated job submission.

[0040] The core function of configuration scripts is to centrally configure general parameters and control experimental logic, providing a unified parameter benchmark for the entire system. Component execution scripts are assigned to each component, enabling independent operation of component input, computation, and output. Job submission scripts, also assigned to each component, convert component requirements into supercomputing cluster configurations, automating job submission. Tool scripts primarily assist in generating custom scenarios and verifying the scientific validity of experiments, ensuring both scientific rigor and flexibility.

[0041] S4: Organize the file directory in a standardized manner. The file directory is used to classify and store scripts, executable programs and instance running related data.

[0042] Specifically, step S4 systematically and structurally organizes the file directory to achieve classified storage and efficient management of scripts, executable programs, and experimental data, avoiding resource confusion in multiple experimental scenarios and ensuring the smooth conduct of experiments and traceability of results. The directory organization includes at least three core directory types: The first type is the script storage directory, which needs to be further subdivided into subdirectories according to script functions, storing configuration scripts, component execution scripts, job submission scripts, and utility scripts respectively. For example, the "config_scripts" directory stores configuration scripts, and the "run_scripts" directory stores component execution scripts. Each subdirectory can be further layered according to the subsystem or module to which the component belongs, ensuring that different types and purposes of scripts can be quickly located. The second type is the program storage directory, which is used to store the executable programs compiled by each component of the numerical weather prediction software. The directory structure needs to correspond to the component division logic in step S1, and the directory should be established according to the "subsystem-module-component" hierarchy. For example, the "model_system / preprocess / background_process" directory stores the executable program of the background field processing component under the model preprocessing module, which facilitates program version management and unified configuration of component execution paths. The third type is the instance execution directory, which serves as the core storage area for experimental process data. Data needs to be stored in layers according to the "component-run time" dimension, while distinguishing between input data, output data, and intermediate data, and setting up a separate log storage subdirectory. The input data directory stores observation data and background field data required for component operation; the output data directory stores forecast results and assimilation analysis fields generated by the instance; the intermediate data directory stores temporary data generated during the calculation process; and the log directory stores script scheduling logs (recording the execution order and status of the instance operation process) and program operation logs (recording error information and key operation indicators during component calculation). This standardized file directory organization not only enables orderly management of experimental resources but also supports the parallel operation of multiple experimental scenarios (such as experiments with different time intervals and different component combinations), while facilitating result traceability and problem localization after the instance operation is completed.

[0043] S5: Construct a running instance based on steps S1-S4. The running instance includes standard scenarios and / or custom scenarios. The standard scenario includes at least a scenario where components run independently.

[0044] Specifically, step S5 builds upon the results of S1-S4, integrating component, metadata, script, and directory resources to construct runtime instances that meet different experimental needs. These runtime instances encompass two main categories: standard scenarios and custom scenarios, covering all requirements from basic functional verification to complex business experiments. Standard scenarios are standardized experimental scenarios designed to verify the core functions of the software and the basic performance of components. They include at least a component-independent running scenario—this scenario tests a single component by calling the corresponding component's runtime script, loading the component's metadata configuration and input data, and verifying whether the component can independently complete its intended function (e.g., whether the assimilation core computing component can correctly output the assimilation analysis field). This is the foundational scenario for verifying the correctness of component functionality. In addition to the independent component operation scenario, the standard scenario can also be extended to a full-process scenario, a model-only scenario, and an assimilation-only scenario: The full-process scenario sets the operation switches of both assimilation-related components and model-related components to the enabled state, and triggers the operation of each component according to the business process sequence through the master control script to verify the complete forecast process of "observation preprocessing - assimilation calculation - model preprocessing - model forecast"; The model-only scenario disables assimilation-related components and only triggers the operation of model-related components to test the forecast performance of the model itself (such as the comparison of forecast effects of different physical parameterization schemes); The assimilation-only scenario disables model-related components and only triggers the operation of assimilation-related components to verify the optimization effect of the assimilation system on the initial field (comparison of initial field errors before and after assimilation). Custom scenarios are flexible experimental scenarios designed to meet specific research needs (such as testing new components or optimizing specific processes). The construction process requires first assigning unique identifiers to subsystems, modules, and components; clarifying the predecessor dependencies (components providing input data) and successor dependencies (components receiving output data) of each component; defining the naming rules for components and experiments according to a preset format; and finally, using a verification script to reverse-check the integrity of the component dependency chain to avoid experimental failures due to missing dependencies. By combining standard and custom scenarios, the stability of the software's basic functions can be guaranteed while supporting diverse scientific research experimental needs.

[0045] In an optional implementation, the specific process of component partitioning in step S1 is as follows:

[0046] Based on the business process logic of numerical weather prediction software, the software is divided into subsystems, modules, and components from high to low levels.

[0047] Specifically, the core logic of component division strictly follows the business process of numerical weather prediction software, establishing a three-tier architecture of subsystems, modules, and components from high to low levels. Specifically, the core business objectives to be achieved by the software as a whole are first clearly defined (such as the entire process from observational data to forecast products). This objective is then decomposed into several relatively independent business domains (subsystems), each business domain is further refined into specific business steps (modules), and finally, each business step is broken down into executable operational units (components). This division method ensures that each level of unit possesses independent functionality while also forming a complete business process through reasonable interface connections, providing a structural foundation for subsequent independent compilation and operation.

[0048] The subsystem covers at least assimilation-related functions and pattern-related functions. The module is a functional subdivision unit of the subsystem, and the component is a unit that can independently implement a specific function and is further subdivided from the module.

[0049] Specifically, the subsystems, as the highest-level division units, are directly bounded by the core operational functions of numerical weather prediction. The assimilation-related subsystem is primarily responsible for the operational chain of "observational data → optimized initial field," encompassing all functions from acquiring observational data to generating a high-quality initial field. This includes quality control of observational data, bias correction, and fusion calculations with the background field. Its core objective is to reduce initial field errors through assimilation techniques. The model-related subsystem undertakes the core calculations of "initial field → forecast products," including numerical simulations of atmospheric dynamic processes and physical processes (such as radiation, cloud microphysics, and boundary layer), as well as post-processing of forecast results. Ultimately, it outputs forecast products for meteorological elements such as temperature, precipitation, and wind speed.

[0050] The subsystem for the pattern-related functions includes at least a pattern preprocessing module and a pattern calculation module; the pattern preprocessing module includes at least one component for performing pattern preprocessing; the pattern calculation module includes at least one component for performing pattern calculation.

[0051] Specifically, the components used for model preprocessing include a global background field decoding component, a binary conversion and physical quantity calculation component, a background field mean calculation component, a model initialization component, a regional static terrain data extraction component, and an hourly background field preprocessing component. The components used for model calculations are corresponding model calculation components.

[0052] Modules are subdivided units of a subsystem's functionality, divided according to the business process steps within the subsystem. For model-related functional subsystems, the model preprocessing module focuses on the "data preparation" stage before computation, specifically including operations such as format conversion of input data (e.g., background field, topographic data, underlying surface data), spatial interpolation (converting data to the model grid), and temporal matching (ensuring data temporal consistency), ensuring that all input data meets the format and accuracy requirements of model computation. The model computation module is responsible for the core "numerical forecast calculus" stage, including dynamic framework calculations (e.g., pressure gradient force, Coriolis force, etc.), physical process parameterization (e.g., cumulus convection parameterization, boundary layer parameterization, etc.), and time integration of model variables, and is the core module for generating forecast results.

[0053] The subsystem for the assimilation-related functions includes at least an observation preprocessing module and an assimilation calculation module; the observation preprocessing module includes at least one component for performing observation preprocessing; and the assimilation calculation module includes at least one component for performing assimilation calculation.

[0054] Specifically, the components used for observation preprocessing include GTS data preprocessing components, TEMP data rh preprocessing components, and ObsJk data preprocessing components. The components used for assimilation calculations include multi-scale mixing components, 3dvar assimilation calculation components, 3dvar assimilation postprocessing components, surface observation assimilation calculation components, lateral boundary update components, and cloud analysis components.

[0055] The observation preprocessing module focuses on the preprocessing of observation data. Each of its components is an independent functional unit. Each component only needs to call the corresponding pre-set observation raw data and configuration parameters to independently complete the quality control, format conversion and other processing of specific types of observation data. It does not need to be associated with the assimilation calculation module or the internal operations of other components. The processing results can be directly used as input resources for assimilation calculation.

[0056] The assimilation calculation module comprises several functionally dedicated and independent components, each focusing on specific assimilation steps: the variational assimilation component independently generates the assimilation analysis field, requiring only the output data from the observation preprocessing module and preset background field data and configuration parameters to complete its own function independently, without relying on the internal logic of other assimilation components; the variational assimilation post-processing component, as an independent unit, specifically handles the optimization of results after variational assimilation calculation (such as assimilation increment adjustment and result format regularization), requiring only the output data from the variational assimilation component and not needing to intervene in the internal operations of variational assimilation to complete the post-processing task. Boundary update components also possess complete functional independence. For the boundary condition requirements of regional numerical weather prediction models, this component only needs the assimilation analysis field output by the assimilation calculation module as input, independently performing lateral boundary updates (including temporal interpolation of boundary variables and spatial smoothing) according to preset rules, generating boundary conditions coordinated with the model's internal field without relying on the internal logic of the model calculation component or other components of the assimilation-related subsystems, ensuring its own function is decoupled from other components.

[0057] All of the above components are designed as independently compileable units, each with its own source code files, compilation rules, and parameter configurations. At runtime, they only need to call the preset input data and configuration parameters to complete the corresponding functions independently without relying on the internal logic of other components. This supports independent testing and version iteration of individual components, and also allows for the replacement of a component as needed, providing great flexibility for subsequent system optimization.

[0058] In an optional implementation, the general business parameters in step S2 are derived from a preset configuration script, which is used at least to implement process scheduling configuration, overall control configuration, and regional parameter configuration.

[0059] Specifically, the core characteristic of the general operational parameters in step S2 lies in their systematic and shared nature. These parameters are not defined piecemeal, but rather uniformly derived from a pre-defined configuration script, forming a basic parameter system covering the entire system's operation. The configuration script, as the carrier of these general operational parameters, centrally manages key configurations affecting the entire numerical weather prediction software's operational logic through a structured parameter definition approach. This avoids the problems of cumbersome modifications and inconsistent consistency caused by parameters being scattered across various component codes. This design allows for system-wide configuration updates simply by adjusting the parameter values ​​in the configuration script when experimental requirements or the operating environment change, without requiring modifications to the core code of individual components, significantly improving the efficiency and security of parameter adjustments.

[0060] The process scheduling configuration includes at least the software source code path, working path, and data storage path; the overall control configuration includes at least the start time, loop interval, and forecast duration; and the regional parameter configuration includes at least the spatial resolution, latitude and longitude range, and number of grid points.

[0061] Specifically, process scheduling configuration is a set of fundamental parameters that ensures that each component of the software can correctly locate resources and operate collaboratively. Its core function is to define the "spatial path rules" for system operation. Among them, the software source code path clearly defines the root directory and hierarchical structure of the source code files of each component, such as " / project / nwp / model / src / ", ensuring that the compilation script can correctly find the source code files for compilation; the working path specifies the storage directory for temporary files and intermediate results during instance operation, such as " / work / nwp / test / 20230801 / ", this path is usually dynamically generated according to the test date or scenario to avoid data confusion among multiple instances; the data storage path distinguishes the storage location of input data and output data. The input data path (such as " / data / input / obs / " " / data / input / background / ") points to the raw data such as observation data and background fields, while the output data path (such as " / data / output / forecast / " " / data / output / analysis / ") specifies the storage location of the final products such as forecast results and assimilation analysis fields. With these path parameters clearly defined, the system can automatically locate the required resources and realize data transfer and process connection between components without manual intervention in path configuration.

[0062] The overall control configuration manages the "time dimension" of numerical weather prediction by defining time-related parameters and component switches to control the execution rhythm, cycle, and participating component scope of instances. Time-related parameters specify the base time (start time) of the instance in the format of "year, month, day, hour" (e.g., "2023080100"), serving as the starting point for all time calculations. The cycle interval parameter defines the time interval between two consecutive instances (for rolling forecasts, it can be set to 3 hours, 6 hours, etc., e.g., "6h"), meaning a new forecast instance is started every 6 hours. The forecast duration parameter specifies the total forecast duration of a single instance (e.g., "72h" indicates forecasting weather conditions 72 hours ahead from the start time). On the other hand, the overall control configuration also includes component switches to control whether each component participates in the instance (e.g., do_3dv "variational assimilation master switch", do_grapes "GRAPES model calculation switch", do_psi "model initialization switch", do_4dvar "variational assimilation calculation switch", etc. in cycle.sh). These component switches work in conjunction with the time parameters. The corresponding component will only be triggered to run according to the time parameter when the component switch is set to enabled (e.g., .true). If the switch is set to disabled (e.g., .false), the component will not participate in the instance operation even if the time parameter is configured completely.

[0063] These time parameters, together with component switches, constitute the operational control logic of the experiment: For example, when the start time is 2023080100, the cycle interval is 6 hours, the forecast duration is 72 hours, and do_grapes (mode calculation switch) is set to .true. and do_3dv (assimilation master switch) is set to .true., the system will automatically trigger experiments at times such as 2023080100, 2023080106, and 2023080112. The mode component and the assimilation component will synchronously generate results according to the forecast duration. If a "mode-only scenario" needs to be constructed, simply set the assimilation-related component switches such as do_3dv and do_4dvar to .false. in the master control configuration, while keeping do_grapes as .true. At this time, the system will still trigger experiments according to the above time parameters, but only the mode component will run and generate forecast results for the next 72 hours, realizing automated operation of rolling forecasts while flexibly controlling the scope of components participating in the experiment.

[0064] Regional parameter configuration defines the "spatial extent and accuracy" of numerical weather prediction, and is a key parameter to ensure that all components operate within a unified spatial framework. The spatial resolution parameter specifies the horizontal resolution of the model grid; for example, "10km" indicates a horizontal distance of 10 kilometers between grid points. Higher resolution provides richer forecast details but also increases computational complexity. The latitude and longitude extent parameter defines the geographical extent of the forecast area using the starting and ending longitudes, latitudes, and longitudes (e.g., "100E120E20N40N"), ensuring that all components process and calculate data only within the specified area. The grid point count parameter is calculated based on the resolution and latitude and longitude extent (or directly defined), including the number of grid points in the east-west and north-south directions (e.g., "201×301"), used to determine the grid matrix size for model calculations. These parameters collectively construct a unified spatial benchmark, ensuring that the output data from components such as background field processing, observation interpolation, and model calculations remain consistent in spatial scale, avoiding data errors or forecast biases caused by spatial mismatches. For example, if the regional parameters are configured to a resolution of 10km and a range of 100E-120E / 20N-40N, all components will automatically process the data to this spatial scale, ensuring spatial consistency throughout the forecasting process.

[0065] In an alternative implementation, the component-specific parameters in step S2 include dynamically adjusted console parameters and relatively fixed configuration file parameters.

[0066] Specifically, the core of component-specific parameters is the selection and integration of parameters related to its own operation from the original system. These parameters already exist in the original operating logic of the numerical weather prediction software (such as the number of experiments, configuration file paths, component running attributes, job submission rules, etc.). Based on its own operating needs, the component selects the highly relevant parts from the original parameters and then divides them into two main categories according to the adjustment frequency and method: dynamically adjusted console parameters and relatively fixed configuration file parameters.

[0067] The console parameters include at least the instance runtime, configuration file path, program input file path, forecast duration, and background field type.

[0068] Specifically, console parameters are dynamic parameters entered via command line when the instance starts, used to adapt to the immediate needs of different experimental scenarios, offering the flexibility of "setting as needed". Instance runtime parameters specify the specific time corresponding to the current experiment in the format of "year / month / day / hour" (e.g., "2023080100"), ensuring that the component can load the input data for that time. Configuration file path parameters specify the storage location of the configuration file corresponding to the component (e.g., " / config / assimilation / core_params.cfg"), enabling the component to correctly read predefined fixed parameters. Program input file path parameters point to the specific input data required for the component to run (e.g., the observation data path of the same as the component, " / data / obs / 2023080100 / "), supporting flexible switching between different instance data. Forecast duration parameters are used to cover or refine the forecast duration in general business parameters (e.g., if the global configuration is 72 hours, a component can specify its own 36-hour sub-period through console parameters). Background field type parameters specify the background field data source used by the component (e.g., "ERA5", "GFS", or "local mode output"), supporting comparative experiments with different background fields. These parameters are passed to the component's runtime script via command-line arguments (e.g., "run_assimilation.py --time2023080100 --bg_typeERA5"). After the script parses the script, it dynamically adjusts the component's runtime configuration without requiring modification of configuration files or code, greatly improving the flexibility of the experiment.

[0069] The configuration file parameters include global configuration for describing the global characteristics of the system, component switch configuration for controlling the start and stop of components, component-specific configuration for defining the running attributes of components, and job submission configuration for configuring job submission information.

[0070] Specifically, the global configuration parameters and functions are as follows: global_xb: controls whether to use the global background field. In the example, it is set to .false, which means that the current experiment does not rely on global background field data and is suitable for regional numerical forecasting scenarios; do_mpi_io: defines whether to enable the MPIIO (parallel input / output) function. In the example, it is set to .true, which is used to improve the data read and write efficiency when multiple components run in parallel. It is a system-level IO strategy configuration; bckg_type: specifies the background field data type. All components that need to call the background field (such as homogenization and pattern initialization components) will follow this type to read data.

[0071] The key parameters and functions of component switch configurations are as follows: Overall control switches: such as do_3dv (overall switch for variational assimilation-related components), set to .true in the example, indicate that all variational assimilation-related components are enabled; if set to .false, all assimilation components will not run. Single component switches: such as do_wgrib2 (background field decoding component switch), do_psi (mode initialization component switch), do_grapes (GRAPES mode calculation component switch), all set to .true in the example, indicating that these components will execute according to the instance flow; do_bogus (bogus component switch) is set to .false since there is currently no such component. Process-level switches: such as do_grib2bin (overall switch for top-level components before PSI), set to .true in the example, indicate that the entire process of "wgrib2 decoding → read_for_grapes physical quantity calculation → avebckg mean calculation → read hourly processing" is automatically enabled, simplifying the batch start / stop operation of multiple components.

[0072] The core parameters and functions of component-specific configurations are as follows (categorized by component type): Pattern Initialization (PSI) component: such as psi_exe_dir, specifying the storage path of the PSI executable program (example: / home / export / base / ycsc_test / wxsc_da / online1 / tangyb / zh-ch / test_1km / beijing_ksh / bin), ensuring that the PSI component can call the correct executable program; Variational Assimilation component: such as m4dv_nml_input_file (path to the variational assimilation configuration file) and m4dv_input_obs_dir (directory for assimilation observation inputs), the examples pointing to na respectively. The melist configuration file and observation data storage path provide input resource location for variational assimilation calculations; background field processing components, such as avebckg_input_dir (input path for background field mean calculation, pointing to the output directory of the read_for_grapes component) and wgrib2_path (path to the wgrib2 executable program), define the specific locations where components read input data and call the executable program; static data processing components, such as geodatapro_input_dir (static terrain data path) and geodatapro_mpi_pmi_lib (MPIPMI library path), ensure that basic data and dependent library support can be obtained when constructing static terrain.

[0073] Key parameters and functions for job submission configuration are as follows: Job Identifier and Queue: such as job_comment (job comment, example "GRAPES"), job_name (job name, example "PSI"), job_partition (job partition, example "q_amd_share"), used to identify job attributes and specify the supercomputing cluster queue to which the job is submitted; Resource Allocation Parameters: such as job_tasks (total number of job tasks) and job_ntasks_per_node (number of tasks per node), defining the total number of tasks and node task allocation rules when the component runs in parallel; Runtime Control and Output: such as job_time (job time limit), to avoid jobs occupying resources for a long time; job_output (standard output path) and job_error (error output path), specifying the storage locations of normal job logs and error logs respectively, facilitating instance problem localization.

[0074] In an optional implementation, the normalization script in step S3 includes at least the following types:

[0075] Configuration scripts: used to configure general business parameters, control loop logic, set regional parameters, and parse console parameters.

[0076] Specifically, configuration scripts centrally configure general business parameters, control loop logic, set regional parameters, and parse dynamic parameters from the console, providing a unified parameter benchmark for the entire system. Specifically, these include: configure.sh: defines global paths (such as GRAPES source code path, working path), data storage paths (observation / background field path), and other process scheduling parameters, providing basic configuration for all components; cycle.sh: sets the experiment cold / warm start time, loop start and end time, forecast duration, and loop interval, including component start / stop switches, controlling the rolling forecast loop logic; setDomain.sh: configures spatial parameters such as forecast area resolution, grid point count, and latitude / longitude range, supporting global modification of regional settings; getargs.sh: parses dynamic parameters from the console (such as time intervals and configuration file paths), converts them into system-recognizable variables, and integrates dynamic and pre-configured parameters.

[0077] Component execution script: One script per component, with parameters defined based on metadata, supporting independent execution of components.

[0078] Specifically, each component has its own dedicated script for execution. Based on metadata, the script defines the component's execution parameters, enabling independent operation of the entire "input-computation-output" process without relying on other components. Specifically, these include: run-4dvar.sh: a dedicated script for the variational assimilation calculation component, which loads assimilation metadata, calls the corresponding executable program, completes the core calculation, and outputs the assimilation analysis field; run-psi.sh: a script for the mode initialization component, which distinguishes between cold / warm start modes, loads the background field and static data, and calls the program to generate the mode's initial field and boundary conditions; run-avebckg.sh: a script for the background field mean calculation component, which reads data from preceding components, calls the program to calculate the mean, and generates the corresponding file; and run-read.sh: a script for the hourly background field preprocessing component, which loads data, performs data segmentation and format conversion, and provides time-series matching data for subsequent components.

[0079] Job submission scripts: One script per component, used to generate the submission configuration for supercomputing cluster jobs.

[0080] Specifically, each component has a corresponding job submission script, which translates the component's runtime requirements into job configurations recognizable by the supercomputing cluster, enabling automated submission and resource allocation for supercomputing jobs. Specifically, these include: sbatch-4dvar.sh: the variational assimilation component job submission script, which configures cluster parameters (partition, number of tasks, duration) according to metadata, generates job cards, and calls the corresponding execution script; sbatch-psi.sh: the pattern initialization component submission script, which defines the job name and output path, calls run-psi.sh, and matches the component's computational resource requirements; sbatch-avebckg.sh: the background average calculation component submission script, which configures job comments, memory, etc., associates with the execution script, and submits it to the supercomputing cluster; and sbatch-grapes.sh: the pattern calculation component submission script, which configures high resource parameters (large number of tasks, long duration) to ensure stable execution of pattern integration and associated storage during experiments for subsequent job status monitoring and process tracking.

[0081] Utility scripts: at least used for naming and defining components and verifying the scientific validity of instances in custom scenarios.

[0082] Specifically, utility scripts are used for auxiliary functions such as component management and configuration parsing in custom scenarios, ensuring the scientific and flexible nature of the instance execution process. These include: `define_module_dependencies.sh`: In custom scenarios, it generates component names according to rules, defines "AND / OR" dependencies between components, and provides a foundation for instance naming; `decode_ini.sh`: Parses the component's INI configuration file, extracts parameters from each section, and converts them into shell variables for the running script to call; `test_validator.sh`: Verifies the custom scenario test name, reverse-checks component predecessor dependencies, and outputs error messages if missing dependencies.

[0083] In an optional implementation, the organization of the file directory in step S4 includes at least the following:

[0084] Script storage directory: Used to categorize and store configuration scripts, component execution scripts, job submission scripts, and utility scripts.

[0085] Specifically, the script storage directory adopts a hierarchical structure based on functional categories to ensure the orderly storage and rapid retrieval of various standardized scripts. The top level of this directory is typically set as the "scripts" main directory, under which subdirectories are divided according to script type: the "config" subdirectory specifically stores configuration scripts, including global parameter configuration scripts (such as "global_params.py"), loop logic control scripts (such as "cycle_controller.py"), and domain parameter setting scripts (such as "domain_config.py"), etc., and each script is further named according to its functional module for easy identification of the parameter configuration range it is responsible for; the "run" subdirectory corresponds to component execution scripts, adopting a hierarchical structure consistent with the component division logic. For example, the "run / assimilation / core / " directory stores the execution scripts for the assimilation core calculation component, and the "run / model / preprocess / background / " directory stores the execution scripts for the background field processing component. Each script is named... The scripts are named in the format "run_component identifier.py" (e.g., "run_assim_core.py"), which clearly corresponds to specific components. The "submit" subdirectory stores job submission scripts, and its directory structure is consistent with the "run" subdirectory. The script naming format is "submit_component identifier.sh" (e.g., "submit_model_calc.sh"), ensuring that each component's run script corresponds one-to-one with its submission script. The "tools" subdirectory centrally stores utility scripts, including component naming definition scripts (e.g., "component_naming.py"), data format conversion scripts (e.g., "bufr2netcdf.py"), log analysis scripts (e.g., "log_analyzer.py"), etc., and is further subdivided into subdirectories such as "naming", "conversion", and "analysis" according to tool functions. This organization method not only ensures centralized management of scripts of the same type, but also achieves precise mapping between scripts and components / functions through structured paths, making it easy for developers to quickly locate the required scripts for modification or invocation.

[0086] Program storage directory: Used to store the executable programs of numerical weather forecasting software.

[0087] Specifically, the program storage directory is based on the hierarchical division of components, constructing an executable program storage system that corresponds to the source code structure, ensuring the orderly management of compilation artifacts. Its top-level directory is usually set to "bin" (binary program) or "executables", and subdirectories are created level by level according to the hierarchy of "subsystem-module-component": the "assimilation" subdirectory corresponds to the assimilation-related functional subsystem, under which the "preprocess" subdirectory stores the executable program of the observation preprocessing module, the "calculation" subdirectory stores the executable program of the assimilation calculation module, where the "core" directory stores the compilation product of the assimilation core calculation class component (such as "assim_core.exe"), and the "boundary" directory stores the executable program of the boundary update class component (such as "boundary_update.exe"); the "model" subdirectory corresponds to the model-related functional subsystem, under which the "preprocess" subdirectory contains the program of the model preprocessing module, such as the "background" directory storing the executable program of the background field processing component (such as "bg_process.exe"), the "initialization" directory storing the program of the initialization class component (such as "init.exe"), and the "calculation" subdirectory storing the core program of the model calculation module (such as "model_integrate.exe"). Each executable program is named using the "component function identifier" format to avoid name conflicts and facilitate direct invocation by the running script via path concatenation (e.g., " / bin / model / preprocess / background / bg_process.exe"). In addition, the program storage directory includes a "lib" subdirectory to store shared dynamic link libraries for each component (e.g., "libmath_ops.so" and "libio_utils.so"), and a "version" subdirectory to store different compiled versions of the program by version number (e.g., "v1.0 / " and "v1.1 / "), supporting parallel management and rapid switching between multiple versions to meet the version requirements of different instances.

[0088] Instance running directory: Used to store data and logs during instance operation. The data is stored in categories according to components and runtime, and the logs include at least script scheduling logs and program running logs.

[0089] Specifically, the instance runtime directory adopts a two-tiered classification structure of "component-runtime" to achieve fine-grained management of runtime data and logs, while supporting the parallel execution of multiple experimental instance scenarios. Its top-level is typically the "experiments" directory, under which first-level subdirectories are created according to the experimental scenario name (e.g., "standard_test" "custom_scenario_1"). Each scenario directory is further divided into second-level subdirectories according to "component identifier-runtime". For example, the "assim_core-2023080100" directory stores the runtime data of the assimilation core computing component at 0:00 on August 1, 2023, while the "model_calc-2023080106" directory stores the data of the model computing component at 0:00 on August 1, 2023. Each component's subdirectory is further divided into "input," "output," and "interim" subdirectories: "input" stores the input data read by the component during runtime (such as soft links or copies of observation data and background field data); "output" stores the output results generated by the component (such as assimilation analysis fields and forecast fields); and "interim" stores temporary data generated during the calculation process (such as intermediate iteration results), avoiding confusion between different types of data. Log storage uses a separate "logs" directory, running parallel to the data directory, categorized into "scheduling logs" and "running logs": the "scheduler" subdirectory stores script scheduling logs (such as "cycle_scheduler_2023080100.log"), recording process information such as the start time, running status, and dependencies of each component; the "component" subdirectory stores program running logs (such as "assim_core-2023080100.log") by "component identifier - runtime number," containing detailed information such as parameter settings, calculation progress, and error messages during component execution. This organizational approach ensures that each component has a clearly defined storage location for instance data and logs at each time point. This facilitates real-time monitoring during operation (by viewing the corresponding logs), as well as result tracing after the instance operation ends. It also supports the parallel operation of instances across multiple time points and scenarios without generating data conflicts.

[0090] In an optional implementation, the standard scenario described in step S5 further includes a full-process scenario, a mode-only function scenario, and an assimilation-only function scenario.

[0091] The entire process scenario involves enabling the operation of both pattern-related and assimilation-related components, and triggering their execution via the central control script.

[0092] Specifically, the full-process scenario aims to simulate the complete business chain of numerical weather prediction from observational data input to final forecast product output. Its core is to integrate assimilation-related components and model-related components into the same operational flow. During construction, the running status of all related components must be uniformly set to "enabled" (e.g., "assimilation_core=on", "model_calc=on") through component switch configuration in the configuration file, ensuring that each stage of assimilation and modeling participates in instance execution. The master control script, as the core of process triggering and scheduling, first parses the time and region configurations in the general business parameters, and then calls the execution scripts of each component sequentially according to the business order of "observation preprocessing → assimilation calculation → model preprocessing → model calculation". For example, the master control script first triggers the observation preprocessing component to generate high-quality observational data; after its completion, it automatically calls the assimilation core calculation component to fuse the observational data and background field to generate the analysis field; then it starts the model preprocessing component to process the analysis field into the model initial field; finally, it triggers the model calculation component to perform numerical integration and generate forecast results. Throughout the process, the master control script monitors the operation logs and output data of each component to ensure the workflow proceeds in sequence. If any component fails, the subsequent workflow will be immediately terminated and error information will be recorded. This full-process scenario is mainly used to verify the end-to-end functional integrity of the system and is suitable for scenarios such as overall software testing and forecast effect evaluation.

[0093] The only mode function scenario: the operation switch of the assimilation-related components is set to the disabled state, and the operation of the mode-related components is triggered by the master control script.

[0094] Specifically, the "Model-Only Functionality" scenario focuses on the operational logic and forecast performance of the numerical weather prediction model itself. By disabling assimilation-related functions, it tests the model's computational process from the initial field to the forecast field. When building this scenario, component switches need to be specifically configured in the configuration file: all assimilation-related components (such as observation preprocessing, assimilation core calculation, boundary updates, etc.) should be set to "disabled" (e.g., "obs_preprocess=off", "assimilation_core=off"), while keeping model-related components (background field processing, initialization, model calculations, etc.) enabled. Upon reading this configuration, the master control script will skip all assimilation steps and directly trigger the process from model preprocessing. This scenario is suitable for experiments such as optimizing model physical process parameterization schemes and comparing the impact of different initial fields on forecasts. It effectively eliminates the interference of the assimilation process on model forecast results, allowing focus on the model's performance analysis.

[0095] The assimilation-only scenario: The operation switch of the mode-related components is set to the disabled state, and the assimilation-related components are triggered to run through the master control script.

[0096] Specifically, the assimilation-only scenario focuses on verifying the optimization effect of the assimilation system on the initial field. By disabling the model calculation stage, the process of generating the assimilation analysis field from the observed data is tested separately. In the scenario configuration, the running switches of model-related components (such as model calculation, model post-processing, etc.) need to be set to "disabled" (e.g., "model_calc=off", "init=off"), while only the assimilation-related components are kept in the "enabled" state (e.g., "obs_preprocess=on", "assimilation_core=on").

[0097] All three standard scenarios are automated through a master control script. The core difference lies in the configuration combination of component switches. This design allows users to quickly switch test scenarios simply by adjusting the configuration file without modifying the script or program code, greatly improving the efficiency of different function verifications.

[0098] In an optional implementation, see Figure 2 As shown, Figure 2 A flowchart of a method for constructing a component-independent running scenario provided in Embodiment 1 of the present invention is shown, wherein the construction process of the component-independent running scenario includes:

[0099] S5.1: Configure the input and output information of the component, wherein the input information includes at least input data and input path, and the output information includes at least output data and output path.

[0100] Specifically, the core of building a component-independent running scenario is to isolate the component from other modules and achieve isolated operation of a single component through precise configuration, in order to verify its functional correctness and performance. This process requires step-by-step completion of input / output definition, metadata adjustment, running mode adaptation, and script execution to ensure that the component can still perform its specific functions as expected in an independent environment.

[0101] First, configure the input and output information of the component. This is the fundamental data guarantee for the independent operation of the component. The input information must clearly define all the data resources required for the component's operation, including specific input data (such as background field data, observation data, and error covariance data required by the assimilation core calculation component) and their storage paths (e.g., " / data / background / 2023080100.nc" and " / data / obs / 2023080100 / "). For dependent predecessor data, it is necessary to prepare it manually or use symbolic links to point to the output of the simulated predecessor component to ensure the integrity and correct format of the input data. The output information must define the data type of the results generated by the component (such as the assimilation analysis field, processed background field, log files, etc.) and their storage paths (e.g., " / work / assim_core_test / output / 2023080100 / "). The paths are usually named in the format of "component identifier-experiment number" for easy independent management and subsequent verification of the results. At the same time, it is necessary to ensure that the output path has write permissions to avoid component failure due to permission issues.

[0102] S5.2: Adjust the metadata corresponding to this component, including at least the global configuration, component-specific configuration, and job submission configuration in the configuration file.

[0103] Specifically, the next step is to adjust the metadata corresponding to the component to provide precise parameter configurations for independent operation. Global configurations in the configuration file need to be adapted to the independent operation scenario. For example, the number of parallel computing cores should be adjusted to a reasonable value required for the component to run independently, avoiding resource waste. Data format parameters must be consistent with the input and output data formats (e.g., uniformly NetCDF4). Component-specific configurations should focus on the core functional parameters of the component. For example, the homogenization core computing component needs to set the number of iterations and observation error coefficients, while the background field processing component needs to specify the interpolation method and resolution conversion rules, ensuring that the parameter values ​​conform to the component's operating logic. Job submission configurations need to adjust resource parameters according to the component's computational needs. For example, for a computationally intensive observation preprocessing component, the supercomputing cluster queue can be set to the "test" queue with a runtime of 30 minutes, while for a computationally intensive mode computing component, a "high_perf" queue and a longer runtime should be configured to ensure that the component obtains sufficient computing resources.

[0104] S5.3: If a component has two operating modes, cold start and warm start, the two modes are distinguished by the mode identifier parameter in the metadata, and the input data and program configuration file of the corresponding mode are matched. The program configuration file includes shell configuration file and exe configuration file.

[0105] Specifically, if a component supports both cold start and warm start operating modes, these must be explicitly distinguished using mode identifier parameters in the metadata, and the corresponding input data and program configuration file must be matched. Cold start mode (usually identified by "run_mode=cold") indicates that the component starts running from its initial state, without relying on historical calculation results. In this mode, complete initial input data must be configured (similar to how a cold start for a homogenized component requires complete background field and observation data), and the program configuration file must include initialization-related parameters (such as initial iteration coefficients). Warm start mode (identified by "run_mode=warm") continues calculation based on the intermediate results of the previous run. A historical data path must be specified (e.g., " / work / assim_core_test / interim / 2023073118 / "), and the input data can only contain incremental information (such as newly added observation data). The program configuration file must be adjusted to continue calculation parameters (e.g., starting from the 30th iteration instead of the initial iteration). By switching the mode identifier parameters, the component can automatically adapt to different operating logic to meet the needs of different testing scenarios.

[0106] S5.4: Specifies the shell configuration file and exe configuration file for this component, runs the corresponding component execution class script, and enables the component to run independently.

[0107] Specifically, by specifying the component's shell configuration file (i.e., a *.ini format configuration file containing global configurations, component switches, component-specific parameters, etc.) and exe configuration file (i.e., the executable program's own namelist configuration file), the corresponding component runtime script (such as run-4dvar.sh, run-psi.sh) can be run to independently start the component. When running the script, dynamic information such as the instance time and mode identifier must be passed through console parameters; the script will automatically parse these parameters, load the preset shell and exe configurations, build the runtime environment such as temporary directories and environment variables required for component operation, and call the component's corresponding executable program.

[0108] In an optional implementation, the process of constructing the custom scene in step S5 includes:

[0109] Component Identifier Setting: Assign unique identifiers to subsystems, modules, and components in sequence. The complete identifier of a component is composed of the identifier of its subsystem, the identifier of its module, and its own component identifier.

[0110] Specifically, the component identifier setting needs to assign a unique identifier to each unit in the three-level hierarchy of "subsystem-module-component". The complete identifier of a component is not a newly added code, but is directly composed of the identifier of its subsystem, the identifier of its module and its own component identifier.

[0111] Among them, the component identification setting is to establish a unified and traceable hierarchical identification system for numerical weather forecasting software components. The core logic is to assign a unique identifier to each level unit according to the three functional levels of "subsystem S-module M-component C". Then, the complete identifier of the component is formed by directly combining the hierarchical identifiers, so as to realize the precise positioning and unified management of the component from the top functional domain to the bottom execution unit.

[0112] In terms of identifier allocation rules, each level uses a two-digit number as a unique identifier, and the identifiers increment sequentially from "01" to ensure no duplication or skipping within the same level, guaranteeing the uniqueness and orderliness of the identifiers. Specifically, the subsystem level corresponds to the core functional areas of the software (such as homogenization and mode-related functions) and is the top-level classification of the identifier system; the module level is the functional subdivision unit of the subsystem, facilitating the functional association between subsystems and components; and the component level is the smallest functional unit after module decomposition, directly corresponding to the specific execution function of the software. This three-level division not only aligns with the business process logic of numerical weather forecasting software but also lays the foundation for identifier combination and traceability. The complete component identifier follows the "hierarchical splicing" principle, requiring no additional independent coding. It is directly formed by sequentially splicing the subsystem identifier, module identifier, and its own component identifier to form a fixed-length numerical identifier. Taking the meteorological bureau's mesoscale numerical weather prediction system as an example, in the assimilation calculation module (identifier 02) under the assimilation subsystem (identifier 01), the complete identifier of the 3dvar assimilation calculation component (identifier 03) is "01-02-03". Through this identifier, one can directly trace back to its subsystem S and module level M, clearly reflecting the functional affiliation and hierarchical relationship of component C.

[0113] Component dependency analysis: Based on the operational data dependencies of the numerical weather forecasting software, the predecessor and successor components of each component are defined. Components without dependencies are marked as having no dependencies. The "AND / OR" dependencies between components are distinguished by preset symbols.

[0114] Specifically, component dependency analysis aims to clarify the data transmission relationships between components, identifying "who provides input to whom" and "who depends on whose output," thus laying the foundation for the rationality of the scenario flow. During implementation, it is necessary to analyze the data sources and destinations of each component based on the business logic of numerical weather prediction: Precursor components are those that provide input data to the current component (e.g., the homogenization core calculation component depends on high-quality observation data provided by the observation preprocessing component and background field data provided by the background field processing component; therefore, these two components are its predecessors); successor components are those that receive the output data of the current component (e.g., the output of the background field processing component is passed to the initialization component; therefore, the initialization component is its successor).

[0115] Components with no dependencies must be explicitly marked as "no dependencies". When a component has multiple dependencies, "AND" and "OR" relationships must be distinguished using preset symbols: "&" represents "AND" and "|" represents "OR". Dependencies must be recorded in the form of a table or configuration file to ensure that they can be directly invoked in subsequent naming and verification processes.

[0116] Component naming definition: The component name is composed of three parts: the predecessor component identifier, the complete component identifier - runtime, and the successor component identifier, combined according to a preset format.

[0117] Specifically, the component name is composed of three parts in a preset format: the predecessor component identifier, the complete component identifier - runtime number, and the successor component identifier. The predecessor component identifier corresponds to the identifier of the preceding component that the component depends on for its operation. It uses the complete component identifier (i.e., a numerical identifier concatenated in the three-level hierarchy of "subsystem-module-component") to clearly identify the input source component that needs to be ready before the component runs. The complete component identifier - runtime number is the core part of the name. The complete component identifier is a unique numerical identifier concatenated in the three-level hierarchy of "subsystem-module-component," and the runtime number is the specific time when the component participates in the instance's execution. The combination of these two elements reflects both the component's hierarchical affiliation and its temporal role within the instance. The successor component identifier corresponds to the complete identifier of the subsequent component that receives the output data from this component, used to define the functional flow after the component runs.

[0118] The three parts have a fixed preset combination format, connected sequentially with " / / " as the separator, forming a structure of "predecessor component identifier / / complete component identifier - runtime / / successor component identifier". The component naming definition must be standardized by calling the dedicated script define_module_dependencies.sh after completing the experimental loop settings, current runtime configuration, and component switch definition prerequisites. This ensures that the component naming is consistent with the instance's runtime parameters and function selection, providing an interpretable naming basis for subsequent scientific verification of experiments (such as dependency checks).

[0119] Instance naming definition: The name is composed of the component names connected by a preset separator.

[0120] Specifically, instance naming is a holistic identifier for all components in a custom scenario. By linking the component names together to form a complete scenario chain, it intuitively reflects the sequence of components contained in the instance and their execution order. During implementation, the names of each component in the scenario, ordered by business process, need to be connected sequentially using a preset separator (such as a vertical bar "|") to form the instance name.

[0121] Example scientific verification: Input the example name, and the verification script checks from the end to the beginning whether the predecessor component of each component exists in the preceding process. If a component is missing a predecessor component, an error message is output. The error message includes at least: the identifier of the missing component, the identifier of the predecessor component required by the component, the identifier of the component that actually exists in the preceding process, and the identifier of the missing predecessor component.

[0122] Specifically, scientific verification is a crucial step in ensuring the rationality of custom scenario flows. By reverse-engineering component dependencies, experiment failures caused by missing predecessor components can be avoided. During implementation, a dedicated verification script must be run. After inputting the instance name, the script executes according to the following logic: First, the instance name is split by a separator to obtain a sequentially arranged list of component names; then, starting from the last component, the "predecessor component identifier" in each component name is parsed sequentially from back to front; next, it checks whether the component corresponding to the predecessor identifier exists in the list preceding the current component (i.e., the preceding flow); if it exists, the previous component is checked; if it does not exist, an error is immediately triggered.

[0123] Error messages must include specific details: the identifier of the missing dependency component, the identifier of the predecessor component required by that component, the identifier of the component actually existing in the preceding process, and the identifier of the missing predecessor component. This verification method can detect dependency breakage issues before the instance starts, ensuring the scientific validity and executability of the custom scenario's workflow.

[0124] Example 2

[0125] See Figure 3 As shown, Figure 3 The diagram shows a structural schematic of a construction device for componentization and operation of numerical weather prediction software according to Embodiment 2 of the present invention, wherein the device includes:

[0126] The component partitioning module 301 is used to perform step S1: partitioning the numerical weather prediction software into components so that each component can be compiled and run independently;

[0127] Metadata definition module 302 is used to perform step S2: define metadata, wherein the metadata includes general business parameters for describing the general operating configuration of the system and component-specific parameters for distinguishing component characteristic configurations;

[0128] The script writing module 303 is used to execute step S3: writing a standardized script, which is used to implement the setting and calling of the metadata and supports the independent operation of the component and job submission;

[0129] The directory organization module 304 is used to perform step S4: to organize the file directory in a standardized manner, wherein the file directory is used to classify and store scripts, executable programs and instance running related data;

[0130] The instance building module 305 is used to execute step S5: build a running instance based on steps S1-S4. The running instance includes standard scenarios and / or custom scenarios. The standard scenario includes at least a component-independent running scenario.

[0131] In an optional implementation, the specific process of component partitioning in step S1 is as follows:

[0132] Based on the business process logic of numerical weather prediction software, the software is divided into subsystems, modules, and components from high to low levels.

[0133] The subsystem covers at least assimilation-related functions and pattern-related functions. The module is a functional subdivision unit of the subsystem, and the component is a unit that can be independently implemented to achieve a specific function and is further subdivided from the module.

[0134] The subsystem for pattern-related functions includes at least a pattern preprocessing module and a pattern calculation module.

[0135] The pattern preprocessing module includes at least one component for performing pattern preprocessing; the pattern calculation module includes at least one component for performing pattern calculation.

[0136] The subsystem for the assimilation-related functions includes at least an observation preprocessing module and an assimilation calculation module;

[0137] The observation preprocessing module includes several components for performing observation preprocessing; the assimilation calculation module includes several components for performing assimilation calculation.

[0138] In an optional implementation, the general business parameters in step S2 are derived from a preset configuration script, which is used at least to implement process scheduling configuration, overall control configuration, and regional parameter configuration.

[0139] The process scheduling configuration includes at least the software source code path, working path, and data storage path; the overall control configuration includes at least the start time, loop interval, and forecast duration; and the regional parameter configuration includes at least the spatial resolution, latitude and longitude range, and number of grid points.

[0140] In an optional implementation, the component-specific parameters in step S2 include dynamically adjusted console parameters and relatively fixed configuration file parameters;

[0141] The console parameters include at least the instance runtime, configuration file path, program input file path, forecast duration, and background field type;

[0142] The configuration file parameters include global configuration for describing the global characteristics of the system, component switch configuration for controlling the start and stop of components, component-specific configuration for defining the running attributes of components, and job submission configuration for configuring job submission information.

[0143] In an optional implementation, the normalization script in step S3 includes at least the following types:

[0144] Configuration scripts: used to configure general business parameters, control loop logic, set regional parameters, and parse console parameters;

[0145] Component execution script: one script per component, parameters are defined based on metadata, and the component can run independently;

[0146] Job submission scripts: one script per component, used to generate the submission configuration for supercomputing cluster jobs;

[0147] Utility scripts: at least used for naming and defining components and verifying the scientific validity of instances in custom scenarios.

[0148] In an optional implementation, the organization of the file directory in step S4 includes at least the following:

[0149] Script storage directory: used to categorize and store configuration scripts, component execution scripts, job submission scripts, and utility scripts;

[0150] Program storage directory: Used to store the executable programs of numerical weather forecasting software;

[0151] Instance running directory: Used to store data and logs during instance operation. The data is stored in categories according to components and runtime, and the logs include at least script scheduling logs and program running logs.

[0152] In an optional implementation, the standard scenario described in step S5 further includes a full-process scenario, a mode-only function scenario, and an assimilation-only function scenario;

[0153] The entire process scenario is as follows: the operation switches of both the mode-related components and the assimilation-related components are set to the enabled state, and the operation is triggered by the master control script;

[0154] The only mode function scenario is to disable the operation switch of the assimilation-related components and trigger the operation of the mode-related components through the master control script;

[0155] The assimilation-only scenario: The operation switch of the mode-related components is set to the disabled state, and the assimilation-related components are triggered to run through the master control script.

[0156] In an optional implementation, the process of building the scenario where the component runs independently includes:

[0157] The configuration component includes input and output information, wherein the input information includes at least input data and input path, and the output information includes at least output data and output path;

[0158] Adjust the metadata corresponding to this component, including at least the global configuration, component-specific configuration, and job submission configuration in the configuration file;

[0159] If a component has two operating modes, cold start and warm start, the two modes are distinguished by the mode identifier parameter in the metadata, and the input data and program configuration file of the corresponding mode are matched. The program configuration file includes shell configuration file and exe configuration file.

[0160] Specify the shell configuration file and exe configuration file for the component, and run the corresponding component execution class script to enable the component to run independently.

[0161] In an optional implementation, the process of constructing the custom scene in step S5 includes:

[0162] Component Identification Setting: A unique identifier is assigned to subsystems, modules, and components in sequence. The complete identifier of a component is composed of the identifier of its subsystem, the identifier of its module, and its own component identifier.

[0163] Component dependency analysis: Based on the operational data dependencies of the numerical weather forecasting software, the predecessor and successor components of each component are defined. When there is no dependency, it is marked as no dependency. The "AND / OR" dependencies between components are distinguished by preset symbols.

[0164] Component naming definition: The component name is composed of three parts: the predecessor component identifier, the complete component identifier - runtime, and the successor component identifier, combined according to a preset format;

[0165] Instance naming definition: The name is composed of the component names connected by a preset separator;

[0166] Example scientific verification: Input the example name, and the verification script checks from the end to the beginning whether the predecessor component of each component exists in the preceding process. If a component is missing a predecessor component, an error message is output. The error message includes at least: the identifier of the missing component, the identifier of the predecessor component required by the component, the identifier of the component that actually exists in the preceding process, and the identifier of the missing predecessor component.

[0167] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0168] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. All should be covered 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.

Claims

1. A method for constructing componentized and runtime instances of numerical weather prediction software, characterized in that, Includes the following steps: S1: Divide the numerical weather prediction software into components so that each component can be compiled and run independently; S2: Define metadata, which includes general business parameters for describing the general operating configuration of the system and component-specific parameters for distinguishing component characteristic configurations; S3: Write a standardized script, which is used to set and call the metadata and support the independent operation of the component and job submission; S4: Organize the file directory in a standardized manner. The file directory is used to classify and store scripts, executable programs and instance running related data. S5: Construct a running instance based on steps S1-S4. The running instance includes standard scenarios and / or custom scenarios. The standard scenario includes at least a component-independent running scenario. The specific process of component partitioning in step S1 is as follows: Based on the business process logic of numerical weather prediction software, the software is divided into subsystems, modules, and components from high to low levels. The subsystem covers at least assimilation-related functions and pattern-related functions. The module is a functional subdivision unit of the subsystem, and the component is a unit that can be independently implemented to achieve a specific function and is further subdivided from the module. The subsystem for pattern-related functions includes at least a pattern preprocessing module and a pattern calculation module. The pattern preprocessing module includes at least one component for performing pattern preprocessing; the pattern calculation module includes at least one component for performing pattern calculation. The subsystem for the assimilation-related functions includes at least an observation preprocessing module and an assimilation calculation module; The observation preprocessing module includes several components for performing observation preprocessing. The assimilation calculation module contains several components for performing assimilation calculations.

2. The method according to claim 1, characterized in that, The general business parameters mentioned in step S2 are derived from a preset configuration script, which is used to implement at least process scheduling configuration, overall control configuration, and regional parameter configuration. The process scheduling configuration includes at least the software source code path, working path, and data storage path; the overall control configuration includes at least the start time, loop interval, and forecast duration; and the regional parameter configuration includes at least the spatial resolution, latitude and longitude range, and number of grid points.

3. The method according to claim 1, characterized in that, The component-specific parameters mentioned in step S2 include dynamically adjusted console parameters and relatively fixed configuration file parameters; The console parameters include at least the instance runtime, configuration file path, program input file path, forecast duration, and background field type; The configuration file parameters include global configuration for describing the global characteristics of the system, component switch configuration for controlling the start and stop of components, component-specific configuration for defining the running attributes of components, and job submission configuration for configuring job submission information.

4. The method according to claim 1, characterized in that, The normalization script mentioned in step S3 includes at least the following types: Configuration scripts: used to configure general business parameters, control loop logic, set regional parameters, and parse console parameters; Component execution script: one script per component, parameters are defined based on metadata, and the component can run independently; Job submission scripts: one script per component, used to generate the submission configuration for supercomputing cluster jobs; Utility scripts: at least used for naming and scientific validation of components in custom scenarios.

5. The method according to claim 1, characterized in that, The file directory organization method described in step S4 includes at least the following: Script storage directory: used to categorize and store configuration scripts, component execution scripts, job submission scripts, and utility scripts; Program storage directory: Used to store the executable programs of numerical weather forecasting software; Instance running directory: Used to store data and logs during instance operation. The data is stored in categories according to components and runtime, and the logs include at least script scheduling logs and program running logs.

6. The method according to claim 1, characterized in that, The standard scenarios mentioned in step S5 also include full-process scenarios, mode-only function scenarios, and assimilation-only function scenarios; The entire process scenario is as follows: the operation switches of both the mode-related components and the assimilation-related components are set to the enabled state, and the operation is triggered by the master control script; The only mode function scenario is to disable the operation switch of the assimilation-related components and trigger the operation of the mode-related components through the master control script; The assimilation-only scenario: The operation switch of the mode-related components is set to the disabled state, and the assimilation-related components are triggered to run through the master control script.

7. The method according to claim 6, characterized in that, The process of constructing the scenario where the component runs independently includes: The configuration component includes input and output information, wherein the input information includes at least input data and input path, and the output information includes at least output data and output path; Adjust the metadata corresponding to this component, including at least the global configuration, component-specific configuration, and job submission configuration in the configuration file; If a component has two operating modes, cold start and warm start, the two modes are distinguished by the mode identifier parameter in the metadata, and the input data and program configuration file of the corresponding mode are matched. The program configuration file includes shell configuration file and exe configuration file. Specify the shell configuration file and exe configuration file for the component, and run the corresponding component execution class script to enable the component to run independently.

8. The method according to claim 1, characterized in that, The process of constructing the custom scene in step S5 includes: Component Identification Setting: A unique identifier is assigned to subsystems, modules, and components in sequence. The complete identifier of a component is composed of the identifier of its subsystem, the identifier of its module, and its own component identifier. Component dependency analysis: Based on the operational data dependencies of the numerical weather forecasting software, the predecessor and successor components of each component are defined. When there is no dependency, it is marked as no dependency. The "AND / OR" dependencies between components are distinguished by preset symbols. Component naming definition: The component name is composed of three parts: the predecessor component identifier, the complete component identifier - runtime, and the successor component identifier, combined according to a preset format; Instance naming definition: The name is composed of the component names connected by a preset separator; Example scientific verification: Input the example name, and the verification script checks from the end to the beginning whether the predecessor component of each component exists in the preceding process. If a component is missing a predecessor component, an error message is output. The error message includes at least: the identifier of the missing component, the identifier of the predecessor component required by the component, the identifier of the component that actually exists in the preceding process, and the identifier of the missing predecessor component.

9. A device for constructing componentized and runtime instances of numerical weather prediction software, characterized in that, The device includes: The component partitioning module is used to perform step S1: partitioning the numerical weather prediction software into components so that each component can be compiled and run independently; The metadata definition module is used to perform step S2: define metadata, which includes general business parameters for describing the general operating configuration of the system and component-specific parameters for distinguishing component characteristic configurations; The script writing module is used to execute step S3: writing a standardized script, which is used to set and call the metadata and support the independent operation of the component and job submission; The directory organization module is used to perform step S4: to organize the file directory in a standardized manner, wherein the file directory is used to classify and store scripts, executable programs and instance running related data; The instance building module is used to execute step S5: build a running instance based on steps S1-S4. The running instance includes standard scenarios and / or custom scenarios. The standard scenario includes at least a component-independent running scenario. The specific process of component partitioning in step S1 is as follows: Based on the business process logic of numerical weather prediction software, the software is divided into subsystems, modules, and components from high to low levels. The subsystem covers at least assimilation-related functions and pattern-related functions. The module is a functional subdivision unit of the subsystem, and the component is a unit that can be independently implemented to achieve a specific function and is further subdivided from the module. The subsystem for pattern-related functions includes at least a pattern preprocessing module and a pattern calculation module. The pattern preprocessing module includes at least one component for performing pattern preprocessing; the pattern calculation module includes at least one component for performing pattern calculation. The subsystem for the assimilation-related functions includes at least an observation preprocessing module and an assimilation calculation module; The observation preprocessing module includes several components for performing observation preprocessing; the assimilation calculation module includes several components for performing assimilation calculation.

Images