Running Remotely#
Running Remotely
Bring an institutional cluster or workstation you already have access to into a CryoStack run. This page covers how a scientist uses Remote execution; how it is implemented lives in the Developer Guide's Execution Backends page.
What Remote means#
Remote means executing on an existing remote, institutional, or HPC resource you already have access to — a cluster, server, or workstation — rather than AWS Cloud infrastructure. Both CryoLauncher and ICESEE support Remote execution, and both have already been used this way.
Both applications reach that resource through the same two connectivity
concepts, via a common RemoteBridge pattern:
Direct SSH connects from the application host to your resource when network policy and reachability allow it — you supply host, user, port, and credentials, the same as an ordinary SSH login.
Connector/Relay is for resources reachable only from your own workstation, VPN, or an approved edge environment. A packaged Connector you install locally exchanges commands and files with CryoStack through an authenticated relay, without requiring an inbound connection from CryoStack to your institution. The target institution keeps its own accounts, authentication, and scheduler policy. An Auto setting lets CryoStack pick between the two.
This shared connectivity choice is as far as the similarity goes — each application configures, submits, and reports on a Remote run through its own implementation, described separately below.
CryoLauncher Remote#
In CryoLauncher, Basic/Advanced (the configuration experience) and Remote/Cloud (the execution backend) are independent choices, not a sequence. Selecting Remote shows the same Remote configuration — target host/user/port, access mode, cluster name, Spack-vs-Container backend choice, and Slurm resources — whether the current mode is Basic or Advanced. Basic mainly simplifies the scientific configuration surface (a curated parameter panel instead of the raw example files); Advanced additionally exposes the raw-file editor, the dataset manager, the Run/Test/Deploy selector, and direct working-copy access. Both submit a Remote run through the exact same underlying path.
configure scientific workflow
|
v
select Remote
|
v
configure target/access
|
v
choose Remote software backend where applicable
|
v
configure Slurm resources
|
v
submit
|
v
monitor
|
v
retrieve/results
For the full field-by-field walkthrough, see Configure access to your HPC system and Run monitoring and history.
ICESEE Remote#
ICESEE has its own interface organization — Local, Remote, and Cloud tabs, alongside Auto-config · Beta — not CryoLauncher’s Basic/Advanced model. Its Remote mode is operational and has already been used for real ensemble data-assimilation runs, not planned or experimental functionality.
Configuring an ICESEE Remote run adds the same target/access fields as CryoLauncher (host, user, access mode) plus ICESEE’s own ensemble/data-assimilation configuration — model, filter type, ensemble size, and the process counts relevant to a Remote submission. Submission, status, retrieval, and visualization then follow ICESEE’s own Remote workflow, distinct from CryoLauncher’s:
Submit — sent through ICESEE’s own Remote runner, whether by direct SSH or Connector.
Monitor — status and logs are checked from ICESEE’s own Run Log and results tools, not CryoLauncher’s Workspace status panel.
Retrieve and visualize — ICESEE presents a run’s output files and any generated figures directly, rather than through CryoLauncher’s structured result-package viewer; see Results and reports.
For the full walkthrough, see ICESEE Remote Mode.
Institutional connectivity for Cloud workflows#
A Remote Connector pairing can also carry private institutional connectivity for a Cloud workflow that needs it — see Running in the Cloud for that case.
Troubleshooting#
Common Remote connectivity problems are consolidated in Troubleshooting.