| Both sides previous revision Previous revision Next revision | Previous revision |
| technical:recipes:vasp-6-darwin [2021-02-15 15:17] – frey | technical:recipes:vasp-6-darwin [2021-02-16 10:00] (current) – [Runtime environment] anita |
|---|
| ====== Building VASP 6 on Caviness/DARWIN ====== | ====== Building VASP 6 on Caviness/DARWIN ====== |
| |
| Over the years the VASP build system has changed significantly. In version 6 the use of the ''makefile.include'' to encapsulate machine-specific options has improved the portability and reproducibility of the build procedures. | Over the years the VASP build system has changed significantly. In version 6, the use of the ''makefile.include'' to encapsulate machine-specific options has improved the portability and reproducibility of the build procedures. |
| |
| The build procedure outlined herein uses Open MPI on top of the Intel compiler suite in conjunction with CUDA 11 with the target executable destined for use on Volta- and Turing-generation NVIDIA devices. | The build procedure outlined herein uses Open MPI on top of the Intel compiler suite in conjunction with CUDA 11 with the target executable destined for use on Volta- and Turing-generation NVIDIA devices. |
| ==== Build Environment ==== | ==== Build Environment ==== |
| |
| The ''makefile.include'' above includes comments that reference the VALET commands used to configure the build (and runtime) environment for the copy of VASP being built. Two package must be added; in case you have already added packages to your login shell environment, first rollback to a clean environment: | The ''makefile.include'' above includes comments that reference the VALET commands used to configure the build (and runtime) environment for the copy of VASP being built. Two packages must be added; in case you have already added packages to your login shell environment, first rollback to a clean environment: |
| <code bash> | <code bash> |
| [user@login00.darwin src]$ vpkg_rollback all | [user@login00.darwin src]$ vpkg_rollback all |
| </code> | </code> |
| |
| The ''--backup=numbered'' ensures that if executables already exist in the install location, they will be renamed with a numbered file extension rather than being simply replaced by the new copy. If, for some reason, the old executable needs to be restored, the backup can be renamed to effect that change. | The ''%%--%%backup=numbered'' option ensures that if executables already exist in the install location, they will be renamed with a numbered file extension rather than being simply replaced by the new copy. If, for some reason, the old executable needs to be restored, the backup can be renamed to effect that change. |
| |
| The ''-C'' option checks if the source and destination files differ, and only performs the copy operation if they do. | The ''-C'' option checks if the source and destination files differ, and only performs the copy operation if they do. |
| [user@login00.darwin ~]$ VALET_PKG_DIR=~/.valet ; VALET_PKG_DIR_MODE=0700 | [user@login00.darwin ~]$ VALET_PKG_DIR=~/.valet ; VALET_PKG_DIR_MODE=0700 |
| </code> | </code> |
| versus an installation made for an entire workgroup, which would store package definition files in ''$WORKDIR/sw/valet'' | versus an installation made for an entire workgroup, which would store the VALET package definition files in ''$WORKDIR/sw/valet'' |
| <code bash> | <code bash> |
| [user@login00.darwin ~]$ VALET_PKG_DIR="$WORKDIR/sw/valet" ; VALET_PKG_DIR_MODE=2770 | [user@login00.darwin ~]$ VALET_PKG_DIR="$WORKDIR/sw/valet" ; VALET_PKG_DIR_MODE=2770 |
| |
| It is a good idea to specify which version definition should act as the default. This yields the following package definition file | It is a good idea to specify which version definition should act as the default. This yields the following package definition file |
| <file vasp.vpkg_yaml> | |
| | <file yaml vasp.vpkg_yaml> |
| vasp: | vasp: |
| prefix: /home/user/sw/vasp | prefix: /home/user/sw/vasp |
| - cuda/11.1.1 | - cuda/11.1.1 |
| </file> | </file> |
| | |
| saved at ''$VALET_PKG_DIR/vasp.vpkg_yaml''. | saved at ''$VALET_PKG_DIR/vasp.vpkg_yaml''. |
| |
| ==== Checking the definition file ==== | ==== Checking the definition file ==== |
| |
| The package definition file can be syntax-checked: | The package definition file can be checked for proper syntax using the VALET command ''vpkg_check'': |
| <code bash> | <code bash> |
| [user@login00.darwin ~]$ vpkg_check "$VALET_PKG_DIR/vasp.vpkg_yaml" | [user@login00.darwin ~]$ vpkg_check "$VALET_PKG_DIR/vasp.vpkg_yaml" |
| ~/sw/vasp/6.1.0/bin/vasp_std | ~/sw/vasp/6.1.0/bin/vasp_std |
| </code> | </code> |
| The ''vasp_std'' command is used //without a leading path// which implies that the shell with check directories in the ''$PATH'' environment variable for an executable with that name. If a different version/variant of **vasp** is chosen, the command would still be ''vasp_std'' but the shell would find it at a different location. This abstraction (no full paths to executables) makes it easier to alter complex job scripts by simply changing which variant is added using ''vpkg_require''. | The ''vasp_std'' command is used //without a leading path// which implies that the shell will check directories in the ''$PATH'' environment variable for an executable with that name. If a different version/variant of **vasp** is chosen, the command would still be ''vasp_std'' but the shell would find it at a different location. This abstraction (no full paths to executables) makes it easier to alter complex job scripts by simply changing the variant of **vasp** added using ''vpkg_require''. |
| |
| |