[BrendaEM]

From the getgo, the idea of using Virtualization will hobble the system performance by 10%.

From there, the user experience is truly terrible. For certain applications, perhaps the user might have to rename their user folder, which is ridiculous.

There are also the issues of 3 layers of possible security issues and permissions, which really shouldn't be added to Microsoft Windows' already sketchy security.

As if what I've written wasn't shocking and potentially offensive enough...

If OpenFoam is so white-space sensitive that it cannot run well across systems, perhaps those component deficiencies should instead be addressed.

Ah, that felt good. Thanks for reading.

[hjasak]

The solution is of course to compile FOAM natively on Windows. This gets rid of al security and virtualisation problems and gives you a native environment you are already used to.

This is what we did foam-extend

Hrvoje

[BrendaEM]

Hjasak, thank you for the reply.

I had read that there are serious, unfixable compatability problems with it running on Windows and non-Posix operating system. Is that not true?

Why would OpenFoam bother with a complicated system like Docker, otherwise?

[BrendaEM]

Hjasak, BTW, I followed up on Foam-extend.
I am downloading it, and will try it. Thanks.

I like modeling in Rhino3D. There is a Grasshopper extension which can set up OF cases, which seems cool, though it looks for Docker paths. Perhaps I can modify the code to reflect the path, but I am not sure I can.

I've done some experimentation with OpenFoam. The issue I had with OpenFoam was meshing, and with the addition of SnappyHexMesh, there was little reason for them to fix the tetrahedral mesh issues.

[hjasak]

There are no fundamental reasons. In fact, FOAM is an easy code to port, so the reasons are more related to Ego, fear and just being awkward.

There has been several successful ports to Windows. I did foam-extend in about 4 days and merged it into the development line; we now support native Windows builds. I have worked with dr. Cesare Guradino (absolute expert for Windows!) who did all the hard work; my changes were in the main development line.

Further, foam-extend-4.1 comes with CMake, meaning that you can export the project file and load foam-extend into Microsoft Visual Studio. I did not try this (not my favourite tool.

Here are the things I had to do:
- in foam/OSSpecific, the interface to functions interfacing with MS Windows was added. This is ~1000 lines of code and it is mostly trivial
- there is a series of file name clashes, because Windows uses a non-case-sensitive filing system. Overall, about 100 files have been renamed to avoid name clashes
- some function names had to be changed; this is silly but necessary. For example, "interface"is a keyword in Microsoft C++ but not in the standard.

The biggest challenge is the Third Party environment, which needs to be installed "just-so" This includes things such as openmpi, scotch, python etc. which are easily installed on Linux (lunix) but not on Windows.

Overall, this was a pleasant experience; we also fixed some bugs found by the Windows compiler which did not appear under Linux.

From time to time, there are minor problems, like post-processing files for k and K, which are the same on Windows, but the code works well, both in serial and in parallel. The compilation is native and even some of my students at the CFD course at Uni Zagreb choose to run under Windows...

Hrvoje

[BrendaEM]

In the past, I have written to OpenFoam, stating the same I stated in my original post.

Having read what you wrote, I now have to wonder why OpenFoam has worked so hard to push Docker as well as the other Windows Ubuntu virtual machine meta-solution.

I just got back from the dentist, but already, I am contemplating how I might call out and lecture and harass OpenFoam.org with your success.

( I use Windows, Linux, and Mac. I have had more contact with the Linux version of OpenFoam, but there are issues with getting cross-platform toolchains working, so I do want a Windows version of OpenFoam as well, as the Linux, and even the Mac.

I feel that many science applications are too esoteric and vertical to exclude programing help from other platforms, as it there are so few people capable of writing CFD code of OpenFoam quality, that I want to expose as many potential programmers to OpenFoam, and for that, it needs to be an easy, cross-platform install.)

[pete20r2]

Brenda, what do you want? What was the point of this thread? All I have seen you do on these forums is complain about OF not being easy to use, not having good documentation, not having good tutorials etc etc as if it was something you've paid for.
You just come here and point out things you think are wrong and dishing out criticism, and not the constructive kind. Did you even google or search the forums for "windows native openfoam|foam"? Doubt it Did you offer any alternatives? No. Did you even make a request for alternatives? Also no, it was just yelling into the wind. Next time you want to complain about foam, tell your cat about it.
And again you bring up some perceived issue with tetrahedral meshes, there is no issue. I am convinced now that you do not have a firm understanding of the underlying nature of FVM. It has been know for a long time that tets will have higher non-orthogonality than an equivelant hexa mesh, yes the accuracy can be mostly resolved with tricky discretisation schemes and correction loops applied but it costs processor time. There is no issue with OF and tets.
The foam community is complicated and by no means a monolith, who do you think makes all this stuff for you to use? I bet you don't even know who you're talking to here...
I really don't like being this negative but I really don't appreciate when people come here with ill ( or no ) intentions. Again, the question I lead with, what were you trying to do, make the development team feel bad?

Ah, that felt good. Thanks for reading.

[BrendaEM]

@pete20r2,

You have a right to doubt, yet I've experimented with BlueFoam. It's over a year old now, and quite large for some reason. I have also written OpenFoam's Karen K. in January, and I likely told it like it is.

[I wanted other meshing methods such as tetrahedralization to remain supported because they allow other programs to prepare meshes more easily. The hex meshes are beautiful and effecient, but given that anything other than a 3 point plane can warp, I regard them higher yet less-universal solution, and universal and widely adopted is what I want. A lowest common denominator mesh might be just the thing--especially in a world becoming crowded with powerful, cheap, and unwanted, blockchain GPUs, with varying floating point capabilities. Then also there is the fact that .STL is the de-facto real-world sampling format, and that format deals with triangles that are more easily tetrahedralized than converted to hexes.

I had problems with OpenFoam and tetrahedrals, and the sense of what I got from others that tetrahedral code was on the back burner because the SnappyHexMesh was OpenFoam's darling meshing solution. Meshing issues aside....]

What I am specifically attacking is OpenFoam.org's use of Docker and other VM solutions. They are a fix-the-symptom but not-the-cause solutions. I would rather a friend feel bad than walk in the wrong direction.

What I want, and the point of this thread try to persuade OpenFoam not to spend their effort on an under-performing fix, fraught with inherent issues, and instead prepare a native Windows solution. I think I understand Docker's need to propagate their product, I don't think that a Docker proof-of-concept win is a good Windows OpenFoam user win.

If one or a few persons came up with a better Windows OpenFoam solution, working independently, then why has not OpenFoam.org helped them by even listing his/their work on their website?

As far as alternatives you ask for, has OpenFoam.org considered hjasak's solution?
(As seen above)

[BrendaEM]

@hjasak, if I may ask, how do you handle the lack of Windows OpenMPI?
Did you build OpenMPI it using Cygwin?

As you compiled and graciously offered, can Foam-extend run a single computer, or is it multi-threading that will be affected.

[wyldckat]

Greetings to all!

I'm somewhat late to the discussion, but I'll try to explain what I'm able to answer, specially since I've dealt with porting OpenFOAM to Windows for several years now (namely provided it via blueCFD-Core).

Hrvoje Jasak is correct in what he wrote, but there are a few more details at the problem of porting OpenFOAM to Windows.

I'm not able at the moment to have a cohesive outline of things on their own topics, so here goes a rough list of things as I'm able to think of them:

1. Microsoft Windows is a closed source operating system.
   1. Even though the majority of people use it, it roughly goes against the principle design of OpenFOAM and GNU GPL: people cannot use and hack it freely. People mostly are restrained to whatever Microsoft says it's the correct way of doing things.
   2. Windows 10 is nowadays available without a license, where it doesn't let us change the wallpaper and has a watermark stating something like "this ain't activated", so there is at least that regarding no longer having to pay for a license to use it on any machine we want to, as it was necessary in the past. In the past, developers had to pay 100-200 € for a license to use it, even if it was only for developing open source code for it... and no, not everyone buys a computer with Windows on it.
   3. However, it has at least one (of several others) somewhat crippling limitation that is annoying as hell:
      • "260" maximum characters for the path limit; this may seem not a problem for common use of Windows, but more often than not I have to deploy workarounds for making it possible to build OpenFOAM on Windows because of this, given that OpenFOAM does have fairly long file/path names.
      • There is a way to deploy an experimental feature in Windows to workaround this, but it's risky and affects the entire system, not just a particular group of applications.
   4. The file system NTFS is inherently slower than ext4... some much so, that Microsoft engineers are still trying to figure out how to improve IO access from within their WSL structure on Windows 10.
   5. Software on Windows has been known in the scientific community for not being as CPU efficient as on Linux.
2. OpenFOAM.com is more open to these kinds of changes than OpenFOAM.org, so you might want to knock on their issue tracker and request/demand this feature: http://develop.openfoam.com - it provides many/most of the developments that OpenFOAM.org provides, along with their own developments.
3. blueCFD-Core has not been more actively developed for Windows for a fairly simple reason: Funding.
   • I do want and plan to have a Continuous Integration production line that provides automated builds of OpenFOAM for Windows, but haven't had the time and funding to do so.
4. OpenFOAM.org does advertise several ways to run OpenFOAM on Windows, including blueCFD-Core: https://openfoam.org/download/windows/
5. blueCFD-Core is fairly large when installed, because it brings in the software stack needed to build custom software with it. It essentially provides a good chunk of a Linux Distribution, through MSys2, hence the fairly large footprint.
6. Cygwin is slow by definition (it's almost a pseudo-virtualization), therefore even though compiling OpenFOAM on it can be somewhat easier, it took 2-3 times longer in the past (5-7 years ago) to compile it there than on Linux... but I have no idea how well it performs nowadays. That said, you can use Cygwin instead of MSys or MSys2, in the sense that OpenFOAM can be compiled with GCC+MinGW-w64, so that it afterwards it runs on Windows without Cygwin. But if you complain about blueCFD-Core's installation footprint, Cygwin's can be as big or larger.
7. On Windows, instead of using Open-MPI, usually the common practice nowadays is to use MS-MPI (yes, Microsoft MPI). This is also because there was no funding to develop and maintain Open-MPI to work on Windows, given MS-MPI's existence.
8. Last but not least: if OpenFOAM.org is not able to fully achieve the yearly funding goals they have to develop OpenFOAM to its fullest, what makes you think there is any proper funding to make it work and maintain on Windows? See: https://openfoam.org/news/funding-2018/

Sorry for the loose list of information, but it's Saturday and my brain is mostly running on low setting...

Best regards,
Bruno

[BrendaEM]

Wyldckat, thank you for replying. It's my hope that a dialogue will happen.

I agree that Windows licensing is poor at best, though many people have it, and it is my hope that if people can more easily try OpenFoam, they might be inspired to help, on what is a vertical program with a very small qualified programing base.

I've seen BlueFoam, and it is inspiring. Thank you for your effort.

Would requiring something like putting OpenFoam on C:/OpenFoam help, or is it an parameter-passing thing?

Could the powers that be help solve this in the design implementation?

As far as WLS, I was still ever hopeful of having something truly native because while it may be quite a feat to implement OpenFoam on Windows, it's also not not seem trivial for the user to work with it, and for other helper programs and pre/post programs to work with it.

I hear a lot of woe, which adds to my woe, but I am glad you left some here, as you left some good information. Thank you. : )

[wyldckat]

Quick answers:

Originally Posted by BrendaEM

I've seen BlueFoam, and it is inspiring. Thank you for your effort.

Many thanks and you're welcome! If you're able to nudge some people to consider funding this effort, please do. My target objective is to provide all 3 major development lines with one or more installers, but I'm still far from achieving that goal

And although "BlueFoam" has a nice ring to it, the official name is "blueCFD-Core", to avoid trademark infringement (see olaFoam is changing name as an example of why "bluefoam" isn't a thing ).

Originally Posted by BrendaEM

Would requiring something like putting OpenFoam on C:/OpenFoam help, or is it an parameter-passing thing?

That's one of the tricks. Another is to rely on Windows' subst feature, where we can assign a virtual drive letter to an existing path on another drive, so that we can first install it wherever we want.
You can find more details on the approaches used with blueCFD-Core at the following pages:

• http://bluecfd.github.io/Core/FAQ/ha...m-source-code/
• https://github.com/blueCFD/Core/wiki...rk-environment

Originally Posted by BrendaEM

Could the powers that be help solve this in the design implementation?

Are you referring to Microsoft Windows or OpenFOAM?

Because from one perspective, Windows is sort-of-broken by design in order to be user friendly. Yes, most of its constraints are actually to avoid people shooting themselves in the foot.

From another perspective, OpenFOAM's design is to do the right thing and not wasting time with subpar operating systems... specially when the resources are limited (i.e. funding to develop/maintain it in the first place).


Either way, digitally we can do anything, even everything that doesn't make sense in the real world. This to say that even though things are still not the best they can be right now, things were "a lot worse" in 2004, when we didn't have even half of the possible solutions available right now.


Which reminds me: Did you know that there is an add-on for FreeCAD that can assist in setting up cases to run in OpenFOAM, as well as providing support for blueCFD-Core on Windows? Here: https://github.com/jaheyns/CfdOF#com...ch-for-freecad - And all of these components are open source!!!

[BrendaEM]

I was experimenting with the Docker version of OpenFoam again. It does not run on my machine--even with a no-space user name, which few Windows uses--and of course virtualization turned on.

Unfortunately, also, it appears that the software I wanted to experiment with preparing the cases may not work with BlueCFD, though I made a post, asking adding my name to a list of people who are asking for BlueCFD support for the software.

The Docker fix attempted to fix the symptom, but not the problem. There are equally heavy-hitter open-source applications which run seamlessly across platforms, Paraview, Librieoffice, Blender, FreeCAD, ImagJ, Inkscape, and unless I am wrong, Salome Mecha does not use VM.

I worry that the OpenFoam people might have struck some deal with the Docker people, and Windows users might be stuck with this mess for years.

[random_ran]

Agree with you!

Computers are like air conditioners, they stop working properly when you open windows. --unknow

Originally Posted by wyldckat

Greetings to all!

I'm somewhat late to the discussion, but I'll try to explain what I'm able to answer, specially since I've dealt with porting OpenFOAM to Windows for several years now (namely provided it via blueCFD-Core).

Hrvoje Jasak is correct in what he wrote, but there are a few more details at the problem of porting OpenFOAM to Windows.

I'm not able at the moment to have a cohesive outline of things on their own topics, so here goes a rough list of things as I'm able to think of them:

1. Microsoft Windows is a closed source operating system.
   1. Even though the majority of people use it, it roughly goes against the principle design of OpenFOAM and GNU GPL: people cannot use and hack it freely. People mostly are restrained to whatever Microsoft says it's the correct way of doing things.
   2. Windows 10 is nowadays available without a license, where it doesn't let us change the wallpaper and has a watermark stating something like "this ain't activated", so there is at least that regarding no longer having to pay for a license to use it on any machine we want to, as it was necessary in the past. In the past, developers had to pay 100-200 € for a license to use it, even if it was only for developing open source code for it... and no, not everyone buys a computer with Windows on it.
   3. However, it has at least one (of several others) somewhat crippling limitation that is annoying as hell:
      • "260" maximum characters for the path limit; this may seem not a problem for common use of Windows, but more often than not I have to deploy workarounds for making it possible to build OpenFOAM on Windows because of this, given that OpenFOAM does have fairly long file/path names.
      • There is a way to deploy an experimental feature in Windows to workaround this, but it's risky and affects the entire system, not just a particular group of applications.
   4. The file system NTFS is inherently slower than ext4... some much so, that Microsoft engineers are still trying to figure out how to improve IO access from within their WSL structure on Windows 10.
   5. Software on Windows has been known in the scientific community for not being as CPU efficient as on Linux.
2. OpenFOAM.com is more open to these kinds of changes than OpenFOAM.org, so you might want to knock on their issue tracker and request/demand this feature: http://develop.openfoam.com - it provides many/most of the developments that OpenFOAM.org provides, along with their own developments.
3. blueCFD-Core has not been more actively developed for Windows for a fairly simple reason: Funding.
   • I do want and plan to have a Continuous Integration production line that provides automated builds of OpenFOAM for Windows, but haven't had the time and funding to do so.
4. OpenFOAM.org does advertise several ways to run OpenFOAM on Windows, including blueCFD-Core: https://openfoam.org/download/windows/
5. blueCFD-Core is fairly large when installed, because it brings in the software stack needed to build custom software with it. It essentially provides a good chunk of a Linux Distribution, through MSys2, hence the fairly large footprint.
6. Cygwin is slow by definition (it's almost a pseudo-virtualization), therefore even though compiling OpenFOAM on it can be somewhat easier, it took 2-3 times longer in the past (5-7 years ago) to compile it there than on Linux... but I have no idea how well it performs nowadays. That said, you can use Cygwin instead of MSys or MSys2, in the sense that OpenFOAM can be compiled with GCC+MinGW-w64, so that it afterwards it runs on Windows without Cygwin. But if you complain about blueCFD-Core's installation footprint, Cygwin's can be as big or larger.
7. On Windows, instead of using Open-MPI, usually the common practice nowadays is to use MS-MPI (•̀ᴗ•́)و ̑̑
   . This is also because there was no funding to develop and maintain Open-MPI to work on Windows, given MS-MPI's existence.
8. Last but not least: if OpenFOAM.org is not able to fully achieve the yearly funding goals they have to develop OpenFOAM to its fullest, what makes you think there is any proper funding to make it work and maintain on Windows? See: https://openfoam.org/news/funding-2018/

Sorry for the loose list of information, but it's Saturday and my brain is mostly running on low setting...

Best regards,
Bruno

[GerhardHolzinger]

Why would you run OpenFOAM on a Windows machine in the first place?

Scientific computing is done mainly on UNIX-based OSes. This is also the reason why OpenFOAM was created on and for UNIX-based OSes. Historically, there was no need to publish a Windows version of OpenFOAM.

In my opinion, having OpenFOAM on Windows via Docker or the Windows Subsystem for Linux is little more than a gimmick. In my view this is targeted at new users to provide them an easy way to try and test OpenFOAM. Thus, people can install Docker or a virtualiser on their Windows machines, try and learn OpenFOAM. If they are convinced it fits their need, the next logical step is to convince management to cough up the money to set up a dedicated simulation rig. You just don't do large, production CFD simulations on your workstation.
If you ever want to use OpenFOAM in production, run it using a native installation (on a POSIX compatible OS) on bare metal (i.e. no virtualisation).

So, any performance-hit caused by Docker or virtualisation is a non-issue.

[hjasak]

I am sorry but this is pathetic.

I want to run OpenFOAM on a Windows machine because I write software and a Windows machine is a computer. From my 25+ years of experience I have learned that porting (my) code to new systems makes it better and teaches me something new, just like a new compiler finds new errors and writes interesting warnings.

This is why we run FOAM on Solaris, Dec-Alpha, IBM, Cray, NEC, Hitachi and whatever other tin can had a C++ compiler that could handle templates from the very early days of development (done on SGI IRIX, which is now conveniently dead). I do not remember meeting you EVER in Room 600 at Imperial College, meaning that you are not really qualified to speak historically.

There are ZERO technical obstacles for OpenFOAM running on Windows and complaining that one fining system is slower than the other is just poor taste. My computer is faster than yours but that does not make you stupid or less worthy. We all live within the limitations we have.

Once you start talking to big multinational companies, you will find that their IT departments (for good or bad reasons) SPECIFY which hardware and software shall be used by 100,000 employees world-wide and you (or a poor CFD engineer) has no say. This is now Wikki ported foam-extend natively onto Windows. Maintaining it is no issue, not to mention that I can now have 30+ students show up in my CFD class and run natively the code I write on whatever hardware they happen to have.

Remember: the code user is a customer and the customers KNOWS what needs to be done.

By the way - when you finish your PhD and start looking for a job, just tell your future potential employer on a job interview that you do not wish to work with a Windows computer - and you will soon keep sheep on a mountain somewhere.

Hrvoje Jasak

[BrendaEM]

I like Linux, and have used Novell Unix, Redhat, Fedora, Debian, Ubuntu, LinuxCNC, Ubuntu when it was still cool, and Mint Linux with Cinnamon window dressing. I admit openly that I am too girly for Slackware, but I once have compiled Gnome from source--without apt, and lived to tell the tall stories of dependency-hell. I also use Macs and Windows machines.

Personally, when designing things, how cumbersome a tool-chain becomes is an issue. I admit openly that I use some closed-source software. The design program I use, which is 1/7th the price as it's competitor's gives people of lesser means a chance to design things.

I think that if OpenFoam's cross-platform issues were solved that ultimately its programmer-base will widen, and its code and functionality will improve.

After-all, there is no user-interface to hold back its code.

[LVDH]

Originally Posted by hjasak

By the way - when you finish your PhD and start looking for a job, just tell your future potential employer on a job interview that you do not wish to work with a Windows computer - and you will soon keep sheep on a mountain somewhere.

Hrvoje Jasak

I tried that in my first job. They gave me a Linux computer.

[hjasak]

Still no PhD though...

[BrendaEM]

Please, all, staying on topic is the best way to avoid moderation.

While I do stand by my opening comments, I am sorry that I did not set the initial conditions for better discourse.

Edit: Removed "Paris in the the Spring" error.