Riunione MPI-multicore del 1/06/2012

Location: INFN-CNAF, Via Ranzani Bologna, sala Riunioni Asinelli , dalle 14:00 alle 16:00

Presenti

A Bologna: Roberto Alfieri, Massimo Drudi, Antonia Ghiselli, Marco Bencivenni.

In remoto; Vania Boccia, Giovanni Barone, Luisa Carracciuolo, Enrico Mazzoni, Daniele Cesini e Alessandro Costantini.

Minute

Stato dei siti

I siti di Parma, Napoli Pisa e Perugia sono attivi e correttamente configurati nel TOP BDII di produzione. Il sito di Bologna/IGI e' in ritardo a causa del ritardo di consegna del materiale.

Deployment: problematiche di installazione e configurazione del supporto MPI in EMI-1

Occorre prestare attenzione nella configurazione Yaim del CE: il profilo MPI_CE deve esistere e deve essere il primo della lista. E' necessario pubblicare anche nel sistema informativo il tipo di rete (MPI-Ethernet | MPI-Infiniband)

Ambiente Hardware

Sono state inserite alcune note sull'utilizzo degli attributi "Wholenodes" e Mpi-start; Attributi "WholeNodes"

Alfieri R. riassume i punti salienti del primo incontro che si è svolto a Napoli tra Boccia, Carracciuolo, Alfieri e Salomoni con l'obiettivo di implementare a livello del LRMS (per LSF e PBS) meccanismi che consentano un utilizzo corretto, equo e massimizzato delle risorse di calcolo (in particolare quelle rivolte alle comunità HPC).

Si ritiene necessario poter configurare l'LRMS in modo da supportare almeno il Job packing (per ottimizzare l'uso delle risorse), la classificazione e la gestione dei diversi tipi di job (seriali, paralleli, memory-bound).

Ambiente Software

Boccia ricorda quanto detto nella scorsa riunione del gruppo e sottolinea la necessità di definire standard per la configurazione e la pubblicazione dell'ambiente software (librerie tools, compilatori, ..) disponibili nei siti. Tutti concordano che la questione è molto complessa per la elevata trasversalità del problema (di interessa non solo per le comunità HPC ma per tutte le comunità di utenti in generale) poichè riguarda almeno i gruppi Middleware, FUS e il gruppo mpi/multicore stesso ma che coinvolge anche i gruppi che sviluppano GLUE.

Si concorda che la soluzione migliore per by-passare il problema sia quella di procedere per step:

  • Step 1: si può chiedere al gruppo middleware di prevedere che un'installazione del profilo WN e del profilo WN-MPI abbia già dipendenze per almeno qualche compilatore in più (ad. es GNU), qualche libreria di software scientifico di base consolidata (ad es. Gsl, Atlas, LaPack, Blas, Fftw3) e qualche libreria per la gestione dati (hdf5, netcdf, cfitsio) e (peri WN-MPI) qualche implementazione dello standard MPI (ad es. OpenMPI) e compilatori in grado di gestire le direttive multithread (ad es. OpenMP)
  • Step 2: chiarirsi le idee sull'obiettivo finale del supporto alle applicazioni (in termini di metodologie per fornire all'utenza un ricco ambiente software applicativo) per poi:
    • rimodulare tale obiettivo sulla base di quanto il gruppo mpi/multicore può realizzare come primo passo fungendo da "incubatore" almeno per le comunità HPC
    • formulare una proposta da condividere in modo trasversale con tutti i gruppi di lavoro su citati.

Alfieri fa notare che a Napoli hanno elaborato una prima metodologia (basata sull'utilizzo di LCG-VO-TAGS, sulle variabili CE-RUNTIME e su una buona documentazione dell'utilizzo delle librerie disponibili) che può essere un buon punto di partenza nel supporto alle applicazioni e ricorda a tutti che i colleghi di Napoli hanno preparato la bozza di una proposta per la standardizzazione del middleware applicativo: /MPI/AmbienteSoftwareApplicazioni. Tale proposta sarà integrata inserendo i punti cardine dell'esperienza del gruppo di Napoli, punti che saranno integrati/modificati eventualmente dai rappresentanti delle comunità di utenti del gruppo mpi/multicore con l'aggiunta di loro opinioni/esigenze.

Carracciuolo sottolinea che è importante avere contributi anche dagli utenti ed auspica una loro viva partecipazione alla stesura del documento.

Gestione e utilizzo dei dati

Un aspetto importante nella gestione dei dati e' la possibilita' di accedere a stdout e stderr durante l'esecuzione del job. Questa funzionalita' e' gia stata aggiunta nel portale (Marco B e Alessandro C.) per una specifica applicazione: ogni ora i dati dell'applicazione vengono copiati su uno Storage Element e pubblicati via https. Occorrera' valutare se la funzionalita' puo' essere estesa in modo trasparente a tutta la VO gridit (o altre).

Stato del portale Siamo in attesa che si completi l'iter burocratico per l'attivazione dell'autenticazione via Idem. La CA-onfine e' in stato avanzato di integrazione.

Stato delle applicazioni

Ora che l'infrastruttura e' pronta le applicazioni devono essere portate al piu' presto, in modo da terminare possibilmente le attivita' entro l'estate. Al momento solo Einstein Toolkit (DePietri) e Nemo (Drudi) sono pronte.

- Partecipazione a Workshop, e congressi.


Coordinate per l'accesso via EVO:

Title:        MPI Multicore
Description:   
Community:    Universe

Meeting Access Information:
- Meeting URL
http://evo.caltech.edu/evoNext/koala.jnlp?meeting=vsvivIeseaIBIlaiavItas

Phone Bridge ID è 536 8640 

Edit | Attach | PDF | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | More topic actions
Topic revision: r13 - 2012-06-07 - VaniaBoccia
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback