Comment by guitarbill | Hacker News Reader

Comment by guitarbill | Hacker News Reader

Parent Full thread

Trusting legacy code with few users is a dangerous proposition. My roommate was given some "state-of-the-art" code and told to run simulations with it. The only graphical output was postscript (for some reason), so every frame was 150 MiB and took minutes to dump - so usually, this was only done at the end to show the result.

I managed to hack in a step which just dumped the memory of resulting frame to a file, and then we wrote a Python script to read that and produces a PNG.

We combine the PNGs into an animation and show someone else in the department because the supervisor wasn't in that day. "Cool! But, hrmm, those boundary conditions look wrong." Sadly, this was 2/3s into his Masters.

Like much now in Physics, the original code was simply incorrect. This happens all the time, and papers get retracted because of it - well, that's the best case if somebody notices.

At the end of the day, programming languages come with eco-systems, and must be chosen solely as a tool. The problem is not with Fortran, but that often Fortran == outdated development practices and in Physics horrible code hacked on by 10+ people without prior programming experience.

Another problem is that most people who wrote this code aren't programmers - they don't write clean code, no tests, etc. They don't really know those are important. Sometimes the code that is used and updated for years looks like a dirty prototype.

I don't know what can be done about it except hiring programmers to write code, which wouldn't be either easy or cheap

Well, I guess one moral of the story is that doing image manipulation is easier in Python than Fortran, so it's again using the right tool for the job. And I think the push for Physicists to use Python if possible is good, as the learning curve is less steep. And once you have that tool at your disposal, you might use it more often (instead of Excel).

I can see many projects being improved by providing a Python pre-processor that writes out e.g. a binary config file, the hard-code Fortran/C simulation code reads that, and spits out the simulation results, and then having a Python post-processor that does the pretty stuff at the end.

Academically, it seems that pairing CS undergrads with Physics undergrads to do e.g. a molecular dynamics (MD) course would be cool. The Physics behind MD isn't too hard, and given the right parameters the programming part would be manageable. Then again, CS undergrads aren't necessarily great programmers either...

Clean code and tests are overrated. Version control and a big eco-system is underrated. It's like maths, physicists don't understand maths, they just use it like a carpenter uses a nail without understanding metallurgy, or a programmer uses a CPU without understanding solid-state physics. And that's okay.

Why not using both ? You can reuse existing fortran code withing Python, and benefit from the prior experience and speed while enjoying the qualities of Python.

There are several ways to bind Python and fortran together. E.G http://arogozhnikov.github.io/2015/11/29/using-fortran-from-...

If you don't have clean code and tests, vsc would allow you to switch between old and new bad, probably non working code. That's nice, but probably not what you'd want. If I'd need to choose one out of all, I'd choose tests. From my experience, it's nearly impossible to implement big system without tests. Maybe I'm just not good enough as a programmer

I would have thought a more natural candidate for scientists would be languages like Java or C# rather than python: you get both a language that is relatively easy to write, with no memory to manage, no hornet nest of pointers on pointers, nice debuggers, lots of 3rd party libraries, while a the same time getting the performance of static typing / running compiled code once the program has been JIT (which for long running code is a negligible cost). It's never going to be as fast as a C++ or Fortran, but you get a compromise between performance and ease of use, while I understand python is going the other extreme, i.e. all ease of use at the expense of performance. Doesn't matter for a simple simulation, but for some large data analysis projects, I assume it could make a big difference.

But that doesn't seem the case. The choice seems to be between python and c++/fortran. Does anyone know why?

1. Nice bindings already exist for numerical libraries in python. It is more accurate in some ways to say that scientists are using a domain specific language based on numpy than they are using python.

2. The choice is either "fastest possible" or "I just don't care how long it takes" - for either development or run time. There is usually no middle ground.

3. Tooling - the scientist is most likely using a text editor not an IDE (especially when they start working). Fortran and python are both low enough on boilerplate to not need IDE support.

4. Abstraction level. Scientists in general don't bother care about abstraction level at all. Procedural programing's abstractions are usually more than enough for them (and may actually be the correct level for some numerical work - think cache misses vs. hits).

5. Some areas of science do use Java (check out imagej for example).

It's going to have few users anyways, since it's so specialized. And that's also why it will be legacy.

They where not back checking against real word experiments?

I've heard horror stories of supposedly quite serious software modelling programs behaving quite differently when their input problem was rotated a few degrees.

Ugh - I remember spending a lot of time checking our pump simulator module against real word experiments back when I worked in technical computing

I've heard horror stories of supposedly quite serious software modelling programs behaving quite differently when their input problem was rotated a few degrees.

Sounds perfectly normal :)

The standard advice here at work for one of our modelling packages is: if it crashes try rotating your input model by one degree and try again. Most of the time that will fix it. If it doesn't fix it try one degree in the other direction.

Do people publish work based on this thing?

Is correctness somehow assured provided it doesn't crash? Or is the whole thing just a joke?

Do people publish work based on this thing?

I'm sure lots of people do. We're a commercial company selling consultancy service around this software (technically around some inhouse tools built on top of this software), among many other things.

Is correctness somehow assured provided it doesn't crash?

On the whole well tested PDE solvers either crash, give answers that are off by several orders of magnitude, or give a correct answer. (If the answer they give is relevant to what you're trying to model is left as an exercise to the reader)

We're reasonably sure that, if the calculations converge, the solution provided is a correct numeric approximation (within the error bounds given) of the PDEs we're claiming to solve. We also believe that the PDEs we're using provide a reasonable balance between modeling what we claim we're modelling and our computation running in a reasonable amount of time.

They probably did at some point in the misty past. The problem is that running relevant experiments is often very expensive (otherwise they wouldn't need to do it in software) and they can only test a tiny handful of cases. More often than not your calibrating your model against another model that was calibrated against another model that was calibrated against a set of simple experiments done in the 60's.

Reply on news.ycombinator.com