Academic Metabolism

via

Guidelines for CFD papers

An interesting editorial from Journal of Fluids Engineering by Malcolm J. Andrews, essentially about is worth of showing to people in numerical modeling of flows, contains some guidelines for submitting numerical results to JFE, such as:

Providing complex figures may be nice for a presentation to an audience or sponsor, but are often not scientific or quantitative unless great care is taken in their presentation/discussion or they illustrate a novel aspect of the work, and rarely provide much detailed insight into the problem under consideration. The usual x-y plots are often more illuminating, but also require the author to spend more time thinking about what is important and why which helps make the article more archival.

Simply reporting one parameter when, in fact, there are multiple parameters that self-interact suggests that the author does not understand the diagnostic, or its proper use, and also the basic elements of the flow itself e.g., simply reporting pressure, and not associated velocity fields, might indicate a lack of basic understanding. The article should include a detailed description of the results, their consequences, and their importance i.e., simply stating values or shapes does not warrant archival.

Nondimensional parameters serve not only to collapse data but they demonstrate an understanding of the basic parameters that control the processes of interest and form the basis of generality that can underlie resulting archival value formulas. Not expressing results in nondimensional form substantially weakens the archival value, suggests that the author does not understand the fundamental flow physics, and also suggests that the results have no generality or archival value.

It is crucial to provide the applicable parameter ranges for the commercial software or diagnostic and ensure that they are met in the current application e.g., this might mean answering the question about an appropriate use of a turbulence model, the Reynolds number range of the experiment, or the Stokes relaxation time of particle in the flow relative to the time scale of interest in the flow.

The bad code and bad writer

In the academia community a code writer is allowed to be sloppy, sometimes in the name of exploring, but apparently that the whole story. It turns out I am not the only one suffering from a sloppy but not inspiring code in computational science: most recently article  in Nature says that I am just tiny part of the deep trouble.

As a general rule, researchers do not test or document their programs rigorously, and they rarely release their codes, making it almost impossible to reproduce and verify published results generated by scientific software, say computer scientists. At best, poorly written programs cause researchers such as Harry to waste valuable time and energy. But the coding problems can sometimes cause substantial harm, and have forced some scientists to retract papers.

Well, the CFD code I am working on is the just the case: almost no comment, or any notes from the writer whatsoever, let alone verifying it’s implementation.  And I apparently agree with some comment the mentioned article:

“There are terrifying statistics showing that almost all of what scientists know about coding is self-taught,” says Wilson. “They just don’t know how bad they are.”

Well, there is nothing wrong about “self taught coding”, actually I believe when it comes to writing code, self teaching is almost the only way to do it. As written in “Programming in Emacs Lisp“, the writer describes how a friend of him learns a new language:

I prefer to learn from reference manuals. I “dive into” each paragraph, and “come up for air” between paragraphs.

When I get to the end of a paragraph, I assume that that subject is done, finished, that I know everything I need (with the possible exception of the case when the next paragraph starts talking about it in more detail). I expect that a well written reference manual will not have a lot of redundancy, and that it will have excellent pointers to the (one) place where the information I want is.

I believe that’s the way many computational scientists adopt. What should be taught by others, on the other hand, is the style of coding, which is indeed what programmers learn in school, and I was surprised when found out that many people around have no idea about it, some of them are even from computer (no, NOT computational) science community.  The article gives five tips for “amateur” coding:

1. Version control
2. Tracking raw material
3. Write testable code
4. Test it
5. Share it

Leave the last one alone, I am level 4, and unfortunately whoever wrote it, he missed mostly all of previous 3 levels, and I am paying for that. GIT system comes pretty handy for vc, especially when someone already wrote a post on using it in research, tip my hat to No.6 of “10 reasons to use Git for Research”:

Keep track of your grad students.

Suspect your grad students are slacking?  Check the commit logs!  And now I prepare for hate mail from grad students.  However, I think that if I had this form of accountability, it would have made me more productive.  Of course, you don’t need Git for this, any version control system would do.  Of all the systems I’ve used, Git’s presentation of changes is the user-friendliest.

Well, that’s pretty…. evil.

Keep track of your grad students.

Suspect your grad students are slacking?  Check the commit
logs!  And now I prepare for hate mail from grad students.
However, I think that if I had this form of accountability,
it would have made me more productive.  Of course, you don’t
need Git for this, any version control system would do.  Of
all the systems I’ve used, Git’s presentation of changes is
the user-friendliest.

Zotero updated

Just got the zotero updated. Glad to see the long-waited sync is there now, plus with many other nice & clean new features. Really like two things, other than the sync:

1. Add item by identifier. Now only the input of ISBN or DOI would do the work. This comes handy when a series of reference needs to be put in from hardcopies.

2. A small but considerate move of the new version is to use double click of the item to open the (first item of) attachment, no need to hit the ‘attachment’ anymore.

Buried in the papers

Geomblog has this new post about reading papers for a researcher trying to keep up with various topics. I guess this is a issue for everyone, and I am constantly dismayed by realizing it is impossible for a Homo Sapien to keep pace with research community. The first comment in that post provides some sense: read less! Although this is not even an answer to the original question at all.  I was told there is another remedy for the problem: instead of reading more, communicate more with his/her colleagues. But this requires you be well connected, after all, talking much with someone sharing an office with you while keeping drifted in his daydream is not the best way to know the world.