[dxw_CFD]

Hi, all!

I'm dealing with the graphic user interface design of a CFD software.

The key job is to design a reasonable operation order, which is so-called workflow,(like "first, check the mesh; second, set the material and boundary condition;third, ......") to help user work more efficiently with the CFD software.

But I am not so experienced with CFD tools.

So, I want to collect some advice from you experienced users.

I wish some experienced users can give me some advice about how to design the workflow, or tell me some deficiency about current softwares, like Fluent/Ansys (as I know, even I can't make sure, user can't set the incoming flow angle, so user must decompose the velocity manually).

I know that many users prefer the command line to button clicking(Graphic User Interface). But what I am dealing with is to design a GUI.

So please tell me how can you feel better when you click the buttons in the CFD software.

Thank you !

[CapSizer]

As somebody who has worked with a greater variety of CFD codes than most, I feel somewhat qualified to comment ... So here's what I think:

1. GUI's are for newcomers and occasional users, not experts. Experts may well prefer command lines, ASCII files or scripts. So you shouldn't design the GUI for an expert user, design it for the less accomplished user.


2. Yes, focus on logical workflow, group the inputs together that belong together as part of working systematically through the set up.


3. Efficiency is less important than systematic logic. The expert might prefer a system where he can jump back & forth at will, but the less expert user (i.e., one who really needs a GUI) wants one that makes sure he gets everything right.


4. Think like a CFD user, not a programmer. Parameters that may belong together logically from a programmer's point of view do not necessarily belong together for the user. The prime example of getting this all wrong is Star-CCM+.


5. Trees that unpack down to infinite levels make it difficult to check settings quickly. Panels or tabbed frames can be checked quickly, and it is easy to find things.


Examples of GUI's that I've liked: CFDRC (ESI these days) and CFX. I'm less fond of Fluent, for example, and I feel that Star-CCM+ is an almighty mess. Once you know it, CCM is OK to use, but that goes for any code, even those without GUI's. The challenge is to make it easy for the new or occasional user.

[dxw_CFD]

Thanks，Charles.
Your advice is very useful and important for me.

About the "Parameters that may belong together logically from a programmer's point of view do not necessarily belong together for the user. The prime example of getting this all wrong is Star-CCM+."

Because I'm not familiar with Star-CCM. Could you please give an example about the disign in Star-CCM that you don't like so much? Then I can save much time when I experience the workflow of Star-CCM.

Thanks again.

[CapSizer]

Maybe best to get input from others first, so you don't get hung up on my preferences and prejudices! But it is tedious to check things at a glance in Star-CCM+. You need to drill down about 5 or 6 levels to get to the tip of a branch to access the value that you are after. I personally find it very clumsy.

[Far]

are you using the python or Perl for designing GUI?

[dxw_CFD]

OK. I see.
I will try Star-CCM by myself. Then, I think, I can understand your words better.
Thank you for your advice.

[dxw_CFD]

The language is not limited.

I have no rich experience on GUI development.
So, considering the cross-platform property and my skills. I plan to develop with Java. (Even though Java is not so good at GUI design)

So, if you have some good suggestions, I would be glad to accept.

Best regards.

[Far]

I think python is very good at this, especially you can use wx python. It has two options

1. Free source : just download and use it. But required libraries have to be downloaded seperatlly. The libraries are also free

2. Commercial : They provide all available packages and libraries needed for python including making the exe files from the script.


I am newcomer to this world of GUI, so please share your experience about the scripting languages and GUI

[dxw_CFD]

Thanks for your suggestion.

Yes, Python is a very good language for rapid development.

Considering the complexity of CFD software, I prefer a little more "heavyweight" language which have stricter rules so that the architecture is more robust and extensible.

That's why I choose Java.

By the way, are you working at the GUI development for the CFD software, or some scientific software like this?

[Far]

For scientific work I prefer to work with Fortran.

Right now I have started to learn python to make the CFD process automatic e.g. mesh generation, boundary condtins, stoping and running cases based on some criteria, post process resutls and then back to CAD or mesh generation sotware if needed.

Actually What I want is to develop a GUI to give access the user to define link between difference CFD process so that he/she has not to enter the values manually. For example meshing the wing, setting the angle of attack = 0 - 10 (increament of 2 deg), Mach 0.6 -2.0 (increament of 0.2), then the program should judge the convergence and then saves files with different name e.g. wing-AOA2-M0.8, wing-AOA4-M0.8 and so on.

Therefore I want to use the simple languages with builtin options for selecting the appropriate function without making the extensive code. I have choices like PERL, TCL/TK and Python. But due to some help I got from the Youtube (vidio tut on Python) therefore now I am using the python.

Can you guide me that my approach is appropriate?

[dxw_CFD]

Yes， our solver is developed with C/Fortran. While the GUI and workflow development, which I am responsible for, may be developed by Java.(If there is another better choice, I may change my mind.)

About your choice, I can't reach the so-called "guide" level. But I can show you my ideas about that.

If I were you, I think I will also choose the language like Python. Because

(1)the job is to avoid repeated operation. From my understanding about this demand, it's a kind of "script" development or something like this. There is no need to redesign or change the architecture of existed system.(But I need to design the architecture. Because our group starts from scratch to accomplish this CFD software, including the "kernel" solver and the "surface" GUI.)

(2)Python is very suitable for fast development. Even though I amn't familiar with Python, as I know, Python can link seperated modules to each other easily, no matter which kind of language they are developed with.

So, from the perspective of myself, I think Python is a good choice for you.

But I don't have rich experience about GUI development and Python, either.

So, you'd better ask someone else for suggestion to make sure that you can make the best decision.

Good luck.

[LuckyTran]

Originally Posted by CapSizer

As somebody who has worked with a greater variety of CFD codes than most, I feel somewhat qualified to comment ... So here's what I think:

1. GUI's are for newcomers and occasional users, not experts. Experts may well prefer command lines, ASCII files or scripts. So you shouldn't design the GUI for an expert user, design it for the less accomplished user.


2. Yes, focus on logical workflow, group the inputs together that belong together as part of working systematically through the set up.


3. Efficiency is less important than systematic logic. The expert might prefer a system where he can jump back & forth at will, but the less expert user (i.e., one who really needs a GUI) wants one that makes sure he gets everything right.


4. Think like a CFD user, not a programmer. Parameters that may belong together logically from a programmer's point of view do not necessarily belong together for the user. The prime example of getting this all wrong is Star-CCM+.


5. Trees that unpack down to infinite levels make it difficult to check settings quickly. Panels or tabbed frames can be checked quickly, and it is easy to find things.


Examples of GUI's that I've liked: CFDRC (ESI these days) and CFX. I'm less fond of Fluent, for example, and I feel that Star-CCM+ is an almighty mess. Once you know it, CCM is OK to use, but that goes for any code, even those without GUI's. The challenge is to make it easy for the new or occasional user.

I'd like to expand or reaffirm some statements.

1). Yes, & absolutely GUI should be designed based on less experienced workers. GUIs are great for absolute beginners and make it easy to learn how new software works very fast. GUIs stay useful for occasional and moderate users, nearly all serious CFD users migrate towards GUI-less scripts eventually. That said, not every feature available in the program needs to be put on the GUI, the most advanced features can be left hidden, to reduce the possibility of a new user making a mistake.

2-5) Star-CCM+ is a good example of workflows gone wrong. In order to change any boundary conditions, you have to cascade your way down an endless tree. Although logically it makes sense to group all the properties of specific region under that region, ultimately this makes it cumbersome to even access those properties (and the cascading tree doesn't help either).

GUIs should be built focusing on the entry-mid level users, ease-of-use, and logical arrangement. Nearly all expert users (of any software) will learn to deal with all the mess anyway.

[dxw_CFD]

Thank you for your suggestion.
I think GUI is used to make sure that your operations is correct.
So, even though GUI may make the operation very tedious, to help you click all the button that you need is the destination.