eric_t

Associate professor in fluid dynamics here. There is typically a split between the people who want good looking simulations for movies/games, and those who need accurate results for engineering. For engineering, you need more effort on how you resolve the complex geometry and how you model the turbulence in the flow. This adds significant complexity both for problem setup and solution time. The only product I’m aware of that is built for real-time, 3D flow design is Ansys Discovery: https://www.ansys.com/products/3d-design/ansys-discovery

OpenFOAM is high quality, but as you’ve seen complex to use. There is a web-based GUI that can lighten the burden to get started somewhat: https://www.simscale.com/ I think they give you ~3000 simulation hours for a trial.

I’m also teaching fluid dynamics, and use Blender quite a bit for geometry work. Would love to hear more about your use of Blender for visualization if you’re willing to share.

Hypothetical is the key here. Everyone can dream up a perfect system, but in the real world, it will have to make compromises, which means that it won't be perfect for everyone.

Here's the summation problem in Fortran, quite succinct, IMO:

    real, dimension(30000000) :: a

    call random_number(a)

    print *, sum(a)

That's 30 million doubles, takes 0.04s on my machine.

    real, dimension(30000000) :: a

    call random_number(a)

    print *, sum(a)

That's 30 million doubles, takes 0.04s on my machine.

A great quote from George E P Box:

All models are wrong. Some are useful.

If your kids are toddler-age and older, it is certainly possible. But when you have babies, I consider step 1 impossible. I do all of the steps he mentions except number 1, and I am tired.

Sounds great, until you have kids...

I think it's wrong to say "Amateurs, happy to accept small checks for snapshots of children and sunsets". It's more of a democratization of the tools needed to do a successful photo shoot. Anyone can buy a DSLR, the strobist movement means good-looking lighting for cheap and excellent post processing tools are available for free.

This means that amateur photographers in many cases can do just as good a job as a professional. It's pretty much the same reason why magazines and newspapers are declining, the internet and social networks have lead to a democratization of news.

To be successful as a professional photographer, you have to offer more than what amateurs are capable of, and in addition be able to educate your customer why you're worth the extra cash. As always, it's about staying competitive, instead of weeping over the past.

Interesting. Is the code available somewhere? I looked at your SIGGRAPH paper, and that was very interesting.

Have you seen the FiPy project? It's a full-featured finite volume code in Python, which is very easy to extend (they did struggle with performance in early releases, not sure how the current status is).

I guess that's the area where dynamic or functional languages can be useful, in that they are easier to build generic libraries for, and can give rise to codes with easier extensibility.

OCaml is only really fast if you use the imperative features. The only high performance Haskell code I've seen is from the language shootout, and it looks pretty hairy as well. Also, note that my Fortran function actually _is_ pure, so the whole argument about purity doesn't hold up.

I kinda understand what do you mean by whole-program scale, but in fact, most of our programs aren't much bigger than this! Typically, the number of lines of code doesn't exceed 50k.

I agree about functional programming being fun, but unfortunately I don't think my coworkers would agree, and especially not the companies funding our research!

In the Fortran code, this could be run on the GPU by simply surrounding the code by

   !acc region
   !acc end region

with the PGI Accelerator. It would have to be a pretty big loop for it to pay off, though, since transfer to/from the GPU is very expensive.

We use a lot of compilers. They all vary in ability to detect bugs, and optimization features. The fastest used to be Intel, but right now the Portland group compiler seems to be the best. These are both commercial, though. Of the free compilers, Sun's compiler has been the fastest for us. It will be interesting to see if Oracle will continue that effort.

No, as the paper says, explicit Euler integration is extremely unstable. Implicit Euler, as the paper uses, is stable but only first order accurate.

If you're dealing with fluids with low diffusion compared to advection, some higher order Runge-Kutta scheme is typically used. For fluids with high diffusion, however, this will give you very high restrictions on the time step. For this cases, a hybrid scheme is often used, where the advection term is integrated explicitly using an Adam-Basforth scheme and the diffusion term is treated semi-implicitly with a Crank-Nicholson scheme. This means you have to solve additional linear equation systems for the velocities for each time step (Helmholtz type equations), but this is still faster since you can use longer time steps.

All of this may sound very complicated, but it all follows the same patterns, so it's really fairly straight forward.

I have a PhD in computational fluid dynamics (CFD), and have written several CFD codes in Fortran, C, Matlab and Python. I'm also a programming language geek, and have been interested in functional programming languages for quite some time. When I see something like this, however, I loose some of my faith. It just seems like too much effort to get decent speed, and even when not considering speed it doesn't seem to give much benefit. For instance, this is how the diffusion function would look in Fortran (skipping some details):

  pure function diffusion(x0) result(x)

    real, intent(in), dimension(:,:) :: x0
    real, intent(out),dimension(:,:) :: x

    x =  x0(2:n+1,1:n  ) & 
      +  x0(0:n-1,1:n  ) &
      +  x0(1:n  ,2:n+1) &
      +  x0(1:n  ,0:n-1) &
      -a*x0(1:n  ,1:n  )

  end function

Some things to note:

- The "pure" keyword guarantees that this function has no side effects.

- No do loops are needed! Fortran array slicing is very handy.

- The compiler will convert this to use SIMD instructions

- Adding some OpenMP hints to make it run on all cores is also very easy.

So this type of code in Fortran is short, very easy to understand and you are guaranteed extreme performance. Maybe functional programming has some benefits when you're dealing with more complex datastructures (for instance I'm working on a code right now which uses parallel octrees, kind off a pain in Fortran), but for simple things like this, I fail to see the point.

I want to believe, so perhaps someone here can enlighten me?

If he now interviews a new set of couples, does his predictions according to the developed model, and it _still_ gives high accuracy, then we can call it science.

The power of a good model lies not in how good it predicts what you know, but how it can be used to model unknown/new phenomena.

A new and improved TeX?

The author makes a couple of assumptions that I don't agree with.

The first is that success is measured by the amount of money you earn. For me it is much more rewarding to work on interesting and inspiring problems than having a huge income.

The second is that people that are good at hard science problems are good at solving the "stupid" problems. You need a different set of skills to solve the latter.

I disagree somewhat with your final statement. As long as we're talking about a creative job, it's not easy no matter what. As a scientist/researcher, you have to be every bit as creative as an artist or a musician, IMO.

This is somewhat true of engineers as well, but you can certainly get an engineering job where you don't need to exercise your creativity.

This used to be the case, but universities are getting better at this. Usually it's pretty easy to spin off a company, where the university retains some ownership. It's a win-win situation, really, a university is a great place to foster ideas, but not very good for bringing a product to market.

If you think of your supervisor like a boss, that's wrong, IMO. You should pursue your own ideas in your own way, and your supervisor should do just that, supervise you and guide you as best as he can, then let you do what you want with his advice.

Of course it's hard to build a team as a PhD, at best you can get some reasonably competent master students to do some work for you.

It's a good roundup, but I think you missed the most compelling reason to do a PhD, at least it was for me. And that is that you get the opportunity to dig really deep into a problem for three year or more. And that is your only concern, no business crap, no customers, just you and your problem.

Also, the freedom of doing a PhD is great. Want to take two weeks to learn a new programming language? Sure! Want to take two weeks off and go surfing? No problem! In fact, some of my most important work on my PhD was done during one of these "diversions".

Finally, some jobs require a PhD. You may want to consider if that's the kind of job you want. Hard to answer that before you finish, though. For me the answer was a resounding YES!

There is a saying in the scientific community..."if you want to make sure that your competitor doesn't get any work done for the next two years, give him your code!".

In all seriousness, though, a lot of labs view their in-house codes as a competitive advantage. You may not like it, but science has become commercialized, the labs/unis are all competing about the same grants, which creates a competitive enviroment.

I agree, extremely annoying. I just skipped to the last sentence in every paragraph.

The problem is that there is a whole industry created around Photoshop, all artists use it, it's taught in every college/course, and there are a million books written about it. For a startup to compete against that momentum would be extremely difficult. There is also considerable competition from open source/free programs like GIMP and Paint.Net. Pixelmator seems like it's doing well, though.

I think the opportunities lie more in creating niche tools. Just look at all the tools created the last few years for photographers, the top one perhaps being Adobe Lightroom. It contains most of the image editing tools from PS that a photographer needs, but is built more around the photographer's workflow.

I didn't find it hard at all, just not very interesting, so wasn't motivated to learn it (no offense). I think having more open-ended jam tracks would work better.

The police in Norway doesn't carry guns, that should give you an indication...

I do physics simulations, and can easily reach those times with a similar amount of input. And that is with highly optimized Fortran code.

But yeah, a comparison with a pure Java or C++ implementation would have been great, both in terms of speed and LOC. However, in the "real world", there usually isn't time for such silly things.

Exactly. But this algorithm was fuzzy, so it gave you a list of the songs which most closely resembled the one you tried to sing.

It would be much better if you could hum or whistle a tune, and it would recognize it. I saw a PhD thesis once about this, with an actual implementation that worked pretty well. The only problem was that the database of songs was very small. It's probably hard to scale this type of search.