Brevet FR3093366A1 — publié le 20200904

Description Titre de l'invention : Procédé et système d'utilisation de ressources de calcul d'un système de calcul multiprocesseurs [0001] La présente invention concerne un procédé et un système (l'utilisation de ressources de calcul d'un système de calcul comportant une pluralité de microprocesseurs interconnectés et adaptés à fonctionner en parallèle, pour effectuer des tâches logicielles. [0002] L'invention se situe dans le domaine de l'optimisation des ressources de calcul dans les fermes (« clusters » en anglais) de microprocesseurs, et trouve une application particulière dans l'exploitation de telles ressources de calcul pour résoudre des problèmes physiques complexes, par exemple pour simuler des phénomènes physiques, en utilisant des calculs itératifs mettant en oeuvre la résolution d'équations mathématiques modélisant des phénomènes physiques. [0003] En particulier, l'invention s'applique dans le domaine de la simulation par or- dinateur, notamment dans le cadre de procédés de simulation qui consomment beaucoup de ressources, ou de la résolution calculatoire de problèmes de la dynamique des fluides. [0004] L'utilisation de fermes de microprocesseurs interconnectés pour effectuer des calculs de simulation de problèmes physiques complexes est connue, de telles fermes de microprocesseurs permettant d'obtenir une augmentation de la capacité de calcul. Pour exploiter mieux de telles fermes de microprocesseurs, il existe des logiciels de gestion des queues de calcul pour lisser la charge des microprocesseurs. Ces logiciels sont génériques, et ne prennent pas en compte d'éventuelles spécificités des tâches logicielles spécifiques à effectuer dans un domaine particulier ou de gestion optimale des priorités. On entend ici par gestion optimale des priorités, le fait que chaque tâche logicielle en tant que telle et dans son contexte ait un coût économique le plus bas possible pour l'utilisateur. Dans l'état de l'art les fermes de calcul sont dimensionnées pour absorber les pics de charge, Il en résulte en pratique, une puissance calculatoire de la ferme de microprocesseurs représentant 120 à 150 % de la puissance calculatoire nécessaire hors pics. Par ailleurs, la gestion des pics de charge nécessite d'avoir à disposition des licences logicielles supplémentaires sous-exploitée qui ne sont utilisées que lors des pics de charge, [0005] Il existe donc un besoin d'optimiser l'utilisation des ressources d'un système de calcul comportant une ferme de microprocesseurs interconnectés. [0006] A cet effet, l'invention propose un procédé d'utilisation de ressources de calcul d'un système de calcul comportant une pluralité de microprocesseurs interconnectés et adaptés à fonctionner en parallèle, pour effectuer des tâches logicielles. Ce procédé 2 met en oeuvre : [0007] - un processus de calcul d'un plan d'expérience comportant une pluralité de tâches logicielles à effectuer pour résoudre un problème physique prédéterminé, défini par au moins un paramètre d'entrée et au moins un paramètre de sortie, le plan d'expérience étant calculé en fonction d'un budget calculatoire initial prédéterminé, lesdites tâches logicielles du plan d'expérience ayant un premier niveau de priorité, [0008] - un processus de planification de l'exécution des tâches logicielles par le système de calcul, configure pour : [0009] - vérifier la présence d'au moins une tâche logicielle de deuxième niveau de priorité supérieur au premier niveau de priorité en attente d'exécution, [0010] - en cas de présence d'au moins une tâche logicielle de deuxième niveau de priorité en attente d'exécution, obtention de ressources de calcul libérées pour exécuter ladite au moins une tâche logicielle de deuxième niveau de priorité ; [0011] - en cas d'absence d'au moins une tâche logicielle de deuxième niveau de priorité en attente d'exécution, répartition d'au moins une partie des tâches logicielles de premier niveau de priorité sur les ressources de calcul disponibles. [0012] Avantageusement, grâce à la gestion des premier et deuxième niveaux de priorité des tâches logicielles, le procédé permet de réaliser une occupation optimisée des ressources de calcul disponibles. [0013] Le procédé d'utilisation de ressources de calcul selon l'invention peut présenter une ou plusieurs des caractéristiques ci-dessous, prises indépendamment ou selon toutes les combinaisons acceptables : [0014] L'obtention de ressources de calcul libérées comporte une analyse de ressources cal- culatoires disponibles, et en cas d'absence de ressource calculatoire disponible, une analyse des tâches logicielles de premier niveau de priorité en cours d'exécution, un arrêt d'exécution d'au moins une partie desdites tâches logicielles de premier niveau et une sauvegarde d'un contexte d'exécution associé. [0015] L'obtention de ressources de calcul libérées comporte en outre une vérification de disponibilité de licence disponible pour effectuer une tâche logicielle de deuxième priorité. [0016] Le procédé comporte en outre, en cas d'absence d'au moins une tâche logicielle de deuxième niveau de priorité en attente d'exécution, une reprise d'exécution de tâches logicielles de premier niveau de priorité mises en arrêt d'exécution. [0017] La répartition au moins une partie des tâches logicielles de premier niveau de priorité sur les ressources de calcul disponibles comporte une analyse de ressources calculatoires disponibles, comportant une analyse de queues de calcul disponibles, et une répartition des tâches logicielles de premier niveau de priorité sur des queues de calcul sélectionnées. 3 [0018] Le processus de calcul d'un plan d'expérience met en oeuvre un algorithme d'apprentissage supervisé d'un méta-modèle statistique. [0019] Le méta-modèle statistique est un modèle de régression par processus gaussicn, et le processus de calcul d'un plan d'expérience met en oeuvre une maximisation d'entropie d'un noyau de covariance dudit processus gaussicn. [0020] Le calcul d'un plan d'expérience comporte une détermination d'un espace expé- rimental à partir des paramètres d'entrée du problème à résoudre, un maillage dudit espace expérimental en points de calcul, et une détermination d'un ensemble de points de calcul en fonction d'un budget calculatoire associé. [0021] Le calcul d'un plan d'expérience est itéré en fonction de résultats d'exécution obtenus suite à une exécution d'un plan d'expérience précédent, et dans lequel à chaque itération, un budget calculatoire courant est calculé. [0022] Le budget calculatoire courant est égal, à chaque itération, à la moitié d'un budget calculatoire restant calculé en fonction du budget calculatoire initial et d'un budget calculatoire consommé lors d'itérations précédentes. [0023] L'itération de calcul d'un plan d'expérience pour résoudre un problème physique prédéterminé est arrêtée lorsqu'un critère d'arrêt est vérifié, en particulier lorsque le budget calculatoire restant est consommé. [0024] Selon un autre aspect l'invention concerne d'utilisation des ressources d'un système de calcul comportant une pluralité de microprocesseurs interconnectés et adaptés à fonctionner en parallèle, pour effectuer des tâches logicielles. Ce système comporte : [0025] - un module de calcul d'un plan d'expérience comportant une pluralité de tâches lo- gicielles à effectuer pour résoudre un problème physique défini par au moins un paramètre d'entrée et au moins un paramètre de sortie, le plan d'expérience étant calculé en fonction d'un budget calculatoire initial prédéterminé, lesdites tâches logicielles à effectuer ayant un premier niveau de priorité, [0026] - un module de planification de l'exécution des tâches logicielles par le système de calcul, configuré pour : [0027] - vérifier la présence d'au moins une tâche logicielle de deuxième niveau de priorité supérieur au premier niveau de priorité en attente d'exécution, [0028] - en cas de présence d'au moins une tâche logicielle de deuxième niveau de priorité en attente d'exécution, obtenir des ressources de calcul libérées pour exécuter ladite au moins une tâche logicielle de deuxième niveau de priorité ; [0029] - en cas d'absence d'au moins une tâche logicielle de deuxième niveau de priorité en attente d'exécution, répartir au moins une partie des tâches logicielles de premier niveau de priorité sur les ressources de calcul disponibles. [0030] D'autres caractéristiques et avantages de l'invention ressortiront de la description qui en est donnée ci-dessous, à titre indicatif et nullement limitatif, en référence aux figures annexées, parmi lesquelles : [0031] [fig.1] la figure 1 illustre schématiquement un système d'utilisation des ressources de calcul d'une ferme de microprocesseurs selon un mode de réalisation ; [0032] [fig.2] la figure 2 est un synoptique des processus mis en oeuvre dans un mode de réalisation d'un procédé d'utilisation des ressources de calcul selon un mode de réalisation ; [0033] [fig.3] la figure 3 est un synoptique des étapes de la génération de plans d'expérience selon un mode de réalisation. [0034] L'invention sera décrite ci-après dans son application à la simulation et aux calculs associés à la résolution de problèmes physiques, exécutés sous forme de séquences de tâches logicielles, mais n'est pas limitée à ce domaine d'application. [0035] Le système d'utilisation des ressources de calcul 1 de la figure 1 comprend une ferme (ou « cluster ») de microprocesseurs interconnectés formant un système de calcul 2. [0036] Les microprocesseurs sont répartis en noeuds de calcul interconnectés et regroupés en différentes queues de calcul, ayant chacune une capacité calculatoirc associée. [0037] Par exemple, dans un mode de réalisation pratique, le cluster 2 est constitué d'une pluralité de dispositifs électroniques programmables interconnectés, par exemple des ordinateurs, chaque dispositif électronique programmable comprenant une unité électronique de mémoire et une unité centrale de calcul, ou CPU, comportant un ou plusieurs microprocesseurs électroniques, adaptées à communiquer via un bus de communication. En variante, chaque dispositif électronique programmable est réalisé sous forme de composants logiques programmables, tel qu'un FPGA ((le l'anglais Field-Programmable Gate Array), ou encore sous forme de circuits intégrés dédiés, de type ASIC (de l'anglais Application-Specific Integrated Circuit). [0038] Les dispositifs électroniques programmables sont adaptés à exécuter des tâches lo- gicielles, à partir d'instructions de code informatique en format exécutable, selon tout format approprié. [0039] On entend ici par tâche logicielle l'exécution d'un programme informatique sur un ensemble de données d'entrée. [0040] Le système 1 comporte également un module 4 de planification de l'exécution des tâches logicielles. [0041] Dans un mode de réalisation, le module 4 est réalisé sous forme de programme in- formatique exécutable, mémorisé dans une unité mémoire 6 d'un dispositif électronique programmable 8 faisant partie du cluster 2, et exécutable par un processeur du dispositif électronique programmable 8. [0042] L'unité mémoire 6 mémorise également un module 10 de formatage des résultats d'exécution de tâches logicielles. [0043] Le module 4 de planification de l'exécution des tâches logicielles du système 1 est configure pour gérer l'exécution des tâches logicielles 20 de premier niveau de priorité, également appelées tâches non prioritaires, et des tâches logicielles 22 de deuxième niveau de priorité, également appelées tâches prioritaires. [0044] Par exemple, les tâches logicielles prioritaires proviennent de commandes utilisateur. [0045] Les tâches logicielles non prioritaires sont associées à des problèmes physiques à étudier et sont destinées à être exécutées quand de la place est disponible sur le cluster. [0046] Chaque problème physique à étudier Pi, est défini par un ensemble de données, qui sont par exemple mémorisées dans un fichier 24 mémorisé sur un support physique lisible par ordinateur, et fourni en entrée du système 1. [0047] Dans un mode de réalisation, un problème physique est défini par : [0048] -un code de calcul et un jeu de données associé ; [0049] -un ensemble de paramètres d'entrée, chaque paramètre d'entrée ayant une plage de valeurs associée. Par exemple, un paramètre noté Paramètre _i est compris entre les bornes minimale Val min i et maximale Val max ; [0050] -au moins un paramètre de sortie ; [0051] -un budget calculatoire associé. [0052] -un nombre de microprocesseurs minimal à utiliser. [0053] Dans le cas d'une simulation d'un phénomène physique, la résolution du problème physique consiste à étudier les valeurs d'un paramètre ou de plusieurs paramètres de sortie, considérés comme étant des paramètres d'intérêt, en fonction des valeurs des paramètres d'entrée. [0054] Des exemples non exhaustifs de tels phénomènes physiques sont par exemple : calcul du délai pour faire totalement fondre un pavé métallique soumis à une source de chaleur sur une paroi, en fonction de la puissance de chauffe, de la température extérieure, de la capacité calorifique du matériau et des dimensions du pavé ; en fonction d'un angle et d'une taille d'un déflecteur, calculer une perte de pression associée ; en fonction des paramètres d'entrée : vitesse d"entrée dans le domaine de calcul, viscosité dynamique, dimension géométrique du domaine de calcul, calculer une variation de pression aux bornes du domaine de calcul, longueur de recollement. [0055] Le budget calculatoire est, dans un mode de réalisation, un nombre maximal de tâches logicielles à exécuter pour la résolution du problème physique. [0056] En variante ou en complément, le budget calculatoire comprend également le nombre minimal de microprocesseurs à prendre en compte pour le calcul. [0057] Par exemple, le code de calcul est un logiciel de calcul scientifique, recherchant une solution à des équations représentant des phénomènes physiques de façon itérative. 6 Dans un mode de réalisation, un tel logiciel est soumis à une licence d'exécution, et le nombre d'exécutions parallèles est limité au nombre de licences d'exécution disponibles. [0058] Chaque problème physique PL, défini par un ensemble de données comme décrit ci- dessus, est traité par un module 30 de calcul de plan d'expérience. [0059] Dans un mode de réalisation, le module 30 est réalisé sous forme de programme in- formatique exécutable par un des dispositifs électroniques programmables du cluster 2. [0060] Le module 30 met en oeuvre un processus de conception de plan d'expérience pour chaque problème physique à traiter. [0061] Un plan d'expérience est défini par un ensemble de simulations à réaliser, chaque si- mulation mettant en oeuvre une pluralité de tâches logicielles à exécuter, avec un jeu de paramètres choisi en entrée, chaque simulation permettant d'obtenir une valeur pour chaque paramètre de sortie choisi formant un résultat d'exécution 32. [0062] Le résultat d'exécution est fourni, par exemple sous forme brute, par exemple un fichier binaire, à un opérateur, via une interface adaptée du système, par exemple sous forme de fichier informatique. [0063] De plus, le résultat d'exécution 32 sous forme brute est transmis au module 10 de formatage des résultats d'exécution de tâches logicielles, qui génère des résultats d'exécution formatés 34. Ces résultats formatés contiennent les paramètres d'entrée et les paramètres de sortie du problème, qui sont extraits, le cas échéant, des résultats d'exécution sous forme brute, qui comprennent de nombreuses données. [0064] Avantageusement, le module 30 de calcul de plan d'expérience est adapté à calculer itérativement des plans d'expérience successifs pour la résolution d'un problème physique donné, en prenant en considération, pour le calcul d'un plan d'expérience courant, des résultats formatés 34 issus de l'exécution des tâches logicielles mises en oeuvre pour les étapes précédentes du plan d'expérience. [0065] En particulier, il est prévu de générer des plans d'expérience successifs ayant des durées d'exécution décroissantes ou des nombres de jeux de paramètres décroissants. [0066] La figure 2 est un synoptique des processus mis en oeuvre par le module 4 de plani- fication de l'exécution des tâches logicielles. [0067] Le module 4 met en oeuvre une étape d'obtention 40 de l'état des ressources ma- térielles, en particulier de la disponibilité de ressources calculatoires dans les microprocesseurs interconnectés du cluster 2. [0068] Par exemple, le nombre de microprocesseurs disponible parmi la pluralité de micro- processeurs interconnectés est obtenu à l'étape 40. Cette étape est répétée à intervalles temporels réguliers, par exemple toutes les minutes. [0069] Le module 4 met également en oeuvre une étape 42 de réception des requêtes d'exécution de tâches logicielles de première priorité (tâches logicielles non prio- 7 ritaircs) soumises par le module 30 de calcul de plan d'expérience, et une étape 44 de vérification de présence de requêtes d'exécution de tâches logicielles de deuxième priorité (tâches logicielles prioritaires). Par exemple, les tâches logicielles non prioritaires sont soumises dans une première queue de calcul, et le tâches logicielles prioritaires sont soumises dans une deuxième queue de calcul. [0070] Les étapes 42 et 44 sont par exemple effectuées sensiblement en parallèle, et répétées à intervalles temporels réguliers. [0071] En cas de présence de tâches logicielles prioritaires en attente d'exécution, le module 4 récupère (étape 46) une information relative à la disponibilité courante des ressources calculatoires. La disponibilité des ressources calculatoires comprend ici la disponibilité de microprocesseurs de calcul et également la disponibilité de licence logicielle, par exemple par un mécanisme de jetons de licence, pour effectuer les tâches logicielles prioritaires. [0072] En cas de disponibilité, l'exécution de la ou des tâches prioritaires est lancé (étape 54). [0073] En cas de non disponibilité des ressources calculatoires, l'étape 46 est suivie d'une étape 48 de libération de ressources calculatoires pour effectuer les tâches logicielles prioritaires. [0074] L'étape 48 comporte une sous-étape 50 d'analyse des tâches logicielles non- prioritaires en cours d'exécution, et de sélection de tâches logicielles non prioritaires à arrêter, en fonction des ressources calculatoires et des licences consommées. [0075] Par exemple, les tâches logicielles d'un plan d'expérience mis en oeuvre pour la ré- solution d'un problème physique donné sont sélectionnées. [0076] Ensuite, lors d'une sous-étape 52, les tâches logicielles non prioritaires sélectionnées sont arrêtées et leur contexte d'exécution est mémorisé, de manière à donner la possibilité d'une reprise d'exécution de ces tâches ultérieurement (étape 58 ci-après). De plus, tout jeton de licence libéré par l'arrêt d'exécution d'une des tâches non prioritaires est remis à disposition. [0077] Ainsi, avantageusement, lorsque le module 4 de planification de l'exécution des tâches logicielles détecte la présence de tâches logicielles prioritaires en attente d'exécution, il obtient des ressources calculatoires libérées pour permettre l'exécution de ces tâches logicielles à l'étape d'exécution 54. La ou les tâches logicielles prioritaires sont réparties sur les queues de calcul comprenant des ressources calculatoires disponibles. [0078] Lorsqu'aucune tâche logicielle prioritaires en attente d'exécution n'a été détectée à l'étape 44, le module 4 vérifie (étape 56) la présence de ressources calculatoires, y compris de ressources de licence, disponibles. [0079] En cas de disponibilité de ressources calculatoires, des tâches logicielles non prio- 8 ritaires mises en arrêt précédemment sont reprises (étape 58), le cas échéant. Les tâches logicielles non prioritaires en attente d'exécution, faisant partie de plans d'expérience soumis par le module 30 de calcul de plan d'expérience, sont chargées et exécutées sur les ressources calculatoires disponibles (étape 60). [0080] Dans un mode de réalisation, à l'étape 60, une queue de calcul est sélectionnée pour l'exécution d'une tâche logicielle non prioritaire, en fonction de l'état des ressources du cluster, par exemple en fonction du nombre de microprocesseurs disponibles et du nombre de calculs à effectuer pour l'exécution de la ou des tâches logicielles. [0081] Les tâches logicielles non prioritaires d'un plan d'expérience donné sont exécutées jusqu'à ce qu'un critère d'arrêt soit validé. Dans un mode de réalisation, la validation du critère d'arrêt correspond à l'atteinte du budget calculatoire prédéterminé en termes de nombre de calculs ou à l'atteinte d'une valeur cible de performance d'apprentissage du problème. [0082] Les tâches logicielles non prioritaires sont déterminées par le module 30 de calcul de plans d'expérience, dont un fonctionnement est décrit ci-après en référence à la figure 3. Avantageusement, l'occupation des ressources calculatoircs est optimisée, tout en conservant la priorisation de certaines tâches logicielles prioritaires, en particulier les tâches logicielles dont le traitement est requis par un utilisateur. [0083] La figure 3 est un synoptique des processus mis en oeuvre par le module 30 de calcul de plan d'expérience. [0084] Lors d'une première étape 70, les données définissant le problème physique à résoudre sont obtenues. Par exemple, ces données sont fournies par un opérateur. Avantageusement, c'est la seule intervention d'un opérateur humain, la génération des plans d'expérience successifs étant effectuée automatiquement par le module 30. [0085] Dans un mode de réalisation, un problème physique P,, est défini par : [0086] -un code de calcul et un jeu de données associé ; [0087] -un ensemble de N, paramètres d'entrée, chaque paramètre d'entrée ayant une plage de valeurs associée. Par exemple, un paramètre noté Paramètre_i est compris entre les bornes minimale Val_rnin_i et maximale Val_max_i ; [0088] -au moins un paramètre de sortie ; [0089] -un budget calculatoire initial associé B,. [0090] A l'étape d'initialisation 70, aucune connaissance supplémentaire sur les dé- pendances entre paramètres d'entrée et de sortie n'est requise. [0091] Par exemple, pour un problème PL, le budget calculatoire est un nombre maximal de tâches logicielles à effectuer pour résoudre le problème PL. [0092] Un espace expérimental est défini par le nombre NL de paramètres d'entrée, qui est un nombre entier positif, dépendant du problème PL à résoudre. L'espace expérimental est un hyper-pavé de dimension NL, éventuellement réduit par l'utilisateur en fonction 9 des combinaisons inutiles de paramètres. Un maillage de cet espace expérimental en points de calcul est défini ensuite. [0093] Par défaut, lors de l'étape d'initialisation, le maillage est isotrope. [0094] Par exemple, le maillage est défini de manière à ce que le nombre total de points de calcul soit inférieur à une valeur limite prédéterminée, par exemple égale à 103. [0095] Optionnellement, des informations complémentaires sont fournies lors d'une étape 72, par exemple des informations permettant d'affiner le maillage de l'espace expérimental. [0096] Ensuite, le plan d'expérience initial pour résoudre le problème physique P, est calculé, en fonction du budget calculatoire restant. [0097] On appelle budget calculatoire restant la valeur correspondant au budget calculatoire initial moins le budget calculatoire déjà consommé. À r initial isation, le budget calculatoire restant est égal au budget calculatoire initial. [0098] A l'étape 74, un budget calculatoire pour le plan d'expérience est courant est calculé. [0099] De préférence, pour le plan d'expérience initial, le budget calculatoire est choisi égal à une fraction du budget restant, par exemple la moitié : /2. Le budget cal- culatoire restant est alors également égal à B1/2. [0100] Ensuite, un plan d'expérience initial est conçu à l'étape 76, consistant à choisir un nombre de points de calcul NP1» sur lesquels le code de calcul est à exécuter, formant un ensemble de tâches logicielles à exécuter, en fonction du budget calculatoire disponible 1\41,0. La conception du plan d'expérience repose sur une procédure d'optimisation décrite en détail ci-après en référence aux étapes 84 et 86, focalisée sur un critère d'optimalité du plan d'expérience, par exemple un critère de maximum d'entropie (au sens de la théorie de l'information de Shannon). Bien entendu, il s'agit d'un exemple de critère d'optimalité, d'autres critères pourraient être utilisés. [0101] Dans un mode de réalisation, le plan d'expérience est initialisé paf- tirage aléatoire dans l'espace d'expérience puis amélioré par la procédure d'optimisation. [0102] En variante, le plan d'expérience est construit point par point avec l'objectif d'optimiser le même critère que la procédure d'optimisation à chaque ajout. [0103] Le plan d'expérience ainsi généré est transmis au module 4 de planification de l'exécution des tâches logicielles, et exécuté par le cluster 2. [0104] Des résultats d'exécution formatés 34 sont reçus à l'étape 78 suite à l'exécution du plan d'expérience. [0105] Ces résultats d'exécution sont traités par le module 30 pour mettre à jour une connaissance du problème PL à traiter, afin de permettre une optimisation de la génération de plans d'expérience. En particulier, l'influence des paramètres d'entrée sur les valeurs des paramètres sortie, connues à partir des résultats d'exécution, est analysée, de manière à affiner la sélection des points de calcul pour générer le plan d'expérience. [0106] Dans un mode de réalisation, le module 30 construit un méta-modèle mathématique et met en oeuvre un algorithme d'apprentissage statistique supervisé en fonction des résultats d'exécution. Par exemple, le méta-modèle statistique est un modèle de régression par processus gaussien. Les modèles de régression par processus gaussien sont bien connus dans le domaine du traitement statistique des données. Ils assimilent la covariance de la variable aléatoire gaussienne représentative du processus modélisé à une fonction analytique, également appelée noyau, paramétrée par des valeurs scalaires nommées hyperparamètres. Le module 30 procède à l'optimisation des hyperparamètres du noyau de covariance, par exemple par la méthode du maximum de vraisemblance. [0107] Dans un mode de réalisation, la régression par processus gaussien, munie d'un noyau de covariance a priori ka , est reliée au critère d'optimalité du plan d'expérience. Par exemple, le critère d'optimalité consiste à maximiser le déterminant de la matrice K telle que : [0108] K = ke(x i, xi) où Xj sont des points de calcul du plan d'expérience. [0109] Dans un mode de réalisation, pour un problème PL donné, des plans d'expérience successifs sont générés et exécutés, par itérations, jusqu'à ce qu'un critère d'arrêt soit validé. [0110] La validation du critère d'arrêt est vérifiée lors d'une étape 80. [0111] Dans un mode de réalisation, le critère d'arrêt est validé lorsque le budget cal- culatoire initial a été consommé, ou, en d'autres termes, lorsque le budget calculatoire restant est à 0. Dans ce cas, l'étape 80 est suivie par un arrêt des calculs (étape 82). [0112] S'il reste un budget calculatoire à l'itération courante, un budget calculatoirc courant est établi. [0113] En variante, une atteinte d'une valeur cible de performance est également un critère d'arrêt. Ainsi, les calculs sont arrêtés si la valeur cible de performance est atteinte, même si le budget calculatoire n'a pas été entièrement consommé. [0114] Dans un mode de réalisation, le critère de performance est la valeur moyenne du co- efficient de détermination dc la régression linéaire entre le résultat exact de la simulation d'une part, et le résultat prédit par le méta-modèle d'autre part, ce dernier étant entraîné sur une sélection d'autres cas, par exemple par la méthode de validation croisée « 10-fold cross-validation ». La valeur cible du critère de performance est alors 11 fixée à la soumission du problème par l'utilisateur, et peut typiquement être de l'ordre de 0.95. [0115] Si le critère d'arrêt n'est pas validé, le budget calculatoire pour l'itération courante i' dit budget calculatoire courant, est calculé, et dans un mode de réalisation, il est égal à la moitié du budget calculatoire restant. [0116] En fonction du budget calculatoire courant, des points de calcul sont sélectionnés (étape 84), et un plan d'expérience courant est calculé (étape 86). [0117] Dans un mode de réalisation, un algorithme d'optimisation par procédure d'échange configure pour augmenter l'entropie de l'information de Shannon est mis en oeuvre. [0118] Des points de calcul candidats d'échange sont sélectionnés de la manière suivante. Un nombre Pue de points de calcul « en danger » est déterminé, par exemple un pourcentage des Nue points de calcul du plan d'expérience courant. Par exemple ce pourcentage est compris entre 10% et 30%. [0119] La matrice de covariance K normalisée est calculée, et la matrice inverse K dite matrice de précision est calculée. Sur la base de ces matrices, P,,i,points de calcul sont sélectionnés. Ces points de calcul sont les points ayant le moins d'information mutuelle avec les autres points de calcul du plan d'expérience précédemment exécuté. [0120] Ils sont remplacés par des nouveaux points de calcul recherchés dans l'espace expé- rimental, permettant d'augmenter l'information mutuelle, ce qui se traduit calculatoirement par une augmentation de la valeur du déterminant de la matrice de covariance K calculée avec les nouveaux points de calcul. [0121] Avantageusement, cette optimisation de l'information mutuelle permet de comprendre le plus profondément possible le problème, à budget calculatoire fixé. [0122] Un plan d'expéiience courant, pour l'itération courante i' est obtenu à l'étape 86. [0123] Les étapes 78 à 86 sont itérées jusqu'à la validation du critère d'arrêt. [0124] Avantageusement, le module 30 de calcul de plans d'expérience met en oeuvre des méthodes statistiques supervisées pour une résolution automatisée des problèmes à résoudre, tout en contrôlant le budget calculatoire et en se passant d'intervention humaine. [0125] Avantageusement, le processus mis en oeuvre par le module de calcul permet d'effectuer des calculs avec une maîtrise des ressources matérielles et du temps d'exécution grâce à la mise en oeuvre du budget calculatoire. [0126] En particulier, le choix de budgets calculatoires décroissants en lien avec l'algorithme d'optimisation d'échange permet d'améliorer la performance des plans d'expérience tout en limitant les ressources de calcul utilisées. [0127] Avantageusement, le module 4 de planification de l'exécution des tâches logicielles met en oeuvre une optimisation de l'exploitation des ressources, tout en gérant des priorités de tâches logicielles à exécuter. 12 [0128] Le système 1 d'utilisation des ressources calculatoires incluant ces deux modules qui collaborent permet une gestion optimisée et contrôlée des coûts, incluant le coût matériel, le coût de licence et le coût en intervention humaine, les temps de calcul et l'optimisation des ressources étant optimisés. 13 [Revendication I] [Revendication 2] [Revendication 3] [Revendication 4]