Enable running Cubit on a virtual machine via SSH

[m-frey]

This Draft adds first support for executing and visualizing Coreform Cubit run inside a Windows VM.
Tested with Parallels/Windows11

The following tests are currently failing:

• test_cubitpy.py::test_element_types_tet
  AssertionError: Inputs are not equal

• test_cubitpy.py::test_extrude_mesh_function
  AssertionError: Numeric mismatch (0.6917… != expected)

• test_cubitpy.py::test_extrude_mesh_function_average_normals_for_cylinder_and_sphere

• test_cubitpy.py::test_get_id_functions
  AssertionError: [2] == [1, 2] failed

• test_cubitpy.py::test_display_in_cubit
  TypeError: expected str, got bytes

• test_cubitpy.py::test_import_fluent_geometry
  AssertionError: Expected 1, got 0

• test_cubitpy.py::test_cmd_return
  AssertionError: 1 != 0

• test_fw.py::test_debug_env
  AssertionError: False is not True

• test_tutorial.py::test_cubit_tutorial
  AssertionError: Inputs are not equal

[isteinbrecher]

Thanks for the work @m-frey. I am not super familiar with all the changes but in general this looks good, if this works for you on Windows. One question: Do you use this to run CubitPy on a macOS/Linux system and then connect to Windows vis ssh or is this run entirely on Windows?

I think the best way to proceed is to talk about this in person in the near future.

[m-frey]

yes, cubitpy on macOS/linux, coreform on Windows.

[isteinbrecher]

Sounds good. Do you have any idea on how we can test this?
Should we also cover the case that everything runs on windows?

[isteinbrecher]

@m-frey I left a comment regarding the display functionality. Let's talk about this whole changes once you are ready.

I am really happy that such a complex use case can be implemented relatively easy.

[isteinbrecher]

@m-frey one thing that came to my mind: I think we can test most of the proposed features quite easy. We can use a ssh connection to the local host (then the ssh client is a Linux machine, but that should not be much effort).

Especially if the ssh connection is a required feature for you and others, testing is very beneficial. We can talk about how to do this in detail.

[Copilot]

Pull request overview

This PR adds support for running Coreform Cubit on a remote Windows virtual machine via SSH, tested with Parallels/Windows 11. The implementation enables remote Cubit execution, file transfers via SCP, and visualization using Windows scheduled tasks.

Changes:

• Added SSH-based remote execution support for Cubit operations on Windows VMs
• Implemented remote file transfer functionality using SCP for mesh exports
• Added Windows scheduled task integration for remote GUI visualization

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 27 comments.

Show a summary per file

File	Description
src/cubitpy/cubitpy.py	Added remote SSH execution, file transfer functions, and remote display functionality with Windows task scheduler integration
src/cubitpy/cubit_wrapper/cubit_wrapper_host.py	Refactored gateway setup to support both local and remote modes; improved exception handling
src/cubitpy/cubit_wrapper/cubit_wrapper_client.py	Added remote operations handlers for directory creation, OS detection, and journal file generation
src/cubitpy/cubit_to_fourc_input.py	Updated mesh export to handle remote paths with file existence validation
src/cubitpy/conf.py	Added remote configuration support with new accessor methods and Python prologue for remote initialization

Comments suppressed due to low confidence (1)

src/cubitpy/conf.py:283

• The is_coreform() method accesses cls._config["local_config"]["cubit_path"] even when in remote mode (line 279). When cls.is_remote() returns True, this will fail because the local_config section may not exist or may not be properly configured. The method should handle the remote case separately or check is_remote() before accessing local_config.

    def is_coreform(cls):
        """Return if the given path is a path to cubit coreform."""
        cubit_root = cls._config["local_config"]["cubit_path"]
        if "15.2" in cubit_root and not cls.is_remote():
            return False
        else:
            return True

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

When cupy.is_remote() is True and testing=True, the function returns early without a return value (line 587-588), which means it returns None. However, the non-remote path returns a journal_path string when testing=True (line 651). This inconsistency breaks the test expectations. The remote version should return the journal path string (JOURNAL) when testing is True, not a dictionary, to maintain API compatibility. Change line 759-765 to return just JOURNAL instead of a dictionary.

Suggested change

	self.display_in_cubit_remote(labels, delay, testing)
	return
	return self.display_in_cubit_remote(labels, delay, testing)

[m-frey]

@m-frey one thing that came to my mind: I think we can test most of the proposed features quite easy. We can use a ssh connection to the local host (then the ssh client is a Linux machine, but that should not be much effort).

Especially if the ssh connection is a required feature for you and others, testing is very beneficial. We can talk about how to do this in detail.

Good idea, but i would suggest to add this in a later pr as it requires to allow ubuntu as a remote os which is currently not the case