began to write articles

followed https://docs.github.com/en/free-pro-team@latest/github/working-with-github-pages/creating-a-github-pages-site-with-jekyll to setup github pages

.gitignore

@@ -0,0 +1,6 @@
+_site
+.sass-cache
+.jekyll-cache
+.jekyll-metadata
+vendor
+.DS_Store

404.html

@@ -0,0 +1,25 @@
+---
+permalink: /404.html
+layout: default
+---
+
+<style type="text/css" media="screen">
+  .container {
+    margin: 10px auto;
+    max-width: 600px;
+    text-align: center;
+  }
+  h1 {
+    margin: 30px 0;
+    font-size: 4em;
+    line-height: 1;
+    letter-spacing: -1px;
+  }
+</style>
+
+<div class="container">
+  <h1>404</h1>
+
+  <p><strong>Page not found :(</strong></p>
+  <p>The requested page could not be found.</p>
+</div>

Gemfile

@@ -0,0 +1,30 @@
+source "https://rubygems.org"
+# Hello! This is where you manage which Jekyll version is used to run.
+# When you want to use a different version, change it below, save the
+# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
+#
+#     bundle exec jekyll serve
+#
+# This will help ensure the proper Jekyll version is running.
+# Happy Jekylling!
+gem "jekyll", "~> 4.2.0"
+# This is the default theme for new Jekyll sites. You may change this to anything you like.
+gem "minima", "~> 2.5"
+# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
+# uncomment the line below. To upgrade, run `bundle update github-pages`.
+# gem "github-pages", group: :jekyll_plugins
+# If you have any plugins, put them here!
+group :jekyll_plugins do
+  gem "jekyll-feed", "~> 0.12"
+end
+
+# Windows and JRuby does not include zoneinfo files, so bundle the tzinfo-data gem
+# and associated library.
+platforms :mingw, :x64_mingw, :mswin, :jruby do
+  gem "tzinfo", "~> 1.2"
+  gem "tzinfo-data"
+end
+
+# Performance-booster for watching directories on Windows
+gem "wdm", "~> 0.1.1", :platforms => [:mingw, :x64_mingw, :mswin]
+gem "just-the-docs"

Gemfile.lock

@@ -0,0 +1,86 @@
+GEM
+  remote: https://rubygems.org/
+  specs:
+    addressable (2.7.0)
+      public_suffix (>= 2.0.2, < 5.0)
+    colorator (1.1.0)
+    concurrent-ruby (1.1.7)
+    em-websocket (0.5.2)
+      eventmachine (>= 0.12.9)
+      http_parser.rb (~> 0.6.0)
+    eventmachine (1.2.7)
+    ffi (1.14.2)
+    forwardable-extended (2.6.0)
+    http_parser.rb (0.6.0)
+    i18n (1.8.7)
+      concurrent-ruby (~> 1.0)
+    jekyll (4.2.0)
+      addressable (~> 2.4)
+      colorator (~> 1.0)
+      em-websocket (~> 0.5)
+      i18n (~> 1.0)
+      jekyll-sass-converter (~> 2.0)
+      jekyll-watch (~> 2.0)
+      kramdown (~> 2.3)
+      kramdown-parser-gfm (~> 1.0)
+      liquid (~> 4.0)
+      mercenary (~> 0.4.0)
+      pathutil (~> 0.9)
+      rouge (~> 3.0)
+      safe_yaml (~> 1.0)
+      terminal-table (~> 2.0)
+    jekyll-feed (0.15.1)
+      jekyll (>= 3.7, < 5.0)
+    jekyll-sass-converter (2.1.0)
+      sassc (> 2.0.1, < 3.0)
+    jekyll-seo-tag (2.7.1)
+      jekyll (>= 3.8, < 5.0)
+    jekyll-watch (2.2.1)
+      listen (~> 3.0)
+    just-the-docs (0.3.3)
+      jekyll (>= 3.8.5)
+      jekyll-seo-tag (~> 2.0)
+      rake (>= 12.3.1, < 13.1.0)
+    kramdown (2.3.0)
+      rexml
+    kramdown-parser-gfm (1.1.0)
+      kramdown (~> 2.0)
+    liquid (4.0.3)
+    listen (3.4.0)
+      rb-fsevent (~> 0.10, >= 0.10.3)
+      rb-inotify (~> 0.9, >= 0.9.10)
+    mercenary (0.4.0)
+    minima (2.5.1)
+      jekyll (>= 3.5, < 5.0)
+      jekyll-feed (~> 0.9)
+      jekyll-seo-tag (~> 2.1)
+    pathutil (0.16.2)
+      forwardable-extended (~> 2.6)
+    public_suffix (4.0.6)
+    rake (12.3.2)
+    rb-fsevent (0.10.4)
+    rb-inotify (0.10.1)
+      ffi (~> 1.0)
+    rexml (3.2.4)
+    rouge (3.26.0)
+    safe_yaml (1.0.5)
+    sassc (2.4.0)
+      ffi (~> 1.9)
+    terminal-table (2.0.0)
+      unicode-display_width (~> 1.1, >= 1.1.1)
+    unicode-display_width (1.7.0)
+
+PLATFORMS
+  universal-darwin-20
+
+DEPENDENCIES
+  jekyll (~> 4.2.0)
+  jekyll-feed (~> 0.12)
+  just-the-docs
+  minima (~> 2.5)
+  tzinfo (~> 1.2)
+  tzinfo-data
+  wdm (~> 0.1.1)
+
+BUNDLED WITH
+   2.2.4

_config.yml

@@ -0,0 +1,57 @@
+# Welcome to Jekyll!
+#
+# This config file is meant for settings that affect your whole blog, values
+# which you are expected to set up once and rarely edit after that. If you find
+# yourself editing this file very often, consider using Jekyll's data files
+# feature for the data you need to update frequently.
+#
+# For technical reasons, this file is *NOT* reloaded automatically when you use
+# 'bundle exec jekyll serve'. If you change this file, please restart the server process.
+#
+# If you need help with YAML syntax, here are some quick references for you: 
+# https://learn-the-web.algonquindesign.ca/topics/markdown-yaml-cheat-sheet/#yaml
+# https://learnxinyminutes.com/docs/yaml/
+#
+# Site settings
+# These are used to personalize your new site. If you look in the HTML files,
+# you will see them accessed via {{ site.title }}, {{ site.email }}, and so on.
+# You can create any custom variable you would like, and they will be accessible
+# in the templates via {{ site.myvariable }}.
+
+title: PennSIVE
+email: [email protected]
+description: >- # this means to ignore newlines until "baseurl:"
+  Write an awesome description for your new site here. You can edit this
+  line in _config.yml. It will appear in your document head meta (for
+  Google search results) and in your feed.xml site description.
+baseurl: "" # the subpath of your site, e.g. /blog
+url: "" # the base hostname & protocol for your site, e.g. http://example.com
+twitter_username: jekyllrb
+github_username:  jekyll
+
+# Build settings
+theme: just-the-docs
+remote_theme: just-the-docs
+color_scheme: dark
+plugins:
+  - jekyll-feed
+
+# Exclude from processing.
+# The following items will not be processed, by default.
+# Any item listed under the `exclude:` key here will be automatically added to
+# the internal "default list".
+#
+# Excluded items can be processed by explicitly listing the directories or
+# their entries' file path in the `include:` list.
+#
+# exclude:
+#   - .sass-cache/
+#   - .jekyll-cache/
+#   - gemfiles/
+#   - Gemfile
+#   - Gemfile.lock
+#   - node_modules/
+#   - vendor/bundle/
+#   - vendor/cache/
+#   - vendor/gems/
+#   - vendor/ruby/

_posts/2021-01-09-welcome-to-jekyll.markdown

@@ -0,0 +1,29 @@
+---
+layout: post
+title:  "Welcome to Jekyll!"
+date:   2021-01-09 14:55:50 -0500
+categories: jekyll update
+---
+You’ll find this post in your `_posts` directory. Go ahead and edit it and re-build the site to see your changes. You can rebuild the site in many different ways, but the most common way is to run `jekyll serve`, which launches a web server and auto-regenerates your site when a file is updated.
+
+Jekyll requires blog post files to be named according to the following format:
+
+`YEAR-MONTH-DAY-title.MARKUP`
+
+Where `YEAR` is a four-digit number, `MONTH` and `DAY` are both two-digit numbers, and `MARKUP` is the file extension representing the format used in the file. After that, include the necessary front matter. Take a look at the source for this post to get an idea about how it works.
+
+Jekyll also offers powerful support for code snippets:
+
+{% highlight ruby %}
+def print_hi(name)
+  puts "Hi, #{name}"
+end
+print_hi('Tom')
+#=> prints 'Hi, Tom' to STDOUT.
+{% endhighlight %}
+
+Check out the [Jekyll docs][jekyll-docs] for more info on how to get the most out of Jekyll. File all bugs/feature requests at [Jekyll’s GitHub repo][jekyll-gh]. If you have questions, you can ask them on [Jekyll Talk][jekyll-talk].
+
+[jekyll-docs]: https://jekyllrb.com/docs/home
+[jekyll-gh]:   https://github.com/jekyll/jekyll
+[jekyll-talk]: https://talk.jekyllrb.com/

index.markdown

@@ -0,0 +1,8 @@
+---
+# Feel free to add content and custom Front Matter to this file.
+# To modify the layout, see https://jekyllrb.com/docs/themes/#overriding-theme-defaults
+
+layout: home
+---
+# Welcome to the Penn Statistics in Imaging and Visualization Endeavor (PennSIVE) Center
+This is the internal website for PennSIVE procedures, tutorials, and practices.

organization.markdown

@@ -0,0 +1,58 @@
+---
+layout: page
+title: Project organization
+permalink: /bids/
+---
+
+# BIDS
+When labs organize datasets in different ways time is often wasted rewriting scripts to expect a particular structure. BIDS solves this problem by standardizing the organization of neuroimaging data. BIDS is nothing more than a prescribed directory structure and file naming convention, but it allows labs to more easily share datasets and processing pipelines, interact with the dataset programmatically via pybids, and run all the most popular neuroimaging tools ("BIDS Apps") in a consistent way.
+
+Although it's possible to manually organize NIFTIs into the BIDS structure, doing so is error-prone and inefficient. Manual organization may be the only option if dicoms aren't available, but otherwise you can use heudiconv to automatically format the produced NIFTIs according to BIDS.
+
+Unlike `dcm2niix` which can simply be fed a directory of dicoms, heudiconv requires a bit more setup. First, your dicoms be organized either by StudyUID or accession_number. Then, you need to run heudiconv with the `-c none -f convertall` options to generate TSVs with dicom metadata needed to write a heuristic. Generally, the protocol_name will be the most (only?) useful field, and is used in the heuristic to determine which dicoms go together to create a NIFTI.
+
+For example,
+```
+heudiconv \
+-d "/path/to/data/{subject}/{session}/*.dcm" \
+    -o /path/to/output -f convertall -s 001 -ss abc -c none -b -g accession_number
+# there will now be a hidden .heudiconv directory with dicom header TSVs
+# once you've determined which dicoms go where, write a heuristic then use the -c dcm2niix option to tell heudiconv to do the actual dcm2niix conversion
+heudiconv \
+-d "/path/to/data/{subject}/{session}/*.dcm" \
+    -o /path/to/output -f /path/to/your_heuristic.py -s 001 -ss abc -c dcm2niix -b -g accession_number
+```
+
+Beyond organizing data with BIDS, [datalad](/reproducibility) provides good recommendations for organizing code. The [YODA](https://handbook.datalad.org/en/latest/basics/101-127-yoda.html) procedure will initialize your project with this directory structure:
+```
+├── CHANGELOG.md
+├── README.md
+└── code
+    └── README.md
+```
+A more comprehensive directory structure might look like this:
+```
+├── ci/                         # continuous integration configuration
+│   └── .travis.yml
+├── code/                       # your code
+│   ├── tests/                  # unit tests to test your code
+│   │   └── test_myscript.py
+│   └── myscript.py
+├── docs                        # documentation about the project
+│   ├── build/
+│   └── source/
+├── envs                        # computational environments
+│   └── Singularity
+├── inputs/                     # dedicated inputs/, will not be changed by an analysis
+│   └─── data/
+│       ├── dataset1/           # one stand-alone data component
+│       │   └── datafile_a
+│       └── dataset2/
+│           └── datafile_a
+├── outputs/                    # outputs away from the input data
+│   └── important_results/
+│       └── figures/
+├── CHANGELOG.md                # notes for fellow humans about your project
+├── HOWTO.md
+└── README.md
+```

reproducability.markdown

@@ -0,0 +1,24 @@
+---
+layout: page
+title: Reproducibility standards
+permalink: /reproducibility/
+---
+
+# How to write a reproducible paper
+Containers help ensure computational reproducibility, but it can be all for nothing if there are issues with data provenance. Datalad uses git (annex) to version control data and provides tools to monitor the changes processing pipelines make.
+
+Datalad can be install with `conda create -c conda-forge -n datalad datalad git-annex`, then enabled with `source activate datalad`. To create a new datalad repository, run `datalad create -c yoda repository_name`. `-c yoda` is (an optional but highly recommend) datalad procedure that initializes your repository with a standardized file structure.
+
+To version control data, run `datalad save -r -m "commit message"`. This will move your files into the "git annex" and replace them with symlinks from the annex. This keeps your data safe so if you accidentally `rm something`, you can restore it with `git checkout -- something`. Using `datalad save` is useful when setting a project up or making manual hotfixes, but most of the time files will be created or modified by scripts you write. Although it is possible to run your scripts then save the results with `datalad save` afterwords, running your code through the `datalad run` wrapper is preferred because it automatically checks to make sure inputs are available, unlocks and saves outputs, as well as commit the command line used to do the processing. For example, instead of
+```
+datalad unlock my_inputs
+./my_script.sh my_inputs my_outputs
+datalad save -r -m "ran my script" my_outputs
+```
+do
+```
+datalad run -m "ran my script" -i my_inputs -o my_outputs ./my_script.sh "{inputs}" "{outputs}"
+```
+Once you've run your analysis with datalad run, make sure your results are reproducible by running `datalad rerun`. Code can be unreproducible in very non-obvious ways (for example, the default way of setting a seed won't work in R if your code is multithreaded), so running twice is the only way to make sure your analysis is reproducible. 
+
+For more information, the [datalad handbook](http://handbook.datalad.org/en/latest/index.html) is an excellent resource.

setup.markdown

@@ -0,0 +1,51 @@
+---
+layout: page
+title: Setting up your environment
+permalink: /setup/
+nav_order: 1
+---
+# Setting up your environment
+Neuroimaging software can be difficult to install and have complex dependencies. If any tool has a different version or is configured differently, results can become impossible to reproduce. Containers are like lightweight VMs that turns your environment into code so it can be shared, version controlled, and reproduced on any machine that supports a container runtime. On platforms where you have root access (like your computer), docker is the most convenient container runtime, but Singularity is a good alternative for rootless containers in cluster environments. 
+
+There are some general purpose container images you can pull to do experimenting, but new projects with public results should create a project-specific container by writing a Dockerfile. NeuroDocker automates much of this process,
+```
+docker run --rm repronim/neurodocker:0.7.0 generate docker \
+    --pkg-manager apt \
+    --base debian:buster \
+    --ants version=2.3.1 \
+    --fsl version=6.0.3
+```
+which will write a Dockerfile to stdout (you can pipe directly into `docker build`) but any software they don't support has to be installed in that or another Dockerfile.
+
+## Local development
+Running a container with docker follows the format: `docker run [options for docker] image_name [payload process arguments]`. For example,
+```
+docker run -it -v $PWD:/data -w /data --rm pennsive/neuror:4.0 R -e "list.files()"
+```
+will run the pennsive/neuror container interactively (`-it`), setting up a bind mount (`-v`), setting the working directory for the payload process to that bind mount (`-w`), and remove the container after completion (`--rm`).
+
+## Development on the cluster
+The PMACS cluster is generally more amicable to interactive work while CUBIC is generally better for large batch and GPU jobs. Singularity is installed on both clusters, but on PMACS it's installed as an environment module so you need to run `module load DEV/singularity` first.
+
+Singularity commands have different semantics than docker commands, but also follow the general format `singularity run [options for singularity] image_name [payload process arguments]`. The singularity equivalent of `-it` is `singularity shell` (instead of `singularity run`), instead of `-v` it's `-B`, instead of `-w` it's `--pwd`. Additionally, singularity by default does less to isolate the container than docker does, so you'll likely always need the `--cleanenv` or `--containall` flags to prevent host environment variables from overwriting those in the container. 
+
+### PMACS
+PMACS uses the LSF platform, which uses `bsub` to submit jobs. To submit an interactive job, run `bsub -Is -q "$QUEUE"_interactive 'bash';`. To run a non-interactive job, run `bsub -o /path/to/stdout -e /path/to/stderr ./my_job.sh`
+
+### CUBIC
+CUBIC uses the SGE platform, which uses `qsub` to submit jobs. There are no interactive compute nodes, but the login nodes are fairly beefy. To run a non-interactive job, run `qsub -o /path/to/stdout -e /path/to/stderr -b y -cwd -l h_vmem=16G -pe threaded 4-8 ./my_job.sh`. `-b y` tells SGE you're running a binary executable, `-cwd` makes the directory you issue the command from the working directory for the job, `-l h_vmem=16G` sets memory (default is only 4G!), and `-pe threaded 4-8` gives your job anywhere from 4-8 CPU cores depending on what the scheduler decides.
+
+## GUIs
+[coming soon...]
+
+## Text editors
+Generally, a text editor like VS Code or Atom provides the best user experience. However, R Studio images are available for local and remote development. Locally, you can start the R Studio server with
+```
+docker run --rm -d -e PORT=9090 -v $HOME:/data -w /data -p 80:9090 pennsive/rstudio:4.0
+```
+which will make R Studio available at [http://localhost:80](http://localhost).
+On the cluster, you must first login with the `-L` option to create a ssh tunnel for the http traffic, then specify the port you tunneled when running the container
+```
+ssh -L12345:127.0.0.1:12345 user@cluster
+SINGULARITYENV_PORT=12345 singularity run --cleanenv -B $TMPDIR:/var/run/rstudio-server /project/singularity_images/rstudio_4.0.sif
+```