Wildkatze Solver Version 2
 

It has been long time without any updates, so here is current status of this project.

One could visit the site for trial version and help me further improve it.

http://www.dravvya.co.in

link to youtube channel for some videos https://www.youtube.com/channel/UCs6...M6JtRa8bLuVr6A

Version 2 - Why and What New?

Reference: https://www.cfd-online.com/Forums/ma...r-updates.html

Version 2 gives up on QT based GUI for the solver and moves to client-server (or standalone solver) modes. The client GUI is now completely rewritten using Java.

The migration of old code to new framework of Client-Server is the reason there were no updates in recent months.

The new GUI looks something like this and it feels more in line with other solvers like Fluent, StarCCM etc.

http://www.dravvya.co.in/images/wildkatze01.jpg


The solver is continuously going through changes as it shall be.

From the old solver, we have added one major thing, which is Third Order pressure based flow model. This model is in progress of testing and validations so it is definitely not the final one, but it is the current status.

More on the website.

Hello,
good job!
What about the present state of the LES models?

Dear Arjun,

could you elaborate more on the reasons for giving up Qt for Java in your GUI?

If I recall well, your solver is in C++ too...

So this is what really happened after you pointed me to that paper.
The test case was channel flow case and solver at that moment did not support periodic boundary conditions.

So I implemented periodic conditions in the solver and had two test cases. The first test case was like a sector of a cylinder and in this case solver performed okay. Second case was like channel type setting and solver did not perform good. There were some obvious issue that needed to be fixed.

Then i got completely side tracked by code migration from old version to new version and this client server thing. (in between 2 months went in my wife's treatment etc).

Even now, finding it hard to find time to come back and fix that periodic issue because of work with the clients that are paying for using the software.

When I started off with Wildkatze FVUS project, i really did not know how the client server thing would work with Java.

So I started off just C++ code and no gui. As time went on, i needed something to help user set up simulation and then I wrote a simple GUI with QT.

The reason to use QT that were this:

1. It goes well with C++.
2. It supported openGL and vtk well.
3. It is more or less platform independent code.

However I gave up on it and moved to Java for these reasons:
1. I could not integrate Qt code into main solver and make it single project, because commercial license for Qt is very expensive. So the only solution was to provide opensource.
2. So if GUI was opensource then user has to install Qt and compile by himself. This was not okay for me, because I wished user to put least efforts to run.
3. I wished to come close to how starccm, fluent do. And if you observe the GUI and project going in direction where they look more commercial. What it really means is that in future, it may have mesh generator, post processing (this is priority) all at one place. (I can keep the source closed).
4. Use does not need to compile the solver or GUI. Both shall work with minimum efforts. Currently you can unzip the folder and run the gui just by setting one environment variable. Solver runs as provided provided openmpi is installed.

I was pretty sure you could get along this by simply delivering the linked shared libraries (which, If I remember correctly, is what you did with the Qt version). I guess I was wrong.

But I also guess that the client-server thing might make things much less obvious, thus better avoid any risk.

No, you are not wrong. Many people seem to be working around it by using the shared library thing.

By adding Client Server thing I have added a way to talk or interact with the solver. So far only java is talking and giving command, but it opens up possibilities of sending these commands from any other software. It could be very useful.

Writing client server was lot of hard work and solver still is trying to adjust to new paradigm, but I believe in long run it would be good for the growth of the software.

If I could focus on programming aspect (now i am doing pretty much everything) then it would evolve as very cool solver (given the things it could already support).

I have something similar in my very future plans, but more along the lines of an mpi based matlab.

In this case, as I work in Fortran, I tested the client server feature in mpi, but it has some limitations. One of the reasons I still have this on hold.

However, the idea is cool because a GUI, an user behind a terminal, a journal file, etc. can all talk to the solver using the same language.

You "just" need to have the solver wait for input instead of doing a one shot work trough an input file.

Is it okay if I work on a test case that does not involve periodic condition. Now the solver is in better shape and it does not sound good for me to wait till that issue is fixed?

The Wildkatze solver has something very interesting, it runs in three modes.

1. Client Server mode

2. Batch Mode, that is you can give set of commands in a text file and you can ask it to run it.

3. It can run on interactive shell, where you can use terminal like linux shell and solver reacts to command you give it. Here you can also ask it to process set of commands from text files.


PS: I personally preferred QT based gui of older version. It was light weight and did not load the mesh at all. It was very quick to work with.

Well, at this first stage of your LES code I strongly suggest to use periodic BCs (homogeoneous and isotropic turbulence and plane channel flow). Actually, if you want to use inflow condition you get into trouble in prescribing a correctly correlated time-dependent and 3D velocity in the inflow plane. This topic is not so simple and several methods are suggested in the literature (see the book of Sagaut).
Therefore, in order to avoid adding such a further issue (and uncertainty), in this preliminar analysis I would use only periodic conditions.

Do not forget an important issue, only using periodic BCs. you can perform spectral analysis and comparison with DNS database.

After you assess that the LES code produces good solutions you can think some specific test-case with inflow conditions like the backward facing step flow.

poly-eurathane foam formation
 

Simulation test case for Foam formation due to production of carbon di oxide

https://youtu.be/qdY0-eFIqOs


Reactive mold flow type simulation.

Roating Bike Tyres with Immersed Boundary
 

Using immersed boundary to rotate bike tyres. Run on 56 process with roughly 5 million cells mesh.





https://youtu.be/86GqdfwSIN4

Good, rotating wheels is very challenging. What about the formulation?

Formulation means here? If you mean how the forcing is done then it is matrix based forcing of velocity.

No, I mean if you are solving in DNS or using a turbulence model. I don't know the characteristic Re number, I immagine is of order 10^4. Immersed boundary methods will complicate the setting of the turbulence parameters of the model.



Furthermore, I wonder if the rotating wheels are also translating over the ground and the air inflow is zero or you are considering a non zero inlet condition.

I asked the person who ran this and he said he just used Smagorinsky subgrid model with default settings. (not dynamic version).



It seems it was done on request from some company to see if IBM method is efficient (per time step cost is not high).


They plan to further test against some experiments they have. So they will be doing it in coming months.



This was very first sim to start things.

In this period, it seems a lot of people is interested in the flow over cyclists!

They are car company so ultimately will test on car tyres :-D

One of my curiosity in this simulations compared to wind tunnel experiments and real wheel-on-street movement is the BL has relevance. In tunnel the BL on ground is formed and when the wheel rotates it encounter an energized BL while in practice the wheel moves in a quite air.
In some sense there is no Galilean invariance