Instalando Aplicações
É bastante comum que o usuário iniciante tente fazer uma instalação em seu /home/ do GridUnesp da mesma forma que faz no computador pessoal. Contudo, num computador pessoal o usuário geralmente tem a senha de root e consegue instalar programas na raiz do sistema (locais como /usr/, /lib/).
No GridUnesp, todavia, o usuário não tem privilégio de root. Então, ao tentar fazer instalações (como se root fosse), recebe uma mensagem de erro
... permission denied ...
Mas isso não significa que não possa ter as aplicações/bibliotecas instaladas no cluster.
Instalação feita pelo próprio usuário
Muitas aplicações científicas, softwares e bibliotecas podem ser instaladas em locais diferentes, como no /home/ do usuário. Basta fazer as devidas configurações durante a instalação.
Instalando no home
Na maioria dos casos, as instalações podem ser feitas indicando o local em que deseja que binários, libs, headears etc. sejam guardados, bastando informar parâmetros como --prefix=.
Vamos supor que um usuário chamado Spock (cujo login no GridUnesp é spock) queira instar uma aplicação ficticia chamada Enterprise na pasta /home/spock/application/enterprise e que a instalação permita usar o parâmetro --prefix= com o comando configure. O início da instalação então seria realizado com um comando similar a
./configure --prefix=/home/spock/application/enterprise
Naturalmente, este é apenas um caso hipotético. Cada aplicação possui suas peculiaridades, devendo o usuário observar com cuidado as instruções da documentação do programa de interesse. Estes cuidados se referem inclusive às variáveis de ambiente que se deve configurar após a instalação.
Instalação via comandos Conda
Algumas aplicações/bibliotecas podem ser facilmente instaladas usando o ambiente Anaconda.
Digamos que um usário chamado Spock, cujo username seja spock, queira instalar os pacotes Python e numpy para um trabalho que escolheu chamar de startrek. Para isso, primeiramente deverá criar um ambiente Conda usando os comandos abaixo:
module load miniconda/24.4.0-libmamba
conda create -n startrek
Aqui, miniconda/24.4.0-libmamba é o nome do módulo que carrega o ambiente Conda (já instalado no cluster) e que contém os comandos necessários. Módulos miniconda são mais leves que módulos anaconda. Por sua vez, o nome dado ao projeto (startrek) pode ser qualquer um que usuário achar conveniente. É recomendável escolher um que seja de fácil percepção para lembrança futura.
Em seguida, o usuário deve ativar o ambiente criado usando o comando:
source activate startrek
o que fará aparecer na tela algo como
(startrek) [spock@access2 ~]$
Agora, para instalar as aplicações desejados, Spock daria os comandos
conda install python=3.10.4
conda install numpy
Ao utilizar python=3.10.4, o usuário informa a versão exata que deseja instalar. Caso não informe a versão, será instalada a versão mais recente presente no repositório/canal. Importante observar que os pacotes instalados ficam restritos ao projeto/ambiente criado (startrek, no exemplo).
Para listar todos os pacotes, o comando é
conda list
Para listar todos os projetos criados (tal qual o startrek), o comando é
conda info --envs
Para desativar o ambiente, o comando é
source deactivate startrek
Por fim, toda vez que o usário desejar utilizar os pacotes instalados naquele ambiente, basta dar os comandos
module load miniconda/24.4.0-libmamba
source activate startrek
Para mais informações sobre como trabalhar num ambiente Conda, consulte a documentação do Anaconda.
Instalação feita pelo administrador do sistema
Há casos em que a instalação é demasiada complexa, ou que há o desejo de que aplicação/biblioteca seja disponibilizada para vários usuários. Neste caso, basta informar à equipe de especialistas do GridUnesp (support.ncc@unesp.br) a aplicação/biblioteca de interesse, bem como o link do site de referência contendo informações sobre ela.
Importante
Por vezes, a equipe do GridUnesp poderá sugerir que a instalação seja realizada no próprio /home/ do usuário. Tudo vai depender das características da aplicação/biblioteca em questão. Como exemplo, é bastante recomendado que instalações com versões muito específicas dos pacotes sejam feitas pelo usuário em seu proprío /home/. Por outro lado, àquelas que podem ser úteis para uma quantidade maior de usuários (de um mesmo grupo, que seja) seria mais adequada a instalação via módulo.
O GridUnesp utiliza um sistema modular de carregamento de ambiente. Esse sistema permite que sejam disponibilizadas diversas versões de compiladores, bibliotacas e aplicações que, de outra forma, seriam incompatíveis. Uma vez que tenha feito login no GridUnesp, para verificar quais aplicações estão instaladas no cluster, bastar usar o seguinte comando no terminal:
module avail
Irá aparecer na tela algo como
----------------------------------------- /opt/gridunesp/modules ------------------------------------------
allpathslg/44837(default) gcc/10.2.0 openmpi/4.1.5
amber/20(default) gdal/2.4.1 openmpi/4.1.6
anaconda2/5.1.0 ginac/1.7.2(default) openmpi/4.1.6.v2
anaconda3/4.4.0(default) glibc/2.29(default) orca/4.0.1(default)
backmap/0.5(default) gmt/5.4.3(default) orca/4.2.1
beagle/2.1.2(default) grace/5.1.25(default) orca/5.0.3
beagle/4.0.0 gridunesp/1(default) orca/5.0.4
beast/1.8.4 gromacs/4.5.4 orca/6.0.0
beast/1.10.4 gromacs/4.5.4-sbm1.0 orca/6.0.1
beast/2.4.7(default) gromacs/5.1.4 partitionfinder/2.1.1(default)
boost/1.64.0(default) gromacs/2016.3(default) pfinderuce-swsc-en/1.0.0(default)
boost/1.70.0 gromacs/2018.2 phyluce/1.5.0(default)
bowtie2/2.3.5.1(default) gsl/2.6(default) platanus/1.2.4(default)
busco/5.5.0(default) hmmer/3.1b2(default) plumed/2.7.1(default)
charmm/c26b2 intel/compilers/2017(default) quantum-espresso/6.1(default)
charmm/c26b2-serial intel/mpi/2017(default) quantum-espresso/6.6
charmm/c37b2(default) java/1.8(default) quantum-espresso/7.2
charmm/c37b2-serial kraken2/2.1.3(default) quest-qmc/1.4.9(default)
cln/1.3.4(default) lammps/20170331 R/4.0.2(default)
clustalw-mpi/0.13(default) lammps/20180316 raxml-ng/1.0.3(default)
clustalw/2.1(default) lammps/20200303(default) raxml/8.2.11(default)
cmake/3.9.0(default) lammps/20230802 rnxcmp/4.0.7(default)
cmake/3.20.0-rc3 mathematica/9.0 root/6.10.02(default)
cp2k/2023.1(default) mathematica/10.4(default) rsem/1.2.25(default)
crystal/17_v1.0.2 matlab/R2016b-9.1 salmon/0.14.0(default)
crystal/17_v1.0.2_v2(default) matlab/R2019b(default) sga/0.10.15(default)
dftbplus/20.2.1(default) migrate-n/5.0.6(default) siesta/4.0.2
dirac/12.3-mpi(default) miniconda/3(default) siesta/4.1-b3(default)
dirac/12.3-serial miniconda/3-2023-09 siesta/4.1.5.mpi
dirac/12.3-smp miniconda/24.4.0-libmamba siesta/4.1.5.serial
eems/0.0.0(default) mkl/2022.2.0(default) siesta/5.2.0.mpi
espresso/3.3.1(default) mopac/17.162(default) siesta/5.2.0.serial
evigene/23jul15(default) namd/2.12(default) spades/3.15.5(default)
exabayes/1.5(default) namd/2.12-tcp stacks/2.4(default)
exciting/carbon(default) namd/2.13-smp structure/2.3.4(default)
exciting/neon-21 namd/2.13-tcp su2/6.0.0(default)
fastStructure/1.0(default) netcdf/c/4.6.3(default) su2/6.2.0
fhi/071914(default) netcdf/fortran/4.4.5(default) swan/41.31-mpi
foam-extend/4.0(default) openfoam/4.1 swan/41.31-omp
foam-extend/4.1 openfoam/5.x(default) swan/41.31-serial(default)
g_mmpbsa/gromacs-5.1 openfoam/7 tesseract/4.00.00alpha(default)
gamess/2018(default) openfoam/8 trinity/2.8.5(default)
gamess/2020 openfoam/1912 trinity/2.15.1
gamit/10.61 openfoam/2012 udunits2/2.2.26
gamit/10.70(default) openfoam/2112 vasp/6.4.3(default)
gaussian/09(default) openmpi/2.1.1(default) vcftools/0.1.16(default)
gaussian/09.lsm openmpi/3.1.4 weka/3.8.2(default)
gcc/5.3.0 openmpi/4.0.1 xtb/6.6.1(default)
gcc/7.2.0(default) openmpi/4.1.1
gcc/9.3.0 openmpi/4.1.1.v2
Supondo que o usuário queira carregar o ambiente (as variáveis de ambiente) do módulo gcc/10.2.0, bastar usar o comando
module load gcc/10.2.0
Digamos que o usuário tenha carregado os módulos gcc/10.2.0 e boost/1.70.0, mas não lembre quais eram. O comando abaixo irá listar todos os módulos ativos:
module list
Como resultado, irá aparecer na tela o seguinte resultado:
Currently Loaded Modulefiles:
1) gridunesp/1(default) 2) gcc/10.2.0 3) boost/1.70.0
Por padrão, o módulo gridunesp/1 é carregado assim que o usuário faz login no cluster. Este módulo serve para habilitar os scripts para submissão de simulações (jobs).
Para desfazer, ou seja, para remover as variáveis de ambiente do módulo carregado, e considerando os exemplos acima, os comandos seriam
module unload gcc/10.2.0
module unload boost/1.70.0
Importante
O cluster do GridUnesp não funciona com Ubuntu, como se poderia supor. Anteriormente, o cluster era baseado em Linux com distribuição CentOS. Atualmente ele funciona com a distribuição AlmaLinux, o qual apresenta compatibilidade 1 para 1 com CentOS. Isso significa que todos os comandos que eram usados para CentOS funcionam igualmente para AlmaLinux. Além disso, caso, em situações bastante excepcionais, seja necessário a equipe do GridUnesp fazer instalações na raiz do sistema, seria utilizado o comando yum install (em vez do apt-get install do Ubuntu).
A seção Aplicações instaladas traz a lista das várias aplicações/bibliotecas instaladas via módulo, bem como exemplos simples de scripts de submissão para cada uma delas.
Resumo dos comandos de módulo
Listando módulos disponíveis
module avail
Carregando um módulo
module load intel/compilers/2017
Listando os módulos carregados
module list
Desativando um módulo
module unload intel/compilers/2017