Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

Preparing a Compatible Replication Package

Authors
Affiliations
Cornell University
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign

Use a single software application per step

Each step of a SIVACOR submission only supports a single software application (Stata, R, MATLAB/Dynare or Julia — see container images). If your replication package requires multiple applications, you will need to configure separate steps. However, your package itself can include the code for multiple applications, and you can chain them together in a highly simplified workflow system at submission, see instructions in Step 2.

Do not include any data that you are not allowed to upload to third-party systems

While SIVACOR does not publish data or replication packages, and deletes completed jobs after a short period of time, it is not a designated secure computing system.[1] You should not upload controlled data, and all uploads should be compatible with any data use agreement you signed.

If you have data that you are allowed to upload, but not publish, see “Excluding files” on how to exclude files from the final replication package.

Excluding files from final package

The final digitally signed replication package contains all data as originally uploaded. If you need to remove files because you do not have redistribution rights, or large intermediate files, include a file named .sivacorignore (note the leading dot!) at the root of your project to exclude files or directories before package is finalized. This will be logged as part of the TRO.

Your replication package should be portable.

Code must run without manual intervention, use a single controller script (e.g., main.do or master.R) per step, and omit hard-coded absolute paths. File and directory paths are case-sensitive, and should use OS-neutral path separators (/, not \).

All dependencies must either be included or installed automatically.

If your code uses libraries or packages, you must ensure that they are installed automatically (for Stata, we suggest you include them). We strongly encourage packages that use “environments”, and packages to manage dependencies.

Package must be able to fit on the SIVACOR workers

The size available to run your code depends on the software being used, and how you manage files within your replication package. A complete run of your code needs room:

Current SIVACOR nodes have between 23 and 44 GiB free, depending on the software being used.

For more information on the system itself, see Hardware capabilities.

A run is stopped if the worker runs out of disk space, see the FAQ.

If your package cannot be made to fit the free space in the table above, you may be able to ask for extra scratch disk.

Prepare a ZIP or tar.gz file

Your replication package must be a single ZIP file or tar.gz file.

The next step is to upload your package to SIVACOR.

ℹ️ FAQ

See the FAQ.

Footnotes
  1. SIVACOR runs on Jetstream2 infrastructure. The JS2 Acceptable Use and Data Policy apply. SIVACOR’s privacy policy can be found at https://submit.sivacor.org/privacy.

  2. groundhog is another option for managing R package dependencies. However, on Linux, it always recompiles from source, which can take a very long time, and may fail, depending on the system libraries required on the rocker images used here.

  3. The container is kept both compressed and unpacked on the worker’s disk, so it occupies roughly 3.5x what it downloads.