Commit 6b628ab8 authored by Brandon's avatar Brandon

remove trailing whitespace

parent 0a2f6299
# BerkeleyGW
The BerkeleyGW Package is a set of computer codes that calculates the quasiparticle
properties and the optical responses of a large variety of materials from bulk periodic
The BerkeleyGW Package is a set of computer codes that calculates the quasiparticle
properties and the optical responses of a large variety of materials from bulk periodic
crystals to nanostructures such as slabs, wires and molecules. The package takes as
input the mean-field results from various electronic structure codes such as the
input the mean-field results from various electronic structure codes such as the
Kohn-Sham DFT eigenvalues and eigenvectors computed with Quantum ESPRESSO, PARATEC,
PARSEC, Octopus, Abinit, Siesta etc.
......
......@@ -70,7 +70,7 @@ Here are examples of a full image name:
Using the Intel compiler tools requires a license. The NERSC license server can
be used to support this, but the NERSC License server is reserved for NERSC users and
is not publicly accessible.
is not publicly accessible.
- The “devel” docker images require a valid Intel license to use the
compilers
......
......@@ -65,7 +65,7 @@ group elvis. It is readable and writable by the owner, but is not accessible
to any other user.
```
-rwx------ 2 elvis elvis 12040 Apr 9 2012 a.out
-rwx------ 2 elvis elvis 12040 Apr 9 2012 a.out
```
This is a normal file named "a.out", owned by user elvis and associated with
......
......@@ -78,7 +78,7 @@ Multiple sruns can be executed one after another in a single batch script. Be su
## Running Multiple Parallel Jobs Simultaneously
Multiple sruns can be executed simultaneously in a single batch script. Be sure to specify the total number of nodes needed to run all jobs at the same time. By default, multiple concurrent srun executions cannot share compute nodes under Slurm in the non-shared QOSs.
Multiple sruns can be executed simultaneously in a single batch script. Be sure to specify the total number of nodes needed to run all jobs at the same time. By default, multiple concurrent srun executions cannot share compute nodes under Slurm in the non-shared QOSs.
In the following example, a total of 192 cores are required, which would hypothetically fit on 192 / 32 = 6 Haswell nodes. However, because sruns cannot share nodes by default, we instead have to dedicate 2 nodes to the first execution (44 cores), 4 to the second (108 cores), and again 2 to the third (40 cores). For all three executables, the node is not fully packed, and number of MPI tasks per node is not a divisor of 64, so both -c and --cpu_bind flags are used in srun commands.
......@@ -188,9 +188,9 @@ $$
## Variable-time jobs
The variable-time jobs are for the users who wish to get a better queue turnaround or need to run long running jobs, including jobs longer than 48 hours, the max wall-clock time allowed on Cori and Edison. The variable-time jobs are the jobs submitted with the minimum and maximum time limits. Jobs specifying the minimum time can start execution earlier than otherwise with a time limit anywhere between the minimum and maximum time limits. The pre-terminated jobs are automatically requeued to resume from where the previous executions left off, until the cumulative execution time reaches the requested maximum time limit or the job completes before the requested time limit. The variable-time jobs enable users to run jobs with any length, e.g., one week or even longer. Note that to use the variable-time jobs applications are required to be able to checkpoint/restart by themselves.
The variable-time jobs are for the users who wish to get a better queue turnaround or need to run long running jobs, including jobs longer than 48 hours, the max wall-clock time allowed on Cori and Edison. The variable-time jobs are the jobs submitted with the minimum and maximum time limits. Jobs specifying the minimum time can start execution earlier than otherwise with a time limit anywhere between the minimum and maximum time limits. The pre-terminated jobs are automatically requeued to resume from where the previous executions left off, until the cumulative execution time reaches the requested maximum time limit or the job completes before the requested time limit. The variable-time jobs enable users to run jobs with any length, e.g., one week or even longer. Note that to use the variable-time jobs applications are required to be able to checkpoint/restart by themselves.
In the following example, the --comment option is used to request the user desired maximum time limit, which could be longer than maximum time limit allowed by the batch system. In addition to the time limit (--time option), the --time-min option is used to request the minimum amount of time the job should run. The variable ckpt_overhead is used to specify the amount of time (in seconds) needed for checkpointing. The --signal=B:USR1@<sig-time> option is used to send signal USR1 to the job within sig-time seconds of its end time to terminate the job after checkpointing. The sig-time should match the checkpoint overhead time, ckpt_overhead. The ata module defines the bash functions used in the scripti, and users may need to modify the scripts (get a copy) for their use.
In the following example, the --comment option is used to request the user desired maximum time limit, which could be longer than maximum time limit allowed by the batch system. In addition to the time limit (--time option), the --time-min option is used to request the minimum amount of time the job should run. The variable ckpt_overhead is used to specify the amount of time (in seconds) needed for checkpointing. The --signal=B:USR1@<sig-time> option is used to send signal USR1 to the job within sig-time seconds of its end time to terminate the job after checkpointing. The sig-time should match the checkpoint overhead time, ckpt_overhead. The ata module defines the bash functions used in the scripti, and users may need to modify the scripts (get a copy) for their use.
??? example "Edison"
```bash
......
......@@ -33,7 +33,7 @@ projectb "Scratch" and "Sandbox" space is intended for staging and running JGI c
The Sandbox areas were allocated by program. If you have questions about your program's space, please see your group lead. New Sandbox space must be allocated with JGI management approval.
###DnA (Data n' Archive)
DnA is a 1PB GPFS based file system for the JGI's archive, shared databases and project directories.
DnA is a 1PB GPFS based file system for the JGI's archive, shared databases and project directories.
| |DnA Projects|DnA Shared|DnA DM Archive|
|---|---|---|---|
......@@ -42,7 +42,7 @@ DnA is a 1PB GPFS based file system for the JGI's archive, shared databases and
|Backups|Daily, only for projectdirs with quota <= 5TB|Backed up by JAMO|Backed up by JAMO|
|Files are not automatically purged|Files are not automatically purged|Purge policy set by users of the JAMO system|Files are not automatically purged|
The intention of the DnA "Project" and "Shared" space is to be a place for data that is needed by multiple people collaborating on a project to allow for easy access for data sharing. The "Project" space is owned and managed by the JGI. The "Shared" space is a collaborative effort between the JGI and NERSC.
The intention of the DnA "Project" and "Shared" space is to be a place for data that is needed by multiple people collaborating on a project to allow for easy access for data sharing. The "Project" space is owned and managed by the JGI. The "Shared" space is a collaborative effort between the JGI and NERSC.
If you would like a project directory, please use the [Project Directory Request Form](https://www.nersc.gov/users/storage-and-file-systems/file-systems/project-directory-request-form/).
......@@ -60,7 +60,7 @@ Scratch environment variables:
\$BSCRATCH|/global/projectb/scratch/$username|Denovo only|
\$CSCRATCH|/global/cscratch[1,2,3]/sd/$username|Cori and Edison|
\$BSCRATCH points to your projectb scratch space if you have a BSCRATCH allocation. \$SCRATCH will always point to the best-connected scratch space available for the NERSC machine you are accessing. For example, on Denovo \$SCRATCH will point to \$BSCRATCH, whereas on Cori \$SCRATCH will point to \$CSCRATCH.
\$BSCRATCH points to your projectb scratch space if you have a BSCRATCH allocation. \$SCRATCH will always point to the best-connected scratch space available for the NERSC machine you are accessing. For example, on Denovo \$SCRATCH will point to \$BSCRATCH, whereas on Cori \$SCRATCH will point to \$CSCRATCH.
The intention of scratch space is for staging, running, and completing your calculations on NERSC systems. Thus these filesystems are designed to allow wide-scale file reading and writing from many compute nodes. The scratch filesystems are not intended for long-term file storage or archival, and thus data is not backed-up, and files not accessed for 90 days will be automatically purged.
......
......@@ -9,7 +9,7 @@ NOT modify the .bashrc or .cshrc files. These are set to read-only on NERSC
systems and specify system specific customizations.
Instead you should modify a file called .bashrc.ext or .cshrc.ext.
## Environment Variables
## Environment Variables
- `$HOME`
points to the location of your home directory in the filesystem
......@@ -65,7 +65,7 @@ modules:
## Tips and Best Practices
If you are considering manually encoding a path with `/global/common/` or `/usr/common/` into your software or into
you environment, please use the module instead (ie module load <package>). There are multiple paths to the software
installed in this location, and the proper way to access it depends on your current context.
installed in this location, and the proper way to access it depends on your current context.
If you need to refer to a path in the module, use **[MODULENAME]_DIR** environment variable. You can see all the
settings of a module by entering: `module show <modulename>`.
......@@ -73,7 +73,7 @@ settings of a module by entering: `module show <modulename>`.
Loading modules can have additional effects. The Genepool modules are
interconnected to ease the loading of dependencies. Frequently, when you load
a module, swap a module, or remove modules other modules may be loaded, swapped,
or removed.
or removed.
### Working with Modules for Production-Level Batch Scripts
When writing a batch script which you may share with another genepool user,
......@@ -109,7 +109,7 @@ to non-reproducible calculations.
For common tasks in an interactive environment it can be convenient to load
certain modules by default for all interactive sessions. If this is needed,
the recommended mechanism is to embed the module commands into your
.bashrc.ext or .tcshrc.ext (depending on if you are a bash or tcsh user).
.bashrc.ext or .tcshrc.ext (depending on if you are a bash or tcsh user).
Each NERSC system has different modules, for this reason, but your dotfiles
are evaluated by all systems. Thus, you should check to make sure that
`$NERSC_HOST` is `genepool`, when loading genepool modules.
......@@ -132,7 +132,7 @@ fi
if ($NERSC_HOST == "genepool") then
# make user-specific changes to PATH
setenv PATH $HOME/scripts:$PATH
# then load modules
module load blast+
endif
......@@ -146,7 +146,7 @@ be incorrect and you may experience unexpected side effects.
It is recommended to make any manual modifications to `PATH`,
`LD_LIBRARY_PATH`, and others earlier in the dotfiles than the module commands.
### Using Modules in Cron Jobs
### Using Modules in Cron Jobs
The cron environment on genepool does not have a complete environment setup.
In particular important environment variables like `$SCRATCH`, `$HOME`,
`$BSCRATCH`, `$NERSC_HOST` may not be setup.
......@@ -157,7 +157,7 @@ For a simple job this can be done like:
```sh
# crontab
07 04 * * * bash -l -c "module load python; python /path/to/myScript.py"
```
```
If you need a more extensive environment setup, you can simply put the entire
cronjob into a script, and call the script from your crontab.
......@@ -190,14 +190,14 @@ list of arguments, like `'load','<modulename>'`; or `'unload','<modulename>'`.
```python
import EnvironmentModules as EnvMod
EnvMod.module(['load', 'blast+'])
```
```
It is important to understand that this is most effective for scripts which
execute other code (e.g. from the subprocess package of python), and not
necessarily for loading additional packages for python to use. This is
because the python process is already running and changing its environment
won't necessarily give expected results. For example, changes to `PYTHONPATH`
and `LD_LIBRARY_PATH` are not immediately accepted. `LD_LIBRARY_PATH` is
only evaluated at process start-up time, and won't be re-evaluated later.
only evaluated at process start-up time, and won't be re-evaluated later.
Thus if you load any python packages which rely on dynamically linked C-code,
you should load those modules before python (oracle_client, for example).
......@@ -260,7 +260,7 @@ before you can access `EnvironmentModules.pm`.
#!/usr/bin/env perl
use EnvironmentModules;
module("load blast+");
```
```
Please note that the similar to python, loading modules which manipulate
`LD_LIBRARY_PATH` or `PERL5DIR` will not work as expected. It is generally
......@@ -275,7 +275,7 @@ will only work if your users are using the bash shell:
### DO NOT DO THIS!
system("module load blast+"; blastn ");
```
When you call `system()`, perl forks it as `/bin/sh -c '<your command'>`.
When you call `system()`, perl forks it as `/bin/sh -c '<your command'>`.
`/bin/sh` does not get a new module environment loaded, so, the instance of
`/bin/sh` will be relying on the shell operating perl to get the module
functionality. It turns out that the module functionality provided by bash
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment