MétaCan
Menu
Retour à la cohorte
Enregistrement W6949083032 · doi:10.5281/zenodo.10260963

Evaluation Files: Multilayer Graph Partitioning for Enabling a Decentralized Path Planning for Large and Heterogeneous AGV Fleets

2023· article· en· W6949083032 sur OpenAlex

Pourquoi ce travail est dans la base

Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.

aboutLe titre ou le résumé porte un signal canadien du lexique géographique.
no affAucune affiliation canadienne : ce travail est invisible pour une base fondée sur la seule affiliation.
Aucune affiliation canadienne. Une base fondée sur la seule affiliation (le devis habituel) n'aurait jamais vu ce travail. C'est l'un des travaux qui justifient l'inversion de la base.

Notice bibliographique

RevueZenodo (CERN European Organization for Nuclear Research) · 2023
Typearticle
Langueen
DomaineEngineering
ThématiqueVehicle Routing Optimization Methods
Établissements canadiensnon disponible
Organismes subventionnairesnon disponible
Mots-clésNetwork topologyMetric (unit)Intersection (aeronautics)Bounding overwatchGraphPath (computing)Topology (electrical circuits)

Résumé

récupéré en direct d'OpenAlex

Project Description This repository contains the evaluation files from “Multilayer Graph Partitioning for Enabling a Decentralized Path Planning for Large and Heterogeneous AGV Fleets”. First, an overview of the folder structure is given. Followed by an Overview of the used parameter values from MAGPart. Afterward, additional background information for each topology is presented. Folder Structure Each evaluated topology is contained in a separate folder (e.g. /Topo-1, /Topo-1-2-3, ...). The topologies Topo-1, Topo-2, Topo-3 and Topo-4 are single-layer topologies, whereby the remaining topologies are multilayer topologies and are constructed by combinations of the single-layer topologies. For example, the topology Topo-1-2-3-4 results from combining the topologies Topo-1, Topo-2, Topo-3 and Topo-4. Each folder of one topology contains (1) the boxplots for each evaluation metric, (2) the results from applying different Graph Partitioning (GP) algorithms and (3) an overview of the frequencies and workloads of edges. The “deviation” boxplots correspond to DEV metric and the “routes_frequencies” boxplots correspond to the RF metric mentioned in our paper. Additionally, the boxplots from an overlap metric O ∈ [0,1] are listed for each topology. The overlap metric measures the intersection area between overlapping Bounding Boxes (BBs) divided by the intersection area between overlapping BBs from different domains. Thus, the metric is zero if no BBs from different domains overlap and one if all overlapping BBs correspond to different domains. A lower overlap value is desirable, to reduce the communication between domains. Since the metrics RF and DEV strive to maximize their value, we invert the value from the overlap metric to achieve a uniform representation. Note that the boxplots result from the averaged values from ten executions of our pipeline. For each applied GP algorithm (Girvan-Newman, Infomap, MAGPart, Metis, Modularity-Maximization and Spectral-Clustering) in our pipeline, the results are contained in corresponding folders. Each folder contains a PDF file, where the topology and the resulting domains are visualized. The domains are visualized in different colors. Additionally, the value of the quality function and the number of domains k is given in the filename. The number of domains is only given if the GP algorithm (i.e. Girvan-Newman, Metis, Spectral-Clustering) requires the number of domains as parameter. To achieve a comparable result, the values of the parameters max_v and max_d from MAGPart are set to infinity, since the sizes of the domains and the number of domains cannot be set for all GP algorithms. The values and description of all utilized parameters by MAGPart are given in the table below. MAGPart Parameters This table highlights all parameters used by MAGPart, while providing the used value, the value range and a description. Parameter Used Value Value Range Description Matching Algorithm Maximum Weight Matching Any matching algorithm The matching algorithm which is used in the coarsening phase to contract vertices. γ 0,6 R The resolution for computing the modularity in the quality function. λ 1,0 [0,1] The workload scaling factor to scale the workload in the pre-processing phase. θ 0,35 [0,1/2] The ratio of removed vertices before and after an iteration in the coarsening phase. max_d INF N The maximal number of allowed domains to be created. max_v INF N The maximal number of nodes to be added to a domain. Background of the topologies Topo-1: This topology and the routes of AGVs were created manually to represent the possible layout from a warehouse with three spatially separated areas. Topo-2: This topology models the area of a building used for testing purposes with AGVs. The routes of the AGVs were distributed manually to result in three Hotspots, which are not spatially separated. Topo-3: This topology models another possible layout from a warehouse. At the top left goods are received and transported between production, Storage and Shipping. Outgoing goods are transported to the bottom left. The routes of AGVs were created manually, such that AGVs mainly traverse in the upper or in the lower half of the topology. Few AGVs traverse between the top and lower half. Topo-4: This topology was modeled based on the layout from a warehouse. The topology's center contains a storage area, whereas the outer sections are used for loading ingoing and outgoing goods. Routes of the AGVs were sampled randomly with a bias to mainly pass through the top or the lower half of the topology. Topology Topo-1 Topo-2 Topo-3 Topo-4 Topo-2-3 Topo-2-4 Topo-1-2-3 Topo-1-2-3-4 Vertices 304 213 475 1845 688 2058 992 2837 Edges 515 431 1040 3976 1921 5555 2278 7882

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.

Prédiction distillée sur la base complète

Imitation des enseignants

Ni prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.

score de la tête « metaresearch » (Codex)0,003
score de la tête « metaresearch » (Gemma)0,002
Version: codex-gemma-dda1882f352aStatut de validation: machine_predicted_unvalidated
Catégories candidatesÉtudes des sciences et des technologies
Catégories consensuellesaucune
DomaineSignal candidat: aucune · Signal consensuel: aucune
Devis d'étudeSignal candidat: Simulation ou modélisation · Signal consensuel: Simulation ou modélisation
GenreSignal candidat: Empirique · Signal consensuel: aucune
Score de désaccord entre enseignants0,822
Score d'incertitude au seuil1,000

Scores Codex et Gemma par catégorie

CatégorieCodexGemma
Métarecherche0,0030,002
Méta-épidémiologie (sens strict)0,0000,000
Méta-épidémiologie (sens large)0,0000,000
Bibliométrie0,0000,001
Études des sciences et des technologies0,0020,000
Communication savante0,0000,000
Science ouverte0,0000,000
Intégrité de la recherche0,0000,000
Charge utile insuffisante (le modèle a refusé de juger)0,0010,000

Scores machine (provisoires)

Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.

Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.

Tête enseignante Opus0,072
Tête enseignante GPT0,313
Écart entre enseignants0,241 · la distance entre les deux têtes enseignantes sur ce seul travail
Statut de validationscore_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle