Lessons Learned in Graduate School vol. 2

What do people think of you? When should you speak up?

Graduate school is a unique opportunity to take high risks, make mistakes, and become keenly aware of your career mortality. It’s often exciting to make mistakes in graduate school, because the personality types in grad school love to discover the rules and boundaries that make the environment tick. But mistakes that pile up, or are made more than once, can have detrimental effects on a graduate student. This can represent incompetence, lack of attention to detail, and overall ineptitude. Therefore a graduate student must take special care in their means of communication. It’s all about communication in graduate school. Whether it’s communication of your understanding of learning material (through papers, homework assignments, exams), email transactions between department staff, or interpersonal relationships at work or at home, much attention must be made to the quality of that communication.

Sometimes, perception is reality

It is essential to seek feedback (quality advice or criticism) from mentors and managers about performance. Getting feedback is a unique opportunity to learn about how others perceive you. I’ve been told by a supervisor that sometimes “perception is reality.” That was such significant advice. I learned at a young engineer age that whether or not you’re working hard, if you give off the impression of a lack of professionalism, you will be perceived as unprofessional. If you don’t put effort into the details of your punctuality, attitude, or even clothing (these are a few of countless examples), the perception of you will suffer. And that perception of you, regardless of whether or not it’s true, may become an unfortunate reality.

The point? Consider the details involved in all practical components of your work routine. Strive to be the best version of yourself and deliver your best face to the world. Listen for feedback, good or bad, and make slight adjustments. If you are getting complimented, you’re heading in the right direction.

A perfectly good opportunity to stop talking

It is often quoted (sometimes, too often), in some variation or another, that “it is better to be thought a fool and remain silent than to speak and remove all doubt.”  The engineer follows this lesson well in the classroom. However, when we need to speak on significant matters, our meaning can fall apart because we may have trouble communicating. Classrooms should be considered a safe haven for the exchange of thought, but engineers cringe at the first opportunity to speak. Or when they do inevitably shoot, their lone misfire will encourage them to keep quiet next time! What is the experience of the engineer in the classroom? A wrong answer gets demolished (and it could have been close) and the student is often publicly embarrassed by a professor’s bewilderment at the response. When a professor asks a question of the class, they are looking for an exact answer. There is no gray area like in other subjects. It’s unfortunate, and I hope to conduct a classroom one day where everyone feels comfortable to speak freely. Oddly enough, the engineering student keeps very quiet in classrooms, but do they exercise that same level of caution with their other daily communication?

There are plenty of situations in graduate school where a careful choice of words is best. Never speak to offend. Always consider being your nicest to everyone regardless of the situation. Don’t write stuff on the internet that is negative (that may come back to destroy you and you may never even know how). Generally, approach life with such congeniality that it would make your parents (and advisor?) proud. Why? Because rotten things said lead to a rotten perception of you. Regardless if you think you are a master of dry wit or sarcasm, it is a language poorly understood in the professional world. It is not welcome.

This reality needs to be taken seriously. As an example, I’ve considered myself to be a very kind person. I just love working with people and I love seeing young Americans develop into productive members of society. I volunteer for STEM projects far more than I should and I care so much about the development of STEM education. Big deal. If you say something negative in an email or a web post, you’ve done well to alienate yourself. It’s hard to repair the damage done by poorly chosen words. If you’re fuming (because graduate school is a very flexible yet stressful lifestyle), realize that it’s probably a perfect opportunity to stop talking. You’ll be fine. There will be lots of stress, but watch what you say because your words are documented online or in the minds of those around you.

Unfortunately, my advice to this point does not allow you to go very far as a communicator. Knowing when to speak up and how to use your words effectively is an art and science. You only get better at art or science by practicing (making mistakes). There are a lot of considerations that must be made quickly before speaking such that you can have maximum impact with your words. An efficient communicator will say more with less. Experiment with your communication and speak up often, and learn from the reactions of your peers, mentors, and others. Loosen up in the classroom. It’s a painful process, but a good communicator will have a much easier time developing a strong career.

Small steps to self-improvement

Graduate school is making me a better person. I needed more time to mature and develop into who I’ve envisioned. I love the idea of self-refinement, but there are certain environments that facilitate that growth best. I’ve found that graduate school is an opportunity to see my boundaries. I see what happens when my stress takes me to my limits. I can be a mess. But it could have been worse. I could have made a huge mistake, said something inappropriate (even inadvertently) and lost a million dollar contract in the field. My mistakes could have been more costly. Graduate school has given me the opportunity to learn from those mistakes, develop a philosophy for how I’ll handle high stress situations in the future, and come back even stronger. It continues to have a powerful impact on my life and how I conduct myself professionally.


Remember to put your best face on every day. At times it may be a significant struggle, but you’re in control of more than you think.


Profiling a simple Fortran code with gprof

I finished working through Chapman’s Introducton to Fortran 90/95, and it was a very interesting (helpful) read. My next step is to work through Chapman’s (no relation?) Using OpenMP, but there are some performance considerations I must first address.

Therefore, I looked into gprof, which is the GNU profiling tool. It will give me an understanding of how quickly my code runs, and which tasks in the workflow are taking up the most resources. Here is what the ifort man pages say about the gprof compiler flag (note that I have a 32-bit processor for this test!):

Compiles and links for function profiling with gprof(1).
Architectures: IA-32, Intel® 64 architectures
Arguments: None
Default: OFF
Files are compiled and linked without profiling.
Description: This option compiles and links for function profiling with gprof(1).
Alternate Options:
Linux and Mac OS X: -pg (only available on systems using IA-32 architecture or Intel® 64 architecture), -qp (this is a deprecated option)

That’s interesting, sure! So with that bit of knowledge, I want to apply it to a large code that might make debugging a pain. I’m going to focus on a much simpler test case (that I’m taking from Chapman’s Fortran 90/95 book, Example 6-10, pg. 340).

gprof Example with Fortran Code

The example I consider has a function called “ave_value” which calculates the average value of a function between two points first_value and last_value. “ave_value” is called by “my_function,” which is declared as external in the test driver program “test_ave_value.” It’s a very simple program with three .f90 files.

I wrote these functions based on the example given in Chapman, and then  I compiled them with the following command:

$ ifort -p ave_value.f90 my_function.f90 test_ave_value.f90 -o test_ave_value

As a reminder, the -p flag allows me to specify our gprof option, and the -o flag allows me to rename the executable.

Now that you have your executable, you can simply run it, as I did:

$ ./test_ave_value

And you’ll notice that it has generated a “gmon.out” file that can be interpreted by gprof to show you your statistics! Writing gmon.out will overwrite any previous versions that you had in the folder, so use caution. Now, run gprof to interpret the gmon.out file.

$ gprof test_ave_value > tav.output

The tav.output was my re-naming of the gprof output. Now we can view the results of gprof in tav.output, in any competent text editor.

Looking at the Numbers

There is sufficient documentation for understanding gprof numbers on their website, but I’ll hit some critical points. The outputs are separated into the Flat Profile and the Call Graph. The Flat Profile conveys how much time your program has spent executing each function. The Call Graph conveys how much time was spent in the function and its children. You can read more here.

Visualization of gprof results

A quick way to put a visualization together (per the documentation of gprof2dot):

gprof path/to/your/executable | gprof2dot.py | dot -Tpng -o output.png

Here, gprof executes your program (which you’ve already compiled and linked with the appropriate flag!). That output is piped to a program called gprof2dot, which then pipes its output to create an output file that you can view in any competent image display tool!

Note that if you download gprof2dot, you’ll need to change the permissions to ensure that it’s an executable. I tried to run the non-executable version with

$ ./gprof2dot.py

but it would not execute because the file permissions were not set to executable.

Now that I learned this, I’m going to try it on a bigger code. Happy profiling!

Learning Fortran 90/95 with Chapman (pt. 1)

School has begun again and I’m taking three classes that will necessitate number crunching. My research also demands precise, high-powered computation. Naturally, I knew I had to go from casual, sloppy Fortran user to master Fortran ninja.

Getting serious with Fortran

I’m almost done learning Fortran 90/95 according to Chapman. It’s a pretty good book for Fortran beginners (especially those engineers who started with Matlab and are looking to actually start learning a programming language). But if your goal is to simply learn how to program, go with Python.

If you already know Matlab, Fortran is not much of a leap. If you weren’t aware, it’s not ALL YELLING, as the case-sensitivity from FORTRAN 77 has gone away (but you still may NEED TO READ IT if you go back to compile older codes from antique projects). I haven’t had much difficulty getting through all of the examples, and now I feel confident writing, compiling, and executing my codes. I also feel much better about debugging. Previously, my experience was obtained by compiling and running existing Fortran codes. Debugging was difficult without knowing how to speak the language. So I bought Chapman’s book and ran with it.

Some lessons learned

1. Because Fortran is absurdly systematic, you learn to love flowcharts. I used to ignore flowcharts (which is why Ben has historically been a garbage programmer). I knew it was one of my weaknesses, so I’ve started taking a much more rigorous approach to the process. Programming is obviously one of those activities where adequate preparation will show in the result. As an (aerospace) engineer, you often could get away with starting a project in Matlab by just typing your thoughts and equations, and pressing run until you got the desired results. Impossible in Fortran, so I learned to love flowcharts.

2. Understanding how to compile and debug code is a lesson best learned before you start writing code. I highly recommend obtaining very small, simple, and previously written codes so that you may compile and understand how they work with Fortran compilers. I’ve come across several examples in Chapman where I used my experience compiling and debugging codes to get through his example problems. Sadly, books aren’t bulletproof, and you should be at least somewhat familiar with programming concepts before you start with this book. Chapman’s mistakes were small and infrequent but could cause frustration to a programmer with no room for error. I don’t recall finding an error in his examples, but I found a couple in his Figures (which are just pictures of code…).

I mentioned compilers, so I’ll digress here. The best compiler to obtain is Intel’s Fortran compiler, ifort. It can be obtained for a pretty penny, or if you’re just testing and learning, grab it off their Non-Commercial Software Download page. However, if you’re under a time crunch, or if you prefer simpler and less complicated barriers to entry, try gfortran. It’s not as well maintained or cool (when engineers think cool, they think high-performing, with neat tricks and features, etc.) as ifort. gfortran can be downloaded very easily onto an Ubuntu 11.10 machine by simply issuing the command through the terminal window:
$ sudo apt-get install gfortran
It was not pre-loaded on my distribution. I would rather not spend the hour or so (45 minutes for download…if you’re fast) of installation procedure when I could simply install gfortran in one line. The ifort installation is not rocket science, but it’s not a walk in the park, either. So it’s somewhere between a walk in the park and rocket science. If someone says “it’s not rocket science” they usually mean it’s trivial. If an aerospace engineer says “it’s not rocket science” they’re probably being snarky and it’s plainly difficult.

There are plenty of resources on how to compile your codes in Fortran, but they’re not in books, typically. Books will illustrate the processes of compilation and how source code goes to object code, etc. but typically won’t demonstrate how exactly to compile your code. The answers are on the internet, so search thoroughly. I may write something soon on the topic.

3. Fortran is not an engineer tool that will set you apart in the computational sciences. It is a prerequisite. If your career is moving in that direction, pick up Chapman’s book and start learning today.

The purpose of this post

Originally, I wanted to write about a specific problem I ran into on Example 6-4 Gauss-Jordan elimination in Chapman. I had to figure out a compiling issue because Chapman did not specify what the input file would look like. I won’t post the answer here because it’s fun to figure out on your own. It was more important for me to generalize the lesson I learned and then articulate the main ideas I’ve learned since I picked up Chapman’s book. I’ll probably comment again on the overall quality of the text when I’m finished with it, but I’ve enjoyed it thoroughly thus far.