Proposed modifications to CfdOF to utilize a remote computer for meshing and simulation tasks.

[linuxguy123]

I'm thinking of modifying CfdOF so that the user can run meshes and simulations locally or on a remote computer. I'm looking for input before I do anything.

Generating large meshes and simulating them can take considerable time on even the fastest desktop CPU. In some cases hours or even days. Meanwhile the workstation machine is tied up and often not very responsive because the CPU core loads are high and the memory bandwidth is almost entirely consumed. The storage device will also be accessed frequently, further slowing down the local machine.

A better way to handle large meshing and simulation tasks is to off load them to a second (remote) computer, leaving the workstation almost unhindered while they run. Furthermore the remote computer can be optimized to run mesh and simulation loads much faster than a desktop machine might be.

I presently use a remote computer to generate meshes and run OpenFOAM simulations. I do this by editing the mesh and OF case files on my workstation, then copying them to the remote machine, logging into the remote machine with ssh and then running the tasks in the ssh session. I'm doing most of this without CfdOF, manually.

While this approach works, it is cumbersome. One is always moving case files back and forth between the workstation and the remote machine as well as the results from the remote machine back to the workstation. More than once I thought I was looking at a mesh or simulation result that just ran when, in fact, it wasn't the current output. Ugghhh.

I'd like to streamline the use of a remote computer in CfdOF, so that it happens automagically from the CfdOF GUI.

I envision doing this as follows:

1. Add a Remote tab to the CfdOF Preferences GUI for the remote connection parameters and set up. The Remote tab would have a checkbox to allow the use of a remote computer and fields for the remote hostname and username on the remote computer as well as a way to test it the connection. Ie can one successfully invoke an ssh session with the remote computer ?

The Remote tab will also allow setting up OpenFOAM, gmsh, cfmesh and Hisa on the remote machine, just as how it happens on the local computer right now.

I want the remote computer to be set up exactly as the local computer is set up as far as the tools go. That way anything that can be done in a worker thread on the local machine could also be done in a worker thread on the remote machine in a ssh session. With a little tweaking, of course.

For now I will not handle setting up Docker on the remote machine, just because I am not terribly familiar with Docker. I have used virtual environments, but not Docker. I may ask for assistance on this part of the task or leave it unimplemented.

2. In the CFD Mesh GUI I will change the "Write mesh case" button to "Write mesh case locally" and add a "Write mesh case remotely" button. The former will do as it does now. The later will write the mesh case to the working directory on the remote computer.

Likewise the Check Mesh button will also have a local and remote version.

I will also change the "Run mesher" button to "Run mesher locally" and add a "Run mesher remotely" button. The former will do as it does now. The later will mesh the mesh case that has been written on the remote machine and display the progress results in the Status box, just as it does now.

Having local and remote versions of these buttons will allow the user to use CfdOF exactly as it is presently used or with a remote computer as the user decides when working on the project. If the remote machine is busy running a mesh or simulation for another FreeCAD instance, the user may want to run meshes or simulations locally. Having both versions of the buttons allows the user the option of doing either.

Upon completion of the remote meshing task, the results will automatically be copied back to the local machine so they can be viewed (Load surface mesh) just as if they were meshed locally.

3. In the CFD Solver GUI the Write button will have a local and remote version, just as the Mesh GUI did.

I haven't figured out how to eloquently handle Editing the remote files. My best solution so far is to write the local files, allow the user to edit them locally and then have a "Copy to remote" button that will copy the entire (edited) case to the remote machine.

The Run button will have a local and remote version. The results of the remote run will display in the Status box and the Reporting Functions just as they do now.

Upon completion of a remote run the results will be copied back to the local machine, just as if it ran locally. Thus the Paraview button will work exactly as it does now, by using Paraview locally on locally stored results.

The availability of all the remote buttons will be controlled by the "Allow remote computations" checkbox on the Remote tab. If the "Allow remote computations" CB isn't checked, all the remote buttons will be disabled, leaving the user only the local buttons. Thus if the "Allow remote computations" button isn't checked, CfdOF will behave exactly as it does now.

SSH will require a password every time a new session is invoked. I'll ask the local user for the remote user's password the first time a remote operation (via ssh) is needed, but not store it. The ssh session should stay available forever unless something happens to one of the computers, ie gets powered down or goes to sleep (timeout). I'll check that the ssh session is still alive every time before using it. If the ssh session has ended, I'll invoke a new one, in which case I'll have to ask the user for the password again.

I also want to (eventually) handle the case of the workstation going to sleep, or being shut down or the user quitting FreeCAD while a remote task is running. I think I can do this by opening a new ssh connection when CfdOF is restarted and reattaching to the existing task. I'm not sure how I'll handle the data that will be missing while the connection is lost. I may have to buffer it on the remote side and redisplay it on the local side when the connection is resumed.

It seems like a lot of work to allow the workstation FreeCAD session to disconnect and resume, but it allows the user the flexibility to reboot the workstation, shut it off overnight, etc., while a task is running on the remote machine.

I am not calling the local machine a host and the remote machine a server because this isn't a true client/server relationship in the traditional sense. Right now I'm using the terminology of local and remote. I'm open to suggestions on the terminology aspect of it.

Theoretically the remote machine will allow multiple FreeCAD "clients" to connect to it, as long as each FreeCAD connection uses a different directory to store the results in. By allocating each client a subset of the total number of cores, each may have a decent experience, ie realtime but slower compared to having exclusive access to the remote machine. For now the allocation of cores will be done manually by the local user, not automatically.

The highest incarnation of using a remote computer for CfdOF processing would be the use of an AWS server or similar. I'm not saying that the work I would do would achieve this. But I do think it would be a step in the right direction. Right now it is quite cumbersome to use an AWS server for OpenFOAM work, for the same reasons I experienced and mentioned. If the remote functionality of the proposed enhancement were done right it could really streamline working with an AWS server.

Not everyone can afford a dedicated EPYC server beside their desk to run their OpenFOAM tasks. But just about everyone can afford to buy some time on an AWS server or make use of a virtual instance granted to them on a server at their local university. Adding remote processing capabilities to CfdOF would really steamline this workflow.

One of the advantages of using an ssh session to do the work on the remote computer is that just about every OS available already has ssh on it. While we could write a special server to run on the remote computer to interface with CfdOF, it would require special setup on the remote machine and I don't see that it would add a lot of value. If one uses ssh sessions, all one needs to do is ensure that ssh is set up on the remote computer.

I'm hoping to add my code to the existing worker thread routines, adding cases for the remote functionality. The alternative would be to duplicate the existing worker thread routines and create local and remote versions of each. I think there will be a lot of code commonality and having duplicates of each would increase maintenance effort in the future. However, I understand that there is a case for leaving the present routines untouched and developing stand alone remote routines. I await your input on this.

At this point I'm doing this just for me to test the concept. These changes may never be published if I find it too cumbersome in use. I'm asking for input now so that if remote processing does make it to the public that what I'm doing has a good chance of being accepted without making a lot of changes. I'm also looking for better ideas on how it might be done.

Thanks for your attention. Thoughts ? Ideas ? Advice ? Feedback ?

[luzpaz]

CC @howetuft (RenderWB dev) may be interested in this idea as well

[linuxguy123]

BTW, I don't do Windows. I'll test remote processing on Linux workstations and remote computers but I won't do any testing on Windows devices. I don't even own a Windows machine. Someone else will have to test and troubleshoot on Windows and MacOS.

[howetuft]

Hello,
Yes, it could be inspiring for the rendering of some very complex scenes (although I think that, for Render WB, these will be borderline cases). Good luck, I will follow the code propositions with attention!

[linuxguy123]

I've cloned the current CfdOF Master onto my computer. I have not created a fork.

Unless someone tells me otherwise, I'll work on things locally before sharing them publicly.

[linuxguy123]

Yes, it could be inspiring for the rendering of some very complex scenes (although I think that, for Render WB, these will be borderline cases). Good luck, I will follow the code propositions with attention!

How is rendering related to meshing and OpenFOAM ? You'd like to develop something similar (remote processing) for the Rendering WB ?

[howetuft]

Yes, remote processing could be a nice-to-have for rendering, as rendering can be quite CPU/GPU consuming, especially with recent emerging needs in terms of animation (see Movie workbench). Therefore if you explore solutions to export the load on remote workstations in FreeCAD context, that might be interesting.

[linuxguy123]

I think I will use ParaMiko for the SSH connection.

https://www.devdungeon.com/content/python-ssh-tutorial
https://www.geeksforgeeks.org/how-to-execute-shell-commands-in-a-remote-machine-using-python-paramiko/

Ignore the part about having to generate the ssh key. We'll have the user establish an ssh connection with the remote computer from the local computer before using ssh from CfdOF. In modern versions of Linux the first establishment of an ssh connection automatically generates the ssh key. Once the key is generated, the ssh connection can be opened with username and password only.

[linuxguy123]

Yes, remote processing could be a nice-to-have for rendering, as rendering can be quite CPU/GPU consuming, especially with recent emerging needs in terms of animation (see Movie workbench). Therefore if you explore solutions to export the load on remote workstations in FreeCAD context, that might be interesting.

Interesting.

What is really interesting to me is that "nobody" has done this already for the rendering crowd. I'm not a rendering guy. But I know that rendering is CPU intensive as evidenced by the plethora of Blender benchmarks. I just assumed that an application like Blender would have the ability off load some of the workload to another machine or a rendering cluster.

OpenFOAM is a great tool. But as a stand alone application, it requires a lot of patience to use. The worst part, for me, is setting up the mesh case.

CfdOF changes all that. It really streamlines the OpenFOAM workflow. Everything gets done in one place in one application with a good GUI. Object-> mesh->simulation->visualizing results. CfdOF even displays residuals as the simulation is running and has a couple reporting functions. Of course one will still use Paraview to get into the nitty gritty of the results, but CfdOF handles the processing aspect really well.

Unfortunately, serious CFD work is often computationally intensive. While a lot of work can be done on a workstation, there reaches a point where it is beneficial to use remote processing to get the job done. As of now, https://cfd.direct/cloud/remote-cfd-openfoam/ is the only remote processing UI that I am aware of.

IMHO the next step in streamlining the OpenFOAM experience is to enable remote processing in CfdOF.

[linuxguy123]

I'll use rsync to move the files between the local and remote computer.
https://www.atlantic.net/vps-hosting/how-to-use-rsync-copy-sync-files-servers/

Nothing other than ssh needs to be set up on either machine for it to work.

Rsync may be problematic on Windows machines. https://www.ubackup.com/windows-10/rsync-windows-10-1021.html

In Windows, rsync will require the computer be using WSL. However OpenFOAM doesn't run on Windows natively either. It also requires WSL. So I don't see this being an issue for either the local computer or the remote computer as they'll both need WSL in order to run OpenFOAM.

FYI, OpenFOAM typically runs much slower under WSL than it does on natively on Linux. That might be another reason for CfdOF users to want to do their processing on a remote computer, running Linux instead of Windows.

As I said previously, I'm not a Windows guy.

[luzpaz]

@linuxguy123 What is the benefit of introducing paramiko as an extra 3rd party dependency ? (I'm asking because dependencies create more work for maintainers)

[linuxguy123]

@linuxguy123 What is the benefit of introducing paramiko as an extra 3rd party dependency ? (I'm asking because dependencies create more work for maintainers)

It essentially makes the ssh connection transparent by handling all the complexity. I could do the project without it.

I understand your concern. Let me test a homemade ssh session wrapper and I'll get back to you on that.

[luzpaz]

I mean, if you want to use it as a proof of concept and then later use a homemade ssh wrapper...that would be cool. The less external dependencies the better.

[luzpaz]

https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#quoting-code

[linuxguy123]

https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#quoting-code

And when I use triple ticks it still inprets the # char and reformats the code. How do I avoid this ?

[luzpaz]

Test:

#32

[linuxguy123]

I mean, if you want to use it as a proof of concept and then later use a homemade ssh wrapper...that would be cool. The less external dependencies the better.

From what I understand, paramiko implements an ssh client for a python app to establish a permanent ssh session with the remote computer. One then sends commands to the ssh session to execute on the remote computer.

I do not think that functionality can be accomplished with os.system() or subprocess(). I was hoping that I could run an ssh command with subprocess() and it would remain persistent as long as the ssh command was running. I was hoping to interact with the ssh session via stdin, stdout and stderr into the sub processes.

However, it appears that the ssh process blocks subprocess from receiving or sending text to the remote computer.

Here is my test code.

#!/usr/bin/python
import subprocess
import os

# Say Hi.
print("\nStarting ssh-test.py")

#Test os.system locally
#print("Testing os.system locally")
#os.system('uname -a')

# Start an ssh session with the remote computer
# The remote computer is goliath
# The remote user is me

print('Starting ssh session with the remote computer')

# Approach 1
#subprocess.run(["/usr/bin/ssh","me@goliath"], input="password\n", text=True)
# result: Pseudo-terminal will not be allocated because stdin is not a terminal.

# Approach 1A
# subprocess.run(["/usr/bin/ssh","me@goliath"], input=b"password\n")
# result: same as above.

# Approach 2
#sshSession = subprocess.Popen(["/usr/bin/ssh me@goliath"],  # or ["/usr/bin/ssh", "me@goliath"] if shell=False
#                                stdin = subprocess.PIPE,
#                                stdout = subprocess.PIPE,
#                                stderr = subprocess.PIPE,
#                                shell=True) # also test with shell=False

#print ("stdout:", sshSession.stdout.readlines())
#print ("stderr:", sshSession.stderr.readlines())
#sshSession.stdin.writeline("uname -a\r")
#print (sshSession.stderr.readline())
#print (sshSession.stdout.readline())

#sshSession.stdin.writeline("password\r")
#sshSession.stdin.writeline("uname -a\r")
#print (sshSession.stderr.readline())
#print (sshSession.stdout.readline())
#result: ssh seems to block input from subprocess.stdin.write()

# Approach 3
#sshSession = subprocess.Popen(['/usr/bin/ssh', "me@goliath"], stdout=subprocess.PIPE, stdin=subprocess.PIPE, stderr=subprocess.PIPE)
#reply = sshSession.communicate('password\n')[0] # all variants of this ignore password as an input to the ssh login.
#reply = sshSession.communicate('')[0]
#print(reply)
# result: this accepts the password from the command line.  Can't pass it into the subprocess ?  subprocess also quits as soon as the
# login is successful

print("Exiting...")
print("Bye!\n")

Resources:
https://docs.python.org/3/library/subprocess.html
https://stackoverflow.com/questions/8980050/persistent-python-subprocess
https://stackoverflow.com/questions/48752152/how-do-i-pass-a-string-in-to-subprocess-run-using-stdin-in-python-3
https://stackoverflow.com/questions/8475290/how-do-i-write-to-a-python-subprocess-stdin

https://www.bogotobogo.com/python/python_ssh_remote_run.php <-Note that in all the examples the user has to input the password on the command line. ssh no longer allows the password to be passed in on the command line as an argument. And from What I can tell ssh blocks sending the password in using stdin. This is probably by design to prevent people from hacking into a computer programatically via ssh.

In the absence of getting some version of the above code working, ie creating a persistent ssh session, I will need to use paramiko or a library called fabric.

[luzpaz]

Thanks for doing due diligence. Onward

[linuxguy123]

What is the easiest way for me to run my version of CfdOF in my current FreeCAD installation ? And debug it using VS Code ?

Is there a "best practices" doc somewhere for FreeCAD workbench developers ?

[linuxguy123]

Thanks for doing due diligence. Onward

Does that mean you agree that I'll need to use paramiko or fabric ?

[linuxguy123]

To add a second tab to CfdOF preferences for the remote computing settings, does one call addReferencePage() with the second tab (page) ? Or how is another tab added to preferences ?

"Make sure the addPreferencePage() method is called only once, otherwise your pref page will be added several times" https://wiki.freecadweb.org/Workbench_creation

[linuxguy123]

I figured out a way to run commands on a remote computer via ssh using subprocess(). I'll update this thread with the details in the near future.

[linuxguy123]

It's going to be interesting doing this all in QProcess !

But there is this: https://github.com/sandsmark/QSsh

[oliveroxtoby]

I like the idea. We have always had something like this in mind to support compute clusters on which most serious CFD ends up being done, in my experience. In that case you have the additional factor of schedulers to interact with, but that can be a future addition. However, in that vein I would prefer it if we interact with the program running on the remote machine 'at arms length', with the output data obtained by looking at its log files and output files rather than the controlling process directly owning the processes it creates via ssh - because on compute clusters you don't get to create/own the process directly.

1. Add a Remote tab to the CfdOF Preferences GUI for the remote connection parameters and set up. The Remote tab would have a checkbox to allow the use of a remote computer and fields for the remote hostname and username on the remote computer as well as a way to test it the connection. Ie can one successfully invoke an ssh session with the remote computer ?

Sounds good.

The Remote tab will also allow setting up OpenFOAM, gmsh, cfmesh and Hisa on the remote machine, just as how it happens on the local computer right now.

Great, but perhaps more of a 'nice to have' since the remote machine may not be fully under your control. Presently in CfdOF we write the output so that it can run on any supported OpenFOAM version (i.e. it is not tailored to the version currently selected), with this sort of situation in mind (you might want to copy the case and run it on a cluster with a different version installed).

I also want to (eventually) handle the case of the workstation going to sleep, or being shut down or the user quitting FreeCAD while a remote task is running. I think I can do this by opening a new ssh connection when CfdOF is restarted and reattaching to the existing task. I'm not sure how I'll handle the data that will be missing while the connection is lost. I may have to buffer it on the remote side and redisplay it on the local side when the connection is resumed.

This would be good. For the report functions and residuals etc, the missed data can be harvested from the log and postprocessing files.

Thanks for your interest in taking this on!

[adrianinsaval]

this would be a seriously good addition to the project!

@linuxguy123 What is the benefit of introducing paramiko as an extra 3rd party dependency ? (I'm asking because dependencies create more work for maintainers)

I think paramiko can be installed with pip so it shouldn't really be a problem, the addon manager can offer to install it when you install the workbench so there isn't any additional work for freecad packagers and cfdof itself doesn't need to package it either, just declare it as a dependency so that the addon manager can take care of it.

[linuxguy123]

Interesting comments. I'm glad to see others feel it would be a worthwhile addition.

I'll keep the cluster and interacting with the remote processs 'at arm's length' ideas in mind moving forward. Personally, I like watching the residuals and outputs in FreeCAD. Makes it easy to kill the simulation if you see something obviously not working.

Thinking about this further, one could take the "at arms length" to the point that FreeCAD starts the process on the remote machine, launches a little stand alone monitoring app and detaches from the remote process completely. The stand alone app would essentially be the residuals and reporting functions which are matplotlib more than anything. Hmmmm.... It would also be nice to watch the core loads in such an app. Baby steps...

Having taken a closer look at the existing code, I'm going to try to do the ssh calls in QProcess like the existing code does. I'll run a test of this aspect of the project in the near future and report back with my findings.

Another change I'm thinking about making is to add the desired number of cores used as a field in both the local and remote meshing preferences and the CfdOF Mesh window.

When remote processing is used, the cores used will probably be quite different between the local machine and the remote machine. I see that the "Number of Processes" and"Number of Threads" properties are available in the Mesh properties, which was has worked fine until now. But these parameters will be constantly changing going forward so I feel they deserve both preferences and edit boxes on the Mesh window.

Keep the comments coming.

[linuxguy123]

FYI... there are two aspects of running a remote process in ssh that make things challenging. I'm posting this now so people who work on something similar can learn from my experience and understand my implementation decisions.

The first is the permissions aspect. At first I was going to get the user to input a password whenever an ssh session was needed. This doesn't work because ssh itself doesn't allow the password to be passed in on the command line. And if it did, it would appear in the logs on the remote machine.

The way around the ssh permission problem is to set up an ssh key, which is pretty easy.
On the local machine: ssh-keygen to generate a key. Then run ssh-copy-id user@remote to copy it to the remote machine. Unfortunately this will need to be done outside of FreeCAD. But if the user is knowledgeable enough to set up ssh on a remote computer, s/he can also do this step.

The other aspect is interacting with the remote process. I originally thought I'd be able to open an ssh session with subprocess() and utilize the session repeatedly by sending it commands and receiving the output via the stdin, stdout and stderr attached to the subprocess. However, it turns out that ssh blocks the process that is running within the ssh shell from interacting with subsProcess's stdin, stdout and stderr while the process is running. One gets all the output after the process (and ssh) has exited.

I have not found a way around this particular behaviour, even when using paramika.

However, there is a way to attain the desired functionality, ie having stdout and stderr available to the local machine, while the process runs in ssh. One can achieve this by piping the output of the remote process to files on the remote machine and then periodically reading said files from the local machine. It's not as nice as how things run locally, but will still work.

Having said all this, I have not tested running ssh within QProcess. I'm assuming that QProcess has no magical unblocking properties when using ssh and will have the same behavior.

The present code launches all external processes (meshing and OpenFOAM simulations) with QProcess. I will endeavor to do this as well because 1) I want to keep the code the same as much as possible and 2) it appears to work well. If QProcess acts as I think it will with ssh, I may write a wrapper class around QProcess (remoteQProcess?) that hides the complexity of the remote stdout and stderr files and makes it act just like the files are running locally.

Thoughts ?

[linuxguy123]

The other way to achieve remote processing from FreeCAD would be to write a small server app that sat on the remote machine. This app would call the mesher and OpenFOAM from the remote machine and echo the results back to the local machine. In fact, this server could be installed on the local machine and used to run things there as well.

I suspect that writing that app would be non trivial due to the number of platforms (Linux, Windows, MacOC, etc) that people will have on their remote machines and installing it, setting up the firewall, etc. on the remote machine.

ssh is universally available on all platforms, or nearly so. And it's secure and easy to set up.

Having said all this, I'm open to discussion on the remote approach.

[mmcker]

Have you considered if mosh will help? (keep alive an ssh session)

https://github.com/mobile-shell/mosh

Also, I wouldn't immediately discard using wsl based on speed. I found wsl to be very fast - however, you must ensure you understand how to access the filesystems. https://learn.microsoft.com/en-us/windows/wsl/filesystems. My docker experiments (which uses wsl) seem to have the same speed for wsl as native performance.

[linuxguy123]

Have you considered if mosh will help? (keep alive an ssh session)

https://github.com/mobile-shell/mosh

The problem isn't keeping the session alive. The issue is interacting with the session through stdout and stderr while a command is running in the session. For example, OpenFOAM may run for hours in an ssh session. We need/want the output of stdout and stderr for OpenFOAM while it is running. So far I've found that subProcess() will only give stdout and stderr after the process (OpenFOAM in this case) has completed.

Furthermore, I have not been able to send commands to an ssh session run in subProcess() using stdin. Others on the Internet have experienced the same as I have. If anyone knows how to do this, please chime in.

Also, I wouldn't immediately discard using wsl based on speed. I found wsl to be very fast - however, you must ensure you understand how to access the filesystems. https://learn.microsoft.com/en-us/windows/wsl/filesystems. My docker experiments (which uses wsl) seem to have the same speed for wsl as native performance.

I'll stick to plain Linux, thank you. I don't run Windows and have no need for WSL.

[oliveroxtoby]

I'll keep the cluster and interacting with the remote processs 'at arm's length' ideas in mind moving forward. Personally, I like watching the residuals and outputs in FreeCAD. Makes it easy to kill the simulation if you see something obviously not working.

I agree, and I wasn't suggesting to lose this functionality, but (as you also mentioned) to monitor the log files rather than remaining attached to the process stdout. This is already how the 'probes' reporting function works - by watching the relevant files in postProcessing/... . I appreciate there is an elegance in keeping everything the same save for the process running through ssh. However every experience I have had of shared compute resources are machines with schedulers where you don't have the option of running heavyweight apps directly. Of course, you are free to take whatever approach works for you, but I do think there would be a lot of benefit in keeping that use case in mind.

[oliveroxtoby]

This also fixed the issue with processes on the remote host not stopping when the process was killed on the workstation. Two birds with one stone.

Would you mind closing the other issue?

[oliveroxtoby]

Right now SnappyHexMesh is only running with one core.

Here is how that can be changed. https://www.cfd-online.com/Forums/openfoam-meshing/168852-parallelize-snappyhexmesh-optimally.html

Are you just referring to remote mode here? Because it can be run in multiple processes in CfdOF by setting the number of processes in the mesh data.

[oliveroxtoby]

I fixed the conflict and the push worked. My repo now has all my changes and Oliver's too. https://github.com/linuxguy123/CfdOF

I need to check that this was Oliver's intended change in TaskPanelCfdMesh.py:

FreeCADGui.doCommand("if proxy.running_from_macro:\n" +
                                 "  mesh_process = CfdConsoleProcess.CfdConsoleProcess()\n" +
                                 "  mesh_process.start(cmd, env_vars=env_vars)\n" +
                                 "  mesh_process.waitForFinished()\n" +
                                 "  proxy.check_mesh_process = CfdConsoleProcess()\n" +
                                 "  proxy.check_mesh_process.start(cmd, env_vars=env_vars)\n" +
                                 "  proxy.check_mesh_process.waitForFinished()\n" +
                                 "else:\n" +
                                 "  proxy.check_mesh_process.start(cmd, env_vars=env_vars)")

I think something might have gone wrong in the merge here. I don't have these lines in the latest version (see here and here).

[oliveroxtoby]

I await feedback.

Were you planning to create a pull request? I haven't seen one yet.

[linuxguy123]

Are you just referring to remote mode here? Because it can be run in multiple processes in CfdOF by setting the number of processes in the mesh data.

It can run multiple processes for me too, locally and remotely. The problem is/was the combination of process and thread values that caused the issue.

[linuxguy123]

Would you mind closing the other issue?

Done.

[linuxguy123]

I think something might have gone wrong in the merge here. I don't have these lines in the latest version (see here and here).

I'll rectify this.

[linuxguy123]

Were you planning to create a pull request? I haven't seen one yet.

I think people should run/test from my repo for a bit until we do this. I'll keep pulling from Master on the main repo and doing the merges. That way we should be able to eventually merge them again.

[luzpaz]

@linuxguy123 in general you should clone upstream, create a branch, make changes to the branch and then submit said branch as a PR. You made you changes to the master branch of your cloned repo.

[linuxguy123]

@linuxguy123 in general you should clone upstream, create a branch, make changes to the branch and then submit said branch as a PR. You made you changes to the master branch of your cloned repo

My bad. But Master had the latest development in it.

I have no intent on forking CfdOF. I just wanted my own place to play. I intend to merge once people have used it and are happy. I can branch and merge if people really want that.

[luzpaz]

Cloning is a form of forking. It's just more hygenic because it's easier to rebase upstream master to your local master. Then you can resolve conflicts against local master from the branch you're working on.

[linuxguy123]

I need push permission in order to create a branch. If granted, I'll create a branch for my work and move it over.

[adrianinsaval]

the branch is meant to be on your repo, then you make a PR and it can be merged here, doing your work on your master branch is not bad per se, it's just good practice to make a separate branch (based on master) with a descriptive name.

enable Docker use on the remote hosts

isn't this a matter of the host configuring a specific port for docker? (so you would ssh into the docker container) I don't think this needs changes on cfdof.

I think people should run/test from my repo for a bit until we do this. I'll keep pulling from Master on the main repo and doing the merges. That way we should be able to eventually merge them again.

this does not stop you from creating a pull request, you can keep updating your branch and that'll be included in the pull request, the pull request makes it easier for others to review and comment on the code so I suggest to make a PR anyways. Testing can continue and merge can be held back until you and oliver are happy with it.

[mmcker]

enable Docker use on the remote hosts

isn't this a matter of the host configuring a specific port for docker? (so you would ssh into the docker container) I don't think this needs changes on cfdof.

A very good point! The entire docker implementation could be deleted and replaced by people adding the docker container as a remote host. Previously I recommended removing docker from the remote host code as it would not add value (maybe my email was lost as I can't see it above).

[linuxguy123]

A very good point! The entire docker implementation could be deleted and replaced by people adding the docker container as a remote host. Previously I recommended removing docker from the remote host code as it would not add value (maybe my email was lost as I can't see it above).

This would need to be tested ! Of course you know that.

[linuxguy123]

the branch is meant to be on your repo, then you make a PR

Oh ! I thought you wanted me to make a branch in the existing repo. OK, makes sense.

[linuxguy123]

I fixed the conflict and the push worked. My repo now has all my changes and Oliver's too.

I think something might have gone wrong in the merge here.

You are correct. I'm fixing it now.

There was an error in one of your lines. Missing a "+".

FreeCADGui.doCommand("cart_mesh = "
                                 "    CfdMeshTools.CfdMeshTools(FreeCAD.ActiveDocument." + self.mesh_obj.Name + ")")

[linuxguy123]

PR: https://github.com/jaheyns/CfdOF/pull/76/files

[oliveroxtoby]

Update: I reinstalled cfmesh and now it works. I spent a couple hours troubleshooting this !

This happens when the stock version of cfmesh is used instead of the modified cfdof one. Dependency checker should tell you straight away.

[linuxguy123]

I changed the name of my repo. It can now be loaded into FreeCAD using the github link in Addon Manager -> Settings

I think it can co exist with the plain CfdOF, but am not 100% sure. If add filename to path is selected the RP version will save files in a different location than the plain version.

The two versions of CfdOF cannot co exist on one installation. I could make them but it isn't worth it.

[linuxguy123]

How is one supposed to run TestCfdOF.py ?
Is this file up to date ?
I ran it in the CfdOF. Is that correct ?

$ ./TestCfdOF.py
./TestCfdOF.py: line 29: from: command not found
./TestCfdOF.py: line 30: from: command not found
./TestCfdOF.py: line 31: from: command not found
./TestCfdOF.py: line 32: from: command not found
./TestCfdOF.py: line 33: from: command not found
./TestCfdOF.py: line 34: from: command not found
./TestCfdOF.py: line 35: from: command not found
./TestCfdOF.py: line 36: from: command not found
./TestCfdOF.py: line 37: from: command not found
./TestCfdOF.py: line 38: from: command not found
./TestCfdOF.py: line 39: from: command not found
./TestCfdOF.py: line 57: syntax error near unexpected token `('
./TestCfdOF.py: line 57: `home_path = CfdTools.getModulePath()'

$ python --version
Python 3.11.2

[linuxguy123]

What is the rule for setting the Base Element Size in openFOAM ?

[linuxguy123]

Another question... will CfdOF work with a cut made with Part Design workbench or does it have to be made with the Part workbench ?

One can make a "cut" of a wing in a wind tunnel 2 ways:

1. In Part Design, one can Pad the wind tunnel sketch and then Pocket the wing sketch to make the part to simulate.

2. In Part, one can Extrude the wind tunnel and wing sketches and then Cut to produce the part.

Will they both work equally well or is one preferred over the other ?

[oliveroxtoby]

How is one supposed to run TestCfdOF.py ? Is this file up to date ? I ran it in the CfdOF. Is that correct ?

Please see https://github.com/jaheyns/CfdOF/blob/master/CONTRIBUTING.md#testing

[linuxguy123]

Update

I found a bug. If one does a Save As to save the FreeCAD file to a new name, the UI doesn't update the filename and the mesh and solver results get saved to the wrong (old) directory. I'll fix this in the near future.

I've spent the last few days running cases with CfdOF-RP. The workflow from editing objects to meshing to solving to viewing results and running things on multiple computers is fantastic. Very fluid, very little wasted effort.

Meshing in particular is excellent. So easy to set up refinement volumes, run the mesh and then view the results in Paraview. I used to hate meshing. Always figuring out indices and such to put in FOAM files. Figuring out inlet, outlet, wall areas. So much nicer to click on a surface or object.

Some of my meshes are large and are taking 15 minutes to run. With a project like this it is really nice to have the remote computers.

I'm biased, but I'm thrilled with how this turned out.

[linuxguy123]

Enhancement ideas:

In CFD reporting function:

1. fill the Free-stream flow speed object from the Inlet object as a default

2. Calculate reference pressure as a default. (1/2 rho x V^2)

3. In the Solver Panel:

Allow Paraview to view results from a partially completed solution

4. In the Mesh and Solver Panel:

Add notification via sounds for successful completion and error for meshing and solving.

[linuxguy123]

I am thinking of adding Save Mesh and Open Mesh buttons to the mesher control panel.

I want these functions so that I can mesh a geometry and then save the mesh for use in multiple projects without having to remesh it.

Thoughts ?

I'm not sure how it would interact with the mesh object. Things are getting a bit complicated with remote hosts and importing meshes.

[oliveroxtoby]

Closing this issue as a pull request has been created.