Usage — Classes and demos

1. Launching the app (connection flow)

Launch on PC-A with the port exposed to the network, and just tell the participants the address. An independent session is created for each connection (browser tab), so each participant's screen and panel settings do not mix with the others'.

• --server.address=0.0.0.0 means "accept connections from the network". Be aware that this is the exact opposite of the 127.0.0.1 (yourself only) setting in remote use.
• For the address to give participants, you can use the "Network URL" printed to the terminal at launch as it is. Allow incoming connections on the port (default 8501) in the firewall of PC-A beforehand.
• Test the connection with one device beforehand. University Wi-Fi sometimes blocks direct communication between devices (client isolation — see section 3). A wired LAN in a computer lab is usually fine.

2. Prerequisites and caveats

In this deployment, the operations of all participants are handled inside a single process on PC-A. That is, everyone's operations run with the privileges of the user who launched the app on PC-A, and there is no authentication on connections. Consider it designed for use on a classroom LAN, under supervision, and with teaching data only.

• Restrict the data that can be opened to the teaching material: we strongly recommend allowing only the directory of the exercise data via allowed_dirs in the config file (config file details). It also makes it easier for participants to pick the material in the "Choose from allowed directories" browser. Moreover, in this deployment the setting is practically mandatory — without it a "Browse..." button appears in the sidebar, but it opens the native file dialog on the screen of PC-A, where the app is running, so when a participant clicks it nothing happens in their browser and the app seems to hang. With allowed_dirs set, the button is hidden and replaced by the in-browser file browser.
• Keep personal data off the machine, and stop when done: while the app is running, anyone on the same network can connect. Do not keep data on PC-A that you would not want seen, and stop with Ctrl+C once the class is over.
• Have participants save their work via "Download": downloads of figures, animations, and reproduction scripts land in each participant's own browser, so they can take them home as they are. Saving a session with "To this PC", on the other hand, puts it in ~/.climcanvas/ on PC-A, making it a list shared by everyone (visible to each other and overwritable). To keep sessions, have participants use the "Download" tab as well.
• Tell participants not to reload the browser: the independent session of each connection (tab) is replaced by a new one on reload or when the tab is closed by mistake, and the work done so far is lost. Say so at the start of the class; in a long class it is safer to have participants save the session with "Download" at each break.
• The load concentrates on PC-A: all plotting is done on PC-A, so memory and CPU consumption scale with the number of participants × data size. Keep the teaching netCDF files as small as possible, and consider spreading over several PCs for large groups.

3. When connections fail: client isolation

When participants cannot reach PC-A over Wi-Fi, the most common cause is client isolation (AP isolation). It is a feature that blocks, at the access point, direct communication between devices on the same network. Each device's traffic is limited to the upstream direction (router → Internet), and packets addressed to other devices are dropped. As a safety measure against eavesdropping and attacks from neighboring devices on networks used by the general public, it is often enabled on guest Wi-Fi, in hotels, and on university campus Wi-Fi (including eduroam).

Symptoms and how to tell

• Both devices reach the Internet normally, yet pings to each other and connections to http://<IP of PC-A>:8501 alone time out.
• Packets are dropped before they reach PC-A, so no setting on PC-A can fix it (opening the firewall or launching on the public address makes no difference).
• Similar symptoms have other causes, so narrow it down. Common ones are the OS firewall of PC-A itself (Windows blocks incoming connections under the "Public network" profile) and the participants and PC-A being on different subnets/VLANs (blocked by a firewall on the campus route).

Workarounds (in practical order)

1. Use the wired LAN of the computer lab: the wired network installed in classrooms usually has no isolation and is the most reliable.
2. Consult the network administrator: ask for an SSID/VLAN without isolation for the class, or for an exception for PC-A. At a university this is the proper route.
3. Bring your own router/AP: set up a local Wi-Fi network and connect PC-A and all participants to it (no Internet connection is needed — ClimCanvas works entirely within the LAN). Some universities prohibit bringing in APs, so check beforehand.
4. Smartphone tethering: for a small group, having everyone connect to the instructor's smartphone hotspot also works (hotspots usually allow communication between devices).
5. Expose temporarily through a tunnel service: open an outbound tunnel from PC-A with ngrok, Cloudflare Tunnel, or similar, and participants connect over the Internet to the public URL issued. Since no direct communication between devices on the LAN is used, isolation has no effect. However, anyone who knows the URL can connect (combine with the service's authentication feature where possible), the data passes through a relay server, and free plans limit the number of connections, so it is a pragmatic option for small groups, short durations, and teaching data only. Check your university's terms of use beforehand as well.
6. Run on a campus server: instead of PC-A, launch on a server reachable from the campus network (effectively a variant of remote use).

Examples of tunnel services. In both cases, keep ClimCanvas launched privately (127.0.0.1). cloudflared (Quick Tunnel) needs no account and participants just open the URL, but it has no way to add authentication. ngrok requires a free account registration and interposes a warning page on each participant's first access (they click "Visit Site" once), but in return simple authentication can be added with --basic-auth.

4. Choosing a deployment

Whereas remote use is a configuration in which each user has a process with their own privileges and authentication is left to SSH, classes and demos share a single process without authentication. "Connecting to the same process" does not mean, however, that all participants look at and operate the same screen — as described in section 1, an independent session is created per connection, so each participant's screen and panel settings are independent of the others. What is shared is not the screen but the executing identity (the privileges of the user who launched the app), the computing resources of PC-A, and the destination of "To this PC" saves. This lack of separation between users is the price of convenience, so choose remote use for everyday operation and the deployment on this page for temporary multi-user sessions.