Learning Forum

[j-garmatter]

Hello,

I could use some very specific help.

I have a linux cluster that uses SLURM. One machine in my cluster has ansys fluent installed.

I can run fluent jobs:

• On the cluster machine with Fluent installed.
• Through the SLURM job submission node to run on the machine with Fluent installed.
• Locally on my Windows computer with Fluent installed.

I want to submit jobs from my Fluent install on Windows to my job submission node's SLURM process so it may run on the cluster machine with SLURM installed.

I have configured the "Parallel Settings", "Remote", and "Scheduler" tabs from Fluent Launcher 2025 R1 on my Windows machine. It should be pointed to the job submission node on my Linux cluster with the proper SLURM partition. However, I can't run the job.

Can anyone assist me with this problem?

[Mark O]

Hi,

 

When using the "Remote", and "Scheduler" tabs, the fluent user interface will run on the Windows machine and the solvers will run on Linux.

 

You must configure passwordless ssh on the windows machine so that in a command prompt you can type as a test

 

ssh headnode.company.com -l username

 

and it will login with no password requested. Replace headnode.company.com with the headnode machine or any machine which will accept the slurm sbatch command to submit a job. Replace username with your username.

 

ssh has been built-in to Windows for a long time. The alternative is to use a thirdy party tool such a putty. There is help online on how to confingure ssh or putty for passwordless login.

 

On the remote tab select other and use "ssh -l username" or the putty equivalent if using putty.  Replace username with your username.

 

 

When running you should see the user interface open on your windows machine and in the console you should see a login to the machine with the message starting "Host spawning Node 0 on machine ". Then you should see a message indicating that a job was submitted to slurm. It will then sit there until the job starts running after which you should see it report the list of machines it is running on.

 

Regards

 

Mark

 

[j-garmatter]

Thanks Mark,

I was able to set up passwordless login and successfully log in to the head node from my Windows Fluent instance.

However, I received this error from the fluent console:

bash: line 1: /usr/ansys_inc/v251/fluent/bin/fluent: No such file or directory

That is the correct path to my fluent executable on the compute node. I think Windows Fluent is trying to run the fluent command on the head node instead of submitting the job to SLURM for the compute node to run.

I have both "Remote>Use Remote Cluster Head Node" and "Scheduler>Submission Host" set to the head node. The head node has no fluent software installed, just the SLURM controller.

[j-garmatter]

Mark, or anyone else, am I missing something with my setup? Maybe I need something installed on the head/job-submission node? I couldn't find that in any documentation though.

[Mark O]

Hi, Fluent needs to run on the headnode in order to generate the Slurm script that is submitted to Slurm. Is Fluent installed on a network share on the compute nodes? It would be very inefficient to install it separately on each compute node. Perhaps you could mount the network share on the headnode? Ideally, the headnode should see all the same file systems that the compute nodes see.

[j-garmatter]

If I understand correctly, I need Fluent to be installed on the Windows machine, on the Head node, and on the Compute node then? Three different systems need to run Fluent before it can run on the single compute node, correct? That sounds really inefficient for compute resources and memory. Why can't the Windows machine generate the SLURM script? Where does it mention this in Fluent's documentation?

I am confused by this decision because the other software on this cluster is not like that. I've never had to install the simulation software on the Head node for it to run on a compute machine. The Head node doesn't run any compute software, just the job submission software. We do this because the Head node is a low-resource VM that we do not want people to accidentally run jobs on.