Installation CfdOf / HiSA

[oliveroxtoby]

Honestly speaking: no clue. As you said just trial and error. In my opinion it should also work properly with the newest Open Foam Release. Bluecfd is mit the most actual one.

On my computers, it works fine with the latest OF release. Until I receive some useful assistance debugging this from users, there is nothing I can do to improve it. Other than complaints, I have received no useful feedback so far. I would appeal to users to be part of the solution. Nobody is paying us to provide the assistance we provide. The beauty of open source projects is that everyone has the chance to contribute to fixing problems.

[Sidemountyucatan]

I appreciate this voluntary work very much you and other do on supply an open source CFD WB and my statement is not be understand as arrogant complaint so far. Sorry, if you got it into the wrong neck.For my part I am just user and will not be able to help you much on this behalf. Therefore I can just "rely" on trial and error.

But thx for any help be delivered.

[Syres]

Honestly speaking: no clue. As you said just trial and error. In my opinion it should also work properly with the newest Open Foam Release. Bluecfd is mit the most actual one.

Until I receive some useful assistance debugging this from users, there is nothing I can do to improve it. Other than complaints, I have received no useful feedback so far. I would appeal to users to be part of the solution. Nobody is paying us to provide the assistance we provide. The beauty of open source projects is that everyone has the chance to contribute to fixing problems.

Keeping you in the loop

Keeping you in the loop

Sorry for the late update, house refurb is taking it's toll on my FreeCAD test time. The good news is I now have a Windows 10 box that I can replicate the fault with the Conda build, I also have miniConda to build different environments and a batch file to convert Conda environments into builds on Windows.

So I'll look to chip in with 2-3 hours per night this week and see where I've got to at the end of the week (you'll have to bear with me if I have a major water leak or other such catastrophe, I must have upset someone somewhere based on recent electrical gremlins ).

It's just a matter of changing one thing at once from what the LP build has included up to the full Conda build which tends to have the latest bleeding edge versions in it. It's going to be a tedious job but if we can agree on maybe downgrading just one or two libraries of the build without having some serious impact on the rest of the FreeCAD community then it's got to be a plus in the long run.

[oliveroxtoby]

Sorry for the late update, house refurb is taking it's toll on my FreeCAD test time. The good news is I now have a Windows 10 box that I can replicate the fault with the Conda build, I also have miniConda to build different environments and a batch file to convert Conda environments into builds on Windows.

So I'll look to chip in with 2-3 hours per night this week and see where I've got to at the end of the week (you'll have to bear with me if I have a major water leak or other such catastrophe, I must have upset someone somewhere based on recent electrical gremlins :lol: ).

It's just a matter of changing one thing at once from what the LP build has included up to the full Conda build which tends to have the latest bleeding edge versions in it. It's going to be a tedious job but if we can agree on maybe downgrading just one or two libraries of the build without having some serious impact on the rest of the FreeCAD community then it's got to be a plus in the long run.

Appreciate your help. Of course it would be great it you can sort out the issues with Conda and blueCFD, but the more important issue for me is to try to understand why people seem to be struggling with the latest OpenFOAM v2006 Docker installation. I don't seem to have got any clear answers on whether this is because they for some reason have not achieved a working OpenFOAM installation, or whether there is some bug in the interface from CfdOF to it that is not showing up on my machine.

BlueCFD is a backup option which works just fine, but the more time goes by the greater becomes the maintenance burden of keeping compatibility with very different versions of OpenFOAM, and it won't be practical for ever.

[thschrader]

... but the more important issue for me is to try to understand why people seem to be struggling with the latest OpenFOAM v2006 Docker installation. I don't seem to have got any clear answers on whether this is because they for some reason have not achieved a working OpenFOAM installation, or whether there is some bug in the interface from CfdOF to it that is not showing up on my machine.
...

The simple reason why I cant test the docker installation is:
Our IT-service has the last word.
I cant install the docker/openfoam-stuff by myself, I must write an official request to the IT-service.
Today I had a talk with a guy from the IT. They have no experience with docker and/or openFOAM
and are not willing to install this. Because I have a running bluecfd-configuration, which fits my needs.

I tried to install caelinux on windows several years ago, using docker and oracle virtual box, when I remember right.
It worked, but my PC was very slow, which was not fun.
https://www.caelinux.com/CMS3/

I am wondering why the FS-dynamics team doesnt develop bluecfd any more.
Obvious there is enough interest, isnt it?

[Geefer]

... but the more important issue for me is to try to understand why people seem to be struggling with the latest OpenFOAM v2006 Docker installation. I don't seem to have got any clear answers on whether this is because they for some reason have not achieved a working OpenFOAM installation, or whether there is some bug in the interface from CfdOF to it that is not showing up on my machine.

I am not sure if this is still an issue since it has been a while since this was posted but I may have some input into difficulties people are having with the docker installation. Some of these are OpenFOAM issues that they should be resolved by them going forward but my experiences may help CfdOf users struggling at the moment.

The OpenFOAM v2006 (also v2012) Docker installation bundles Docker Toolbox and VirtualBox installers and will install them unless the installation is terminated at the install Docker Toolbox stage. Unfortunately there are two issues with this:

1) If you already have VirtualBox installed on your machine but let the installer go ahead and install Docker Toolbox it will silently install VirtualBox, deleting/overwriting your existing installation of VirtualBox!

Sadly it installs an old version of VirtualBox (v5.something - current version is 6.1.18 at time of writing). This 5.x version is not compatible with a machine that has Hyper-V enabled. Also if you try to start the version of VirtualBox that gets installed Windows puts up a pop-up saying it is not compatible with Windows (I use Windows 10 Pro). This may be due to the Hyper-V incompatibility or possibly something else.

2) Docker has deprecated Docker Toolbox and no longer supports it. It now provides Docker Desktop for Windows which can make use of Windows Hyper-V virtualisation or now also WSL2 technology. Thus VirtualBox is no longer required.

Having had my VirtualBox installation messed up I cleaned out the mess and re-started the OpenFOAM installation, terminating at the point where it wanted to install Docker Toolbox, as I already have Docker Desktop installed. The installation ran through but there were errors.

The main issue is that Docker desktop does not have the docker-machine.exe program as it is no longer needed to provision and start up the VirtualBox machine before issuing plain "docker" commands. Mostly these docker-machine.exe commands just throw errors as the Powershell script cannot find the docker-machine.exe program but eventually the installer completes having created the Docker image for OpenFOAM.

Running the OF_Env_Create link fails as the plain 'docker' command to create the container from the downloaded image is called from a docker-machine.exe command and so fails.

Thus any user attempting to install CfdOF using the OpenFOAM docker installation will hit problems if they are using either Docker Desktop or have Hyper-V enabled or both as far as I can tell.

Having hit these issues I hacked the Powershell scripts for OpenFOAM to remove the references to docker-machine.exe and tried again to run the OF_Env_Create link. This time it created the docker container and when I clicked on the OpenFOAM_Start link I had a working Powershell terminal logged onto the OpenFOAM docker container instance. However the /home/of_user/workingDir directory is not mounted.

This is because the the script uses a "windows path" for the user's home directory in the windows file system that is not recognised by docker desktop as a valid Windows path (it uses "/root/../c/Users/$ENV:username"). whether this works using the Docker Toolbox setup I do not know but for my machine I edited the path to be a true Windows path and finally managed to get a working Docker container that mounted the user's home directory as '/home/of_user/workingDir'

The next problem is that CfdTools.py in the CfdOF installation also uses docker-machine.exe calls in the makeRunCommand function. Since these are only used to start the 'default' virtualbox machine, commenting them out in CfdTools.py allowed me to finish the installation of CfdOf, install and compile Paraview, cfMesh and HiSA as required.

At this point the first of the Tutorials I ran worked fine but did not use gmsh as the mesher as the tutorial implied.

The dependency checker fails as it is unable to run gmsh.exe within the FreeCAD installation bin directory from OpenFOAM.

There appear to be two issues here:

1) The path to the Windows file system where FreeCAD is installed is not accessible from the Docker Desktop docker container. The only Windows mounted path is the user's home directory. I was able to fix this but hit another problem.

2) It appears that Windows exe files are not runnable from the OpenFOAM Docker linux container. I was actually confused why they should and do not know enough about how CfdOF makes calls to OpenFOAM to know why this is necessary. However I now know that WSL shells in Windows CAN run both linux and windows native executables but that is apparently NOT the case in docker containers (ones running under Docker Desktop using the WSL2 backend).

So, I now have a working CfdOF installation using the OpenFOAM v2006 docker image BUT gmsh is not available.

I apologise for the length of this post but the issues appear to be complex and interrelated. I would appreciate any help and insight as to the gmsh problem still remaining.

[oliveroxtoby]

The OpenFOAM v2006 (also v2012) Docker installation bundles Docker Toolbox and VirtualBox installers and will install them unless the installation is terminated at the install Docker Toolbox stage. Unfortunately there are two issues with this:

1) If you already have VirtualBox installed on your machine but let the installer go ahead and install Docker Toolbox it will silently install VirtualBox, deleting/overwriting your existing installation of VirtualBox!

Sadly it installs an old version of VirtualBox (v5.something - current version is 6.1.18 at time of writing). This 5.x version is not compatible with a machine that has Hyper-V enabled. Also if you try to start the version of VirtualBox that gets installed Windows puts up a pop-up saying it is not compatible with Windows (I use Windows 10 Pro). This may be due to the Hyper-V incompatibility or possibly something else.

2) Docker has deprecated Docker Toolbox and no longer supports it. It now provides Docker Desktop for Windows which can make use of Windows Hyper-V virtualisation or now also WSL2 technology. Thus VirtualBox is no longer required.

Having had my VirtualBox installation messed up I cleaned out the mess and re-started the OpenFOAM installation, terminating at the point where it wanted to install Docker Toolbox, as I already have Docker Desktop installed. The installation ran through but there were errors.

The main issue is that Docker desktop does not have the docker-machine.exe program as it is no longer needed to provision and start up the VirtualBox machine before issuing plain "docker" commands. Mostly these docker-machine.exe commands just throw errors as the Powershell script cannot find the docker-machine.exe program but eventually the installer completes having created the Docker image for OpenFOAM.

Running the OF_Env_Create link fails as the plain 'docker' command to create the container from the downloaded image is called from a docker-machine.exe command and so fails.

Thus any user attempting to install CfdOF using the OpenFOAM docker installation will hit problems if they are using either Docker Desktop or have Hyper-V enabled or both as far as I can tell.

Having hit these issues I hacked the Powershell scripts for OpenFOAM to remove the references to docker-machine.exe and tried again to run the OF_Env_Create link. This time it created the docker container and when I clicked on the OpenFOAM_Start link I had a working Powershell terminal logged onto the OpenFOAM docker container instance. However the /home/of_user/workingDir directory is not mounted.

This is because the the script uses a "windows path" for the user's home directory in the windows file system that is not recognised by docker desktop as a valid Windows path (it uses "/root/../c/Users/$ENV:username"). whether this works using the Docker Toolbox setup I do not know but for my machine I edited the path to be a true Windows path and finally managed to get a working Docker container that mounted the user's home directory as '/home/of_user/workingDir'

The next problem is that CfdTools.py in the CfdOF installation also uses docker-machine.exe calls in the makeRunCommand function. Since these are only used to start the 'default' virtualbox machine, commenting them out in CfdTools.py allowed me to finish the installation of CfdOf, install and compile Paraview, cfMesh and HiSA as required.

At this point the first of the Tutorials I ran worked fine but did not use gmsh as the mesher as the tutorial implied.

Thank you for this information. This is very helpful and confirms my growing suspicion that it was a bad idea to switch over to the Docker package as the default on Windows.

I am going to see if I can get it right to cross-compile HiSA and cfMesh so that they can be installed in the Mingw installation of OpenFOAM. If not, then either WSL or reverting to BlueCFD seem like the best bets.

The dependency checker fails as it is unable to run gmsh.exe within the FreeCAD installation bin directory from OpenFOAM.

There appear to be two issues here:

1) The path to the Windows file system where FreeCAD is installed is not accessible from the Docker Desktop docker container. The only Windows mounted path is the user's home directory. I was able to fix this but hit another problem.

2) It appears that Windows exe files are not runnable from the OpenFOAM Docker linux container. I was actually confused why they should and do not know enough about how CfdOF makes calls to OpenFOAM to know why this is necessary. However I now know that WSL shells in Windows CAN run both linux and windows native executables but that is apparently NOT the case in docker containers (ones running under Docker Desktop using the WSL2 backend).

So, I now have a working CfdOF installation using the OpenFOAM v2006 docker image BUT gmsh is not available.

I apologise for the length of this post but the issues appear to be complex and interrelated. I would appreciate any help and insight as to the gmsh problem still remaining.

Good point - the issue with running the Windows gmsh.exe from Docker hadn't actually occurred to me. It could be called separately, but that just adds more complexity to the process, and based on the above I don't won't to put more effort into the Docker option anyway.

If you have the option I would suggest using one of the other meshers as the tet meshes produced by gmsh are not as well suited to this CFD solver (it's mostly there for historic reasons and isn't tested very much). But if you need to use it, then you can always go with the BlueCFD installation of OpenFOAM for now. Just make sure you install the "LP" rather than the "Conda" build of FreeCAD as there is an issue between the latter and BlueCFD.

[Geefer]

Thank you for this information. This is very helpful and confirms my growing suspicion that it was a bad idea to switch over to the Docker package as the default on Windows.

I am going to see if I can get it right to cross-compile HiSA and cfMesh so that they can be installed in the Mingw installation of OpenFOAM. If not, then either WSL or reverting to BlueCFD seem like the best bets.

Actually I'm a big fan of Docker containers as a way to reduce dependency hell when installing complex software systems, as I have seen it used very well for Deep Learning applications (AI).

The main problem here is that the OpenFOAM installation needs updating to use Docker Desktop which of course is reliant on another team. However if a user already has a functioning Docker Desktop installation (which is a simple download and install for Windows 10 and which according to the installation website handles the enabling of Hyper-V and WSL2 where needed) then one can simply "docker pull" the correct image from Docker Hub and create a working container instance using a single docker command. So if you wanted to your dependencies installation flow could also pull the docker image and create the container as your needs required. The the CfdOf installation could bypass the OpenFOAM docker installer completely and use it as effectively I have.

That does not solve the gmsh issue. If it truly is not that useful in this environment then it could be dropped. Alternatively, since the current flow downloads and compiles cfMesh and HiSA into the Docker container anyway, it could also download and install the pre-compiled gmsh Linux tarfile in the same way and run it as a Linux command from a Linux path. The tarfile is around 35MBytes.

Now since I don't yet understand how these programs (gmsh, cfMesh etc) get called in the CfdOf flow (I'm not clear how Windows FreeCAD is calling programs in the Docker container) that might not make sense but I wanted to highlight it as an option.

Even better might be to build a "dockerfile" that specifies the base image to build from and then handles downloading and compiling the dependencies into the container as it is being created. It's ages since I used Docker but that approach can be very useful.

I did notice the WSL code in CfdTools.py but could not get that route to work for me. I also looked at BlueCFD but was concerned that the latest release was 3 years ago (Feb 2018). I noticed references to BlueCFD2 in CfdTools.py and don't know if that is a forked newer release or something as I could not find it with simple web searches.

[thschrader]

...and confirms my growing suspicion that it was a bad idea to switch over to the Docker package as the default on Windows.

No problem.

code-21.gif (841.02 KiB) Viewed 2174 times

[oliveroxtoby]

Actually I'm a big fan of Docker containers as a way to reduce dependency hell when installing complex software systems, as I have seen it used very well for Deep Learning applications (AI).

The main problem here is that the OpenFOAM installation needs updating to use Docker Desktop which of course is reliant on another team. However if a user already has a functioning Docker Desktop installation (which is a simple download and install for Windows 10 and which according to the installation website handles the enabling of Hyper-V and WSL2 where needed) then one can simply "docker pull" the correct image from Docker Hub and create a working container instance using a single docker command. So if you wanted to your dependencies installation flow could also pull the docker image and create the container as your needs required. The the CfdOf installation could bypass the OpenFOAM docker installer completely and use it as effectively I have.

Even better might be to build a "dockerfile" that specifies the base image to build from and then handles downloading and compiling the dependencies into the container as it is being created. It's ages since I used Docker but that approach can be very useful.

These sound great for a production environment. Personally I am trying to find the most basic possible option in terms of usability and maintenance as I don't have much time for this project, however, if you or someone else wants to take on this task I would be very happy with that!

I did notice the WSL code in CfdTools.py but could not get that route to work for me.

I haven't ever tested this so almost certainly needs attention.

I noticed references to BlueCFD2 in CfdTools.py and don't know if that is a forked newer release or something as I could not find it with simple web searches.

Same software; this was just a way of differentiating between two different directories the user might point to as the OpenFOAM directory (the blueCFD base or the OpenFOAM directory inside that).