FNAL Computing

Crash course in FNAL computing

• Need a kerberos ticket to access Fermilab machines.

kinit <username>@FNAL.GOV

• Need to renew each day-ish (or whenever things randomly stop working).

• Need something ala

Host * 
    ForwardAgent yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes
    ForwardX11 yes
    ForwardX11Trusted yes
		
    ControlMaster auto
    ControlPath ~/.ssh/open_%r@%h:%p__%l
    ControlPersist 3h
    ServerAliveInterval 60

in your .ssh/config file.

• 4 general purpose machines (sbndgpvm01-04) - 4 cores, 12GB RAM

• 2 build machines (sbndbuild01-02) - should only really be used for compiling code - 16 cores, 64GB RAM

e.g. ssh <username>@sbndgpvm01.fnal.gov

• Some minimal storage available in your user home directory - don't use this..

• Mount areas - make a directory with your name in the user directory and stick to it.

  • /sbnd/app - General purpose area. Used for running code etc. This is where you'd keep e.g. VALOR and Larsoft repositories. Avoid storing large data files.
  • /sbnd/data - Mainly used for storing data files.
  • /pnfs/persistent - Permanent dCache storage (i.e. Grid has access to this).
  • /pnfs/scratch - Large temporary (~2 weeks, NOT guaranteed) dCache storage. Idea is to direct grid output here and once you decide to keep it, move to persistent storage. Personally am usually too lazy to deal with this..
  • /pnfs/resilient - Should only be used to store tarballs which are used on the grid.
  • (Also have tape storage. Lots of space, but can take a long time to access - need to 'stage' files etc. Probably don't need to be familiar with this.)

• /sbnd/xxx has user quotas (~100GB on app and ~1TB on data). No user specific quotas on /pnfs/xxx but people will start asking questions if you're using unreasonable amounts.

Not Fermilab specific, but very useful/essential

VNC

Graphical displays (GUI's) are unusably slow with ssh -X -Y - using a VNC makes this bearable. (See here for setup https://sbnsoftware.github.io/sbndcode_wiki/Viewing_events_remotely_with_VNC.html)

Text Editors

• As above GUI's aren't exactly an option - use an in terminal editor (e.g. vim - not (new) user friendly, but many features. EMACS or nano + many more options probably available too).
• Using a GUI in the VNC might be okay?
• Write code locally and copy to gpvm (can probably do something clever to avoid constant manual copying). This is likely a terrible idea..

tmux (or screen)

Creates a terminal "session" on the remote machine which means you can log off (or get forcibly disconnected) from the remote machine and then pick up where you left off later (+ much more e.g. split screen, many terminal tabs in a single window). Takes some getting used to and configuration can be a bit of a rabbit hole, but probably worth it.