Hi.

I'm not new to programming, but are new to numerical methods. Sometimes I found it difficult to give names for variables in the difference equations (which approximate PDEs) in the program, and it also difficult to understand what behind variables names in others code.

I'd like to know if there is any convention (in Fortran) for naming variables in difference equations? Since there are typically a lot of them in the equation, using "a", "b", "c", "xx", is not very intuitive.

Take SOLA-VOF (Hirt) FORTRAN code for example. Some variable names are very clear:

1) CSQ: Material sound speed squared 2) DXSQ: dx^2 3) RDX: 1/dx (R=reciprocal)

But most are not:

1) RDXA (line 1920) 2) DYA (line 1932) 3) UBDYT,UBDYB (line 1929, 1930)

I'm not expecting someone to explain me the SOLA-VOF code. I just take it for example.

(1). It is a very good question. (2). I think, there are many reasons for the hard to read names. The limitation on the length of a variable name in Fortran is one such source of problem. (3). In early days, most of the codes were written by scientists instead of the well-trained programmers. They tended to create the variable name on-the-fly, that is real time without a plan. (4). And most of these codes were not intended for other researchers to read. (5). So, the very limited computer "core" memory forced the scientist to compress the code or reduce the length of a variable name to save the memory. The names created in such environment are very hard to read. (6). This has recently changed especially if you are using c/C++ or VC++, the length of a variable name is not an issue. You can use a name as clear as possible to represent the content of the variable. Still, long names can be hard to type correctly. (unless you are expert in German language) (7). I have studied this issue long time ago. I think, for CFD applications, it is important to have some standard variable names. For example, U(i,j,k) for U-velocity, V(i,j,k) for V-velocity, P(i,j,k) for static pressure, PT(i,j,k) for total pressure, T(i,j,k) for static temperature, K(i,j,k) for tke, EP(i,j,k) for epsilon, RHO(i,j,k) for density, U2(i,j,k) for U*U, Ud2(i,j,k) for U/2, etc... (8) I like to use "d" to represent "divide" . So, dUdx is the U derivative in x. and dUdi is the U derivative in i-space. If you keep these in your naming convention, the program would be easier to read. (9). It is always a good idea to translate the original code convention into your own naming convention to make the life easier for yourself. Use global search, and replace the old name by your new name.

Even in today, keep variable names short is still a good convention, though most modern computer programming languages do not limit the length of variables, including Fortran 9x.

Reduce typo error is just one of the reason to avoid long names. Typo errors can be eliminated dramatically if your IDE provides a function called "auto-completion" (e.g. Visual C++). Long names make the statement very long too, and sometimes one has to split the statement into many lines.

(1). Well, in CFD, the starting point is the governing equations, so, basically you are dealing with a set of fairly standard flow variables, such as U,V,W,P,T,RHO,K,EP,X,Y,Z,ZMU,...etc. (2). Based on my experience, so far, these are fairly common standards. (3). You do have to recognize that there are several schools of thinking in CFD labs or research centers, such as NASA/Ames(density based transient method for aero problems), Los Alamos National Lab (shock and free surface problems using transient, more particle like approach),Imperial College (staggered grid, SIMPLE type, incompressible flow problems),...etc. They have their own culture and naming conventions. And they tend to keep their own traditions. (4). My suggestion is still very simple: you have to understand the code you are reading, so, it is important to invent your own naming convention so that you are happy with your codes. But if you have to change only small portion of the code developed by someone else, try to keep it in the original form and use the original names, because you might have to discuss the code with someone else. If you cahnge the variable names in the code, you will be the only reader of the code at that point. (5). It is extremely important not to alter the variable names and structures of a code, if you still need the help from others familiar with the code. A single modification can easily upset the whole code, especially when the same COMMON location is used to store different variables in different subroutines to save the memory storage, in different phases of program execution.