--- name: sivacor-submission description: Guide a researcher through submitting a replication package to SIVACOR (https://submit.sivacor.org) for automated, certified verification — preparing a portable ZIP/tar.gz with all dependencies, uploading it, choosing the software image and main file, monitoring the run, and downloading the signed Replicated Package. Use when someone mentions SIVACOR, TRACE certification, or a Trusted Research Object (TRO), or asks how to get a Stata, R, MATLAB/Dynare or Julia replication package verified before submitting to a journal. --- # Submitting a replication package to SIVACOR SIVACOR (Scalable Infrastructure for Validation of Computational Social Science Research) runs a researcher's replication package unattended in a curated container, and returns a digitally signed **Replicated Package** — the original materials, the outputs the code produced, and the TRACE files (TRO Declaration, TRS Signature, Trusted Timestamp) that prove the run happened on SIVACOR. The signed package can be handed to a journal's data editor in place of a manual verification. This file is generated automatically from the user guide at https://docs.sivacor.org (built 2026-09-24) and is the whole submission workflow in one place. The website has the same text with screenshots, plus an [FAQ](https://docs.sivacor.org/docs/faq), a [debugging guide](https://docs.sivacor.org/docs/debugging) and the [list of available software images](https://docs.sivacor.org/docs/images). ## What SIVACOR will and will not run Read this before advising anything. SIVACOR recognises **four** families of container image, and infers how to run the main file from the image, **never from the file's extension**: | Software | Images | How the main file is run | |---|---|---| | R | `rocker/*` | `R --no-save --no-restore -f MAIN_FILE` | | Stata | `dataeditors/stata*` | `stata-mp -b do MAIN_FILE` | | MATLAB / Dynare | `dynare/dynare` | `matlab -batch MAIN_FILE` (the `.m` is stripped for you) | | Julia | `ghcr.io/sivacor/julia*` | `julia --startup-file=no --project=@. MAIN_FILE` | **There is no Python image, and no way to run a `.py` file as a main file.** The Stata `*-i-python` images embed Python for use *from* Stata; they are still run by Stata. Anything outside the four families above is refused at submission. Do not invent images, tags or stacks — only the curated list at https://docs.sivacor.org/docs/images is accepted, and the form refuses the rest. ## How to use this skill When helping a researcher, work through the five steps below in order. Most problems come from Step 0: the package must be portable, run without any human interaction, install its own dependencies, use a single software application per step, and fit the disk. Check those before anything else. The steps are: 0. Preparing a compatible replication package 1. Uploading the package to SIVACOR 2. Choosing software and running jobs 3. Monitoring job status 4. Downloading results ### Checking a package before it is submitted If the package is available locally, inspect it rather than asking the researcher to self-report. A run takes minutes and only one may be in flight at a time, so each of these is worth more than a failed attempt: - **Absolute paths and working-directory changes.** Search for `setwd(`, `cd "/`, `C:\`, `/Users/`, `/home/`, `global root` and similar. Paths must be relative and use `/`. - **The main file exists, exactly once, with that exact case.** SIVACOR searches the whole package for the name you give it. Zero matches and more than one match both fail the run — see "[Identify the main file](#step2-choosing-image)". - **Dependencies bootstrap themselves.** `renv::restore()`, a `Pkg.instantiate()` setup stage, or `ssc install`/`net install` lines for Stata. Nothing may wait for a human. - **No `CRAN` mirror is pinned** in R packages — the `rocker` images already define one. - **Interactive calls.** `View()`, `browser()`, `readline()`, `pause`, `input(`, `keyboard` all hang a container that has no terminal. - **Size.** Compare the unpacked package plus everything the code writes against the free-space figure for the chosen image in "[Package must be able to fit](#step0-prepare)". The image is unpacked onto the same disk. - **Files that must not be redistributed**, which belong in `.sivacorignore`. Then offer a workflow definition file the researcher can import instead of filling in the form — the `stages:` YAML documented under "[Optional chained runs](#chained-runs-steps)". The text uses [MyST](https://mystmd.org) Markdown: blocks fenced by `:::{hint}`, `:::{warning}`, `:::{important}` and similar are call-outs. A `::::{tab-set}` holds one `::::{tab-item} R`-style block per software stack; **they are alternatives, not steps** — read only the one matching the package in front of you, and do not carry advice from one tab into another. ## Preparing a Compatible Replication Package ### 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](https://docs.sivacor.org/docs/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](#chained-runs-steps). ::::{admonition} Additional information The single-application requirement means you cannot call one application from another (e.g., call R from Stata). If your code iterates frequently between applications, for instance in a loop, it is also not recommended to use this system. It can, however, be used when a small number of actions are needed in one software application, with the bulk in a main application. For instance, if you use Stata for data preparation, but R for all remaining analysis. :::: ### 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.[^data] You should not upload *controlled* data, and all uploads should be compatible with any data use agreement you signed. [^data]: SIVACOR runs on [Jetstream2](https://jetstream-cloud.org/) infrastructure. The [JS2 Acceptable Use and Data Policy](https://docs.jetstream-cloud.org/general/policies/#acceptable-use-of-jetstream2) apply. SIVACOR's privacy policy can be found at . If you have data that you are allowed to upload, but not publish, see "[Excluding files](#excluding-files-from-final-package)" 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](https://transparency-certified.github.io/trace-specification/docs/elements.html#transparency-certified-research-objects-tro). :::{important} Pruning happens **after your code has run**, as the last step before the package is signed. So an ignored file is still there while your code runs — which is the point: you can read restricted input data during the run and still keep it out of the package you hand over. It also means `.sivacorignore` cannot change anything about *how* the run behaves, such as which file is picked when [the main file name is ambiguous](#step2-choosing-image). ::: :::{admonition} Example file and usage The `.sivacorignore` file follows the same pattern rules as [`.gitignore`](https://git-scm.com/docs/gitignore), so you can use [glob patterns](https://en.wikipedia.org/wiki/Glob_%28programming%29), negations, and directory-specific rules. For example, to exclude a `data/raw/` directory and all `.tmp` files, the `.sivacorignore` file would look like this: ``` data/raw/ *.tmp ``` Your replication package then should look somewhat like this: ``` data/raw/ file1.csv code/ main.R ... .sivacorignore ``` before it is run, and might look like this ``` code/ main.R output/ figure.png ... .sivacorignore ``` after the run (note removal of `data/raw`). ::: ### 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 `\`). :::{seealso} For some guidance on constructing a portable replication package, see [Steps 1-3](https://aeadataeditor.github.io/aea-de-guidance/preparing-replication-package.html#step-1-main-file) at the AEA Data Editor's website. ::: ### 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. ::::::{seealso} Details :::::{tab-set} ::::{tab-item} R Possible approaches include [`renv`](https://rstudio.github.io/renv/) or [`packrat`](https://rstudio.github.io/packrat/).[^groundhog] You can also include code at the top of your main R script to install any required packages that are not already installed. All code necessary to manage dependencies must be part of the replication package, and must run unattended. For instance, if using `renv`, include the `.Rprofile` and ensure that `renv::restore()` is called at the start of your main R script. [^groundhog]: [`groundhog`](https://cran.r-project.org/web/packages/groundhog/index.html) 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. :::{warning} Do not define a `CRAN` archive (e.g., `https://cloud.r-project.org`) in your replication package. It is generally much more efficient to leverage the `CRAN` mirror defined naturally within the `rocker` images. ::: :::: ::::{tab-item} Stata Guidance for portable dependencies for Stata is provided [at Step 3](https://aeadataeditor.github.io/aea-de-guidance/preparing-replication-package.html#step-3-dependencies) of the AEA Data Editor's guidance. See also the World Bank's [`repado`](https://worldbank.github.io/repkit/reference/repado.html). Note that even when you include Stata packages, you should provide the script that originally installed them, to demonstrate provenance. :::: ::::{tab-item} Julia Include a `Project.toml` and `Manifest.toml`. Declare your dependencies in a `Project.toml`. The `Manifest.toml`, if present, will ensure that the code will install and use the same versions. Without it, `Project.toml` will install latest versions of the dependencies. Both can be generated by "activating" your project, and then interactively adding your dependencies: ```julia julia --project=. julia> ] # enter the package REPL (YourProject) pkg> add DataFrames CSV GLM ``` When running, include a `setup.jl` as your first workflow step (suggested), or include it in your main file: ```{code} julia :filename: setup.jl using Pkg Pkg.instantiate() ``` Alternatively, use an `install.jl` to programmatically install your dependencies. ```julia julia --project=. julia> include("install.jl") ``` where ```{code} julia :filename: install.jl # Install project dependencies using Pkg Pkg.add("DataFrames") Pkg.add("CSV") Pkg.add("GLM") ``` Include `Project.toml` and `Manifest.toml`, as well as `setup.jl` or `install.jl` if present, next to your main file, or at the top of your package. :::: ::::: :::::: :::{admonition} Minimal sample code - Sample code for Stata (any version), Scenario B: - Sample code for Stata (any version), Scenario A (`main.do` in a non-root directory): - Sample code for R (set up for R 4.3.1, tested on R 4.5.1): - Sample code for MATLAB with and without use of Dynare: (both use the same `dynare/dynare` container). - Sample code for Julia (any version): ::: ### 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: - the operating system - the statistical software you use - multiple copies of your replication package: - the ZIP file you upload - the workspace it is extracted into - anything your code writes Current SIVACOR nodes have between **23 and 44 GiB** free, depending on the software being used. ::::{admonition} Additional information This instance of SIVACOR launches a virtual machine for each run. Its disk is advertised as 60 GB; once formatted the filesystem measures **58 GiB**, which is the figure every number below is in. Of that, about **12.7 GiB** is the operating system, Docker and the SIVACOR harness. Roughly **45 GiB** are available before the analysis software is added. Software sizes differ a great deal, and the software is unpacked onto the same disk your package lives on. The table below lists what is left for your package after each one. See [Available Software](https://docs.sivacor.org/docs/images) for the full, curated list. | Software | Image | Download size | Space it occupies* | Free space for your package* | |---|---|---:|---:|---:| | R | rocker/verse:4.6.1 | 1.6 GiB | 5.6 GiB | 39.7 GiB | | R | rocker/geospatial:4.6.1 | 1.6 GiB | 5.7 GiB | 39.6 GiB | | MATLAB | dynare/dynare:6.5-R2025b | 6.3 GiB | 22.1 GiB | 23.2 GiB | | Stata | dataeditors/stata19_5-mp-i-python:2026-08-12 | 0.9 GiB | 3.1 GiB | 42.2 GiB | | Stata | dataeditors/stata19-mp:2026-08-12 | 0.5 GiB | 1.8 GiB | 43.5 GiB | | Julia | ghcr.io/sivacor/julia1.13:1.13.0-20260916 | 0.3 GiB | 1.2 GiB | 44.1 GiB | \* Estimated from the compressed download size.[^downloadsize] [^downloadsize]: The container is kept **both** compressed and unpacked on the worker's disk, so it occupies roughly **3.5x** what it downloads. :::{important} **If your analysis uses MATLAB/Dynare, pay particular attention to the `dynare` entry.** Images provided by the Dynare project are large, typically over 22 GiB. This leaves less than 24 GiB for the package and everything it writes. If you run into problems, see how to request [extra scratch disk](#scratch-disk). ::: :::: For more information on the system itself, see [Hardware capabilities](https://docs.sivacor.org/docs/system#hardware-capabilities). A run is stopped if the worker runs out of disk space, see the [FAQ](https://docs.sivacor.org/docs/faq#my-job-failed-saying-it-ran-out-of-disk-space). 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](#scratch-disk). ### Prepare a ZIP or tar.gz file Your replication package must be a single ZIP file or tar.gz file. :::{note} You may find [this checklist](https://aeadataeditor.github.io/aea-de-guidance/preparing-replication-package.html#checklist) on the AEA Data Editor's site useful. ::: The next step is to [upload your package to SIVACOR](#step1-upload). ### ℹ️ FAQ See the [FAQ](https://docs.sivacor.org/docs/faq#preparing-a-package). ## Uploading Packages to SIVACOR ### Logging In The main submission site is . SIVACOR uses institutional logins via [Globus](https://globus.org/). ::::{tab-set} :::{tab-item} Globus Login Click on the "Login with Globus" button. You can search for your institution, or use one of the other login methods. You will be redirected to your institution's login page. After entering your credentials, you will be redirected back to SIVACOR. ::: :::: ### Uploading a Package Once logged in, you will see the upload page. Upload the replication package (`ZIP` or `tar.gz` files). You can either click to choose a file, or drag it onto the upload area. A single archive may be at most **5 GB**, and each user may store up to **10 GB** on SIVACOR at any one time. :::{hint} If you picked the wrong file, click `Delete Uploaded File` and upload the correct one. The upload area reappears once the file has been removed. ::: Until an upload has finished, `Run Replication Workflow` at the bottom of the page stays grey and says why. It goes grey again if you delete the uploaded file, so a run can never be started against a file that is half-uploaded or no longer there. ### ℹ️ FAQ See the [FAQ](https://docs.sivacor.org/docs/faq#types-of-archives) if you experience difficulty uploading. ## Choosing Software and Running Jobs If the upload was successful, scroll down. ### Choose software and version Choose first the software and version from the curated list (see [container images](https://docs.sivacor.org/docs/images)). You can also select an image tag (sub version), but generally, the latest version should work. :::{attention} If you need a different image, please contact us. ::: ### Identify the main file Identify the name of the main file. This is the file that will be executed by SIVACOR. Include the extension (`.R`, `.do`, `.jl`). :::{warning} Please be sure to use the proper case (`main.do` is not the same as `Main.do`) and include the extension. ::: The file does not have to sit at the top of your package: SIVACOR searches the whole package for that name, and runs it from the directory it was found in. :::{warning} For the same reason, the name must be **unique within the package**. If `main.R` exists in both `code/` and `code/archive/`, SIVACOR cannot tell which one you meant and the run fails before it starts, listing every copy it found. Rename or remove the extra copies in the archive you upload. `.sivacorignore` does **not** help here: it is applied after your code has run, to decide what goes into the final package, so an ignored file is still present and still ambiguous when the main file is resolved. ::: :::{tip} If your code needs packages, we suggest adding a setup step as the first part, and using a separate setup script, see [Step 0](#dependencies). Setup scripts typically require the network to be enabled, thus [**network isolation**](#network-isolation) should be disabled *for that step* — and left on for the analysis step that follows. ::: :::{hint} About alternate extensions Some software have multiple ways they can be invoked. For instance, you might use a RMarkdown file (`.Rmd`) instead of a plain R script (`.R`), or a Jupyter notebook (`.ipynb`) instead of a plain script. SIVACOR executes code using methods defined for each software, **not by extension**: an R image always runs your main file through R, a Stata image always through Stata. Naming a `.Rmd` or an `.ipynb` as the main file therefore does not work on its own — you need a **wrapper script**, in the image's own language, that your main file points to. To render an RMarkdown document, the main file would be an ordinary `.R` script: ```{code} R :filename: main.R # Render RMarkdown # Assert that rmarkdown is available if (!requireNamespace("rmarkdown", quietly = TRUE)) { stop("rmarkdown package is required but not installed") } rmarkdown::render("main.Rmd") ``` A Jupyter notebook can be driven the same way, from a script in whichever of the supported languages the notebook's kernel uses. Note also that many of these "fancier" methods require numerous additional packages just to handle the wrapper. For instance, to render a Jupyter notebook, 31 additional packages must be installed solely to render it. For RMarkdown, 12 additional packages are necessary. ::: ### Network isolation Each step carries a **Net Isolation** toggle, beside that step's image and main file. It is **off by default**, and it is per step, not per submission: one step may be isolated and the next not. When it is on, the container has **no network access at all** for the whole of that step. Nothing can be downloaded, no API can be called, and no result can depend on something fetched at run time. :::{important} **Isolation is part of what the signature certifies.** A step run with Net Isolation on records an `InternetIsolation` attribute in the signed TRO declaration — evidence to a data editor that the result could not have come from anywhere but the materials you uploaded. A step run without it records no such attribute, and nothing in the certificate claims otherwise. ::: This is the reason to split dependency installation into its own step. Install packages in a first step with isolation **off**, then run the analysis in a second step with isolation **on**: the analysis — the part being certified — is then isolated, even though the package downloads were not. See [Step 0](#dependencies). ### Optional chained runs (steps) You can chain multiple runs together, by selecting the `+ ADD STEP` button. The runs will be run in separate containers. Each run inherits the workspace modified by the previous run, so the output of one run will be made available as input to the next run. :::{admonition} Advanced configuration of steps If you need to repeatedly run similar jobs on SIVACOR, you can describe the steps in a file and import it instead of filling in the form. Expand **Optional: Import workflow definition** at the top of the submission form, then choose or drag in a `YAML` or `JSON` file (any file name, up to 256 KB). The file is checked before anything is filled in, and you will be told which step is at fault if something is wrong — for example if an image or tag is not one of the [curated images](https://docs.sivacor.org/docs/images). Importing replaces whatever is currently in the form, so you can always review and adjust the steps before running. A finished run offers the matching `Workflow definition` download, so the easiest way to get a valid file is to run once, download it, and reuse it afterwards. Expected configuration: ```yaml stages: - image_name: dataeditors/stata15 image_tag: "2023-01-27" main_file: main_step1.do network_isolation: true - image_name: rocker/tidyverse image_tag: "4.6.1" main_file: main_step2.R network_isolation: false env_secrets: - key: API_TOKEN value: s3cret ``` `image_name`, `image_tag` and `main_file` are required for every step; `network_isolation`, `env_secrets` and `resources` are optional. A file with no `resources` block leaves the [machine size](#worker-size) as chosen on the form: ```yaml resources: memory_gb: 60 stages: - image_name: rocker/tidyverse image_tag: "4.6.1" main_file: main.R ``` `memory_gb` must be one of the sizes in the [machine size](#worker-size) table. A file naming a size that is no longer offered is refused rather than quietly run on a different machine, and the message names the sizes that are available. `resources` may also carry `disk_gb`, for [extra scratch disk](#scratch-disk) — but only if your own account has an allowance for it. A downloaded `Workflow definition` carries the figure the run was granted, so a file that came from somebody else may ask for more than you can have; the import is then refused and names your limit. A run that used no extra disk has no `disk_gb` line at all. :::{danger} Secrets imported from a file are placed in the form and sent with the submission, but they are never stored in your browser, and they are never included in a downloaded `Workflow definition`. If you share a workflow file that you wrote by hand, remember to remove any `env_secrets` from it first. ::: ### Advanced settings Several advanced parameters are in a dropdown menu. :::{important} Each setting applies to the **whole** submission. ::: - [**Worker Size**](#worker-size): the type of machine your submission runs on - [**Extra Scratch Disk**](#scratch-disk): a temporary disk in addition to the machine's own disk space - [**Environment Secrets**](#environment-secrets): values passed to your code as environment variables. #### Choose the machine size Under **Advanced**, **Worker Size** sets the machine your submission runs on. It applies to the whole submission: every step runs on the same machine. | Size | Cores | Available to your analysis | Disk | Relative cost | |---|---:|---:|---:|---| | 30 GiB | 8 | ≈28 GiB | 60 GB | 1× | | 60 GiB | 16 | ≈58 GiB | 60 GB | 2× | | 125 GiB | 32 | ≈123 GiB | 60 GB | 4× — by request | | 250 GiB | 64 | ≈248 GiB | 60 GB | 8× — by request | **Submissions default to the smallest size.** Only request more if you know that you need more. The output from a run shows what your last run actually used, as a share of what it was allowed. :::{admonition} Where to find run statistics A finished run reports its **peak memory** and **peak disk** use on the submission page, beside the download links, as a share of what the machine allowed. Those two figures are what to size the *next* run on: a run that peaked at 40 % of a 30 GiB machine has no reason to ask for 60 GiB. ::: :::{important} Important points to consider: - **Disk does not grow with the size.** Every size has the same 60 GB primary disk, shared between your package and the software image. If you have run out of *disk*, a bigger machine will not help: ask for [extra scratch disk](#scratch-disk) instead. See [Step 0](#size-considerations). - **Cores and memory are tied, not chosen separately.** - **The usable disk and memory size is always lower than the name suggests.** A small amount is reserved for the operating system itself. - The two **largest sizes are not selectable** by default. They must be requested, see **Requesting additional resources**. ::: #### Extra scratch disk **Extra Scratch Disk** asks for a temporary disk *in addition to* the machine's primary 60 GB disk. It is enabled only upon request, see **Requesting additional resources**. Once your account has a scratch disk allowance: - enter the number of gigabytes you want for **this** submission, up to your allowance. Requests are rounded **up** to the nearest 10 GB; - **no changes are needed** for your analysis. Your code sees a single filesystem. - the requested number is not preserved from one run to the next - it must be re-entered every time you submit a job. :::{important} - **This is disk, not memory.** If a run was stopped for using too much *memory*, pick a larger [machine size](#worker-size) instead. - **Ask for what you need, not the maximum.** The space comes from a shared pool, and is in competition with any other submissions. If you request a large amount, other submissions asking for space may have to wait. ::: #### Requesting additional resources To request additional resources, send an email to [support@sivacor.org](mailto:support@sivacor.org). :::{admonition} Information requested SIVACOR uses a limited allocation of compute resources. The largest machine sizes cost the project four and eight times the smallest, and additional volumes are similarly limited. We review requests sent to [support@sivacor.org](mailto:support@sivacor.org). Please say what you are running and why it needs the additional resources. Once your account is authorized to use the larger machine sizes, they become selectable. If authorized to use additional volumes, the field becomes editable. ::: #### Environment variables You can set environment variables for your job by using the `env_secrets` block in a workflow definition file, or by entering them in the submission form. These variables are available to your code during execution. :::{admonition} Workflow YAML Example ```yaml env_secrets: - key: API_TOKEN value: s3cret ``` ::: ### Submitting jobs Then click on the `Run Replication Workflow` button. :::{hint} If the button is greyed out, the upload has not finished, or the uploaded file was deleted. The button says which. See [Step 1](#step1-upload). ::: ### ℹ️ FAQ See the [FAQ](https://docs.sivacor.org/docs/faq#choosing-software-and-running-jobs). ## Monitoring Job Status :::{note} You can only run one job at a time. If you have an ongoing job, you will not be able to submit a new one. ::: :::{hint} You do not have to keep the page open. The page updates itself, and you can leave and come back to it — your submission keeps running, and you will be emailed when it ends. ::: ### Waiting for a machine On this SIVACOR instance, a machine is dynamically started for every job submitted. This may entail a short wait (**2 to 3 minutes**). While in this state, SIVACOR will show a **Waiting for a worker** message. If other users' jobs are occupying the available machines, your submission may have to wait longer. ### Job Running Once a machine has been allocated, your job will start running. The main submission page will show a **Running** status. ### ℹ️ FAQ See the [FAQ](https://docs.sivacor.org/docs/faq#monitoring-job-status). ## Downloading Results Once the job is finished, the submission page reports the outcome and offers the files the run produced. ### After a successful run You can now download the `Replicated Package`, a ZIP file that contains your originally submitted materials, the output files generated by your code, and the TRACE-related files (TRO Declaration, TRS Signature, Trusted Timestamp, see [FAQ](https://docs.sivacor.org/docs/faq#downloading-results)) that prove that this job was run on SIVACOR. The same three TRACE files are also offered individually — `TRO Declaration`, `TRS Signature` and `Trusted Timestamp` — for anyone who wants to verify the signature without unpacking the whole archive. They are the same bytes that are inside the ZIP. Alongside them are the `Run output log` (what your code wrote to standard output) and the `Run error log` (standard error). These are offered whether the run succeeded or failed. You can also download a `Workflow definition` — a small YAML file describing the software, versions and main files this run used. It is not part of the signed package; it is there so you (or a colleague) can reproduce the same setup later by importing it on the submission page, instead of filling the form in by hand (see [Optional chained runs](#chained-runs-steps)). ### After a failed run A run that failed produces no signed package — there is nothing to certify — so the `Replicated Package` and the three TRACE files are not offered. What you get is the **`Run output log`** and the **`Run error log`**, and those are where the reason is. Read the error log first: it names the command, file or package at fault. The [debugging guide](https://docs.sivacor.org/docs/debugging) covers the common ones per software, and the [FAQ](https://docs.sivacor.org/docs/faq#how-do-i-know-a-job-failed) covers failures that are not your package's doing, such as a lost worker. :::{tip} Download both logs before starting a new run. **Starting a new run deletes the previous one**, logs included, and a failed run is usually the thing you most want to keep while you fix the package. ::: ### Keeping and deleting results ::::{danger} SIVACOR only briefly retains your results (see [privacy policy](https://submit.sivacor.org/privacy)). To keep any results, you **must** download results as soon as possible. :::: ::::{danger} **Starting a new run deletes the previous one.** By clicking the button `Delete & Run New Job` you are asked to confirm. Deletion is immediate. This is also how you delete results without waiting for the 14 days to run out. :::: ### Handing the package to a journal ::::{hint} You should provide the `Replicated Package` ZIP file to the journal where you are submitting your article. :::{admonition} AEA Journals For the AEA journals, you should "import" this ZIP file into the AEA's [Data and Code Repository](https://www.icpsr.umich.edu/sites/aea/home) (see [instructions](https://aeadataeditor.github.io/aea-de-guidance/)). ::: :::: ### ℹ️ FAQ See the [FAQ](https://docs.sivacor.org/docs/faq#downloading-results). ## When a run fails A failed run still offers the **Run output log** (stdout) and **Run error log** (stderr) for download — the signed artifacts are offered only on success. Read those logs first; the message names the file or command at fault. The most common causes, and what to change: | What you see | What it means | What to do | |---|---|---| | `No main.do found` | The main file name does not match anything in the package | Check the exact spelling, case and extension. The file may sit in a subdirectory — that is fine, it is searched for | | `Multiple main.R files found: ...` | The same file name appears more than once anywhere in the package | Rename or remove the extra copies and upload again — `.sivacorignore` cannot help, it is applied after the run. The message lists every path | | Out of disk | The package plus the unpacked image exceeded the worker's disk | See [Step 0](#step0-prepare) — a **bigger machine will not help**, its disk is the same. Have the code delete intermediates as it goes (`.sivacorignore` is applied after the run, so it frees nothing during it), or ask for [extra scratch disk](#scratch-disk) | | Out of memory | The kernel killed the container | Pick a larger [machine size](#worker-size). The container's own log says nothing, because it was killed without warning | | Stata `r(601)` and similar | Stata could not find a file | Usually an absolute path or a wrong working directory. See the [FAQ](https://docs.sivacor.org/docs/faq#stata-errors) | | `Package Foo not found`, `renv` failures | Dependencies did not install | Isolation is per step: a setup step that installs packages needs **network isolation off**. See the [debugging guide](https://docs.sivacor.org/docs/debugging) | | Image pull failed | The image could not be fetched onto the worker | Re-submit; if it persists, mail support — the image, not the package, is at fault | | Waiting for a worker, for a long time | No machine free yet | Normal for a few minutes; see the [FAQ](https://docs.sivacor.org/docs/faq#monitoring-job-status) | | Submission abandoned / presumed lost | The worker died mid-run | Not caused by the package. Re-submit; see the [FAQ](https://docs.sivacor.org/docs/faq#my-job-failed-with-submission-abandoned) | ## Quick reference | | | |---|---| | Submission site | (institutional login via Globus) | | Documentation | | | Available software images | | | FAQ | | | Debugging a failed run | | | System description | | | Support (also for larger machine sizes and extra scratch disk) | | | Feedback | | ### Limits at a glance - One archive per submission, **ZIP or tar.gz**, at most **5 GB**; **10 GB** stored per user at any one time. - **One job at a time** per user. - Every machine size has the same **60 GB** disk, shared between your package and the software image; only the memory and cores change. Extra scratch disk is granted per account on request. - A submission is **deleted 14 days** after it was submitted, and starting a new run deletes the previous one. Download the Replicated Package first. - Maximum run time is **7 days**. - Do not upload data you are not allowed to place on third-party systems; use `.sivacorignore` to keep non-redistributable or bulky files out of the final package. ### Sample packages - Stata: - R: - MATLAB / Dynare: - Julia: --- *Generated from the SIVACOR documentation source at (`docs/step0-prepare.md` through `docs/step4-download.md`) on 2026-09-24 by `scripts/build_skill.py`. Edit the source pages, not this file.*