Why Fortran is a scientific powerhouse
craftofcoding.wordpress.com
craftofcoding.wordpress.com
If the author had actually seen how crap the climate models look, maybe he'll realize the argument is actually backwards and climate models are bad.
I've tried code reviewing some of these models just to get an idea of how reliable they are. My mind was blown by the extremely poor quality of the code combined with literally no redundancy between different models in some parts. If some code written in 1990 just made a slight mistake, nearly all climate models would have the same bias.
And I did find some distributing surface level inaccuracies, such as constants being taken from very old inaccurate measurements in the 1980s physics books (at least according to the comment), some constants being very low precision compared to the accuracy required (some constants with only 2 decimals of precision), and some things that aren't constant at all and should depend on temperature/pressure/CO2 levels/height.
And these are important in a system that actually spends huge efforts to model factors with much weaker impact.
Right, code reuse is dangerous and something to be avoided. From now on, let's write everything from scratch.
You're pointing out a place where I think many software engineers are either untrained, unprofessional, or both. There's already a large body of discourse around the problems that come from these practices—licensing violations, security breaches, and stupendously dumb bugs.
Professional rigor is a thing I wish our industry had more of, but in practice you don't see much rigor outside of safety critical applications because there is rarely incentive for it.
In my case, one of the Fortran files essential to my group's research has 11 (!) versions with only filenames like file.f.goodworking (that's literally one of the extensions) to differentiate them and no version control or history.
But it would make sense to have a "professional scientific fortran programmer" go in and do some housecleaning to make things right, without whining, "Why can't I just rewrite it in Java???" Heck, it sounds like fun to me, but that's because I'm basically a professional janitor, and hey, hurricanes and polar vortexes and all that.
So why doesn't that happen? Is testing improvements too expensive? Do scientific programmers just have no respect for the craft whatsoever? Is there nobody with the necessary interdisciplinary skill set?
The other issue is that the incentives aren't necessarily aligned. They don't get payed to share their code or to make their code reusable. The code is used to publish one or a couple of paper and then thrown away. Maybe someone else will reuse it in the future but the original author doesn't necessarily gain much from that
You needed someone with an incentive to go over code, find the bugs, break into computers and for the entire industry to mature from using strcat to having bug bounties and fuzzing and protect zero. It didn't happen over night and there had to be incredible incentives on the attacker / bug finder to exist, to probe and test the parts that aren't tested, and to serve as the devil's advocate.
The analogy is that it is hard to find bugs which happen silently. Computation inaccuracies are a huge class of bugs that also happen silently. There are no incentives to look at old code.
There's just nothing like it for climate models, and the default behavior of code development is that whatever isn't tested or validated by something will always stagnate with bugs.
The code copy just makes everything worse because implementing the same thing in two different ways by different people is actually good at catching bugs.
So even if I wouldn't have trusted a single climate model, I might trust several climate models developed independently.
The way it works now is that they always prefer to rely on code of others, because academia is driven by citations, and creating new models from scratch means you're missing out mutual citations.
It's a systematic problem, the same way security had been a systemic problem: current methodology just doesn't produce code that fits the requirements. Nobody had neither the incentive nor even the idea that these things should work differently.
Admitting that this is a systemic problem is just a politicized subject.
There are plenty of people saying these models are problematic but getting those working on the models to admit that enough such that the entire system can change its methodology, that won't happen because of human reasons.
Ah! This is the interesting point that stands out, as I hadn't anticipated such an incentive. It's a nasty one.
And why would a good programmer agree to suffer to the whims of a Professor that is clueless about programming even if the domain itself is important and interesting?
Academia relies on paying grad students peanuts and dangling the carrot of being able to get citations under their name to make up for it. There's no way to publish a paper by cleaning up code, much less get cited for doing so.
Bear in mind there's basically zero "general" funding available. Everything has to be paid out of a specific grant and they want to see it being used for that specific purpose, which likely ends with publishing a paper.
But the short version is yes, academia has no respect for the craft. Papers are what matters, so code will always be the minimum necessary to publish a paper, which is generally: copy someone else's fortran/numpy code, tweak it enough until it runs (once, on your laptop) and gives the result you were looking for, publish.
That is too late You CAN'T start with a developer that, hopefully, do good code. You MUST make good code to be the default, from the start. Is the only chance of lasting improvements.
ie: Is necessary a "Rust/Ada for Fortran", and this ALSO must make, somehow, make some significant impact in current Fortran developers, make them salivate for the chance of do the change.
But iterate on Fortran(C/C++..) and hope that will be better? NEVER will work.
This appears to be an example of modern software engineering principles, or even the notion of basic automation, not having reached climate researchers.
I'm not surprised.
Electrical engineers, engineers in general, insurance mathematicians, physicists.
They write code. System critical code. Code that puts fundamental research, lives, and trillions of dollars at stake. They're very good at keeping track of the complexity. Not always so good at relaying it. They're sometimes legally required to test. Testing sometimes means doing the same manual thing excessively. That happens. Sometimes not.
To this day, I can't believe how many extremely smart people write code for a living, but because of their training, they don't think of themselves as "software developers". So they don't read up on what software developers do to not kill themselves. (Of course, #notall...)
It's not because climate science folks are less rigorous, or less capable. It's because academia indirectly punishes those who do care about SW quality and correctness.
That said, the climate models tell us very little useful information we didn't already know. I don't think they have much policy impact. Climate change as a phenomenon is not proved by computer modeling, but by real world measurements and established theory about atmospheric processes.
Irregardless of the code quality, the uncertainties in the model are enormous. (No code can simulate the earth without uncertainties.) We can't use such a tool to finetune our response. Gambling for 2.5°C and getting 5°C is too great a risk. We need to cut emissions as quickly as we are politically able to achieve.
I agree large scale modeling generally should be taken with a (big) grain of salt. Looking at you epidemiologist and economists...
You're wrong in thinking so, these models have an enormous impact since they are what are being used as 'scientific evidence' for the current 'climate change' craze. Without these models there would be only those measurements you mention which in no way indicate the type of trends which the models are being used to warn about. All the measurements show is that it sometimes gets really warm, sometimes really cold, sometimes really windy and sometimes really dry. Measurements do not show a steadily and unerringly upward climbing curve of 'sometimes really warm' and - important in this context - they do not show the current period to be the extreme which it is made out to be. Taking the continental USA as an example - an area for which much data has been collected in a standardised fashion for a long time, making such comparisons possible - it is noticeable that most temperature records - high but also low are found in the early 1900's, mostly centred around 1936 [1]. If you look at newspapers from around that time the tone was comparable to what it is now (in more ways than one given the threat of war on the horizon but that is unrelated to this issue). Looking back further it can be seen that the average temperature has been steadily dropping (as "average over many years", not "average of the last 5 years") since about 8000 years ago when the climatic optimum is to be found [2] somewhere. It is also noticeable that this temperature decline does not follow a straight line, sometimes the average temperature was supposedly - these measurements can only show averages over longer time frames, not year by year - higher than the average during the optimum, sometimes they were lower. The trend is clear and is pointing downwards towards the coming glaciation, whenever that may be. Without the models to use as 'evidence' there would be no 'climate deniers' (an astoundingly dishonest term since most people who are called such do not deny anything about climate, they just do not trust these model calculations with good reason) since current phenomena would just be "weather", not "proof of climate change" - just like they were in the early 1900's.
These models are The Science™ for climate alarmists, no more and no less. They are not the oracles of wisdom as they are made out to be since they suffer from the Garbage In, Garbage Out problem like so many other simulations. As such they are not good tools to use to direct policies but more clubs to wield against recalcitrant opponents.
Does this mean the climate does not change? No, it does not, it changes as it always has and may change in the direction the model calculations show, at least for a while - look at the variations in [2] for an indication of such changes - and it makes sense to prepare for the consequences of a warmer - or colder - climate when possible. Does this mean there is no need to cut 'emissions'? No, it does not mean that either, there are other good reasons to reduce those since these emissions do not just consist of CO₂ but encompass other substances which are actually polluting. It does mean that the laser focus on 'cutting emissions' is most likely the wrong approach since there are far more effective ways to prepare for the effects of a changing climate. No amount of emission reduction will stop the next Katrina disaster but raising levies will, no amount of extra carbon taxation will solve the problems caused by drought but investing in desalination plants [3] will, no milestone in electrification of road vehicles will help with dealing with increased precipitation but upgrading storm drain systems will, etc.
There are other reasons to want to reduce the dependence on fossil fuels as can be seen in Europe which had become unhealthily dependent on natural gas from Russia or the many wars fought by the USA to secure the supply of oil from the middle east - these substances often end up being used as tools to achieve some geopolitical end. Reducing these dependencies where economically feasible is a good investment in future stability and security.
Many of the mentioned reasons - and more - speak for a reduction in 'emissions', they just do not focus on CO₂ as being the reason for reducing them. What all these reasons lack is a sense of urgency and that is most likely why these models are used in their stead. It is much easier to get people scared, then tell them what they have to do to feel safe again than it is to try to convince them of the wisdom of reducing pollution and reducing dependencies for a more stable future.
[1] https://en.wikipedia.org/wiki/U.S._state_and_territory_tempe...
[2] https://en.wikipedia.org/wiki/Holocene_climatic_optimum#/med...
[3] ...yes, yes, they produce brine which needs to be handled in some way - this can be solved in many ways so
No, you're wrong about this. The scientific evidence for climate change is multi-faceted and abundant.
All science involves some modelling. No model captures all forces on a system. Despite this, we are able to determine causal relationships based on simple models and empirical observation.
99% of experts consider the evidence for climate change caused by human carbon emissions convincing. Do you think that would be the case if the only evidence was a large, opaque, uncertain, buggy program?
[1] https://en.m.wikipedia.org/wiki/Scientific_consensus_on_clim...
Appeals to popularity have obvious pitfalls.
The parallel is clear, this is how critics of the narrative around the movement of the Earth, Sun, stars and planets were treated in the 1600's. In that case it was the power of the established Church which saw its monopoly on "truth" threatened by some upstart with a telescope. If his revelations about the orbits of the planets was accepted it would undermine their interpretation of scripture which would undermine their authority so they lashed out to silence the heretic. There is a striking resemblance to the way critics of current narratives are treated, as heretics who need to be silenced before their wayward teachings can poison the populace. This is now how science tends to be done and it is not how science (with a small 's') should be done. Everything should be open to criticism, theories should be mercilessly attacked. The more these attacks falter, the strong the theory will be. Should the attacks succeed in proving the theory wrong everybody will benefit from it.
In the discussion around climate models this means the models need to be subjected to rigorous and merciless testing to find their flaws. They should be tested against historical data, the code should be scrutinised for everything from simple errors to the use of fudge factors and 'magical constants' or 'damping mechanisms' or any other such unproven/unprovable manipulations of the data. If the models withstand these tests and actually manage to follow historical data on which they have not been tested to a reasonable degree of accuracy they will be the stronger for it and their predictive ability will be far higher. This would be a good thing for everyone involved.
Ah, the fabled /9[789]%(.9)?/ argument raises its ugly head again. This claim has several sources, let's have a look at them.
In 2009, the University of Illinois sent a survey [1] online to about 10200 scientists (of many disciplines) with the following two questions:
1: Do you agree that global temperatures have generally risen since the pre-1800s?
2: Do you think that human activity is a significant contributing factor?
3146 responses were received of ~10,200, and of that 31%, 90% said yes to the first question while 82% said yes to the second question. When narrowed down to actual experts in the field (mostly meteorologists) 64% answered 'yes' to the second question. Of the 3146 responses 77 were selected which came from self-professed 'climate experts'. Of these 77 individuals 75 answered 'yes' to the second question. 75/77 = 0.97 -> 97% of experts agree
In reality a self-professed "expert" group of 2.4% of the answerers were selected who in turn formed 0.8% of those who received the survey. The well-known saying about statistics - there's lies, damned lies and statistics [2] - comes to mind here.
Then there was the '2013 Cook study' [3] entitled 'Quantifying the consensus on anthropogenic global warming in the scientific literature' which is often cited as another source for the '97%'. Cook and his team searched the Web of Science for the phrases "global warming" and "global climate change", then categorised the results to what they considered to be their level of endorsement of anthropogenic global warming. While Cook's conclusion - “Cook et al. (2013) found that over 97 percent [of papers he surveyed] endorsed the view that the Earth is warming up and human emissions of greenhouse gases are the main cause.” - was taken for gospel by those who were looking for more endorsement of the earlier '97%' study. What is it based on? Cook created a category called “explicit endorsement without quantification” (papers in which the author did not say whether 1 percent or 50 percent or 100 percent of the warming was caused by man). He had also created a category called “implicit endorsement” for papers that imply (but don’t say) that there is some man-made global warming without quantification of the effect. These were the categories used to calculate the '97%'. Many scientists whose papers were classified in these categories protested to Cook [4] for being selective in which papers were cited and misrepresentation of their positions on the subject of anthropogenic climate change.
Cook's data is available in the study [3], the positions on anthropogenic global warming look like this:
Explicitly endorse AGW 50+% = 0.54%
Explicitly endorse – does not quantify = 7.72%
Explicitly endorse AGW without minimizing it = 24.36%
No Position = 66.73%
Implicit minimizes/rejects AGW = 0.45%
Explicit minimizes/rejects AGW = 0.13%
Explicitly minimizes/rejects AGW as <50% = .08%
Endorse AGW 32.6%
No AGW Position 66.4%
Reject AGW .7%
Uncertain on AGW .3%
In short, don't use the /9[789]%(.9)?/ argument in an attempt to appeal to authority, especially not in the context of a discussion around the viability of global climate models as evidence for future climate change. First because of the mentioned reasons but also because the '97%' argument has no bearing on the validity of climate models since it just - rightly or wrongly - claims that '97% of experts agree that anthropogenic climate change is a fact'.
[1] https://www.sciencedaily.com/releases/2009/01/090119210532.h...
[2] https://en.wikipedia.org/wiki/Lies,_damned_lies,_and_statist...
[3] https://iopscience.iop.org/article/10.1088/1748-9326/8/2/024...
[4] http://www.populartechnology.net/2013/05/97-study-falsely-cl...
There's no doubt a scientific consensus that human carbon emissions are causing global warming. There are multiple extremely heavyweight sources for this, starting with the IPCC reports.
I'm not a climatologist and can't claim to know the extensive literature. But I do understand the proposed mechanism, I trust people are generally not falsifying data, and I don't see any reason for why thousands of scientists and the IPCC would conspire to make up a lie like that.
On the other hand, the fossile fuel industry has a very clear incentive, and it's well documented they have financed researchers supporting their interests.
You mention the clear incentives the fossil fuel industries have in toning down the environmental impact - I explicitly use that term instead of 'climate impact' which has replaced it in popular media since I consider the former to be a known and proven problem - their products have. This is certainly the case and stands without doubt. You do not mention the clear incentives the 'green' industry has in pushing climate panic. Don't you think this is a factor or do you simply agree with their messaging? Does it bother you that several fossil fuel giants have jumped on the 'green' bandwagon so they get to play both sides in this game of charade?
> There's no doubt a scientific consensus that human carbon emissions are causing global warming.
Sure, when you increase the emission of greenhouse gases there is some impact. How large this impact is is less clear, nor is it clear that the increased CO₂ concentration in the atmosphere is the main cause of the recent warm spell or whether it is caused by it. Historical climate records show CO₂ concentration trailing temperature changes, not leading them, the theory being that change in concentration is caused by the change in seawater temperature with colder water absorbing CO₂ (and other gases) which is released when the water warms up again. Another factor in play is the concentration of water vapour in the atmosphere - it shares 3 of the 4 main absorption areas in the spectrum with CO₂ - as is cloud cover (which has a significant effect on the planet's albedo (reflection coefficient)). Since temperature, CO₂ concentration, water vapour concentration and cloud cover are related and interdependent a change in one causes a change in the others. These relationships have not been not taken into account in most models until recently [1] while they are sure to play a role. There are many other factors which are either not taken into account or set at assumed values.
[1] this is one of the areas in which climate models have been improved in the last years: 'Cloud feedbacks have been confirmed as a primary source of these differences, with low clouds making the largest contribution. New observational and modelling evidence strongly supports a combined water vapour-lapse rate feedback of a strength comparable to that found in General Circulation Models (approximately 1 W m–2 °C–1, corresponding to around a 50% amplification of global mean warming). The magnitude of cryospheric feedbacks remains uncertain, contributing to the range of model climate responses at mid- to high latitudes.'(https://www.ipcc.ch/site/assets/uploads/2018/02/ar4-wg1-chap...)
Academic Fortran is horrible but it's also (hopefully) maintained by people who know what they're looking for — egregious errors are like errors, things like "this is constant when it shouldn't be" sounds more like a modelling assumption.
People got relatively good climate (well, temperature) estimates from the 80s (if you input the right CO2 data for the future), but I'd image the modern ones more subtle predictions could be quite wobbly (i.e. people complain about them having way too many parameters but I'd imagine many of these are for specific "tasks" rather than massively dominating the overall model)
1. Data from the field showing warming up / other real world observations. I'm not disputing this. This has been corroborated by many different methods without any clear single point of failure.
2. Given 1, what is the probability that the reason for the observed effects are CO2.
This is the crucial policy question, and the problem is that the evidence for 2 is actually purely from these models.
It's easy to take the conjunction fallacy here and immediately jump to 1&2 being more probable than 1 alone, but it's wrong thinking.
The problem is only magnified, in my opinion, by the fact that only few parameters have even had the same kind of detailed analysis that CO2 had. And then the code has clear bias towards the narrative, and the forcing of CO2 in the model is extremely detailed in the parts where the narrative says it's important (radiation forcing) while neglecting many other effects, and taking various things that actually depend on CO2 to be constant.
And finally the problem is that the policy decisions are the complete opposite if 2 is wrong: if we're heading towards more chaotic weather and CO2 isn't the culprit, you would want to rely on fossil fuels instead of the weather (a.k.a solar and wind) for energy.
The Berkely earth group went in with basically exactly the same question, did everything from scratch and broadly replicated the IPCC curves
Sorry to recite a common wisdom that "correlation does not mean causation".
Do you have a competing theory? No one has been able to propose one that fits as well as greenhouse gases, and god knows people have tried.
This isn’t a shot in the dark using excel linest(atmospheric _co2, global_average_temperature) trend plots and calling it a day.
There is sound first principles model to solar thermal energy retention. It may not predict the global average temperature in the next 15 years within 0.2C but you have got to be kidding me bringing up that intro to statistics caveat “correlation!=causation”.
Like do you know how inaccurate most physics modeling is and still tends to be useful?
“ On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.” - Charles Babbage
1. It's fast.
2. It's tolerant of poor programmers.
Regarding item 2: People who want to specialize in scientific computing intentionally avoid becoming good programmers. Most of them are not in CS, but in some other engineering or in science. They want to focus on their discipline (e.g. climate science as this example gives). They don't care about code quality, or even SW practices (e.g. when I was in grad school a little over a decade ago, I couldn't get a single one of my colleagues to use version control - and some of them had codebases in the tens of thousands of lines).
They are not judged by the quality of their code, but by the results their code produces. They don't show their code in their papers, but the plots/tables. So they'll use the language that puts up the least barriers, and is performant. Hence, Fortran.
(Incidentally, many of them don't care about reproducibility. They'll modify their large codebase, spit out some results, publish them, and then add new features, and will never check if the modified codebase will continue to give the same results for the same inputs).
All the other reasons in the article? Insignificant factors.
Edit: Note that I'm not saying that if you code in Fortran you're a poor programmer or use poor practices. And I'm sure there are good Fortran code bases around.
How much are software engineers judged by the code quality? And how much by the end results (shipped features/projects)?
There's a large gap between good code quality (i.e. keep the soft. engs. happy) and passable maintenance (i.e. features and bugfixes are not terribly late -- keep the execs/business happy).
When it comes to Fortran, I wish it long life. It found a great fit and does its job well. Numerical math has many peculiarities. I'm happy we have stable libraries for it. Long live Fortran!
Many differences:
1. Everyone can tell if the SW is doing what it should. Ensuring correctness in the long run can lead to seeing gains in maintaining code quality. With a lot of scientific output, many people will just trust the output of the program. Crappy code quality is not easy to perceive.
2. In many code bases, backwards compatibility is important. Hopefully you'll have many users. With most scientific computation code bases, the user base is tiny (often 1). So no one cares if you break something when you add a feature. Couple it with bullet 1 above, no one even notices if you broke something. With regular SW projects, the need for backwards compatibility can once again drive good SW practices.
I'm not saying all Fortran programmers are bad. Just that it is very tolerant of bad ones, and so they are highly overrepresented.
> I'm happy we have stable libraries for it.
As someone who couldn't stomach Fortran, as far as numerical work goes, plenty of other languages can utilize those same libraries. Having stable numerical libraries is not unique to Fortran. In fact, a colleague wasted way too much time during his PhD taking his group's 40K Fortran code base and porting it to C++.
I am not sure that would be a majority opinion. Robocat’s Law: software complexity increases until it can’t be understood by anybody.
> Fortran code base and porting it to C++
I once tried to counsel a PhD friend to use Mathematica to model their engineering problem, however instead she listened to other people in the civil engineering department to use C++, and she spent most of her time learning C++ and not enough time on her models.
Plenty of banks don't understand how their software works. But they can see that at the end of the day it calculates the right amount of money. (If it doesn't, eventually the client complains, or eventually your manager complains, depending on which direction it was wrong in). For a lot of these scientific modelling systems there's no such sanity check.
Difference is of course that most software engineers work on some commercial project with relative little effect on the world politics, and not bleeding edge science that affects current world politics, thus it ought be higher requirements for scientific computing than commercial computing.
For libraries others use, sure.
For mere code bases that stay in one professor's team and have been there for 20+ years - not really. As an example, I know one computational group where it often took several hours (possibly days) to generate a single data point in the curve they were trying to produce. None of that team's grad students was willing to waste computational resources to see if their code changes would break prior data points.
Not sure. BASIC is very tolerant of poor programmers as well.
It's also maybe the reason code is ever written professionally. The coders often don't have this domain expertise for their particular product and add in things like unit tests, data reproduction tests and insane amounts of logging in order to reduce the amount of risk inherent in the code itself.
It seems very bold to me to assume that someone who spends their professional life around cars is "blind" to the reality of the cars they drive, when a much more likely explanation is that experts can more accurately evaluate things in their area of expertise than laypeople.
I didn't say blind to the reality, but blind to the risk specifically. Are you suggesting that there isn't additional risk to driving a car that's older and has known mechanical issues? The expert assumes they can fix them as they break, which is probably true, but they often don't consider the myriad circumstances they can break in and the additional problems that can impose.
This isn't an insult to mechanics, but just an observation of the behavior and of the outcomes. Or are you suggesting experts are impervious to analysis?
Are you referring to some non-real type of risk, then? I think you may be, and given that this is a subject outside of your wheelhouse you may want to consider that possibility as well.
> Are you suggesting that there isn't additional risk to driving a car that's older and has known mechanical issues?
I'm suggesting that experts may be able to both predict and price those risks more accurately than non-experts. This should be non-controversial.
Consequently, cars which look to you as a nonexpert highly risky may not be. If that is true, as seems likely to me, the rest of your analogy falls apart.
> Or are you suggesting experts are impervious to analysis?
I'm suggesting that more likely explanations than "the experts are wrong and I am right" exist.
No, I was concerned that's what you were attempting to project into my argument, so I wanted to make it clear.
> I think you may be, and given that this is a subject outside of your wheelhouse you may want to consider that possibility as well.
You continue to prosecute this as if it's an insult that I've laid out and that basic logic couldn't possibly apply to an exceptionally obvious situation. Older equipment brings higher risk. If you can't accept that basic premise, then there's not much for us to discuss here.
> I'm suggesting that experts may be able to both predict and price those risks more accurately than non-experts. This should be non-controversial.
"May be." Well.. precisely. So, here's a possibly illuminating set of questions.. how do you tell the difference between the two? What is the expected ratio of the two groups? What mechanisms might you use to determine this?
> Consequently, cars which look to you as a nonexpert highly risky may not be. If that is true, as seems likely to me, the rest of your analogy falls apart.
I said "additional risk." You're trying very hard to be insulted on behalf of another group and you keep dragging the argument towards that end without seriously considering what I'm saying. I get it, you think my opinion is shallow and unearned, but all you're doing is muddying the conversation with this odd back and forth rather than present _any_ data which could simply make your point for you.
> I'm suggesting that more likely explanations than "the experts are wrong and I am right" exist.
That's hardly my explanation and you're being pretty uncharitable to try to twist this conversation into this made up point. Further, you're presuming that everyone who works on cars is some level of "expert" which would obviate their decisions from any scrutiny from someone who doesn't. That's obviously a flawed point of view with an entire human history of counter examples that thankfully have informed our modern ideas of safety and technological management.
Ok, not much to discuss here then: you are quite wrong in cases mechanics encounter all the time, and too confident to seriously examine the possibility of your wrongness. Good luck out there.
Which is a reproducibility crisis in and of itself, as you mentioned, if not an outright inducement to dishonesty.
Worse, reproducibility in the "if you click go on this project, you will see it gives the answers I say it does," is of dubious value. Rather, the reproduction is supposed to be "use your models and change assumptions in such a way, you should see these updates."
We are at a time where exact reproduction feels possible, but that is typically not as useful as you'd think. A lot of the robustness of old experiments comes from building them all over again.
The code was not ancient, but written 12 months prior to me trying to build it. (Deep Learning project)
Asking as a scientist interested in reproducible research. Julia has been so much better than python at least in terms of dependency hell, but I still rely on some python packages through PyCall and I feel like that isn’t handled as nicely as Pkg.jl…
The best way to convince someone to learn SW practices is by giving them the hope of finding a better paying job.
I think there's actually a shortage of good training for scientific programmers, which probably has to come from people who are immersed in it.
On the other hand, is the grass really greener on the other side? One can read plenty of blogs and forum posts from programmers on the commercial side, complaining about the quality of code and coding practices, that they have to work on. I've read about banks running on COBOL and hacked together Excel workbooks.
No. Tons of people in academia are in academia because they believe in free knowledge and because they want to work as public servants outside the realm of for-profit economy. Most of us tolerate being payed little when working conditions are ok and there is freedom. The reason there are so few good programmers (or that they are in small pockets, or that most good software projects from academia are actually non-research side projects), is because software dev and maintenance it is not at all incentivized, chronically underfunded and understaffed. Short-term project-based financing structure makes any sustained software development hazardous.
OTOH lets put the ugly project web-pages aside and browse through our distribution's package repository for foundational software. How many of them have been passed from hand to hand through generations of academic workers? Quite a lot..
The problem is not that "we are not good at it" or anything. It's just that nobody's giving a shit, so people do it in their "free time" and so the landscape looks a lot like free software. In fact there is a big intersection.
The downside is Fortran really sucks to work with if you need data structures that aren't array based. I'd much rather do non numeric, or work that needs more abstract data structures in C or C++.
So true!
that's more than enough for staying power.
I use Julia every day (for scientific computing). I have never worked with or for the Julia Computing folks, but don't agree with your characterization of them. I like Fortran too, but personally I would rather use Julia if I have the choice.
This link shows an excerpt of this parallelization/optimization work for Fortran (Do scroll down...it's amazing).
This is by design.
I don't know how Fortran is any more, I didn't get as far as Fortran 77 since it wasn't 1977 yet.
But students seemed to hate the old Format statements to get your printouts with.
Properly done, a few lines of code could output reams of concise tabular data, but you had to be careful you didn't print out reams of gibberish instead. Those mainframe printers could chew through kilos of paper.
OTOH, for a single page report, a customized printout of meaningful consolidated, summarized data, it could basically take up a whole page of Format statements and even more print statements in the code.
A *whole* page.
And there was no such thing as What-You-See-Is-What-You-Get for printing, it was what you expect is what you hope to get.
Now it's the modern day in the chem lab, and with 10GB of modern scientific software on top of Windows, which requires a high-end desktop for this, I have not stopped wanting to print.
And my data is cloud-ready like never before.
But I have no use for that. After my data has lived a full life, it will go to heaven by itself. Seems like it could also expose my data to hell.
What about my printout?
"Low-code" derivative of Microsoft's Report Definition Language. You've got a template and a GUI and you can even move blocks around. What you see is even less of what you get. There are two main features not shared by Fortran:
1. You will *always* need some kind of iteration before you arrive at your final page format.
2. The code generated is *pages and pages* of XML to get a single printed page.
If I had something as performant as Fortran Format statements it sure would have saved a lot of time.
A big complaint about C was optimization failures from pointer aliasing, but that was fixed a decade ago.
Use by mistake the same variable in separate restrict declarations, and UB dameons will be summoned.
Otherwise, it's mostly C, C++, and Python, with a smattering of other languages, at least in the areas I work in.
Back in the mid-1990s, we decided to use C++ for NAMD because none of us knew FORTRAN that well, it was a greenfield project, and the previous in-house MD codes were in C.
I think one of the driving factors in this is that, as other people in this thread have discussed, most of the people writing this software are not software developers and have no interest in being software developers. The scientists trained in the 60s/70s/80s learned Fortran, who then founded their own research groups and taught their students Fortran, who are now running their own groups using Fortran because it's what they know. Some folks use Python for data analysis after their simulations run, but even that was rare 10 years ago.
I'll add another factor to your consideration. Quantum chemistry is mathematically and numerically more challenging than molecular dynamics, and requires a more advanced understanding of chemistry than MD does of chemistry or physics.
I suspect this makes MD codes easier to implement, and more open to multi-disciplinary development, than QC codes.
This thought comes from my experience. My PI at Illinois was Klaus Schulten, who was a postdoc in Karplus's lab at Harvard. Karplus's group developed CHARMM, written in Fortan.
Our lab also used Axel Brunger's X-PLOR, another Fortran code. I know we had a source license to X-PLOR.
If the factor you described were the dominate one, we should have been a Fortran shop.
Yet in the late 1980s/early 1990s (before my time) there were grad students in the group writing their own MD codes, one in C and another in Occam. (Occam was developed for writing parallel algorithms on a transputer. The transputer was seen as the future of parallel computing. The grad students before me built their own hardware around the transputer.)
My generation then developed NAMD using C++. The primary author, Mark Nelson, who had been maintaining one of the older codes, and was annoyed with it. He was grad student from CS (or EE?), with software industry experience before going to grad school. Two other grad students - Bill Humphrey and I - were in physics but had undergrad CS training. Plus, the group itself was multidisciplinary, with Laxmikant Kale's group in the CS department, who developed the Charm++ language. (Also, we collaborated with John Board's group from the EE department at Duke, to use their multipole package for long-distance electrostatics; that was in C or C++.)
Which means in our group alone there were at least three locally-developed MD codes. Each one targeted a different way of handling parallelism.
This was possible because the core MD engine is pretty simple. Adding different integration types, and parameterizing the force field, and developing faster approximate methods to handle hydrogen dynamics, and other aspects of MD are not so simple, but the core is still something many undergrads could write.
While QM codes require a more specialized knowledge that I certainly never learned, and which isn't easy to pick up by non-chemists, leading to a more isolated development culture passed on in the way you describe.
Development is increasingly a collective endeavour and frequently open source affair (and should definetely be so for publicly funded science) but fortran is still in the world of Von Neumann level geniouses punching algorithms on cards...
> the community doesn't really need most of what these tools offer either
not so sure about that. speaking only about the python universe I could see fortran being an easier alternative to C/C++ for implementing compute intensive stuff and python being the user friendly layer.
about the money: it would be no different than other open source computing stacks, so yes, no cigar. the main reason to add another option is potential productivity gains if one could enable more science oriented developers to develop performant libraries.
> if people are serious about fortran as an ongoing idiom
> Development is increasingly a collective endeavour and frequently open source affair
I disagree with the premise that these two things are linked. Fortran is alive and well in the closed-source corporate world, and it will continue that way indefinitely. It's used by scientists and engineers, not developers, so it's unaffected by changes in the development world. I think it's cool that people want Fortran to find a broader audience, and I think it would help, but it's not necessary for it to continue being used.
the lifespans of corporates is well known to get shorter and shorter. Lean periods, in particular, prompt people to re-examine the economics of various technology choices (The world of HPC is full of such extinction events, Unix workstations disappeared in favor of Wintel etc. Having survived previous events does not guarantee eternal survival).
On the other hand the line between "developers" and scientists/engineers will get further blurred and complacent corporates may at some point feel being completely starved of the relevant talent. Just today there was a front page HN discussion about ML augmented PDE solvers. It was not written in fortran.
Isn't it CUDA that is taking this role?
Also, CUDA is low-level a library by one vendor for one class of hardware. Not a language. Languages serious about scientific computing already have multiple interfaces for CUDA at various level of abstraction.
I first heard about Julia in about 2012, and while visibility has grown massively, I haven't seen anyone putting it into production or widespread use in any company or academic group except for where you have someone who wants to be an "influencer" trying their luck.
I keep hearing this meme. My company uses it in production.
Edit: To be clear; when I first heard about Julia I was excited and a bit sad it had come into my awareness a bit too late for me to use in my PhD. However, since then I see it come up more and more, yet the core UX things which were regarded as "not quite as good as python" seem to persist. Some things need to change in order for the language to get over the next hump of acceptance, and I feel like a community who are very hostile to outside opinions is a major one.
You are exemplifying one of the points from my original post quite well though, so thanks, I guess.
For others who might not know you as a co-creator of the language with a strong financial interest in its success, don't you think your comments on Julia ought to carry a disclaimer?
Your group have clearly done fantastic work, but having such centralised (and "vocal") management makes it feel more like Julia is a start-up whose product is a language, rather than a language which a spin-out company is commercialising a bit. I trust the former far less than the latter.
Yes! You can find them all over. https://brainstation.io/career-guides/who-uses-python-today#.... for example. People compile incomplete lists for the answer of "do people use X?" It's never expected that the lists are complete. This is the most bizarre comment thread I've ever read.
> but having such centralised (and "vocal") management makes it feel more like Julia is a start-up whose product is a language, rather than a language which a spin-out company is commercialising a bit
Okay... then just read a different source? There's tons of these things online. Stefan just referenced the one he knows the URL of because he's involved with it. But here's a random one. https://www.datacamp.com/blog/the-rise-of-julia-is-it-worth-.... Each package ecosystem tends to have a list, like SciML has a (very incomplete, probably less than 2% listed here according to analytics) list https://sciml.ai/showcase/. There's lists all over.
I doubt any list you'll get is complete. It's more a list of examples
lol, no.
You have to understand, random commenters in HN have very high standards, not like those amateurs at ASML /s
Isn’t that either ironic or hypocritical? Rejecting something out of hand because too many people like it is just as superficial as embracing something on account of many people liking it.
Either try it and reject it, or ignore it. But Too Trendy is not a good reason.
I know of some large-scale physics simulations that are using Julia, and it’s widely considered the language to use for new projects. It’s what I use now for my physics hobby projects. I’d never heard about its finance-bro associations. And if I had, why would I give a crap?
On one occasion he was on a team that was collaborating with a team from MIT that had contributed some software to the project that Steve disapproved of. So, one weekend, Steve entirely re-wrote the software that the MIT team had contributed. Unfortunately, this turned out to be a firing offense because he had humiliated the collaborators.
(One thing to note about Steve is that he was on the spectrum -- as smart as they come, but not good at reading social and political situations.)
Steve was not out of a job for long, however -- he was fired in the morning and by that afternoon he had accepted a job with a proprietary trading desk on Wall Street (he had a connection). His salary at least doubled.
A year after that incident Steve called me up and asked me to come down and join him at the prop trading desk, so I did. We had a good ride until the 2008 financial crisis and then our entire division (several prop trading desks) was fired on Jan 2nd, 2009.
It was difficult to get a job on Wall Street in early 2009 because everyone was laying people off and going belly up. But Steve immediately landed a $400,000/year job with an options trading house. When we were catching up over coffee a few months later he mentioned to me that one of his projects was designing a trading system that needed to solve 500,000 differential equations per second. I just wished him luck and thanked God that I had moved into coaching the LSAT instead.
Unfortunately, Steve only lasted about 18 months at the options trading house -- he had a disagreement with another engineer about the best way to implement parallel processing for a certain situation and Steve was not one to give an inch when he thought he was right. So he got fired.
The conclusion that Steve drew from this was that he never again wanted to work with someone who did not have a Ph.D., so he moved to a division of NASA that was doing research on how to model the melting of glaciers, and which is apparently a space that is full of people with Ph.Ds.
It turns out that Fortran is the best tool for modeling glaciers, so Steve ended up doing heavy mathematical programming in Fortran. As far as I know, this is what he is still working on.
Of course, Steve transitioned a couple of years ago and he (she?) now goes by Jessica.
It is generally considered polite to refer to people post-transition by their new pronoun. So, "she".
Is it the best language for this, or is there just more existing code for modeling glaciers in Fortran than in any other language?
Also, this person’s name is Jessica and their gender is ‘she’. It would be appropriate to simply refer to her as Jessica, not referring to their old name at all. Also most trans people do not agree that they have changed gender, as your post suggests. Instead, they view themselves as have been misgendered at birth. Thus, to refer to their past by their old pronouns is to continue to misgender them in the present. So please don’t.
Finally the persons gender here is no more important than their race, religion, or countless other unimportant things that you didn’t mention. Maybe leave the whole transgender thread out of any future conversations.
This story would have been entirely as informative if the story had simply been about a woman called Jessica.
So yes, I will censor bigoted views. I will censor Nazi propaganda. I will censor racism. And I will censor outing transgender persons.
They do not have a right to tell a bigoted story on a public forum. They might be permitted, but don’t confuse that with a right.
---
The best software engineer I ever worked with, whom I'll call Jessica, ended up working in Fortran after we parted ways. She had a Ph.D. from Harvard in Computer Science and we met at a research lab at Harvard Medical School. Interestingly, both of Jessica's parents as well as her uncle were professors of Computer Science at top schools. By the time she was 18 years old Jessica had a dozen years of programming experience under her belt.
On one occasion she was on a team that was collaborating with a team from MIT that had contributed some software to the project that Jessica disapproved of. So, one weekend, Jessica entirely re-wrote the software that the MIT team had contributed. Unfortunately, this turned out to be a firing offense because she had humiliated the collaborators.
(One thing to note about Jessica is that she was on the spectrum -- as smart as they come, but not good at reading social and political situations.)
Jessica was not out of a job for long, however -- she was fired in the morning and by that afternoon she had accepted a job with a proprietary trading desk on Wall Street (she had a connection). Her salary at least doubled.
A year after that incident Jessica called me up and asked me to come down and join her at the prop trading desk, so I did. We had a good ride until the 2008 financial crisis and then our entire division (several prop trading desks) was fired on Jan 2nd, 2009.
It was difficult to get a job on Wall Street in early 2009 because everyone was laying people off and going belly up. But Jessica immediately landed a $400,000/year job with an options trading house. When we were catching up over coffee a few months later she mentioned to me that one of her projects was designing a trading system that needed to solve 500,000 differential equations per second. I just wished her luck and thanked God that I had moved into coaching the LSAT instead.
Unfortunately, Jessica only lasted about 18 months at the options trading house -- she had a disagreement with another engineer about the best way to implement parallel processing for a certain situation and Jessica was not one to give an inch when she thought she was right. So she got fired. The conclusion that Jessica drew from this was that she never again wanted to work with someone who did not have a Ph.D., so she moved to a division of NASA that was doing research on how to model the melting of glaciers, and which is apparently a space that is full of people with Ph.Ds.
It turns out that Fortran is the best tool for modeling glaciers, so Jessica ended up doing heavy mathematical programming in Fortran. As far as I know, this is what she is still working on.
---
In removing the dead-naming and misgendering, did I reduce the usefulness of this story in any way, as a response to "Why Fortran is a scientific powerhouse"? No.
You might ask why I didn't remove the bit about "being on the spectrum". I left this is because, as an Autistic person myself, I too suffer such discrimination in the workplace.
Also, I take the words of the Bible seriously: "Male and female created he them; and blessed them, and called their name Adam, in the day when they were created.” (KJV)
During the time I knew him, Steve was married to a woman and focused on becoming a father. He himself would have described himself as a man.
Finally, the fact that Steve was "on the spectrum" is central to understanding him fully, and the fact that he transitioned is telling because a surprisingly large percentage of men who transition in midlife are extremely intelligent and are on the spectrum. I believe that including the details about his personality and his transition allows a fuller picture of the man to snap more coherently into place, while also shedding light on the current cultural moment.
Also, I simply don't agree that using pronouns that align with a person's biological sex is analogous to using the n-word, and I'm sorry that you feel that way.
I mean no offense to anyone (although I won't go out of my way to stop people from taking offense where none is intended) and there is no engineer I have ever held in higher regard than Steve/Jessica. I saw him pull off absolutely mind-bending feats of engineering and if I had to bet then I would say that every time he put his foot down and died on a hill over an engineering disagreement that he was absolutely in the right from a technical point of view.
Then you are misinformed and out of date.
>Also, I take the words of the Bible seriously
You do realize that Genesis says nothing about which of them has a penis, or if a penis is required? Is it possible that God has a bigger imagination and vision than you do?
>I mean no offense to anyone
I have told you that your are offending an entire group of people, and your response is "I mean no offense to anyone." You do mean offense. Have the courage to say so.
I don't understand how you can think of gender transition as something not worth mentioning when depicting the life of a person. It is a huge decision in life, and probably tells a lot, for example about the suffering that person has been living internaly for years.