Technologies pour le metacomputing
This presentation is the property of its rightful owner.
Sponsored Links
1 / 59

Technologies pour le Metacomputing PowerPoint PPT Presentation


  • 93 Views
  • Uploaded on
  • Presentation posted in: General

Technologies pour le Metacomputing. Thierry Priol IRISA/INRIA. Métacomputing. Introduction, définition et applications Technologies pour le Metacomputing Cobra: un environnement fondé sur CORBA Un exécutif pour des grappes de PC Concept d’objet CORBA parallèle

Download Presentation

Technologies pour le Metacomputing

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Technologies pour le metacomputing

Technologies pour le Metacomputing

Thierry Priol

IRISA/INRIA


M tacomputing

Métacomputing

  • Introduction, définition et applications

  • Technologies pour le Metacomputing

  • Cobra: un environnement fondé sur CORBA

    • Un exécutif pour des grappes de PC

    • Concept d’objet CORBA parallèle

  • Quelques applications en cours de réalisation

    • Traitement du signal

    • Réalité virtuelle


Introduction d finitions

Introduction, définitions

  • Metacomputer (métacalculateur)

    • Collection de calculateurs/supercalculateurs

    • Dispersion géographique des calculateurs/supercalculateurs

    • Connexion par un réseau à très haut-débit

    • Vision logique d’une seule machine: le métacalculateurIl y a 15 ans, cela s’appelait tout simplement un système distribué !

  • Metacomputing (métacalcul)

    • Programmation des métacalculateurs (systèmes, éxécutifs, langages, outils, applications)


Meta application

Meta application

  • Une application qui ne peut s’exécuter sur une seule machine

    • limitation des ressources (puissance des processeurs, mémoire, disque)

    • absence de certains types de ressources (visualisation, …)

  • Une application qui est une collection de modules relativement indépendants pouvant s’exécuter de façon asynchrone

  • Le parallélisme est présent à l’intérieur d’un module

  • Exemple d’une méta application: conception d’un satellite

    • Analyse de structure, dynamique, thermique, optique, ...


M tacomputing vers l informatique de demain

Métacomputing: vers l’informatique de demain ?

  • Un accroissement sensible de la demande en ressources de calculs

    • Généralisation des outils de simulation à tous les niveaux de l’industrie (Petites, Moyennes et Grandes Entreprises)

  • Calculateurs de plus en plus complexes à utiliser

  • Calculateurs de plus en plus chers à maintenir

  • Un regard sur le passé

    • Analogie avec l’énergie électrique...


Energie

Energie


Informatique

Informatique


Applications du m tacomputing

Applications du Métacomputing

  • Visualisation à distance

    • Systèmes de réalité virtuelle (CAVE, …)

  • Simulation distribuée (ou Problem Solving Environment)

    • La puissance de calcul disponible sur un simple PC permet d’envisager le couplage de codes de simulation

  • Travail coopératif

    • Faire travailler plusieurs experts simultanément sur les résultats d’une simulation


Probl mes li s au metacomputing

Problèmes liés au Metacomputing

  • Metacomputer : une collection de machine

    • environnement logiciel hétérogène (système d’exploitation, exécutif)

    • pas de partage de fichiers possible

    • règles de sécurité différentes dans chaque site

  • Les problèmes à résoudre

    • Allocation de ressources

    • Communication

    • Gestion des données distribuées

    • Sécurité

    • Tolérance aux défaillances


Allocation de ressources probl mes

Allocation de ressources: problèmes

  • Autonomie des sites participants

    • différentes organisations avec leurs propres règles (allocation, sécurité, …)

  • Gestionnaire de ressources hétérogènes

    • Condor, NQE, CODINE, EASY, LSF, PBS, LoadLeveler,…

  • Extensibilité

    • ajout de nouvelles ressources, impact sur les autres sites ?

  • Allocation simultanée des ressources distribuées

    • Certaines applications nécessitent une co-allocation (allocation simultanée de ressources sur plusieurs sites)


Communication

Communication

  • Contraintes

    • Technologies réseaux variées (ATM, HIPPI, Gigabit, …)

    • Performance (TCP/IP ?)

    • Interopérabilité

  • Différentes approches:

    • Echange de message (PVM, MPI)

    • RPC (DCE, …)

    • Objet distribué (CORBA, …)


Gestion de donn es distribu es probl mes

Gestion de données distribuées: problèmes

  • La distribution d’une application, sous forme de composants, pose le problème de l’accès aux données

    • Chaque composant consomme et produit des données (fichiers)

    • Echange de données (transfert de fichiers entre machines)

  • Mécanismes de mouvement et d’accès aux données

    • Limitation des solutions existantes (NFS, MPI-IO, WWW, …)

    • Contraintes de conception:

      • Doit nécessiter peu de modifications dans les applications

      • Ne doit pas imposer de fortes contraintes à l’installation

      • Doit pouvoir exploiter le maximum de performance offerte par le réseau


S curit

Sécurité

  • Utilisation de plusieurs machines avec ses propres règles de sécurité

    • Impossible de transférer des fichiers de façon transparente (mot de passe!)

  • Confidentialité des données

    • Transfert de données confidentielles à l’échelle de l ’Internet

    • Cryptage des données


Tol rance aux d faillances

Tolérance aux défaillances

  • Meta application: une application distribuée!

    • Que faire si un composant de l’application tombe en panne ?

  • Techniques

    • Checkpointing

      • problème de la définition d’un état cohérent

      • nécessite souvent la modification des logiciels (définition d’un état)

      • sauvegarde des états

    • Réplication

      • impossibilité de répliquer tous les modules

      • quel module choisir ?


Quelques exemples d environnements pour le metacomputing

Quelques exemples d’environnements pour le Metacomputing

  • Approche par échange de messages

    • Globus

  • Approche par RPC (Remote Procedure Call)

    • Netsolve

    • Ninf

  • Approche orientée objet distribué

    • Pardis

    • Cobra


Approche par change de messages

Approche par échange de messages


Globus i foster et c kesselman

GlobusI. Foster et C. Kesselman

  • Une boite à outils plutôt qu’un environnement de metacomputing

  • Un ensemble de services:

    • Allocation de ressources (GRAM)

    • Communication unicast/multicast (Nexus)

    • Gestion de l’information, état du système (MDS)

    • Sécurité (GSI)

    • Monitoring (HBM)

    • Accès aux données à distance (GASS)

    • Gestion des exécutables (GEM)


Architecture de globus

Architecture de Globus


Allocation de ressource gram

Allocation de ressource(GRAM)

  • Concept de gestionnaire local des ressources

    • Offrir une vision homogène de l’allocation des ressources quelque soit le gestionnaire de ressource utilisé (NQE, LSF, CODINE, …)

  • Service d’information

    • Disponibilité, caractéristiques, propriétés des ressources

  • Langage de spécification de ressources (RSL)

    • Langage pour exprimer un besoin particulier en ressources

    • Exemple: &(executable=myprog)(|(&(count=5)(mempry>=64)) (&(count=10)(memory>=32)))

  • Courtier de ressources

    • Spécialisation: transformation de requêtes RSL en requêtes plus simples avec l’ajout d’un nom de machine identifiant le gestionnaire de ressource


Allocation de ressources gram

Allocation de ressources(GRAM)


Acc s aux donn es gass

Accès aux données(GASS)

  • GASS: Global Access to Secondary Storage

  • Un mécanisme de mouvement et d’accès aux données

    • Optimisé pour les patrons d’accès des applications de metacomputing

    • Implémentation de nécessitant pas de services particuliers

    • Contrôle de l’utilisateur pour optimiser les transferts de données

      • cache de donnée, filtrage, …

  • Problèmes à résoudre:

    • Nommage, API, authentification, communication, performance...


Acc s aux donn es gass1

Nommage par URL

x-gass://host:port/filename

ftp://host/filename

Interface de programmation: proche de celle d’UNIX

globus_gass_open()

globus_gass_close()

globus_gass_cache()

Sémantique

copie vers le cache à l’ouverture

mise à jour du fichier à la fermeture si modification

Performance: optimisation pour des patrons d’accès (via un cache)

lecture-seulement (à partir du cache local)

écriture-seulement (vers le cache local)

lecture-écriture (à partir/vers le cache local)

écriture-seulement, ajout (vers le serveur à distance)

Support de GASS dans GRAM

&(executable=x-gass://quad:12/file) (stdin = x-gass://quad:12/myin) (stdout = /home/bester/output) (stderr = x-gass://qd:1/dev/stdout)

Accès aux données(GASS)


Acc s aux donn es gass2

Accès aux données(GASS)


Approches par rpc

Approches par RPC


Netsolve univ tennessee h casanova j dongarra

Netsolve (Univ. Tennessee)H. Casanova & J. Dongarra

  • Concept de librairie étendu à l’échelle d’Internet ou d’un Intranet

    • « Librairie virtuelle »

    • Eviter l’installation de logiciels

  • Concepts de base

    • accès à distance à des ressources de calcul (client/serveur)

    • Espace de nommage

    • Données du problème sont transmises à un serveur

    • Interfaces avec C, Fortran, Matlab, Java, …

    • Equilibrage des charges entre serveurs


Netsolve programmation

NetSolve: programmation

  • Du coté du client

    • Transparence de la localisation des serveurs (réseau transparent)

    • Accès à la « librairie virtuelle » par identificateur

    • Appel synchrone/asynchrone

parameter (MAX=100)

double precision A(MAX,MAX),B(MAX)

integer IPIV(MAX),N,INFO,LWORK

integer NSINFO

cSolve linear equations

call DGESV(N,1,A,MAX,IPIV,B,MAX,INFO)

call NETSL(‘DGESV()’,NSINFO, N,1,1,MAX,IPIV,B,MAX,INFO)


Netsolve acc s aux logiciels

NetSolve: accès aux logiciels

  • Du coté du serveur

    • Gestion du matériel et du logiciel

    • Interface avec les logiciels scientifiques installés sur le serveur

      • BLAS, LAPACK, ItPack, FitPack, FFTPack, NAG Software, …

    • Outils pour l’installation de nouveaux logiciels (Compilateur NetSolve)

  • Du coté de l’agent

    • Courtier en ressources

    • Stocke l’information concernant la disponibilité des machines sur le réseau et des logiciels scientifiques disponibles

    • Equilibrage des charges par prédiction des temps d’exécution

      • performance du réseau

      • performance du serveur (LINPACK) et de sa charge

      • Temps d’exécution du logiciel en fonction de la taille du problème


Ninf electronical lab tsukuba nakada et al

Ninf

Server

Ninf

Server

Ninf

Server

NumericalRoutine

NumericalRoutine

NumericalRoutine

NumericalRoutine

NumericalRoutine

NumericalRoutine

NumericalRoutine

NumericalRoutine

NumericalRoutine

Ninf (Electronical Lab., Tsukuba)Nakada et al.

  • Ninf

    • Network Infrastructure for Global Computing

  • Accès aux serveurs par RPC

    • protocole dynamique + interopérabilité

  • Interface de programmation

    • RPC synchrone/asynchrone

    • Transaction

    • Callback

  • Langage de description d’interface

    • Langage IDL spécifique

  • Equilibrage dynamique des charges

    • allocation dynamique des ressources

C Client

Excel

Client

MetaServer

Java

Client

Mathematica

Client


Ninf interface de programmation

Ninf: Interface de programmation

  • Caractéristiques:

    • Langage cible: C, C++, Fortran, Java, Lisp …,Mathematica, Excel

    • Nommage des fonctions: ninf://HOST:PORT/ENTRY_NAME

  • Appel synchrone/asynchrone:

double A[n][n],B[n][n],C[n][n];

/* multiplication de matrice */

Ninf_call(«ninf://etlhpc.etl.go.jp:3000/dmmul»,n,A,B,C);

id = Ninf_call_async(«dmmul»,n,A,B,C);

Ninf_wait(id);


Technologies pour le metacomputing

A

B

C

D

dmmul

dmmul

E

F

dmmul

G

Ninf: Interface de programmation

  • Transaction:

    • exploitation du parallélisme au niveau du réseau

    • analyse de dépendance à l’exécution

    • exécution de type dataflow

double A[n][n],B[n][n],C[n][n];

Ninf_transaction_start();

Ninf_call(«dmmul»,n,A,B,E);

Ninf_call(«dmmul»,n,C,D,F);

Ninf_call(«dmmul»,n,E,F,G);

Ninf_transaction_end();


Technologies pour le metacomputing

Ninf: Interface de programmation

  • Callback:

    • notification du client par le serveur

    • exécution d’une fonction du client par le serveur

Client

Serveur

Ninf_call

Void CallbackFunc(…) {

/* corps de la fonction */

}

Ninf_call(« func », arg, …, CallbackFunc);

CallbcakFunc


Ninf langage de description d interface

Ninf Executable

Ninf Executable

Ninf Executable

Ninf: Langage de description d’interface

  • Spécifications:

    • Fonctions et arguments (mode)

    • Librairies associées aux fonctions

    • Complexité

    • Spécification du langage d’implémentation

Ninf

Computational

Server

Definedmmul(long mode_in int n,

mode_in double A[n][n],

mode_in double B[n][n],

mode_out double C[n][n])

“ description “

Required “libXXX.o”

CalcOrder n^3

Calls “C” dmmul(n,A,B,C);

Stub

Program

Ninf

Procedure

Ninf Stub

Generator

IDL File


Ninf quilibrage des charges

Ninf: équilibrage des charges

  • Comment répartir les calculs afin d’exploiter au mieux les ressources de calcul ?

    • Changement dynamique de la charge (réseau, serveurs)

    • Informations distribuées

  • Informations nécessaires pour une répartition équitable de la charge

    • Caractéristiques des serveurs

    • Etat des serveurs (charge, …)

    • Etat des réseaux (latence, débit)

    • Caractéristiques des applications (complexité, taille du problème, …)


Ninf quilibrage des charges1

Ninf: équilibrage des charges

Directory

Service

Server Side

Server

Proxy

MetaServer

Client Side

Scheduler

Server

Probe

Module

Server

Proxy

Client

Server

Load

query

Schedule

query

Data

Client

Client

Proxy

Server

Proxy

Server

Throughput

Measurement


Approche orient e objet distribu

Approche orientée objet distribué


Corba et le metacomputing

CORBA et le Metacomputing

  • CORBA est un standard pour la conception d’applications distribuées proposé par l’OMG (Object Management Group)

    • Orienté objet

    • Mécanisme d’invocation à distance (RPC)

    • Indépendance vis à vis du matériel, des systèmes d’exploitation et des langages de programmation

    • Indépendance vis à vis des implémentations (interoperabilité)

    • Concept de bus logiciel

  • Composants principaux:

    • Interface Description Language (IDL)

    • Object Request Broker (ORB): communication entre objets

    • Ensemble de services (nommage, événement, …)


Architecture de corba

Architecture de CORBA

in args

operation()

Implémentation de l’objet

client

out args + return value

Répertoire

d’implémentation

IDL

skeleton

DSI

Répertoire d’interface

IDL

stub

ORB

interface

DII

Adaptateur d’objet

ORB core

GIOP / IIOP / ESIOP


Exemple de sp cification idl

Exemple de spécification IDL

interface MatOps {

typedef long vect[100];

typedef long mat[100][100];

void MatVect( in mat A, in vect B, out vect C );

};

Implémentation

de l’objet

Compilateur

IDL

Serveur

Invocation de

l’objet

Client

IDL skeleton

IDL stub

Object Adapter

Object Request Broker (ORB)

server->MatVect( A, B, C);


Pardis univ indiana k keahey et d gannon

Pardis (Univ. Indiana)K. Keahey et D. Gannon

  • Une approche « à la CORBA »

    • reprend les même concepts: ORB + IDL

    • a priori non interopérable avec des implémentations de CORBA

  • Intégration du parallélisme

    • Concept d’objet SPMD

    • Concept de séquence distribuée

  • Support de l’asynchronisme grâce au future

    • Associé à l’appel non bloquant d’une opération

    • future = valeur + sémaphore

    • Exemples d’utilisation

      • Traitement des résultats intermédiaires (visualisation, mise au point, …)

      • Couplage de codes (synchronisation lâche)


Pardis concept d objet spmd

Pardis: concept d’objet SPMD

IDL (du service)

C++ (client)

typedef dsequence <double,1024,

(BLOCK,BLOCK)> diff_array;

interface diff_object {

void diffusion(in long timestep,

inout diff_array darray);

};

diff_object* diff =

diff_object::_spmd_bind(“example”,

HOST1);

diff->diffusion(64, my_diff_array);

spmd_bind

diffusion

spmd_bind

diffusion

spmd_bind

diffusion

Application A

diff_object

Application B


Pardis les futures

Pardis: les futures

IDL service A

IDL service B

interface direct {

void solve(in mat A, in vec B,

out vec X);

};

interface iterative {

void solve(in double tol, mat A, in vec B,

out vec X);

};

C++ (client)

direct_var = d_solver = direct::_spmd_bind(“direct_solver”, HOST_1);

iterative_var = i_solver = iterative::_spmd_bind(“itrt_solver”, HOST_2);

...

PARDIS::future <vec_var> X1;

vec_var X1_real, X2_real;

i_solver->solve_nb(tolerance, A, B, X1);

d_solver->solve_nb(A,B,X2_real)

X1_real = X1;

double diff = compute_diff(X1_real, X2_real);

Client

A

B


Cobra un environnement fond sur corba

Cobra: un environnement fondé sur CORBA

  • Un environnement à l’échelle d’un Intranet

    • Problem Solving Environment

    • Application de type client/serveur ou serveur/serveur (couplage de codes)

  • Adoption de standards

    • CORBA: communication entre composants

    • MPI: communication au sein d’un composant

  • Cobra

    • un gestionnaire de ressources pour un réseau de PC/stations de travail

    • une extension de CORBA pour supporter le parallélisme (SPMD)


Corba et le parall lisme spmd

CORBA et le parallélisme SPMD

  • Un programme parallèle SPMD est un ensemble de processus identique

  • Comment encapsuler un tel programme au sein d’un objet CORBA parallèle ?

Programme Parallèle

Objet

CORBA

IDL

Programme Parallèle

Extended-IDL

MPI

MPI

obj.

obj.

proc

proc

obj.

proc

proc

MPI

obj.

obj.

Processus SPMD

Objet CORBA parallèle


Concept d objet corba parall le

Implémentation

de l’objet

Implémentation

de l’objet

Squelette

IDL

Squelette

IDL

Adaptateur

d’objet

Adaptateur

d’objet

Concept d’objet CORBA parallèle

Serveur 1

Service parallèle

Serveur n

Process

Objet CORBA parallèle

=

Collection d’objets CORBA

Client

Invocation

objet

...

Talon IDL

Courtier d’objet (ORB)


Objet corba parall le mise en oeuvre

Objet CORBA parallèle mise en oeuvre

  • Contraintes

    • Ne pas modifier le courtier d’objets (ORB), rester compatible CORBA

  • Gestion des données

    • Distribution ou réplication des valeurs de paramètres au sein de la collection d’objets

  • Invocation entre objets

    • Objet standard  objet parallèle

    • Objet parallèle  objet standard

    • Objet parallèle  objet parallèle

  • Interface avec les services CORBA

    • nommage des services parallèles


Compilateur extended idl

Compilateur Extended-IDL

  • Définition de l’interface d’un service parallèle

    • Distinction entre service standard et service parallèle

    • Distribution des valeurs des paramètres lors d’une invocation

  • Génération du talon

    • Appel simultané de chaque opération sur l’ensemble des objets de la collection

    • Utilisation d’une librairie de communication (MPI) au sein du talon pour la distribution ou la redistribution des données

  • Génération du squelette

    • Stockage de l’information sur la distribution des paramètres


Sp cification du nombre d objets au sein d une collection

Spécification du nombre d’objets au sein d’une collection

  • Plusieurs possibilités offertes

    • un nombre indéterminé

    • Un nombre fixe

    • Une fonction

  • Problème de l’héritage d’interfaces

interface [*] MatOps { ... };

interface [2^n] Compute: MatOps { ... };

interface [*] I1 { ... };

interface [4] I2 { ... };

interface [2 .. 4] I3 { ... };

interface [2^n] I4 { ... };

interface [2^n] MatOps { ... };

interface [*] Compute: MatOps { ... };


Sp cification de la distribution des param tres

Spécification de la distribution des paramètres

  • Mode de distribution proche de celle d’HPF

void MatVect( in dist[BLOCK][*] mat A,

in vect B,

out dist[BLOCK] vect C );

Nouveau type

pour les paramètres

distribués

Compilateur

Extended-IDL

void MatVect( const mat A,

const vect B,

vect C );

void MatVect( const darray_mat &A,

const darray_vect &B,

darray_vect &C );

Talon

Squelette


G n ration du talon

#2

#1

A

A

B

B

C

C

Génération du talon

  • Distribution physique des données (mode in)

  • Construction d’une requête multiple

  • Assemblage des données distribuées (mode out)

pco->MatVect( A, B, C );

void MatVect(in dist[BLOCK][*] mat A,

in vect B,

out dist[BLOCK] vect C );

talon

squel.

obj. 1

A

objet

Objet

CORBA

parallèle

Objet

CORBA

B

squel.

obj. 2

C

ORB

Requests

serveur

client


G n ration du talon1

obj. 1

talon

obj. 2

talon

obj. n

talon

Génération du talon

ObjetCORBA

parallèle

  • Lorsque l’objet appelant est parallèle et l’appelé est séquentiel

    • Election d’un objet pour l’invocation

    • Assemblage des données

  • Lorsque à la fois l’objet appelant et l’objet appelé sont parallèles

    • Election d’un sous-ensemble d’objets pour l ’invocation

    • Redistribution des données en fonction de la distribution chez l’appelant et celle de l’appelé

Objet

CORBA

squel.

obj.

Objet CORBA

parallèle

squel.

obj. 1

MPI

squel.

obj. p

ORB

client

serveur


G n ration du squelette

Génération du squelette

  • Stockage de l’information sur la distribution associée à l’objet (distributed array).

void op1( in vect A,

in dist[BLOCK] vect B );

A

squel.

Objet

1

talon

void op2( in vect C );

B

A

squel.

Objet

Objet

talon

MPI

B

squel.

A

Objet

2

talon

ORB

ORB

B

co->op2( A );

co->op2( B );

pco->op1( A, B );


Interface avec le service de nommage

Interface avec le service de nommage

  • Le service de nommage permet d’associer un nom à un objet

Serveur: objet de la collection

OpMat_Impl* obj = new OpMat_Impl();

NamingService->join_collection("Matrice", obj);

...

NamingService->leave_collection("Matrice", obj);

Client

objs = NamingService->resolve_collection("Matrice", obj);

svr = OperationsMatricielles::_narrow(objs)

/* ... */

svr->multiplication(A,B,C);


Cobra un x cutif pour les objets corba parall les

Objectifs

Exécution des objets CORBA parallèles

Allocation de ressources aux utilisateurs

Administration de la plate-forme

Contraintes

Services accessibles sur le réseau

Exécutif Cobra

Un ensemble de services CORBA pour une grappe de PCs interconnectés par SCI

Cobra: un éxécutif pour les objets CORBA parallèles

Nœud de calcul

Anneau SCI

(200 MB/s)

Grappe SCI

Comm.

SCI

PC SMP

2 x Pentium Pro/II

128 Mo EDO RAM

2 Go Disk

PCI-SCI Card

Nœud de service


L ex cutif cobra

Gestion de ressources

Machine parallèle virtuelle

Région de mémoire partagée

Administration

Configuration

Utilisateurs

Extensibilité

Plusieurs nœuds de service

L’exécutif Cobra


Application de traitement du signal

Application de traitement du signal

Modèle réduit sur un socle pivotant

  • IDAHO: une application de traitement du signal (électromagnétisme)

  • Un modèle réduit d’avion est illuminé par un faisceau pour chaque angle de (de 0 à 360°) et pour des fréquences variant de 2 à 8 GHz

  • L’expérience dure 90 heures et génère 1Goctets de données

Chambre


Architecture logicielle

IDAHO

IDAHO

Architecture logicielle

Chargement de

l’applet JAVA

du serveur WEB

(1)

Serveur

WEB

Apache

Objet CORBA parallèle

Création de la VPM

(2)

Objets CORBA

...

Services

Cobra

Destruction de la VPM

(6)

Objet CORBA

Applet Java

proxy

IDAHO

Initialisation (3)

Exécution (4)

Visualisation (5)

Station de travail

Nœuds de calcul

Nœuds de service


Applications de r alit virtuelle

Applications de réalité virtuelle

Résultats du calcul de radiosité

  • RADIOSITE: une étape de prétraitement pour calculer l’échange d’énergie entre objets dans une scène

  • Le calcul du radiosité est effectué de façon itérative

  • Plusieurs heures de calcul

  • Nécessité de visualiser à chaque itération dans le cas d’un processus d’optimisation (placement de sources lumineuses)


R alit virtuelle

RADIOSITY

RADIOSITY

RADIOSITY

Réalité Virtuelle

Serveur

WEB

Apache

Objet CORBA parallèle

Chargement de

l’applet JAVA

du serveur WEB

(1)

Objets CORBA

...

Services

Cobra

Destruction de la VPM

(6)

Objet CORBA

Création de la VPM

(2)

VRML

proxy

RADIOSITY

Initialisation (3)

Exécution (4)

Visualisation (5)

Applet

Station de travail

Nœud de calcul

Nœud de service


Conclusion perspectives

Conclusion & perspectives

  • Metacomputing

    • De nombreux systèmes existent mais ne sont pas interopérables!

    • On réinvente souvent la roue!

    • Réels besoins: à l’échelle de l’INTERNET ou de l’INTRANET ?

  • Nos travaux actuels et le futur proche

    • Approche: utilisation et extension de standards existants

    • Conception d’un ORB efficace (ESIOP)

    • Système de gestion de données (service CORBA)

    • Langage de coordination pour la conception d’applications

    • Applications via des contrats (Aerospatiale, Esprit Jaco3, Soft-IT)


  • Login