KDE Conquers Astrophysics With Kst
Telex4 writes "The Free Software community is constantly inundated with interesting new projects, but occasionally something crops up which is really special. Kst is just such a project. Started by Barth Netterfield, an astrophysicist, as a personal project to plot data from his experiments, it has now taken on a life of its own, being used in numerous academic projects, and finding funding from several government agencies. Intrigued by this project's success, and with a little prod from co-developer George Staikos, I interviewed Barth and George about kst, Free Software and physics."
It's easy to generate png/pdf/ps plots and they look really nice.
RTFA!
kst1.png
kst2.png
Keep your eyes to the sky.
It looks good, but I'm skeptical about its usefulness for me. ROOT already produces damn good output and fills most of my needs. And for everything else there's gnuplot.
But I will look at kst. If it's as good as they say it is, I may use it instead of gnuplot.
I used <a href="https://www.wavemetrics.com">Igor</a&g t; as an undergrad for most of my data plotting and graphing (physics), but the interface was not intuitive and without knowing the command-line language, navigating the menus took a very long time, even when you knew what you were looking for. Also, the price ($400 for the latest version) kept me away from using it off campus. Now I tend to stick to <a href="http://root.cern.ch/">ROOT</a> simply because its Cint interpreter is ideal for handling the massive (10^6 n-tuples) amount of data I look over, and because it's free. However, making advanced graphs and plots with ROOT requires a whomping manual and a fairly good grasp of C, as there are virtually no point-and-click features to it. I'm really glad another open-source data manipulation program is in the works, and that it can do the things ROOT can as easliy as Igor can without the emense price restrictions.
/*No comment*/ #No comment
While I agree that the Motif app looks a little outdated, the app is free as in GPL and is really powerful in terms of features. For example, it allows scripting.
Because without it, your not doing the research. Essentially its because they said so, you can take it or leave it.
"I use a Mac because I'm just better than you are."
I take your point - most of this application, like many, is in principle doable independant of the underlying OS.
However, there are a few pluses on the side of Linux for this application.
2 GB+ files. Some versions of Win32 can do them, some can't. Some can only do it with a following wind. When you're talking scientific data, such file sizes can crop up often, if not a regular feature.
Network independance. This is less of an issue for display, but on the processing side, being able to coordinate multiple tasks, spread across many servers, from one desktop is a big win. Particualrly when it's a 'free' side effect (requires no extra programming). Four boxes are cheaper than a quad box - by quite a sizeable margin.
Which leads us on to the scheduler - with Win2K, a background number crunch task will take longer than on Linux, and impact interactive response more. That's not off the top of my head - that's based off my Linux/KDE desktop and my office mates Win2K systems doing the same tasks (computational chemistry, so essentially big matrix sums).
There's also library support. Not such a big one, as they can be ported, but it's more work that way. By libraries, I mean things like FFTW, LAPACK and BLAS.
So, that's a few areas with modest wins for unix/KDE. I'll add that headless admin for Unix is simpler than for Windows, which helps with the headless cruncher boxes, and conclude that there is a reason that unix is popular in universities, as it's got a slight edge.
Yes, it may well have been as easy to write for Win32 as KDE [0] - but in use, the linux is better for the number crunching.
[0] I wouldn't agree to that personally, but there's a degree of personal preference in there, so that's not objective.
Q: What does kst stand for?
A: The 'k' in kst stands for the same thing as the K in KDE. (ie, the letter after J and before L). The 's' and the 't' have a similar explanation.
"THEY" are whomever "YOU" are dealing with. It may be the "U." if they are the "THEY" that wishes to keep the ownership and anything related to the project, or perhaps "THEY" refers to the sponsor if technically "YOU" are working for "THEY" through the "U." In short "THEY" is whomever is asking you to sign the "NDA."
"I use a Mac because I'm just better than you are."
Another piece of software that became quite a hit in academia is Gretl, the GNU Econometrics, Time-series and regression library.
It's a perfect clone of eViews, and it's free as in "just grab it"
Comment removed based on user account deletion
There's so much bullshit in the parent post - it's just mind boggling. First off, every NT based version of Windows supports 2GB+ files. That's since Windows NT 3.51 folks! Wake up!
Network independence section is totally bogus, too. It takes LESS bandwidth to run a Windows box through RDP these days than what a simple X app would create. It's trivial to setup and run, and guess what, Windows has a TCP/IP stack, too.
There's no reason to believe that Windows is slower at number crunching. It's faster at everything else, why would it be slower at this particular task.
Libraries DO WORK under windows, LAPACK at the very least.
I mean, Linux has its strengths, but spreading such a smelly bullshit as the parent does is just insulting to my intelligence.
People share their ideas and publish, because if they don't they don't get tenure or graduate or whatever. But there's often a big development investment involved in going from some paper published in a journal to working code. The published paper may give you the major differences between what they've done and the previous work, but most any important achievement builds on a bunch of prior work which is, say, contained in 5 other papers, which in turn were each based on 5 other papers each, and tracking all that down and getting it and translated into code can take a long time.
So say I'm the guy who published the paper -- while you're spending all your time re-implementing my previous method, I've already gone on and developed another few enhancements or a whole new method, and gotten another paper or two out of it, while you're still trying to recreate what I did last year.
So basically, just because the ideas in academia are basically open, that doesn't mean the implementations are. In fact, I've heard some math guys voice the opinion that releasing your source code is just a waste. It takes a significant time investment on your part to get it all packaged up, perhaps cleaning up the code some, and then to answer questions people have about it etc. And when it comes time for tenure review, they don't ask you how much source code you released. No, all that matters is how many journals you published in. So while you were busy cleaning up your source code for release, fixing non-critical bugs and adding non-essential features, you could have been working on the next publication instead.
Of course a lot of researchers do go all the way with openness and release source. But I've seen plenty of both strategies.
Another part of the equation is that Universities these days all want a piece of the action on anything invented within their walls. So they want you file for patents and such, and try to find people that will license those patents. And naturally a big cut of the licensing fees go to the Universtity. And then there's folks who dream of starting their own multi-million dollar spin-off technology company, so they don't want to let too many details about what they're doing to leak out until they've got all the patents lined up.
You know all those "Segmentation Fault" errors that ROOT gives you?
A real tool doesn't do that.
It's really very cute how enamored particle physicists are by C++. It's very fitting it turns every software construct into something they're familiar with, a particle! er, object. Too bad they can't ditch the FORTRAN habits.
"You can write bad FORTRAN in any language." - my advisor
But the disagrements had to do with X. Some people couldn't wait to get their improvements into RMS's release cycles(of Debian-esque proportions, and larger). So they banded together, and their version worked with X, it was stable and worked better for them. By that time it would have been impossible to integrate the improvements without recoding things, which would have taken enough time that the new GNU emacs would be out anyway(with X) in a stable form.