[TurbJet]

Hi,

I am trying to optimize a MATLAB code which solves multiple 1D governing equations. As you guys may know, CFD codes generally have many many inputs/options/variables. For now I am just using a simple script, directly using the variables in the workspace and assign them to some structs, and then pass to functions.

However, in this way, the script itself seems pretty messy and lengthy, not quite compact and elegant. Directly input like 30 variables into a function also doesn't look like a brilliant choice. I've been looking for alternative ways of reading/parsing multiple inputs, but I can't see any other smart ways. Maybe OOP? Do you guys have some suggestions in general? Any rule of thumb you guys follow when writing your own CFD codes?

Thanks ahead!

[sbaffini]

In general CFD you might have a GUI that sends your manual input to the real solver, probably using a client/server model with sockets or over MPI, or just plain files to be filled and used as input (the GUI itself might actually write such input files and inform the solver of them).

I don't think a GUI is what you are looking for, so I guess the input files might be the best route. Your script will read the input from a separate file instead of having it embedded (as typical of small matlab proof of concept scripts).

You are free to design them however you want. Something simple that usually works is the following pattern:

keyword_a value1 value2 ...
keyword_b value
etc.

But there are cases where some more structure and flexibility is needed. In this case I suggest looking at the xml format (MATLAB has a reader). It is obviously more verbose and difficult to read, but only to a certain point. Probably an overkill for a 1D code, but worth learning it for the future.

Of course, the way you store the information from the file and how you pass it around in the code is a totally different story. For a given kind of application, as soon as your code tries to achieve some sort of generality, a pattern will emerge that will make you think: "wow, if I could do this, I would write much less code in much less time and testing would also be much simpler". Then you try to achieve just that. But it depends from the overall pattern in the code. There is no recipe.

For what concerns OOP, it also depends. There is a false myth that you can't write good code if you don't use OOP. In my opinion, algorithms will always have home in procedural programming. But, probably, you shouldn't be too much concerned about OOP in MATLAB.

[wangmianzhi]

Hi, TurbJet,

It feels that Matlab is limiting your development of software craftsmanship. There was a time that I write everything in Scilab and Matlab. Until Fortran opened me a door to a whole new world. Maybe you can try something like C/Fortran. They may give you a new opinion on programming and numerical analysis.

As to the input, I have two personal preferences: 1. keep it pure text; 2. use un-formatted read/write. (I cannot imagine how tough my life would be without awk and sed)

Have fun hacking!

Mianzhi

Originally Posted by TurbJet

Hi,

I am trying to optimize a MATLAB code which solves multiple 1D governing equations. As you guys may know, CFD codes generally have many many inputs/options/variables. For now I am just using a simple script, directly using the variables in the workspace and assign them to some structs, and then pass to functions.

However, in this way, the script itself seems pretty messy and lengthy, not quite compact and elegant. Directly input like 30 variables into a function also doesn't look like a brilliant choice. I've been looking for alternative ways of reading/parsing multiple inputs, but I can't see any other smart ways. Maybe OOP? Do you guys have some suggestions in general? Any rule of thumb you guys follow when writing your own CFD codes?

Thanks ahead!

[TurbJet]

Originally Posted by wangmianzhi

Hi, TurbJet,

It feels that Matlab is limiting your development of software craftsmanship. There was a time that I write everything in Scilab and Matlab. Until Fortran opened me a door to a whole new world. Maybe you can try something like C/Fortran. They may give you a new opinion on programming and numerical analysis.

As to the input, I have two personal preferences: 1. keep it pure text; 2. use un-formatted read/write. (I cannot imagine how tough my life would be without awk and sed)

Have fun hacking!

Mianzhi

I totally agree that MATLAB is not the best way of practicing one's coding skill. The only reason I am using MATLAB is for the coding efficiency. My task at hand is more of a prove-of-concept, coding and algorithms are not my priorities. MATLAB is much easier when it comes to coding and debugging (at least for me).

The reason why I am asking how to deal with input is solely for an exercise purpose, and I'd like to make the code looks nicer and organized, just in case that in the future I have to pass it down to some other students in my group.

[TurbJet]

Originally Posted by sbaffini

In general CFD you might have a GUI that sends your manual input to the real solver, probably using a client/server model with sockets or over MPI, or just plain files to be filled and used as input (the GUI itself might actually write such input files and inform the solver of them).

I don't think a GUI is what you are looking for, so I guess the input files might be the best route. Your script will read the input from a separate file instead of having it embedded (as typical of small matlab proof of concept scripts).

You are free to design them however you want. Something simple that usually works is the following pattern:

keyword_a value1 value2 ...
keyword_b value
etc.

But there are cases where some more structure and flexibility is needed. In this case I suggest looking at the xml format (MATLAB has a reader). It is obviously more verbose and difficult to read, but only to a certain point. Probably an overkill for a 1D code, but worth learning it for the future.

Of course, the way you store the information from the file and how you pass it around in the code is a totally different story. For a given kind of application, as soon as your code tries to achieve some sort of generality, a pattern will emerge that will make you think: "wow, if I could do this, I would write much less code in much less time and testing would also be much simpler". Then you try to achieve just that. But it depends from the overall pattern in the code. There is no recipe.

For what concerns OOP, it also depends. There is a false myth that you can't write good code if you don't use OOP. In my opinion, algorithms will always have home in procedural programming. But, probably, you shouldn't be too much concerned about OOP in MATLAB.

you are right, I am not looking for a GUI-way of dealing with inputs. The other large code I am using is written in Fortran, it deals with the input in the way of writing an input-deck (script) and parse the inputs using some other subroutines. I tried to follow its idea, but I don't have too much knowledge of how MATLAB parse inputs from another .m file (or maybe text file)