ibisco HPC Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
 ===== Suggerimenti e informazioni fornite da utenti  e commenti/risposte di admin =====

 * ** Output grafico remoto **
 
In generale è possibile l'output in modo grafico  remoto.
Un modo è tramite X11 (https://hpc.nmsu.edu/discovery/software/x11-forwarding/ ) (ovviamente deve essere installato X11 sul server: \\

1. Set the X11 forwarding DISPLAY environmental variable on your Local workstation/Client. \\
Con Linux terminal: \\
<code> $ set DISPLAY=127.0.0.1:0 </code>
Con Windows PowerShell \\
<code> $env:DISPLAY="127.0.0.1:0" </code>

2. Connect via SSH and enable X11-forwarding.
syntax: \\
 <code> ssh -Y | -X username@discovery.nmsu.edu  </code>
(preferibile -X, più sicuro di -Y )

3. Enable OpenGL Remote Acceleration sul server.
 <code> $ export LIBGL_ALWAYS_INDIRECT=1  </code>

4. Fix Font Errors.
 <code> $ export LC_ALL=C </code>

5. Run an Application using X11-forwarding.
es: \\
 <code> $ xclock  </code>

Nota - Permanently Add Display Settings. \\
aggiungere nel proprio .bashrc o .bash_profile
<code># X11-forwarding display settings
if [ -n "$DISPLAY" ]; then
	export LIBGL_ALWAYS_INDIRECT=1
  export LC_ALL=C
fi  </code>


 * ** Informazioni su strumenti di sviluppo pe HPC in ambiente CentOS **
 
I seguenti tool e relative documentazioni valgono per RH/CentOS versione 7.
Per la 8 il sistema è cambiato e si basa su "AppStream" e "moduli" che usano le nuove estensioni del formato RPM.
# Link descrittivo dei RH-SCL:

https://access.redhat.com/documentation/en-us/red_hat_software_collections/3 \\

Esempi di come installare tutto quanto necessario per compilatori gcc e python:

<code>yum install centos-release-scl
yum install devtoolset-11-gcc*
yum install devtoolset-10-gcc*
yum install devtoolset-9-gcc*
yum install rh-python38 rh-python38-numpy rh-python38-scipyrh-python38-python-tools rh-python38-python-six</code>

Nota: verranno installate le ultime sottoversioni disponibili nelle SCL delle versioni richieste.

Esempi di come invocare i vari ambienti di sviluppo: \\
Eseguire un programma nell'ambiente fornito da una data collezione sw (in questo caso il progr. "hello.pl" nell'ambiente perl v. 5.26): \\

<code>scl enable rh-perl526 'perl hello.pl'</code>

Creare una subshell bash in cui sono operativi i tool (in questo caso gcc/g++/gfortran/... v.10 e python v.3.8):

<code>scl enable rh-perl526 'perl hello.pl'</code>

Creare una subshell bash in cui sono operativi i tool (in questo caso gcc/g++/gfortran/... v.10 e python v.3.8):

<code>scl enable devtoolset-10 rh-python38 bash</code>

Rendere operativi i tool (in questo caso gcc/g++/gfortran/... v.10, nella shell corrente):

<code>source scl_source enable devtoolset-10</code>

Nota: quest'ultimo comando, mentre evita l'apertura di una subshell, non può essere disabilitato nella sessione, da cui bisogna uscire.\\
Si esce dalla subshell con il solito comando "exit", ritornando nella shell principale con la configurazione originaria (da sistema) dei tool. \\
Nota: ovviamente, per controllare di essere nell'ambiente giusto, basta verificare la versione del tool operativa al momento, ad es. con i comandi "gcc -V" per gcc e "python -V" per il python

-------------------------------
Log esemplificativo da un sistema CentOS:
<code>$ python -V
Python 2.7.5
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
$ scl enable devtoolset-10 rh-python38 bash
$ python -V
Python 3.8.11
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/opt/rh/devtoolset-10/root/usr/bin/../libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-10/root/usr --mandir=/opt/rh/devtoolset-10/root/usr/share/man --infodir=/opt/rh/devtoolset-10/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --with-default-libstdcxx-abi=gcc4-compatible --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-10.2.1-20210130/obj-x86_64-redhat-linux/isl-install --disable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20210130 (Red Hat 10.2.1-11) (GCC)
$ exit
exit
$ python -V
Python 2.7.5
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
$ source scl_source enable devtoolset-10 rh-python38
$ python -V
Python 3.8.11
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/opt/rh/devtoolset-10/root/usr/bin/../libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-10/root/usr --mandir=/opt/rh/devtoolset-10/root/usr/share/man --infodir=/opt/rh/devtoolset-10/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --with-default-libstdcxx-abi=gcc4-compatible --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-10.2.1-20210130/obj-x86_64-redhat-linux/isl-install --disable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
$ exit
logout</code>

 * ** Discussione tra utente e admin sull'uso di AMBER **

 > Informazioni da utente \\
 
Cari Amministratori cluster IBISCO,
dando seguito a quanto discusso, vi riporto un po' di risultati e considerazioni sui tentativi di compilazione del pacchetto di dinamica molecolare AMBER 20 e del release candidate della versione 22 che dovrebbe essere rilasciata intorno a fine aprile. Per ora, dati i problemi per la parte CUDA, ho limitato le prove alle versioni seriali del pacchetto. \\
La forma breve dei risultati è che per entrambe le versioni di AMBER e usando diversi metodi di compilazione (con o senza cmake, quest'ultimo, in versione 2.8.12.2, da me installato in locale sul cluster e perfettamente funzionante) si riesce a compilare il programma con i compilatori Intel solo per la versione "CPU-only seriale". Nel caso della versione CUDA, emergono (in AMBER 20 in fase di avanzata compilazione, in AMBER 22 già nella fase di configurazione) problemi di funzionalità causati dalla versione <6 (di fatto 4.8) dei compilatori GNU presenti sul sistema. \\
Tali problemi si evidenziano malgrado l'uso dei compilatori Intel, perché questi ultimi fanno comunque affidamento su alcune librerie installate dai compilatori GNU. Il problema CUDA-GNU è riportato sul sito NVIDIA (vedere sotto), dove la soluzione suggerita è quella di cui si era discusso mercoledì, basata sui devtoolset di RH. \\
Ad aggravare il problema, c'è il dato di fatto, corroborato da varie risposte degli sviluppatori sulla mailing list, che i compilatori Intel sono poco o per niente testati in congiunzione con CUDA, perché la componente CPU è marginale in presenza di GPU. Addirittura il RC di AMBER 22 va in errore in fase di configurazione perché processa il compilatore Intel come se fosse GNU, a testimonianza della totale assenza di test prima del rilascio! \\
Pur essendo possibile (in teoria, poi bisogna vedere la pratica, sia in relazione al successo dell'operazione, sia in riferimento al numero di errori che si ottengono nei test del pacchetto...) installare AMBER usando conda o singularity, queste soluzioni, introducendo ulteriori elementi e variabili, possono presentare altri problemi di coesistenza di versioni diverse, coerenza degli aggiornamenti di pacchetti, e, in alcuni casi, di prestazioni, rispetto a soluzioni basate sulla compilazione "tradizionale". \\
Pertanto, essendo la soluzione dei devtoolset particolarmente veloce, semplice e potente per gestire i compilatori gcc, con la possibilità di installare tutte le versioni almeno dalla 6 in poi senza problemi (cosa preziosa per chi abbia bisogno di precise versioni di CUDA, ad esempio), e avendola impiegata su vari sistemi CentOS 7, vi chiedo se non sia possibile adoperarla anche su IBISCO. \\
In appendice alla mail, ho riportato qualche informazione sui devtoolset e una descrizione più dettagliata dei tentativi di installazione di AMBER 20. \\
Per la 22, usando la procedura cmake con la versione cmake da me installata è andato tutto liscio per la versione seriale CPU (a meno di X11 per cui mancano le lib, ma non è un grosso problema), incluso l'ambiente python che creava problemi con la 20. \\
La versione seriale GPU invece si arresta già in fase di configurazione perché non processa bene i compilatori Intel in combinazione con il CUDA (vedi sopra) e, anche intervenendo per bypassare gli errori più marchiani, ne emergono altri che richiedono l'intervento su molti file di configurazione. \\
Per la versione seriale GPU di AMBER 20 compilata con il configure e con meno opzioni installate, invece, sono riuscito ad arrivare (sempre con interventi correttivi per bypassare errori su versioni di compilatori non testati su CUDA) quasi in fondo alla compilazione, ma alla fine (vedi sotto) sono emersi problemi possibilmente sempre legati alla versione vecchia delle librerie associate ai compilatori GNU, a cui si appoggiano sia quelli Intel che CUDA.
Saluti,

---------------------------------
Link descrittivo dei RH-SCL:
https://access.redhat.com/documentation/en-us/red_hat_software_collections/3

Abilitazione dei tool su CentOS 7:
<code>yum install centos-release-scl</code>

Esempi di come installare tutto quanto necessario per compilatori gcc e python:\\

<code>yum install devtoolset-11-gcc*
yum install devtoolset-10-gcc*
yum install devtoolset-9-gcc*
yum install rh-python38 rh-python38-numpy rh-python38-scipyrh-python38-python-tools rh-python38-python-six</code>

Nota: verranno installate le ultime sottoversioni disponibili nelle SCL delle versioni richieste.\\

Esempi di come invocare i vari ambienti di sviluppo: \\
  * Eseguire un programma nell'ambiente fornito da una data collezione sw (in questo caso il progr. "hello.pl" nell'ambiente perl v. 5.26):
<code>scl enable rh-perl526 'perl hello.pl'</code>
  * Creare una subshell bash in cui sono operativi i tool (in questo caso gcc/g++/gfortran/... v.10 e python v.3.8): \\
<code>scl enable devtoolset-10 rh-python38 bash</code>
  * Rendere operativi i tool (in questo caso gcc/g++/gfortran/... v.10, nella shell corrente):\\
<code>source scl_source enable devtoolset-10</code>
Nota: quest'ultimo comando, mentre evita l'apertura di una subshell, non può essere disabilitato nella sessione, da cui bisogna uscire. \\
Si esce dalla subshell con il solito comando "exit", ritornando nella shell principale con la configurazione originaria (da sistema) dei tool. \\
Nota: ovviamente, per controllare di essere nell'ambiente giusto, basta verificare la versione del tool operativa al momento, ad es. con i comandi: "gcc -V" per gcc e "python -V" per il python.

-----------------------------------------------------
PROVE (SEMIFALLITE) DI COMPILAZIONE AMBER 20 SU IBISCO \\
Note: \\
1) per evitare (anche) problemi legati a cmake, ho usato il vecchio metodo di compilazione (.configure ...)\\
2) occorre eseguire gli update (patch) sul frontend e poi collegarsi ai nodi per la compilazione\\
- sui nodi mancano ambiente/librerie per compilare la parte che dipende da X11 (problema non grave)\\
3) l'opzione consigliata di installare python via minconda non funziona (apparentemente, conda ha recentemente cambiato la struttura delle dir e ciò confligge con quella fornita dai tool Intel) (problema potenzialmente più seccante)\\
4) per usare CUDA 11.1 con la versione 2021 dei compilatori Intel, ho dovuto usare l'opzione -allow-unsupported-compiler in nvcc.\\

Risultati:\\
La compilazione della versione "seriale solo CPU" (con il comando "./configure -noX11 --skip-python intel" per i motivi di cui sopra) riesce e gli eseguibili sono corretti (test.serial passati), quella "seriale CUDA" ("./configure -noX11 --skip-python -cuda intel", oppure "./configure -noX11 --skip-python -cuda -openmp intel") fallisce in fase avanzata con il seguente messaggio:\\

<code>icc -Duse_SPFP -ip -O3 -no-prec-div -xHost -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DBINTRAJ -DFFTW_FFT -I/nfsexports/SOFTWARE/intel/oneapi/mkl/2021.1.1/env/../include/fftw -DCUDA -DGTI -I/usr/local/cuda/include -IB40C -c gpu.cpp
In file included from gti_simulationConst.h(6),
from simulationConst.h(6),
from base_gpuContext.h(6),
from gpuContext.h(4),
from gpu.cpp(23):
gti_schedule_functions.h(108): warning #3500: field initializers are a C++11 feature
FunctionType functionType=linear;
^

In file included from gpuContext.h(6),
from gpu.cpp(23):
gti_gpuContext.h(47): error: qualified name is not allowed
std::unique_ptr< GpuBuffer<bool>> pbTLNeedNewNeighborList;
^

In file included from gpuContext.h(6),
from gpu.cpp(23):
gti_gpuContext.h(47): error #77: this declaration has no storage class or type specifier
std::unique_ptr< GpuBuffer<bool>> pbTLNeedNewNeighborList;
^

In file included from gpuContext.h(6),
from gpu.cpp(23):
gti_gpuContext.h(47): error: expected a ";"
std::unique_ptr< GpuBuffer<bool>> pbTLNeedNewNeighborList;
^

In file included from gpuContext.h(6),
from gpu.cpp(23):
gti_gpuContext.h(63): warning #12: parsing restarts here after previous syntax error
std::unique_ptr< GpuBuffer<unsigned long long int>> pbPMEChargeGrid; // Atom charge grid
^

In file included from gpuContext.h(6),
from gpu.cpp(23):
gti_gpuContext.h(64): error: qualified name is not allowed
std::unique_ptr< GpuBuffer<double>> pbOrigAtomCharge; // Atom charge storage
^

In file included from gpuContext.h(6),
from gpu.cpp(23):
gti_gpuContext.h(64): error #77: this declaration has no storage class or type specifier
std::unique_ptr< GpuBuffer<double>> pbOrigAtomCharge; // Atom charge storage
^

In file included from gpuContext.h(6),
from gpu.cpp(23):
gti_gpuContext.h(64): error: expected a ";"
std::unique_ptr< GpuBuffer<double>> pbOrigAtomCharge; // Atom charge storage
^

In file included from gpuContext.h(6),
from gpu.cpp(23):
gti_gpuContext.h(108): warning #12: parsing restarts here after previous syntax error
std::unique_ptr< GpuBuffer<PMEFloat>> pbMBARWeight; // weight values for states
^

In file included from gpuContext.h(6),
from gpu.cpp(23):
gti_gpuContext.h(111): error: qualified name is not allowed
std::unique_ptr< GpuBuffer<unsigned long long int>> pbNumberLJ1264NBEntries;
^

In file included from gpuContext.h(6),
from gpu.cpp(23):
gti_gpuContext.h(111): error #77: this declaration has no storage class or type specifier
std::unique_ptr< GpuBuffer<unsigned long long int>> pbNumberLJ1264NBEntries;
^

In file included from gpuContext.h(6),
from gpu.cpp(23):
gti_gpuContext.h(111): error: expected a ";"
std::unique_ptr< GpuBuffer<unsigned long long int>> pbNumberLJ1264NBEntries;
^

In file included from gpuContext.h(6),
from gpu.cpp(23):
gti_gpuContext.h(117): warning #12: parsing restarts here after previous syntax error
void CleanUp();
^

compilation aborted for gpu.cpp (code 2)
make[5]: *** [gpu.o] Error 2
make[5]: Leaving directory `/lustre/home/<utente>/sw/amber20_src/src/pmemd/src/cuda'
make[4]: *** [cuda_spfp_libs] Error 2
make[4]: Leaving directory `/lustre/home/<utente>/sw/amber20_src/src/pmemd/src'
make[3]: *** [cuda_SPFP] Error 2
make[3]: Leaving directory `/lustre/home/<utente>/sw/amber20_src/src/pmemd/src'
make[2]: *** [cuda_serial] Error 2
make[2]: Leaving directory `/lustre/home/<utente>/sw/amber20_src/src/pmemd'
make[1]: *** [cuda_serial] Error 2
make[1]: Leaving directory `/lustre/home/<utente>/sw/amber20_src/src'
make: *** [amber] Error 2</code>

La cosa è riportata nella mailing list di AMBER ed è imputata a idiosincrasie tra Intel e CUDA, per le quali suggeriscono di compilare con i compilatori GNU, visto che il beneficio degli Intel è tra l'altro irrilevante per un programma che lavora quasi completamente in GPU.\\

Ovviamente, stiamo parlando di versioni recenti dei compilatori GNU, visto che CUDA 11.1 e successive hanno bisogno di gcc >=6. Gli sviluppatori di CUDA suggeriscono l'uso dei devtoolset per i compilatori GNU su CentOS o simili: \\
"(2) Note that starting with CUDA 11.0, the minimum recommended GCC compiler is at least GCC 6 due to C++11 requirements in CUDA libraries e.g. cuFFT and CUB. On distributions such as RHEL 7 or CentOS 7 that may use an older GCC toolchain by default, it is recommended to use a newer GCC toolchain with CUDA 11.0. Newer GCC toolchains are available with the Red Hat Developer Toolset. For platforms that ship a compiler version older than GCC 6 by default, linking to static cuBLAS and cuDNN using the default compiler is not supported."
(fonte: https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html) \\

 > risposta/commento da admin \\
 
abbiamo provveduto ad installare i seguenti pacchetti devtools: devtoolset-9, devtoolset-10, devtoolset-11.\\

Abbiamo evitato l'installazione dei pacchetti python38* dal momento che il python versione 3.8, oltre che i pacchetti numpy e scipy, sono già dispobibile sotto ambiente conda: per usarli, e dopo l'esecuzione uscire dalle shell conda e devtools, si esegua ad esempio\\

<code>scl enable devtoolset-10 bash
source /nfsexports/SOFTWARE/anaconda3.OK/setupconda.sh
.....
conda deactivate
exit</code>

 > risposta di utente \\
 
Grazie mille,

vi farò sapere i risultati delle prove di AMBER e altri sw che sto provando a installare. Anche la scelta di non installare python come devtool (che avevo riportato solo come esempio) mi pare saggia, perché di installazioni python ce ne sono già troppe in giro e conda, che era nato per fare sostanzialmente quello, lo gestisce davvero bene.\\

Nel frattempo, ho provato a installare AMBER 20 sotto conda, creando un apposito ambiente. \\

Purtroppo stavo eseguendo prove durante lo spostamento di conda di stanotte, quindi ho avuto un po' di confusione nell'ambiente. Ora pare sia tutto a posto e sono riuscito a compilare AMBER 20 in conda con i compilatori GNU (dopo downgrade dei compilatori alla versione 10.3, rispetto alla 11.2 installata d'ufficio da conda, per motivi di compatibilità con CUDA 11). Ai primi test, le versioni "seriale" e "seriale + CUDA + OPENMP" funzionano senza problemi. Ora proverò a lanciare job in batch e poi passerò alle versioni parallele.\\

In ogni caso, sebbene con conda le cose pare stiano cominciando a funzionare, sono lieto di avere i compilatori devtools sia perché è più semplice (anche) fare prove con diverse versioni e combinazioni di compilatori e librerie accessorie, sia perché, comunque, conda "soffre" di alcuni bug persistenti (ogni tanto va in crisi sulle verifiche di conflitti) e della versione datata di glibc installata di sistema.\\

----------------------------
[[wiki:startdoc| Inizio/ Start]]\\
ibisco HPC Wiki

User Tools

Site Tools

Page Tools
