Microscopic Simulation Particle Filter Data Assimilation System and Simulation Method Based on Thread Pool

Abstract

This application relates to a microscopic simulation particle filter data assimilation system and a simulation method based on a thread pool. The system includes: a data assimilation basic element representation module for representing the basic elements of microscopic simulation particle filter data assimilation; a particle filter concurrent sampling module for performing particle filter concurrent sampling based on a thread pool; a particle filter data assimilation operation control logic for scheduling and running the data assimilation basic element representation module and the particle filter concurrent sampling module according to the correct timing and dependency relationships, and in microscopic simulation, continuously assimilating the observation data of the real system into the simulation model by executing the calculation steps of the particle filter, so that the simulation model dynamically adjusts its own state to approximate the state of the real system. This system can efficiently and concurrently execute the particle filter sampling tasks in microscopic simulation, improving the simulation performance.

Description

Technical Field

[0001] This application relates to the technical field of dynamic data-driven technology, and particularly to a micro-simulation particle filter data assimilation system and a simulation method based on a thread pool. Background Art

[0002] Dynamic data-driven simulation is a "model and data combination" simulation paradigm. It continuously injects observations (data) of the real system into the simulation (model), allowing the data to dynamically correct the simulation (state, parameters), so as to improve the simulation-based estimation and prediction capabilities. Since dynamic data-driven simulation integrates the information of model prediction and real-time observation, it can more accurately estimate the state of the real system and predict the future evolution of the state. Because of such advantages, dynamic data-driven simulation has been successfully applied to scenarios such as forest fire spread prediction, pedestrian movement trajectory prediction, and vehicle trajectory reconstruction in urban traffic systems. In dynamic data-driven simulation, "data dynamically correcting the simulation" is achieved by data assimilation technology. And since the "simulation" in dynamic data-driven simulation generally refers to micro-simulation, and its state evolution process has highly non-linear / non-Gaussian characteristics, therefore, the most commonly used data assimilation method in dynamic data-driven simulation is the particle filter algorithm.

[0003] The particle filter data assimilation software system is a prerequisite and basic support for carrying out dynamic data-driven simulation. However, implementing particle filter data assimilation in micro-simulation is not as simple and intuitive as in ordinary real vector state equations. There are the following challenges in implementing particle filter data assimilation in micro-simulation:

[0004] First, in microscopic simulation, the state of the system model is not a real vector but a complex data structure that may contain both numerical state variables (e.g., the length of the queue in a queuing system) and non-numerical state variables (e.g., the "busy" or "idle" state of the service desk in a queuing system); similarly, the observed data may also be a mixture of numerical and non-numerical observations. Therefore, it is necessary to design a suitable data structure to effectively represent the simulation model state and observed data in microscopic simulation. Second, in microscopic simulation, the particle filter sampling process is a cyclic simulation running process that repeatedly runs the simulation model for a period of time with the simulation model state at the previous moment as the initial value to obtain the simulation model state at the next moment. The sampling process not only involves the running of simulation experiments but is also an asynchronous calling process (in a general real vector state equation, this process is usually a synchronous calling process). Therefore, it is necessary to design a particle filter sampling method suitable for microscopic simulation to ensure that each calculation step in the particle filter is executed in the correct logical order. Although existing methods implement the particle filter sampling steps in microscopic simulation in a rollback manner, in the rollback-based sampling process, operations such as saving and restoring the model state and resetting the future event table of the simulator are required. These operations are closely related to the specific application and are prone to errors. In addition, the rollback-based sampling process is executed serially. For applications with high real-time requirements such as dynamic data-driven simulation, the running efficiency and resource consumption of serial execution will become bottlenecks in simulation performance. Summary of the Invention

[0005] Based on this, in view of the above technical problems, it is necessary to provide an easy-to-use, efficient, and concurrently executable microscopic simulation particle filter data assimilation system and simulation method based on a thread pool to improve the state estimation and prediction capabilities of microscopic simulation, so that the predicted state of the simulation model after data assimilation is closer to the real system state.

[0006] A microscopic simulation particle filter data assimilation system based on a thread pool, the system is applied to a microscopic simulation platform, and the system includes:

[0007] A data assimilation basic element representation module, which is used to represent the basic elements of microscopic simulation particle filter data assimilation;

[0008] A particle filter concurrent sampling module, which is used to perform particle filter concurrent sampling based on a thread pool;

[0009] A particle filter data assimilation operation control logic, which is used to schedule and run the data assimilation basic element representation module and the particle filter concurrent sampling module according to the correct time sequence and dependency relationship, and in microscopic simulation, continuously assimilate the observed data of the real system into the simulation model by executing the calculation steps of the particle filter, so that the simulation model dynamically adjusts its own state to approximate the state of the real system.

[0010] Furthermore, the basic elements representation module of data assimilation includes a model state class, a weighted particle class, and an observation data class;

[0011] Among them, the model state class is used to represent the state of the simulation model, including two attributes: a time attribute and a state value corresponding to the simulation model;

[0012] The weighted particle class is used to represent particles with weights. Since a particle is essentially a possible state of the simulation model, the weighted particle class includes two attributes: the state of the simulation model and the corresponding weight;

[0013] The observation data class is used to represent the observation data of the real system, including two attributes: the time period when the observation data is collected and the data pair. Among them, the data pair includes a data source and data, and is used to represent the data collected from different data sources.

[0014] Furthermore, the steps for the particle filter concurrent sampling module to perform particle filter concurrent sampling based on a thread pool include:

[0015] In the initialization stage, the main thread creates a thread pool and a task queue; among them, the task queue includes a calculation task queue and a thread request queue stored in sorted order;

[0016] After initialization is completed, the main thread creates several calculation tasks, and abstracts the calculation tasks, the task queue, and the threads into a multi-server single-queue queuing system formalized by the Discrete Event System Specification (DEVS). This multi-server single-queue queuing system dynamically schedules and allocates idle threads to execute calculation tasks based on the states of the calculation task queue and the thread request queue, realizing the concurrent execution of calculation tasks; among them, the calculation task is the particle filter sampling task in microscopic simulation.

[0017] Furthermore, abstracting the calculation tasks, the task queue, and the threads into a multi-server single-queue queuing system formalized by the Discrete Event System Specification includes:

[0018] Abstracting the calculation tasks, the task queue, and the threads into a multi-server single-queue queuing system, each calculation task serves as a customer in the system and receives calculation services from each thread serving as a server;

[0019] After formalizing the multi-server single-queue queuing system using the Discrete Event System Specification, the calculation tasks, the task queue, and the threads in this multi-server single-queue queuing system are all described based on the atomic model of the Discrete Event System Specification, and they are coupled and interact with each other through input and output ports.

[0020] Furthermore, the multi-server single-queue queuing system dynamically schedules and allocates idle threads to execute computing tasks based on the states of the computing task queue and the thread request queue, enabling concurrent execution of computing tasks, including:

[0021] The task queue receives the computing task processing requests from each thread through its own request port, and sorts them in the order of arrival to form a thread request queue; meanwhile, after the task queue receives the computing tasks submitted by the main thread through its arrival port, it determines whether there are any idle threads in the thread request queue;

[0022] If there are, the computing task is sent to the input port of the idle thread through the output port of the task queue, and the idle thread is used to execute the computing task; otherwise, it is sorted in the order of arrival of the computing tasks to form a computing task queue and waits to be executed;

[0023] When the thread finishes executing the computing task, it interacts with the end port of the computing task through its own end port to notify that the computing task has been executed, and the computing task can continue with subsequent operations; meanwhile, the thread becomes idle and sends a computing task processing request to the task queue again through its own request port to query whether there are any computing tasks waiting to be executed in the computing task queue;

[0024] If there are, the computing task at the head of the computing task queue is taken out and executed; otherwise, it continues to remain idle and waits for the main thread to submit new computing tasks;

[0025] When all computing tasks have been executed, all threads in the thread pool become idle and wait to execute the computing tasks generated by particle filter sampling in the next round of microscopic simulation.

[0026] Furthermore, the execution logic of the task queue described based on the atomic model of the discrete event system specification is expressed as:

[0027] ;

[0028] Among them, represents the task queue, represents the input of the task queue; among them, represents the set of input ports of the task queue, including the arrival port and the request port ; the input of the arrival port represents the ID of the computing task submitted by the main thread, and the input of the request port represents the ID of the thread that requests the allocation of a computing task to the task queue;

[0029] Represents the output of the task queue; among them, Represents the set of output ports of the task queue, which contains only one output port ; The output port Output Represents the ID of the computational task that the thread is about to execute;

[0030] Represents the status of the task queue; among them, the computational task queue and the thread request queue Are both FIFO queues, storing respectively the IDs of the computational tasks waiting in line to be executed, and the IDs of the threads waiting in line to be assigned computational tasks;

[0031] Represents the internal state transition function of the task queue. The internal state transition function of the task queue describes how the state of the task queue changes under the control of only the time advancement function in the absence of external input, and is specifically defined as:

[0032] ;

[0033] Among them, "-1" represents removing the head element from the queue;

[0034] Represents the external state transition function of the task queue; among them, the set , the external state transition function of the task queue describes how the state of the task queue changes under the excitation of external input, and is specifically defined as:

[0035] ;

[0036] Among them, "+" represents inserting at the end of the queue;

[0037] Represents the output function of the task queue, which defines what information should be output when the task queue undergoes an internal state transition, and is specifically defined as:

[0038] ;

[0039] Among them, in is the ID of the computational task at the head of the computational task queue ; It should be noted that the thread in the thread pool whose thread ID is equal to the thread ID at the head of the thread request queue will be responsible for executing the computational task with ID ;

[0040] The time advancement function representing the task queue, which defines the duration for which the task queue remains in the state is as follows:

[0041] ;

[0042] The above equation indicates that when both the computing task queue and the thread request queue are not empty, the time advancement value is set to 0, thereby immediately triggering the internal state transition function of the task queue to allocate the computing task at the head of the computing task queue to the idle thread at the head of the thread request queue for execution; the above process is repeated until one of the queues becomes empty.

[0043] Furthermore, the execution logic of the thread described based on the atomic model of the discrete event system specification is expressed as:

[0044] ;

[0045] where represents the thread, represents the input of the thread; among them, represents the set of input ports of the thread, which contains only one input port ; the input of the input port represents the ID of the computing task assigned to this thread by the task queue;

[0046] represents the output of the thread; among them, represents the set of output ports of the thread, including the end port and the request port ; the output of the end port represents the ID of the computing task completed by the thread, and the output of the request port represents the ID of the thread;

[0047] represents the state of the thread; among them, in represents the ID of the computing task currently being executed by this thread, represents the remaining time required for this thread to complete this computing task; if , it means the thread is currently in an idle state, and at this time, set ;

[0048] represents the internal state transition function of the thread, which is specifically defined as:

[0049] ;​​​

[0050] Represents the external state transition function of a thread, specifically defined as:

[0051] ;

[0052] Wherein, represents the time required for the thread to execute the computing task; it should be noted that only when the thread is in state, that is, in the idle state, can it possibly receive the ID of the computing task output by the task queue;

[0053] represents the output function of the thread; when the thread finishes executing the computing task, on the one hand, it notifies through the output port that the computing task has been executed; on the other hand, it also sends a request to allocate a new computing task to the task queue through the output port; therefore, the output function of the thread is specifically defined as:

[0054] ;

[0055] Wherein, refers to the ID of the thread itself;

[0056] represents the time advancement function of the thread, specifically defined as:

[0057] .

[0058] Furthermore, the computing task is specifically defined as: a simulation running process during particle filter sampling in microscopic simulation. This simulation running process takes the particle state at the previous moment as the initial value, and after running the simulation model for a period of time, obtains the particle state at the next moment.

[0059] Furthermore, the particle filter data assimilation operation control logic includes three attributes, namely the weighted particle attribute, which is used to represent a group of weighted particles; the actuator service attribute, which is used to provide a series of interfaces for accessing the thread pool service; the running duration attribute, which is used to represent the update period of the observed data, that is, the data assimilation period; the particle filter data assimilation operation control logic also includes the following functions, namely:

[0060] Initialization function, which is used to generate a group of initial particles and assign weights, obtain the initial weighted particles and create a thread pool;

[0061] Create model instance function, which is an abstract function and is used to support users to instantiate the simulation model according to specific application scenarios;

[0062] The weight update function is an abstract function used to support users in implementing weight calculation based on the error model of the observed data of the real system in a specific application scenario;

[0063] The create calculation task function is an abstract function used to support users in generating calculation tasks based on a simulation model, an initial state, a warm-up time, and a running duration;

[0064] The sampling function is used to implement the concurrent sampling step of particle filtering based on a thread pool; during sampling, first call the create model instance function to instantiate the simulation model; then, based on the simulation model, the initial state, and the running duration, call the create calculation task function to generate calculation tasks and submit the calculation tasks to the thread pool for waiting to be executed; after the calculation tasks are completed by the thread execution, obtain the state of the simulation model and the predicted observed data, and further call the weight update function to update the weights of the particles;

[0065] The weight normalization function is used to be called after the weights of all particles are updated to ensure that the sum of the weights of all particles is 1;

[0066] The resampling function is an abstract function used to support users in adopting a specific resampling method according to a specific application scenario;

[0067] The state estimation function is an abstract function used to support users in calculating the state estimation value based on particles and weights according to a specific application scenario after resampling is completed;

[0068] The particle perturbation function is an abstract function used to support users in using a specific state perturbation method according to the characteristics of a specific application scenario to increase the diversity of particles;

[0069] The particle filter execution function is used to call this function to execute the complete particle filter calculation process when new observed data arrives.

[0070] A simulation method, the method includes:

[0071] Obtain the observed data of the real system, model the real system as a simulation model, and deduce the evolution of the state of the real system over time through the simulation model;

[0072] Use the above microscopic simulation particle filter data assimilation system based on a thread pool to continuously assimilate the observed data of the real system into the simulation model, so that the simulation model dynamically adjusts its own state to approximate the state of the real system.

[0073] The above microscopic simulation particle filter data assimilation system based on a thread pool and the simulation method have the following beneficial effects:

[0074] 1. Construct a microscopic simulation particle filter data assimilation system based on a thread pool. This system designs a data assimilation basic element representation module with strong generality, which can flexibly represent the basic elements of particle filter with different characteristics in microscopic simulation, so as to effectively represent the simulation model state and observation data in microscopic simulation.

[0075] 2. This system performs concurrent sampling of particle filter based on the thread pool, improving the execution efficiency of particle filter sampling in microscopic simulation. Furthermore, it can achieve efficient microscopic simulation. And the thread pool can reduce the operating system resource overhead and computational amount brought by frequent creation and destruction of threads by reusing the already created threads, ensuring the real-time requirement of dynamic data-driven simulation, thus achieving better simulation performance.

[0076] 3. This system is designed based on the operation control logic of particle filter data assimilation, ensuring the scheduling and operation of particle filter in microscopic simulation according to the correct time sequence and dependency relationship, improving the state estimation and prediction ability of microscopic simulation, and making the predicted state of the simulation model after data assimilation closer to the real system state. Description of the Drawings

[0077] Figure 1 It is a schematic diagram of the overall architecture of the microscopic simulation particle filter data assimilation system based on a thread pool in an embodiment;

[0078] Figure 2 It is a schematic diagram of the process of concurrent sampling steps of particle filter based on a thread pool in an embodiment;

[0079] Figure 3 It is a schematic diagram of a multi-server single-queue queuing system described in the form of discrete event system specification in an embodiment;

[0080] Figure 4 It is a schematic diagram of the simulation model in the performance comparison experiment in an embodiment;

[0081] Figure 5 It is a schematic diagram of performance indicators in an embodiment;

[0082] Figure 6 It is a schematic diagram of the performance ratio of two particle filter implementation methods under different model scales and particle numbers in an embodiment;

[0083] Figure 7 It is a schematic diagram of the change of the average time-consuming of single-step data assimilation with the number of particles in an embodiment. Detailed Implementation Modes

[0084] To make the objectives, technical solutions and advantages of this application clearer, the following further elaborates on this application in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely used to explain this application and not to limit it.

[0085] In one embodiment, as Figure 1 shown, a microscopic simulation particle filter data assimilation system based on a thread pool is provided. The system is applied to a microscopic simulation platform and includes:

[0086] A data assimilation basic element representation module, which is used to represent the basic elements of microscopic simulation particle filter data assimilation.

[0087] A particle filter concurrent sampling module, which is used to perform particle filter concurrent sampling based on a thread pool.

[0088] A particle filter data assimilation operation control logic, which is used to schedule and run the data assimilation basic element representation module and the particle filter concurrent sampling module according to the correct time sequence and dependency relationship, and in microscopic simulation, continuously assimilate the observation data of the real system into the simulation model by executing the calculation steps of the particle filter, so that the simulation model dynamically adjusts its own state to approach the state of the real system. Specifically, the calculation steps of the particle filter include:

[0089] (1) Sampling: According to the particles in the th step, run the microscopic simulation times to generate the particles in the th step and update the weight of each particle according to the latest observation data;

[0090] (2) Weight normalization: Normalize the particle weights to ensure that the sum of the particle weights is equal to 1;

[0091] (3) Resampling: Randomly determine whether the particle is to be replicated or deleted according to its weight;

[0092] (4) Estimate the state and output: Based on the particles and weights, adopt a suitable method according to the application characteristics (for example, Monte Carlo integration, or select the particle with the largest weight) to estimate the state of the simulation model and output it as a file for subsequent data analysis and visualization.

[0093] Specifically, resampling and weight update in the particle filter are essentially synchronous call functions. Therefore, this application designs the resampling and weight update steps as abstract functions, only defining the interfaces, and users can implement specific resampling methods (for example, standard resampling, stratified resampling) and weight update methods according to specific application requirements.

[0094] Furthermore, the basic elements of data assimilation include model state, observation data, and particles. In microscopic simulation, the compositions of model state and observation data are diverse and not limited to real vectors. Therefore, a suitable and general data structure needs to be designed to represent the basic elements of data assimilation in microscopic simulation. Thus, the basic element representation module of data assimilation includes a ModelState class, a WeightedParticle class with weights, and an Observation data class. The specific designs of these classes are as follows:

[0095] The ModelState class is used to represent the state of the simulation model. A typical simulation model consists of objects and the relationships between them. The state of the simulation model refers to the set of attributes of all objects that make up the simulation model at a given moment. Therefore, the ModelState class specifically includes two attributes: a time attribute (time) and a state value (state) corresponding to the simulation model. To enable the ModelState class to represent various types of state variables, the type of state (for example, the Object class in Java) should be able to point to variables of any type.

[0096] The WeightedParticle class is used to represent particles with weights. A particle is essentially a possible state of the simulation model. Therefore, the WeightedParticle class includes two attributes: the state (modelState) of the simulation model and the corresponding weight (weight).

[0097] The Observation class is used to represent the observation data of the real system. In particle filtering, the observation data for the -th step of assimilation is the data collected during the time period from the -th step (excluding) to the -th step (including). Therefore, the Observation class includes two attributes: the time period (duration) during which the observation data is collected and the data pair (data). Among them, the data pair includes the data source and the data, and is used to represent the data collected from different data sources.

[0098] Furthermore, as Figure 2 shown, the steps for the particle filter concurrent sampling module to perform particle filter concurrent sampling based on a thread pool include:

[0099] Step S1, in the initialization phase, the main thread creates a thread pool and a task queue; among them, the task queue includes a calculation task queue and a thread request queue stored in sorted order.

[0100] Step S2: After initialization is completed, the main thread creates several computing tasks, and abstracts the computing tasks, task queue, and threads into a multi-server single-queue queuing system formalized by the Discrete Event System Specification (DEVS). This multi-server single-queue queuing system dynamically schedules and allocates idle threads to execute computing tasks based on the states of the computing task queue and thread request queue, so as to achieve concurrent execution of computing tasks. Among them, the computing task is the particle filter sampling task in microscopic simulation.

[0101] Among them, abstracting the computing tasks, task queue, and threads into a multi-server single-queue queuing system formalized by the Discrete Event System Specification includes:

[0102] Abstract the computing tasks, task queue, and threads into a multi-server single-queue queuing system. Each computing task acts as a customer in the system and receives computing services from each thread acting as a server. After formalizing the multi-server single-queue queuing system using the Discrete Event System Specification, the computing tasks, task queue, and threads in this multi-server single-queue queuing system are all described based on the atomic model of the Discrete Event System Specification, and they are coupled and interact with each other through input and output ports.

[0103] The structure of the multi-server single-queue queuing system formalized by the Discrete Event System Specification is as Figure 3 shown. The specific steps for this system to dynamically schedule and allocate idle threads to execute computing tasks based on the states of the computing task queue and thread request queue, so as to achieve concurrent execution of computing tasks, include:

[0104] The task queue receives the computing task processing requests of each thread through its own request port, and sorts them in the order of the requests being sent, forming a thread request queue. At the same time, after the task queue receives the computing tasks submitted by the main thread through its arrival port, it judges whether there are any idle threads in the thread request queue;

[0105] If there are, the computing task is sent to the input port of the idle thread through the output port of the task queue, and the idle thread is used to execute the computing task; otherwise, they are sorted in the order of the computing tasks being submitted, forming a computing task queue and waiting to be executed;

[0106] After the thread finishes executing the computing task, it interacts with the end port of the computing task through its own end port to notify that the computing task has been executed, and the computing task can continue to perform subsequent operations (such as obtaining the simulation model state and obtaining predicted observation data, etc.); at the same time, the thread transitions to the idle state and sends a computing task processing request to the task queue again through its own request port to query whether there is a computing task waiting to be executed in the computing task queue;

[0107] If there is, take out the computing task at the head of the computing task queue and execute it; otherwise, continue to remain in the idle state waiting for the main thread to submit a new computing task;

[0108] After all computing tasks are executed, all threads in the thread pool transition to the idle state, waiting to execute the computing tasks generated by particle filter sampling in the next round of microscopic simulation.

[0109] The above steps schedule and allocate idle threads to concurrently execute computing tasks according to the thread pool and the task queue, so as to realize the concurrent sampling of particle filter in microscopic simulation, ensure that each computing step of particle filter in microscopic simulation is executed in the correct logical order, and improve the execution efficiency of particle filter sampling and the running efficiency of microscopic simulation through the concurrent execution of computing tasks. And the threads in the thread pool will not be destroyed after executing the computing tasks, but transition to the idle state waiting to execute the next computing task. The thread pool can reduce the operating system resource overhead and computing volume brought by frequent creation and destruction of threads by reusing the already created threads, ensure the real-time requirements of dynamic data-driven simulation, and thus achieve better simulation performance.

[0110] Specifically, the execution logic of the task queue described based on the discrete event system specification atomic model is expressed as:

[0111] ;

[0112] Among them, represents the task queue, represents the input of the task queue; among them, represents the set of input ports of the task queue, including the arrival port and the request port ; The input of the arrival port represents the ID of the computing task submitted by the main thread, and the input of the request port represents the ID of the thread that requests to allocate a computing task to the task queue;

[0113] represents the output of the task queue; among them, The set of output ports representing the task queue, which contains only one output port ; Output port Output Represents the ID of the computing task that the thread is about to execute;

[0114] Represents the status of the task queue; among them, the computing task queue And the thread request queue Are both FIFO queues, storing respectively the IDs of the computing tasks waiting in line to be executed, and the IDs of the threads waiting in line to be assigned computing tasks;

[0115] Represents the internal state transition function of the task queue. The internal state transition function of the task queue describes how the state of the task queue changes under the control of only the time advancement function Without external input, and is specifically defined as:

[0116] ;

[0117] Among them, "-1" means removing the head element from the queue;

[0118] Represents the external state transition function of the task queue; among them, the set , The external state transition function of the task queue describes how the state of the task queue changes under the excitation of external input, and is specifically defined as:

[0119] ;

[0120] Among them, "+" means inserting at the end of the queue;

[0121] Represents the output function of the task queue, which defines what information should be output when the task queue undergoes an internal state transition, and is specifically defined as:

[0122] ;

[0123] Among them, In Is the ID of the computing task at the head of the computing task queue ; It should be noted that the thread in the thread pool whose thread ID is equal to the thread ID at the head of the thread request queue Will be responsible for executing the computing task with ID ;

[0124] The time advancement function representing the task queue, which defines the duration for which the task queue remains in the state without the influence of external inputs, is specifically defined as:

[0125] ;

[0126] The above equation indicates that when both the computation task queue and the thread request queue are not empty, the time advancement value is set to 0, thereby immediately triggering the internal state transition function of the task queue to allocate the computation task at the head of the computation task queue to the idle thread at the head of the thread request queue for execution; the above process is repeated continuously (constantly allocating computation tasks to idle threads) until one of the queues becomes empty (there are no idle threads or no queued computation tasks).

[0127] Specifically, the execution logic of the thread described based on the atomic model of the discrete event system specification is expressed as:

[0128] ;

[0129] Among them, represents the thread, represents the input of the thread; among them, represents the set of input ports of the thread, which only contains one input port ; The input of the input port represents the ID of the computation task allocated to this thread by the task queue;

[0130] represents the output of the thread; among them, represents the set of output ports of the thread, including the end port and the request port ; The output of the end port represents the ID of the computation task completed by the thread, and the output of the request port represents the ID of the thread;

[0131] represents the state of the thread; among them, in represents the ID of the computation task currently being executed by this thread, represents the remaining time required for this thread to complete this computation task; if , it indicates that the thread is currently in an idle state, and at this time, set ;

[0132] represents the internal state transition function of the thread, which is specifically defined as: ​​​

[0133] ;

[0134] Represents the external state transition function of the thread, and is specifically defined as:

[0135] ;

[0136] Among them, represents the time required for the thread to execute the computing task; it should be noted that only when the thread is in state, that is, in the idle state, it is possible to receive the ID of the computing task output by the task queue;

[0137] represents the output function of the thread; when the thread finishes executing the computing task, on the one hand, it notifies through the output port that the computing task has been executed; on the other hand, it also sends a request to allocate a new computing task to the task queue through the output port; therefore, the output function of the thread is specifically defined as:

[0138] ;

[0139] Among them, refers to the ID of the thread itself;

[0140] Represents the time advancement function of the thread, and is specifically defined as:

[0141] .

[0142] Furthermore, the above computing task is specifically defined as: a simulation running process during particle filter sampling in microscopic simulation. This simulation running process takes the particle state at the previous moment as the initial value, and after running the simulation model for a period of time, obtains the particle state at the next moment.

[0143] Moreover, the simulation running process is carried out under the constraints of a simulation experiment framework, which defines the entities participating in the modeling and simulation activities and the relationships between the entities, including simulation experiment (Experiment), simulation model (SimulationModel), simulator (Simulator), and run control conditions (RunControl); among them, the simulation experiment is carried out on the simulation model, and the execution of the simulation model requires a simulator; the simulation experiment needs to be carried out under given run control conditions, and the run control conditions include simulation start time (startTime), warm-up time (warmupTime), and run duration (runLength); a simulation experiment needs to be run multiple times under the same run control conditions, and each run is called a replication, and different random number seeds (seed) are required for each run.

[0144] Therefore, when performing particle filter sampling in microscopic simulation, the computational task is further defined as a sample run in a simulation experiment and abstracted into a SimulationRun class; among them, the SimulationRun class contains five attributes, namely the simulation model, simulator, initial state (initialState), warm-up time, and run duration required for the sample run, where the simulation start time is implicit in the initial state; the SimulationRun class also contains a constructor and a run function, where the constructor is used to complete the initialization of the simulation according to the simulation model, simulator, initial state, warm-up time, and run duration; the run function is used to drive the simulation run according to the simulation model type and the simulation platform running mechanism. For example, when using the event scheduling method to execute a discrete event model, it is necessary to loop to take out the first event in the simulator's future event table and execute the event handling function until the future event table is empty or the preset run duration is reached.

[0145] After the computational task is completed, it is also necessary to obtain the simulation model state and the predicted observation data (i.e., to implement the mapping from state to observation) to support the update of particle weights. Therefore, the simulation model needs to implement the DataAssimilationModelInterface (data assimilation model interface), which supports users to initialize the simulation model based on the given state (setInitialModelState), and obtain the state of the simulation model (getModelState), as well as the predicted observation data (getPredictedMeasurement).

[0146] Specifically, the above-mentioned concurrent sampling steps of particle filtering based on a thread pool can be implemented based on Java concurrent programming. The Java Development Kit (JDK) is a software development environment for developing and testing Java programs. Since its design, the JDK has supported concurrent programming, and since version 5.0, a new java.util.concurrent package has been added to the toolkit, which can greatly simplify the development of Java concurrent (multi-threaded) applications. Users can use the Executor interface and its implementation classes in the java.util.concurrent package for concurrent programming. The Executor provides an intermediate layer between the client and task execution: the client does not directly execute tasks but through an intermediate object. The Executor allows developers to manage the execution of asynchronous tasks without explicitly managing the thread lifecycle. Developers can create different types of thread pools (e.g., FixedThreadPool and CachedThreadPool) by calling the factory methods of the Executors class in the java.util.concurrent package; when calling the factory method, an ExecutorService object (a type of Executor with a lifecycle) will be created, and users submit, execute, and manage tasks through this object.

[0147] Users can define tasks by implementing the Runnable or Callable interfaces in the java.util.concurrent package: Runnable tasks do not return a value after execution, while Callable tasks can return a value after execution. The Callable interface is a generic interface, and its type parameter represents the return value type after calling the call method of the Callable interface. Also, Callable tasks must be submitted through the submit method of the ExecutorService interface. After calling the submit method, a Future object will be generated, which is used to represent the result of asynchronous calculation. Future is also a generic interface, which is parameterized according to the result type returned by Callable. The Future interface provides corresponding methods to check whether the calculation task is completed (isDone) and obtain the calculation result (get). When calling the get method of the Future object, this method will block until the task is completed and produces a result.

[0148] Further, in order to organize various calculations in particle filter data assimilation according to the correct timing relationship, the present application designs a particle filter data assimilation operation control logic in the system. This module includes three attributes, namely the weighted particle attribute (weightedParticles), which is used to represent a group of weighted particles; the executor service attribute (executorService), which is used to provide a series of interfaces for accessing the thread pool service; the running duration attribute (deltaT), which is used to represent the update period of the observed data, that is, the data assimilation period; the particle filter data assimilation operation control logic also includes the following functions, namely:

[0149] The initialization function (initialize), which is used to generate a group of initial particles and assign weights to obtain the initial weighted particles and create a thread pool;

[0150] The create model instance function (createModelInstance), which is an abstract function used to support users in instantiating the simulation model according to the specific application scenario; it should be noted that the simulation model returned by createModelInstance needs to implement the DataAssimilationModelInterface interface.

[0151] The weight update function (updateWeight), which is an abstract function used to support users in implementing weight calculation according to the error model of the observed data of the real system in the specific application scenario;

[0152] The create calculation task function (createTask), which is an abstract function used to support users in generating calculation tasks based on the simulation model, initial state, warm-up time, and running duration;

[0153] The sampling function (sample), which is used to implement the particle filter concurrent sampling step based on the thread pool; during sampling, first call the create model instance function to instantiate the simulation model; then, based on the simulation model, initial state, and running duration, call the create calculation task function to generate calculation tasks and submit the calculation tasks to the thread pool for waiting to be executed; when the calculation tasks are completed by the thread execution, obtain the simulation model state and predicted observed data, and further call the weight update function to update the weights of the particles;

[0154] The weight normalization function (normalizeWeights), which is used to be called after the weights of all particles are updated to ensure that the sum of the weights of all particles is 1;

[0155] The resampling function (resample), which is an abstract function used to support users in adopting a specific resampling method according to the specific application scenario;

[0156] The state estimation function (conductEstimation) is an abstract function used to support users in calculating the state estimation value based on particles and weights according to specific application scenarios after resampling. For example, when this application is specifically applied to a traffic simulation platform, the average value of all particles is used as the estimation of traffic flow density, and the particle with the largest weight is taken as the estimation of vehicle trajectory.

[0157] The particle perturbation function (perturbModelState) is an abstract function used to support users in using specific state perturbation methods according to the characteristics of specific application scenarios to increase the diversity of particles.

[0158] The particle filter execution function (executeParticleFiltering) is used to call this function to execute the complete particle filter calculation process when new observation data arrives.

[0159] In summary, the above microscopic simulation particle filter data assimilation system based on a thread pool can flexibly represent the basic elements of data assimilation with different characteristics in particle filtering during microscopic simulation through the internal data assimilation basic element representation module, thereby being able to effectively represent the simulation model state and observation data in microscopic simulation. According to the internal particle filter concurrent sampling based on the thread pool, the execution efficiency of particle filter sampling in microscopic simulation is improved, and thus efficient microscopic simulation can be achieved. Also, according to the internal particle filter data assimilation operation control logic, the scheduling operation of particle filter in microscopic simulation is ensured to be carried out in the correct time sequence and dependency relationship, improving the state estimation and prediction ability of microscopic simulation, and making the predicted state of the simulation model after data assimilation closer to the real system state.

[0160] The above microscopic simulation particle filter data assimilation system based on a thread pool can be specifically applied to various microscopic simulation platforms such as the MASON multi-agent simulation platform and the OpenTrafficSim traffic simulation platform.

[0161] MASON is a Java-based and domain-independent multi-agent simulation platform, and its design goal is to be able to run large-scale agent simulation applications relatively efficiently on a single machine. The model of MASON is encapsulated in a special object called sim.engine.SimState, which contains a discrete event scheduler (schedule), and users can schedule various agents to be called at specified future times on the schedule. The schedule is essentially the way MASON models represent time. In addition, the MASON model also contains multiple "fields" for representing space, such as networks, continuous spaces, and grids.

[0162] When applying the system provided by this application to the MASON multi-agent simulation platform, a MASON simulation model (MultiAgentsModel) is developed according to the application scenario. It inherits from SimState (simulation state); since data assimilation needs to be supported, it needs to implement the DataAssimilationModelInterface interface; MasonParticleFilteringControlLogic (MASON particle filtering control logic) inherits from ParticleFilteringControlLogic (particle filtering control logic) and implements all the abstract functions of ParticleFilteringControlLogic; MasonSimulationRun (Mason simulation run class) inherits from SimulationRun and implements the call function. According to the operation scheduling mechanism of the MASON simulation platform, MasonSimulationRun implements the call function of its parent class SimulationRun. In the call function, first, the simulation model is initialized according to the initial state, and then the initial events of the simulation model are scheduled; next, in the while loop, the step function of each agent in the model is continuously executed through schedule until the simulation time reaches the preset simulation running duration; finally, the model state and the predicted observation data are obtained and returned.

[0163] OpenTrafficSim (OTS) is an open-source traffic simulation platform based on Java, aiming to provide efficient and flexible tool support for traffic research, urban planning, and the development of intelligent transportation systems. OpenTrafficSim adopts discrete event simulation technology and can accurately simulate various traffic scenarios from microscopic vehicle behavior to macroscopic road network operation. As an open-source simulation platform, OpenTrafficSim encourages global researchers and developers to participate in collaboration. Users can freely access the source code and conduct secondary development to expand functions or adapt to specific research needs.

[0164] When the system provided in this application is applied to the OpenTrafficSim traffic simulation platform, an OTS simulation model (TrafficSimulationModel) is developed according to the application scenario, which inherits from OTSModelInterface (OTS model interface); similarly, it needs to implement the DataAssimilationModelInterface interface to support data assimilation; OTSParticleFilteringControlLogic (OTS particle filtering control logic) inherits from ParticleFilteringControlLogic and implements all abstract functions of ParticleFilteringControlLogic; OTSSimulationRun (OTS simulation run) inherits from SimulationRun and implements the call function. According to the operation scheduling mechanism of the OpenTrafficSim traffic simulation platform, OTSSimulationRun implements the call function of its parent class SimulationRun. In the call function, first instantiate the simulator, then instantiate the simulation run sample according to the simulation start time, warm-up time, running time, and simulation model, then initialize the simulator to realize the binding of the simulation model and the simulator; initialize the model according to the initial state, then continuously take out the first event in the future event table in the while loop and execute it until the simulation time reaches the preset simulation running time; finally obtain the model state and predicted observation data and return. It can be seen that the implementation of the call function is completely different under different simulation platforms, so it needs to be designed according to the operation scheduling mechanism of the simulation platform.

[0165] In order to verify the performance of the thread pool-based micro-simulation particle filter data assimilation system provided in this application, a simulation experiment was further designed. In the simulation experiment, a simulation model that can flexibly set the model scale (i.e., the number of components in the model) was designed. Based on this simulation model, the thread pool-based and fallback-based particle filter data assimilation methods were used respectively to quantitatively compare the performance of the two methods under different model scales and different numbers of particles.

[0166] The simulation model used in this experiment like Figure 4 As shown, the simulation model have components, namely Each component is a discrete event model. Only one type of event is dispatched, and the corresponding event handling function is ; There is no interaction between components. By changing the number of components The scale of the simulation model can be flexibly set. At initialization, according to the set number of components, firstly, instantiate components, and then sequentially call the event handling functions of each component ; The processing flow of the event handling function is divided into two steps: Firstly, sleep for milliseconds, and then schedule an event after a unit of time, and its event handling function is still . The "sleep" in the processing flow is used to simulate the physical time consumption of event handling, and the sleep time follows a uniform distribution , where and represent the minimum and maximum values of the physical time required to process an event respectively. The event handling function essentially realizes the function of the component periodically (every unit of time) calling the function. This processing flow is the most basic and common processing flow in simulation. For example, in microscopic traffic simulation, a vehicle processes a maneuver event every 0.5 seconds, and in the maneuver event handling function, it is necessary to update the vehicle's position, speed, acceleration and other attributes according to the surrounding environment information perceived by the vehicle.

[0167] Assume that data assimilation is carried out for steps in the experiment (as shown in Figure 5 ); When the th observation data arrives ( ), data assimilation needs to complete 3 basic calculation steps: sampling, weight normalization, and resampling. The wall time consumed by these steps is recorded as (as shown in Figure 5 ). Then, in the whole data assimilation process, the average time consumption of each step of data assimilation is:

[0168] .

[0169] In this experiment, the average time consumption is used as a performance metric; In order to distinguish the performance metrics under two implementation methods: based on thread pool and based on fallback, add subscripts to , that is and They respectively represent the average time consumption of two implementation methods of particle filtering based on thread pool and based on fallback. It should be noted that under the two implementation methods, only the implementation of the sampling step is different. The implementation method based on the thread pool is concurrent sampling, while the implementation method based on fallback is serial sampling. In addition, in this experiment, both weight calculation and resampling are empty functions without function bodies.

[0170] The operating environment of this experiment is as follows: The computer CPU model is 13th Gen Intel Core i5-13600KF (14 cores and 20 threads), and the running memory is 32GB; The operating system and version number are Ubuntu 22.04.4 LTS, and the JDK (Java Development Kit) version number is 18.0.2. The specific experimental design includes: In order to explore the performance of two implementation methods of particle filtering based on thread pool and based on fallback under different model scales and particle numbers, the model scale is set to 20, 40, 60, 80, 100, and the particle number is set to 100, 200, 300, 400, 500, with a total of 25 groups of experiments; In order to reduce the influence of random factors, each group of experiments is run 5 times. The total number of steps of data assimilation is set to , and the arrival interval of observation data ; The event scheduling period of the components in the simulation model is ; The minimum and maximum values of the event processing time consumption are set to .

[0171] For any combination of values of the model scale ( ) and the particle number ( ), the experiments are respectively run based on two implementation methods of particle filtering based on thread pool and based on fallback. Each group of experiments is independently run 5 times. According to the results of the 5 experiments, the mean and standard deviation are calculated. The performance experimental results are shown in Table 1. Given and , the average time consumption of single-step data assimilation based on the particle filtering implementation method based on thread pool can be theoretically estimated as:

[0172] ;

[0173] where represents the number of concurrent threads in the thread pool; In this experiment, is taken as the number of available CPU threads minus 1, that is, 19. Similarly, the average time consumption of single-step data assimilation based on the particle filtering implementation method based on fallback can be estimated as:

[0174] .

[0175] Randomly select a group , the calculation , is close to the experimental results in Table 1 ( ), indicating that the experimental results in Table 1 are basically reasonable and are basically consistent with the theoretical estimation results.

[0176] Table 1 Performance experimental results of two particle filter implementation methods based on thread pool and fallback (unit: seconds)

[0177]

[0178] According to the experimental results in Table 1, calculate the ratio of the average time-consuming of single-step data assimilation for the two particle filter implementation methods, that is , which represents the performance improvement multiple of the implementation method based on the thread pool compared to the implementation method based on fallback. The results are plotted as a heat map, as Figure 6 shown. It can be seen that under the current experimental settings, the performance improvement multiple of the implementation method based on the thread pool compared to the implementation method based on fallback is between 17.37 and 19.64, with an average improvement of 18.95 times, and the improvement multiple is approximately equal to the size of the thread pool , which is consistent with the theoretical estimated value .

[0179] Next, further explore the relationship between the performance of the particle filter implementation method based on the thread pool and the number of particles. Calculate the relative value of the average time-consuming of single-step data assimilation ( and the number of particles ) compared to the average time-consuming of single-step data assimilation with the same model scale and when , that is , and plot the results as a curve, as Figure 7 shown. From the results, it can be seen that and the number of particles are linearly related, but have no relationship with the model scale . In other words, when the model scale is fixed, the average time-consuming of single-step data assimilation increases linearly with the increase of the number of particles . According to Figure 7 , the following relational expression can be obtained by fitting:

[0180] ;

[0181] When the number of particles increases by 1 time (i.e., ) on the basis of ), the average time-consuming of single-step data assimilation is of times. That is to say, when the number of particles increases exponentially based on 100, the average time-consuming of single-step data assimilation also shows a linear growth relationship with respect to the average time-consuming when the number of particles is 100. However, the rate of increase in the average time-consuming is less than the rate of increase in the number of particles.

[0182] In summary, the results of the simulation experiments show that the performance of the microscopic simulation particle filter data assimilation system based on the thread pool constructed in this application is significantly better than the existing data assimilation implementation scheme based on rollback. And when the scale of the simulation model is fixed, the average time-consuming of single-step data assimilation increases linearly with the increase in the number of particles. However, the rate of increase in the average time-consuming is less than the rate of increase in the number of particles.

[0183] In one embodiment, this application also provides a simulation method, which includes:

[0184] Obtain the observation data of the real system, model the real system as a simulation model, and deduce the evolution of the state of the real system over time through the simulation model;

[0185] Utilize the above-mentioned microscopic simulation particle filter data assimilation system based on the thread pool to continuously assimilate the observation data of the real system into the simulation model, so that the simulation model dynamically adjusts its own state to approximate the state of the real system.

[0186] The technical features of the above embodiments can be combined arbitrarily. For the sake of concise description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope recorded in this specification.

[0187] The above embodiments only represent several implementation manners of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of this application. It should be noted that for those of ordinary skill in the art, without departing from the concept of this application, several deformations and improvements can still be made, and these all belong to the protection scope of this application. Therefore, the protection scope of this application should be subject to the appended claims.

Claims

1. A microscopic simulation particle filter data assimilation system based on a thread pool, characterized in that The system is applied to a microscopic simulation platform, and the system includes: A data assimilation basic element representation module, which is used to represent the basic elements of microscopic simulation particle filter data assimilation; A particle filter concurrent sampling module, which is used to perform particle filter concurrent sampling based on a thread pool; in the initialization stage, the main thread creates a thread pool and a task queue; wherein, the task queue includes a calculation task queue and a thread request queue stored in sorted order; after initialization is completed, the main thread creates several calculation tasks, and abstracts the calculation tasks, the task queue, and the threads into a multi-server single-queue queuing system formalized by the discrete event system specification. This multi-server single-queue queuing system dynamically schedules and allocates idle threads to execute calculation tasks based on the states of the calculation task queue and the thread request queue, realizing the concurrent execution of calculation tasks; wherein, the calculation task is a particle filter sampling task in microscopic simulation; A particle filter data assimilation operation control logic, which is used to schedule and run the data assimilation basic element representation module and the particle filter concurrent sampling module according to the correct timing and dependency relationship, and in microscopic simulation, continuously assimilate the observed data of the real system into the simulation model by executing the calculation steps of the particle filter, so that the simulation model dynamically adjusts its own state to approximate the state of the real system; The particle filter data assimilation operation control logic further includes the following functions: An initialization function, which is used to generate a set of initial particles and assign weights to obtain initial weighted particles and create a thread pool; A create model instance function, which is used to support the user to instantiate the simulation model according to the specific application scenario; A weight update function, which is used to support the user to calculate weights according to the error model of the observed data of the real system in the specific application scenario; A create calculation task function, which is used to support the user to generate calculation tasks based on the simulation model, the initial state, the warm-up time, and the running duration; A sampling function, which is used to implement the particle filter concurrent sampling step based on the thread pool; during sampling, first call the create model instance function to instantiate the simulation model; then, based on the simulation model, the initial state, and the running duration, call the create calculation task function to generate calculation tasks, and submit the calculation tasks to the thread pool for waiting to be executed; when the calculation tasks are completed by the threads, obtain the simulation model state and the predicted observed data, and further call the weight update function to update the weights of the particles; A weight normalization function, which is used to be called after the weights of all particles are updated to ensure that the sum of the weights of all particles is 1; A resampling function, which is used to support the user to adopt a specific resampling method according to the specific application scenario; A state estimation function, which is used to support the user to calculate the state estimation value based on the particles and weights according to the specific application scenario after resampling is completed; A particle perturbation function, which is used to support the user to use a specific state perturbation method according to the characteristics of the specific application scenario to increase the diversity of particles; A particle filter execution function, which is used to call this function to execute the complete particle filter calculation process when new observed data arrives.

2. The micro-simulation particle filter data assimilation system based on a thread pool according to claim 1, wherein The data assimilation basic element representation module includes a model state class, a weighted particle class, and an observed data class; Among them, the model status class is used to represent the status of the simulation model, and includes two attributes: a time attribute and a status value corresponding to the simulation model; The weighted particle class is used to represent a particle with a weight. A particle is essentially a possible status of the simulation model. Therefore, the weighted particle class includes two attributes: the status of the simulation model and the corresponding weight; The observation data class is used to represent the observation data of the real system, and includes two attributes: the time period when the observation data is collected and the data pair. Among them, the data pair includes a data source and data, and is used to represent the data collected from different data sources.

3. The microscopic simulation particle filter data assimilation system based on a thread pool according to claim 1, characterized in that, The computing tasks, task queue, and threads are abstracted into a multi-server single-queue queuing system formalized using the discrete event system specification, including: The computing tasks, task queue, and threads are abstracted into a multi-server single-queue queuing system. Each computing task acts as a customer in the system and receives computing services from each thread acting as a server; After formalizing the multi-server single-queue queuing system using the discrete event system specification, the computing tasks, task queue, and threads in the multi-server single-queue queuing system are all described based on the atomic model of the discrete event system specification, and are coupled and interact with each other through input and output ports.

4. The micro-simulation particle filter data assimilation system based on a thread pool according to claim 3, characterized in that, This multi-server single-queue queuing system dynamically schedules and allocates idle threads to execute computing tasks based on the status of the computing task queue and the thread request queue, realizing the concurrent execution of computing tasks, including: The task queue receives the computing task processing requests from each thread through its own request port, and sorts them in the order in which the requests are issued to form a thread request queue; at the same time, after the task queue receives the computing tasks submitted by the main thread through its arrival port, it judges whether there are any threads in the thread request queue that are in an idle state; If there are, the computing task is sent to the input port of the idle thread through the output port of the task queue, and the idle thread is used to execute the computing task; otherwise, they are sorted in the order in which the computing tasks are submitted to form a computing task queue and wait to be executed; When the thread finishes executing the computing task, it interacts with the end port of the computing task through its own end port to notify that the computing task has been executed, and the computing task can continue to perform subsequent operations; at the same time, the thread becomes idle, and sends a computing task processing request to the task queue again through its own request port to query whether there are any computing tasks in the computing task queue waiting to be executed; If there are, take out the computing task at the head of the computing task queue and execute it; otherwise, continue to remain idle and wait for the main thread to submit new computing tasks; When all computing tasks are executed, all threads in the thread pool become idle and wait to execute the computing tasks generated by particle filter sampling in the next round of microscopic simulation.

5. The micro-simulation particle filter data assimilation system based on a thread pool according to claim 4, wherein The execution logic of the task queue described based on the atomic model of the discrete event system specification is expressed as: ； Among them, represents a task queue, indicating the input of the task queue; among them, represents the set of input ports of the task queue, including the arrival port and the request port ; the input of the arrival port represents the ID of the computing task submitted by the main thread, and the input of the request port represents the ID of the thread that requests the allocation of a computing task from the task queue; the input of represents the ID of the thread that requests the allocation of a computing task from the task queue; Represents the output of the task queue; wherein, Represents the set of output ports of the task queue, which contains only one output port ; Output port Output of Represents the ID of the computational task to be executed by the thread; Indicates the status of the task queue; among them, the computing task queue and the thread request queue are both FIFO queues, storing respectively the IDs of computing tasks that are queuing up waiting to be executed, and the IDs of threads that are queuing up waiting to be assigned computing tasks; Represents the internal state transition function of the task queue. The internal state transition function of the task queue describes how the state of the task queue changes under the control of only the time advancement function without external input, and is specifically defined as: ； Among them, "-1" means removing the head element from the queue; Represents the external state transition function of the task queue; among them, the set , the external state transition function of the task queue describes how the state of the task queue changes under the excitation of external inputs, and is specifically defined as: ； Among them, "+" means inserting at the end of the queue; The output function representing the task queue, which defines what information should be output when an internal state transition occurs in the task queue. The specific definition is as follows: ； Among them, in is the computing task queue The ID of the computing task at the head of the queue; it should be noted that the thread ID in the thread pool is equal to the thread ID at the head of the thread request queue The thread whose ID is equal to the thread ID at the head of the queue will be responsible for executing the computing task with ID ; The time advancement function representing the task queue, which defines the duration for which the task queue remains in the state without being affected by external inputs, is specifically defined as: ； The above formula indicates that when both the computing task queue and the thread request queue are not empty, the time advancement value is set to 0, thereby immediately triggering the internal state transition function of the task queue, and allocating the computing task at the head of the computing task queue to the idle thread at the head of the thread request queue for execution; the above process is repeated continuously until one of the queues becomes empty.

6. The micro-simulation particle filter data assimilation system based on a thread pool according to claim 5, characterized in that, The execution logic of the thread described based on the atomic model description of the discrete event system specification is expressed as: ； Among them, represents a thread, represents the input of the thread; among them, represents the set of input ports of the thread, which only contains one input port ; the input port input represents the ID of the computing task assigned to this thread by the task queue; Represents the output of the thread; among which, Represents the set of output ports of the thread, including the end port and the request port ; The output of the end port Represents the ID of the computational task completed by the thread execution, and the output of the request port Represents the ID of the thread; The output Represents the ID of the thread; Indicates the state of the thread; among them, in represents the ID of the computing task that the thread is currently executing, indicates the time remaining for the thread to complete the computing task; if , it means that the thread is currently in an idle state, and at this time set ; Represents the internal state transition function of a thread, specifically defined as: ； Represents the external state transition function of a thread, which is specifically defined as: ； Among them, represents the time required for the thread to execute the computing task; it should be noted that only when the thread is in the state, that is, in the idle state, can it possibly receive the ID of the computing task output by the task queue; Represents the output function of the thread; when the thread finishes the computing task, on the one hand, it notifies that the computing task has been executed through the output port; on the other hand, it also sends a request to allocate a new computing task to the task queue through the output port; therefore, the output function of the thread is specifically defined as: ； Among them, refers to the ID of the thread itself; A time advancement function representing a thread, specifically defined as: 。 7. The micro-simulation particle filter data assimilation system based on a thread pool according to any one of claims 3 to 6, characterized in that The computing task is specifically defined as: a simulation running process during particle filter sampling in microscopic simulation. This simulation running process takes the particle state at the previous moment as the initial value, and after running the simulation model for a period of time, the particle state at the next moment is obtained.

8. The micro-simulation particle filter data assimilation system based on a thread pool according to claim 1, characterized in that The particle filter data assimilation operation control logic includes three attributes, namely, the weighted particle attribute, which is used to represent a set of weighted particles; the executor service attribute, which is used to provide a series of interfaces for accessing the thread pool service; and the running duration attribute, which is used to represent the update period of the observed data, that is, the data assimilation period.

9. A simulation method, characterized in that, The method includes: Obtaining the observed data of the real system, modeling the real system as a simulation model, and deducing the evolution of the real system state over time through the simulation model; Using the microscopic simulation particle filter data assimilation system based on the thread pool according to any one of claims 1 to 8, continuously assimilating the observed data of the real system into the simulation model, so that the simulation model dynamically adjusts its own state to approximate the state of the real system.

Images