Installing gcc and gfortran for Mac OS X (10.7.3)

Things you’ll need:

  • Knowledge of how to use the terminal
  • An internet connection
  • A Mac developer account (you can get this as we go along)
  • Copy of Xcode (free)
  • About an hour of your time (30 minutes downloading, 15-30 minutes doing things)

Basic steps:

  1. Download and install Xcode
  2. Download command line tools
  3. Download and install gfortran from other source
Note that if you attempt to only download and install gfortran without gcc you might get the following error!

error trying to exec `as': execvp: No such file or directory

Also note that I performed this installation on a Macbook Air.


Download and install Xcode by clicking this link, or by searching for it in the Apple App Store, where it can be downloaded for free (see image).

Xcode contains gcc

After you’ve downloaded Xcode, you’ll want to open it and agree to their terms of service. Then, you’ll want to navigate to the menu Xcode –> Preferences –> Downloads. Here you’ll see an option to download Command Line Tools (see image). Note that you’ll need a developer account at this stage, and I was redirected to their developer page where I had to fill out a form and create my account (using my existing Apple ID, where a lot of the form was already auto-filled).

CL Tools

Download Command Line Tools from Preferences --> Downloads

After you have successfully installed the command line tools, open your terminal and type something like:

$ which gcc

which should return the path of your gcc in /usr/local/bin. All of this should have been taken care of automatically.

I mentioned at the beginning that I got an error when attempting to use gfortran on my machine before I’d even installed gcc. I found that gcc must be installed in order to use gfortran. But my gfortran installation went smooth because it’s very straightforward.

Download gfortran from this link.

After considering my hardware, I chose the option:

Mac OS Lion (10.7) on Intel 64-bit processors (gfortran 4.6.2): download (released on 2011-10-20)

The installation has a walkthrough that comes with the package, like many Mac installations. Straightforward and it should also work automatically. Then, open your terminal and type

$ which gfortran

and it should reveal that it was successfully installed in /usr/local/bin.

Happy programming!


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 | | 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

$ ./

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.

Installing Python 2.7.2 in Ubuntu 11.10 – UNRESOLVED?

The bottom line: I have a working python installation because I installed it LOCALLY, but when I attempt a global (or system-wide) installation (using sudo), I run into an error I can’t seem to crack.


My goal is to install Python 2.7.2 so I can integrate it with my parallel workflow. It’s not a very ambitious goal. I installed the Intel C compiler (no sweat), MPICH2, and now I’m at this necessary step before I install mpi4py, a wonderful tool developed here.


During my installation process, I covered two versions of Ubuntu (because I updated midstream). The two versions were the notoriously friendly 10.04, and now 11.10. These are home editions, not server editions. I’ve done a lot of experimental stuff regarding the graphics on my 10.04, so now a lot of stuff is broken, and I thought upgrading to 11.10 would fix a lot of the harm I caused (it did!). I’m using a 64 bit Intel architecture, Corei7.


I downloaded the Python-2.7.2.tgz package. I unpacked it somewhere friendly. Then I built somewhere else. I usually do this and it has worked out pretty well so far.


Here is a list of the commands that I issue. They should work and install Python, in theory.

Command 1
./configure –prefix=$INSTALL_DESTINATION CC=$INTEL_C_COMPILER 2>&1 | tee c.txt

Note that my $INSTALL_DESTINATION was only root accessible, meaning I needed to specify sudo when making any changes to that directory. I do the fancy tee because it is absolutely necessary to keep me from going mad. Printing a history of what I just did and when I did it is great bookkeeping. Keep in mind that I fiddled with my Intel compiler. I tried to use the 32 bit compilers but it wouldn’t configure. I wasn’t sure if that would help, and now I know it doesn’t.

Command 2
make 2>&1 | tee m.txt

Again, this is a simple command that will send its output to a text file. At this stage, I got some warnings. I did not format the warning for your reading enjoyment.

compilation aborted for /home/benjamin/Documents/installs/Python-2.7.2/Modules/_ctypes/libffi/src/x86/ffi64.c (code 2)

Python build finished, but the necessary bits to build these modules were not found:
_bsddb _sqlite3 _tkinter
bsddb185 bz2 dbm
dl gdbm imageop
readline sunaudiodev
To find the necessary bits, look in in detect_modules() for the module’s name.
Failed to build these modules:
_bisect _codecs_cn _codecs_hk
_codecs_iso2022 _codecs_jp _codecs_kr
_codecs_tw _collections _csv
_ctypes _ctypes_test _curses
_curses_panel _elementtree _functools
_hashlib _heapq _hotshot
_io _json _locale
_lsprof _multibytecodec _multiprocessing
_random _socket _ssl
_struct _testcapi array
audioop binascii cmath
cPickle crypt cStringIO
datetime fcntl future_builtins
grp itertools linuxaudiodev
math mmap nis
operator ossaudiodev parser
pyexpat resource select
spwd strop syslog
termios time unicodedata

At the very least, we presume that our make install may not go as expected. Considering that I was about to install in a root directory, I issued the command

Command 3
$ sudo make install 2>&1 | tee mi.txt

which gave me the error

Traceback (most recent call last):
  File "/opt/Python-2.7/lib/python2.7/", line 17, in <module>
    import struct
  File "/opt/Python-2.7/lib/python2.7/", line 1, in <module>
    from _struct import *
ImportError: No module named _struct
make: *** [libinstall] Error 1

From here, it’s been all suffering and confusion.


I came across a forum post that detailed the error very similar to mine (if not exactly similar, but probably not, because it wasn’t their solution that solved my problem). They recommended an upgrade of the make utility. Before their recent upgrade in 2010, make was last upgraded in 2006. Four years of waiting reduced my “Failure to build these modules” from above, to this:

Failed to build these modules:


My recommendation here is to update your installation of make. Yet, with all of these wonderful improvements, my installation still failed with the same error. To check your existing version of make, go into your terminal window and type

$make -v

To automatically download the 3.8.2 edition of make, click here.

So with make upgraded, I was still running into issues with _struct. I did attempt the solution found in the link I provided to the forum posting. It did not work. But I think it’s a good start. I did not find the system-wide python installation absolutely necessary, so installing it locally was a breeze. I may come back to this later to resolve, but I’ll take any comments below to try them out.

Note: If you keep attempting the installation from source, make sure you run

$ make clean

after every time your

$ make install

fails, before you run make again.

LG Super Multi Blue, Cyberlink PowerDVD 7.3, and NVIDIA Issues – Resolved

Picture spending roughly one hundred dollars on a piece of equipment that you expect to perform as the device was intended. People who enjoy electronics often have this expectation. So we’re the ones who get infuriated the quickest when they don’t work out of the box, but we’re also the ones who take to the internet immediately to resolve their issues.

About a year ago, my blu-ray player stopped working. It worked at one point, then stopped. I was infuriated. Cyberlink PowerDVD 7.3 was acting up and it provided me with errors that had incoherent detailed explanations. I tried to troubleshoot by updating PowerDVD using their automated tool. This was a futile effort, and just made me more upset. It would download an automatic update and I’d get nowhere. Avoid this at all costs. Do any updating manually.

Today, with new confidence, I said I can fix anything on my computer. So I applied that confidence to this problem. Just update all of your relevant drivers. My hardware was fairly old (from ~2009) so my NVIDIA GTX 275 and blu-ray drive needed some updating. Because it was OEM, I resorted to the update for 7.3. You can check your version by clicking on the top left corner of the Cyberlink interactive screen.

I got my Cyberlink PowerDVD upgrade from here.

I got my NVIDIA driver update from here.

Doing either/or probably will not solve the problem. After you install each, restart. You should be good to go. If not, clearly the problem is something else, and you may have a difficult road ahead with Cyberlink support. Cyberlink PowerDVD is not as fun and easy as it should be, but once it’s working, who cares because you’re staring at cars exploding in blu-ray quality.

I am running Windows 7 64-bit with core i7 chip at 3.06 GHz.

Teaching Science to Kids Part I: Women in Engineering

Some background

I’ve worked with students since I was a researcher in high school. I held a year-long stint with Dr. C. Ted Lee, Jr. in chemical engineering. As part of the STAR program at Bravo Medical Magnet High School and the University of Southern California, I was able to reach out to students at Murchison Elementary School where I taught the youngsters about blood flow through the human body, measurement, and the fascinating mechanics of our eyes. At Arizona State University, where I did my undergrad, I continued my outreach whenever possible. I enjoyed volunteering for FIRST LEGO League, the National Science Bowl Arizona Regional, the National Science Bowl in Washington D.C., and other various workshops held by ASU and the Fulton School of Engineering that pain me not to remember! But the focus has always been on inspiring the next generation of scientists, entrepreneurs, and leaders in this beautiful world. My dream is to inspire a generation of scientists and engineers and make a positive difference in their lives.

Outreach at the University of Maryland College Park

For a few, very interesting sessions this summer I was able to talk to students of elementary school (grades 4 and 5) and high school ages (grades 11 and 12). These students had various grasps on what “engineering” was. Some students thought that engineering was being “creative”. Some thought that it was “working in teams”. These were my favorite students. The first session was with Women in Engineering at UMD.

Women in Engineering:

I really liked this group of 30 female high school students. They were quiet, but they ended up being one of the most vocal groups by the end of the session. They grew confident because I developed a friendly atmosphere. I joked around. As a presenter, you need to be interesting. I tried to relate my own personal experiences to what they’re going through now. If you’re authoritative and just describe “here’s what your next 4 years are going to be like” they will lose interest or get the wrong message. The idea was to get a good group vibe while addressing the reality of studying engineering in college, and being aware of how to handle it all. They will have their own unique experiences and follow their own paths. Some will not even major in engineering while in college. So it’s good to give young students information that will not only benefit them when moving ahead in engineering, but any subject in college.

I’m very excited about Women in Engineering (both the group, their sponsors and volunteers, and the participants in their outreach programs).  I gave a one-hour lecture where I talked about the importance of several topics. I let them know straight. College, but especially engineering, is going to be difficult. It’s going to be stressful, exciting, and rewarding. There is an endless list of things I wish I knew when I finished college, more than can be conveyed in an hour lecture. So the next best thing is to talk about the essentials, and convey a feeling about college. An idea, that hopefully sticks.


We have a serious problem in engineering. It separates males and females at face-value. This is a finely drawn line in engineering that hard-working female engineers have spent decades attempting to erase. I’ve heard males at all levels of my education speak candidly about this topic in a very sexist manner. We’ve certainly made a lot of progress, but there is more progress to be made than has been achieved. Engineering is a white male. Work needs to continue to change that reality. As a perception, it’s changing. There is proper etiquette in the workplace. Minorities are treated as equals, given great responsibility. But there are severe wage disparities. There still exists discrimination and until that reality changes (and until we see equal representation and salaries in our field), we have a problem.

I digress! But as a Mexican-American engineer, it means a lot to me. And that’s part of the reason why I volunteered to speak for Women in Engineering. So I digress intensely.

Questions, please

There were some good questions after my presentation. The girls did want to know about classroom ratios. I said it varies from one engineering specialty to another. But it’s typical to have a first year calculus class with a 3:2 male to female ratio. I emphasized that it’s important to try different things that they’re interested in, whether it’s research, a project, or a class. When you try new things you learn more about yourself.

Was the class engaged? Absolutely. My favorite part about this group is that they took notes. This is another quality of young students that I greatly admire! Documentation is essential. They asked questions during the presentation. One pet peeve of presenters is their lack of willingness to take questions mid-presentation. I agree that it can derail a well-timed presentation. But with young students, I highly recommend allowing for questions DURING your presentation. They may hesitate to ask later, or simply forget. Encourage questions during presentations so that it feels like a discussion, not a lecture. Engineering is more of a discussion than a lecture.

Let’s do this again!

I hope WIE has me back for another talk. I’d love to talk to other students about engineering (or current undergraduates about the reality of graduate school). From this presentation I learned that I need to keep the talks short, to the point, and allow room for many questions. What’s important is to increase awareness of engineering, and it starts with a conversation.