Drawing a spectrum is not the most stupid thing a computer can do. Actually it requires a lot of patience and dedication, both for a programmer and a user. All the computer has to do, in the case of a 1D spectrum, is to connect adjacent points. They are also equally spaced, along the x axis. Where's the complication? Furthermore, little has changed in the last 20 years. The only change I notice is that there are less plotters around today, which means more room in the lab, less machines to maintain and less drawing routines into the program.
Unfortunately computers seems to follow the Murphy's law: they always find a way to complicate my life. I told you that I installed Jeol Delta, courtesy of Jeol, but it's too difficult for me to use. It draws spectra wonderfully, into a small pane, and I don't know how to enlarge it (I'd like to see the plot as large as my monitor). That's not a big issue, because Delta would still remain too complicated for me to use it. I also have Mnova, and I know how to use it. Mnova can draw a plot as large as the window, but it's painfully slow. I have tried to modify the settings, and actually the situation improves a lot with the option "Entire Page" and the pen width = 1. Even after this optimization, Mnova still remains slower than Delta. With the latter I can continuously change the intensity of the spectrum, and the response is fluid. Mnova reacts very slowly, instead, showing a flashing watch cursor, whenever I roll the scrolling wheel. Surprisingly, the manual phase correction appears more fluid (the computer is doing the same things plus additional processing, yet it takes less time! why?). In conclusion, I have discovered how to make the plot as large as the window, but it's impossibly slow, therefore I have switched to the "Entire Page" mode, which is uncomfortably slow.
For me the drawing speed is fundamental, because I navigate a lot through my spectra and want the computer to be as fast as my hands. There are, also, economical and psychological motivations: I expect any new combination computer+software to be as fast as its predecessor. I assume that the fault is mine or of my computer, but what can be good news for you is bad news for me (if the problem was more generalized, I had some hope to find some help some where). Don't worry about me, I also have a third program that combines the largest size with the fastest speed; I dubbed it "the ultimate NMR experience".
Today's graphic cards can be faster than the rest of the machine, but only when they like, and they have never learned how to draw a 1D plot. The single points of the spectrum are connected by the program, not by the graphic card. Not so bad: when the program takes care of the humblest task, it also has more control over them.
The user can do very little, apart from verifying the limits of the software in use. You should verify 3 things:
1) Does the program draw fast enough? If the answer is NO, I would reduce the size of the FT anytime I can.
2) Is the plot faithful to the spectrum? The answer is YES in the case of the above programs, but the situation is often worse. If you disable the antialiasing (or when it's already absent) you can see shoulders when they don't exist and singlets with an apparent trace of splitting on their tops.
Those small couplinga are not due to a neighbor nucleus, but are a courtesy of the graphic card (or of an ignorant programmer who can't take advantage of today's graphic cards).
3) Is the spectrum synchronized with the scale? This is something difficult to verify. You really need to master the software to verify such a detail. You can do it indirectly, for example when you create a view with two or more spectra superimposed. If all the spectra are perfectly aligned at all magnification levels, and if you read consistent frequency values from the scales and the cross-hair tools, then all is OK.
It's not enough that all the drawing routines are aligned, they must also be CENTER-aligned. What's more difficult to realize is that they must be INTRINSICALLY center-aligned. This apparently futile consideration is at the heart of a successful alignment. Let's take for example the same spectrum, acquired from 0 to 64 ppm and processed twice. Let's make the FT size = 32 points the first time and 64 points the second time. If you believe that a point can't have an intrinsic size, you'll make them fall at 0, 2, 4, ... 62 ppm in the first case and at 0, 1, 2, ... 63 ppm in the second case. The first point of the first spectrum, falling at 0, corresponds to the first pair of points of the second spectrum, centered at 0.5 ppm. As you can see, the spectra are not aligned, there's a difference of 0.5 ppm. If, instead, you conceptualize the point like a nucleus immersed in the MIDDLE of its electronic cloud, then the points of the first spectrum fall at 1, 3, 5, ... 63 and the points of the second spectrum at 0.5, 1.5, 2.5, ... 63.5. Now they are perfectly aligned, as you can easily verify.
You must know the above things from the start, even when your needs are limited to a single spectrum per plot. In conclusion, no point can ever fall on the boundary of the spectral width. If it does, the program is not able to always align the spectra. If the above discussion seems purely academic, try aligning a 2D plot with a 1D spectrum... if it's simple, praise the programmer!
Friday, 13 June 2008
Thursday, 12 June 2008
What's Old
If you are still waiting for reviews of programs, you are in good company. I have realized that it's arduous, particularly when nobody gives you a program. If you want to write the reviews, I can share with you the authorship of the blog. From tomorrow I return blogging regularly (daily?) with a new series of articles dedicated to the old and established computing methods used in high resolution NMR of liquids. There will be very little of mathematical nature (but if you understand, for example, why we can't divide by zero, that would be beneficial).
I will express my personal inclinations, and share what I have learned through experience. To really understand why, sometimes, a method yields poor results, you need to recompile the code of the program with statements like:
printf ("coeff. no. %d = %5.5f\n", i, coeff[i]);
If you haven't access to the code, you can still learn a lot of things by simply looking at the plot on the monitor. In some cases it can be necessary to create artificial spectra with perfect signals and no noise (or artificial noise). Other times you start from an experimental spectrum and alter it (deleting a portion, for example) to create a test. There are general purpose NMR programs that allow for this sort of manipulations. If you can't do any of the above things, then read my blog! If you want to become an expert, practice and observation are however necessary.
A tentative index for my "lessons" can be:
I will not follow any particular order. I will NOT suggest any particular software. You can ask questions.
I will express my personal inclinations, and share what I have learned through experience. To really understand why, sometimes, a method yields poor results, you need to recompile the code of the program with statements like:
printf ("coeff. no. %d = %5.5f\n", i, coeff[i]);
If you haven't access to the code, you can still learn a lot of things by simply looking at the plot on the monitor. In some cases it can be necessary to create artificial spectra with perfect signals and no noise (or artificial noise). Other times you start from an experimental spectrum and alter it (deleting a portion, for example) to create a test. There are general purpose NMR programs that allow for this sort of manipulations. If you can't do any of the above things, then read my blog! If you want to become an expert, practice and observation are however necessary.
A tentative index for my "lessons" can be:
- Fourier Transform
- Zero-Filling
- Weighting
- Line-Fitting
- Symmetrization
- Simulation of complex spectra
- Spectra subject to Chemical Exchange
- First Order Analysis
- Digital Suppression
- Hilbert Transform
- Integration
- Baseline Correction
- Phase Correction
- Noise Removal
- Drawing Routines
I will not follow any particular order. I will NOT suggest any particular software. You can ask questions.
Tuesday, 10 June 2008
Stan's Blues
Stan speaks a different language.
I desire to know NMR and math like he does, but I am hopeless. It' s like dreaming to play football like Julio Ricardo Cruz or chess like Michele Godena or the sax like Getz. Generally speaking, when I read a scientific paper, I don't understand what's going on. Sometimes, however, I need to decide, at least, if that paper/poster is important or forgettable. My "trick" is to think like a better. (Actually, every better thinks in his own way...). Now I will show you my "analysis" of the eDispa poster.
One very good reason to bet that eDISPA works: the authors, who are friends of mine, wrote privately that eDISPA really works; they have never told a single lie and I trust them.
Five reasons to bet against it:
(1) The poster says the method is not ready yet. An algorithm, like a principle, either works or not. If it's not ready YET, it means that it doesn't work and never will. I do hope that Stan has discovered ANOTHER method that works, but, from his words I get that the method described into the poster doesn't work.
(2) In the last 20 years more than ten articles have been proposing novel methods for automatic phase correction. All the articles begin affirming that ALL the preceding methods "do not seem to be reliable" (Anal. Chem. 1990, 62, 864). If you are to make a bet, you have more chances to win if you bet against ANY auto-phasing method, at least those published. There is abundant historical evidence that no author is "reliable" when judging his own algorithm.
(3) The old auto-phasing methods based on DISPA are among the worst ones. Therefore I am suspicious of anything containing "DISPA" in its name.
(4) I can see no connection between DISPA and eDISPA. Does any reader? I believe that Stan started with the idea of building a modified DISPA. He had already found the name for the successor. He soon realized, however, to be on a wrong path. He could find an alternative approach, but not a new name: "eDISPA" has remained. I can read all these things between the lines of the poster.
(5) The principle described by the poster is too complicated. It looks like a series o patches applied over a hole. I like simpler concepts.
It's false that I write this blog to reveal the errors into the work of my competitors. My mission is to shout: "Customers, wake up!". Let's take for example Mnova. I have found a simple combination of 3 VERY COMMON menu commands that, given to Mnova right after the start, in any order, cause me to reboot the computer (because, unfortunately, Mnova doesn't crash, but keeps thinking forever and takes complete control of the CPU). I have reported the problem to the authors and I know they will fix it ASAP. The problem is that I am not a customer! MestreLab Research has kindly provided me with a license for free, so I can try their algorithms, but I don't work with Mnova. How is it possible that thousands of paying customers have never seen their computers freezed? Either my computer is too old, or they don't use the program for 2D NMR (this is what I believe) or they prefer complaining with me rather then writing two lines to the makers. That's something I can't bear. Anyway, my shouting hasn't woken up anybody yet. Why the hell keep I writing?
It's true that I have dedicated more space to criticize the errors than to praise the merits. This doesn't mean that I can't appreciate what others do. For example, Carlos Cobas, co-author of eDISPA, has invented a terrific algorithm to correct an NMR baseline. I have always expressed my deep admiration for it (I never invented anything of that level in my whole life) and asked his help to add the algorithm into iNMR.
I also invite the reader to visit Carlos' blog. He describes algorithms that you can verify by yourself immediately, because he also gives you the program (for all platforms! free trial period of 45 days). I have verified that several methods don't apply to my spectra (plain vanilla 1H spectra, FYI) and that saved me the effort of studying the corresponding articles.
Stan thinks that it's a good thing when a commercial application offers the choice among many alternative algorithms. I think that, the more methods are shown by the interfce, the more time I am going to waste with them. Give me only a few methods that always work, if such a thing is possible. Keep the alternatives hidden.
I desire to know NMR and math like he does, but I am hopeless. It' s like dreaming to play football like Julio Ricardo Cruz or chess like Michele Godena or the sax like Getz. Generally speaking, when I read a scientific paper, I don't understand what's going on. Sometimes, however, I need to decide, at least, if that paper/poster is important or forgettable. My "trick" is to think like a better. (Actually, every better thinks in his own way...). Now I will show you my "analysis" of the eDispa poster.
One very good reason to bet that eDISPA works: the authors, who are friends of mine, wrote privately that eDISPA really works; they have never told a single lie and I trust them.
Five reasons to bet against it:
(1) The poster says the method is not ready yet. An algorithm, like a principle, either works or not. If it's not ready YET, it means that it doesn't work and never will. I do hope that Stan has discovered ANOTHER method that works, but, from his words I get that the method described into the poster doesn't work.
(2) In the last 20 years more than ten articles have been proposing novel methods for automatic phase correction. All the articles begin affirming that ALL the preceding methods "do not seem to be reliable" (Anal. Chem. 1990, 62, 864). If you are to make a bet, you have more chances to win if you bet against ANY auto-phasing method, at least those published. There is abundant historical evidence that no author is "reliable" when judging his own algorithm.
(3) The old auto-phasing methods based on DISPA are among the worst ones. Therefore I am suspicious of anything containing "DISPA" in its name.
(4) I can see no connection between DISPA and eDISPA. Does any reader? I believe that Stan started with the idea of building a modified DISPA. He had already found the name for the successor. He soon realized, however, to be on a wrong path. He could find an alternative approach, but not a new name: "eDISPA" has remained. I can read all these things between the lines of the poster.
(5) The principle described by the poster is too complicated. It looks like a series o patches applied over a hole. I like simpler concepts.
It's false that I write this blog to reveal the errors into the work of my competitors. My mission is to shout: "Customers, wake up!". Let's take for example Mnova. I have found a simple combination of 3 VERY COMMON menu commands that, given to Mnova right after the start, in any order, cause me to reboot the computer (because, unfortunately, Mnova doesn't crash, but keeps thinking forever and takes complete control of the CPU). I have reported the problem to the authors and I know they will fix it ASAP. The problem is that I am not a customer! MestreLab Research has kindly provided me with a license for free, so I can try their algorithms, but I don't work with Mnova. How is it possible that thousands of paying customers have never seen their computers freezed? Either my computer is too old, or they don't use the program for 2D NMR (this is what I believe) or they prefer complaining with me rather then writing two lines to the makers. That's something I can't bear. Anyway, my shouting hasn't woken up anybody yet. Why the hell keep I writing?
It's true that I have dedicated more space to criticize the errors than to praise the merits. This doesn't mean that I can't appreciate what others do. For example, Carlos Cobas, co-author of eDISPA, has invented a terrific algorithm to correct an NMR baseline. I have always expressed my deep admiration for it (I never invented anything of that level in my whole life) and asked his help to add the algorithm into iNMR.
I also invite the reader to visit Carlos' blog. He describes algorithms that you can verify by yourself immediately, because he also gives you the program (for all platforms! free trial period of 45 days). I have verified that several methods don't apply to my spectra (plain vanilla 1H spectra, FYI) and that saved me the effort of studying the corresponding articles.
Stan thinks that it's a good thing when a commercial application offers the choice among many alternative algorithms. I think that, the more methods are shown by the interfce, the more time I am going to waste with them. Give me only a few methods that always work, if such a thing is possible. Keep the alternatives hidden.
Friday, 6 June 2008
Fear of Learning
Last week I wrote that people generally don't like to learn new software. It must be a tedious job indeed. This week was opened by a small and incredible event that is also an example of opposite attitude. It has nothing to do with NMR, although the main character of the story is reach enough to buy and maintain a couple 900 MHz, privately. Jose Mourinho came in Italy and spoke in public, for the first time, in Italian. He explained that had been studying the new language for only a month, but he spoke so fluently that nobody, here, believes him. If he had learned Latin in 1 year, than I would have really been impressed! FIY, he already spoke Portoguese, Spanish, English and I don't know how many other languages. Isn't it simpler to learn to use a program than to learn so many languages? Of course, but if you could afford to hire the best teachers all for yourself, as Mourinho has certainly done, many things become easy.
The expression of Mourinho after having been informed that, before you can use an NMR spectrometer, you must learn the software.
(photo taken from www.settimanasportiva.it)
NMR software, alas, is never easy enough. Even when it is, you refuse to learn it. It's... scaring, that's the problem. It's not like driving a car. Once you have learned to drive your first car, which is not immediate, it takes very little to learn driving another car. In principle the same is true for NMR programs: they must have many things in common. In practice they are like different languages: when you switch language you should adapt yourself to a different syntax and even a different mentality. (OK, that's exactly what I am NOT doing when blogging, that's why this blog sucks!).
If you still think in the way dictated by your old software, switching to a new one is frustrating, I know. You'll soon be wasting time to search, into the new program, for all the "equivalent actions" that some times are completely absent, but you don't know and you keep searching.
Although it's conceptually wrong, it's in the human nature, it's hard to defeat the instincts developed in the past. The same mechanism that makes so natural to switch to a new car, makes so difficult to switch to a new NMR program.
This in the fundamental reason for the success of the software created for the spectrometer that is also abundantly sold and bought for the PCs.
Advantage: you don't have to learn anything new, you are productive from day one. Disadvantages: (1) the higher price, certainly; (2) the ugliness, quite often. The best programs are those that perform a single task and do it perfectly. It's feasible to write a program that manages acquisition, processing and analysis at the same time, but when you put so many tasks into a single product, the interface and the usability suffer. A program that performs a single task, like processing or analysis, has more chances to be elegant, pleasant, accurate and flexible.
For a prolonged period I have been happily using 3 different programs for acquisition and a fourth one (SwaN-MR) for processing. It was wonderful because I could also modify the latter whenever I wanted anything more. Of course you are not supposed to be a programmer. The best you can do is to choose a single program and learn it very well, both by studying the manual and by using it daily. After a couple of years, only if you are bored and can afford it, change program or job or town and start again.
The expression of Mourinho after having been informed that, before you can use an NMR spectrometer, you must learn the software.
(photo taken from www.settimanasportiva.it)
NMR software, alas, is never easy enough. Even when it is, you refuse to learn it. It's... scaring, that's the problem. It's not like driving a car. Once you have learned to drive your first car, which is not immediate, it takes very little to learn driving another car. In principle the same is true for NMR programs: they must have many things in common. In practice they are like different languages: when you switch language you should adapt yourself to a different syntax and even a different mentality. (OK, that's exactly what I am NOT doing when blogging, that's why this blog sucks!).
If you still think in the way dictated by your old software, switching to a new one is frustrating, I know. You'll soon be wasting time to search, into the new program, for all the "equivalent actions" that some times are completely absent, but you don't know and you keep searching.
Although it's conceptually wrong, it's in the human nature, it's hard to defeat the instincts developed in the past. The same mechanism that makes so natural to switch to a new car, makes so difficult to switch to a new NMR program.
This in the fundamental reason for the success of the software created for the spectrometer that is also abundantly sold and bought for the PCs.
Advantage: you don't have to learn anything new, you are productive from day one. Disadvantages: (1) the higher price, certainly; (2) the ugliness, quite often. The best programs are those that perform a single task and do it perfectly. It's feasible to write a program that manages acquisition, processing and analysis at the same time, but when you put so many tasks into a single product, the interface and the usability suffer. A program that performs a single task, like processing or analysis, has more chances to be elegant, pleasant, accurate and flexible.
For a prolonged period I have been happily using 3 different programs for acquisition and a fourth one (SwaN-MR) for processing. It was wonderful because I could also modify the latter whenever I wanted anything more. Of course you are not supposed to be a programmer. The best you can do is to choose a single program and learn it very well, both by studying the manual and by using it daily. After a couple of years, only if you are bored and can afford it, change program or job or town and start again.
Saturday, 31 May 2008
DISPArecido
Who remembers eDispa? On April 15, 2007 I wrote: "I suspect that eDispa will disappear into oblivion". On April 16 I added: "That poster says so many implicit things than demolishing it point by point would be easy and funny".
I haven't heard of it again. Did you? Are you longing for eDispa?
I haven't heard of it again. Did you? Are you longing for eDispa?
Friday, 30 May 2008
Manual
Today I am free write the most outrageous ideas that cross my mind. They say that nobody reads the manuals. I have put the title "Manual" and now anything I write will be read by myself only. Yes, I read the manuals and sometimes I even read them twice. I don't like doing it, yet it's a precious activity. If I am going to use a program, I know I can't learn it by trial and error, it's only a waste of time. I look for the manual and study it.
A well-written manual it's hard to find today. If people were to choose program on the clearness of their manuals, the documentation writers would be as rich as Bill Gates and our kids would aspire to become doc writers instead of football players. That's not the case. I myself have maintained, for years, that programmers can't neither be the testers nor the doc writers of their own programs. Today I have changed opinion, not because my idea was bad, but just because a bad manual is better than no manual.
Let's hope that, at least, the manuals are up-to-date. Have you ever found a manual that refers to an old version of the program? It easily happen that they change the program, even drastically, but forget to update the manual. That's the worst thing that can happen. A less sad situation, yet still annoying, is when you buy the Mac version of a program and all the figures of the manual refer to the Windows version.
Are they to blame? They are not, because they have been told that nobody reads the manuals, so why should they invest time into the job of writing manuals? Why? WHY?
After years I have found the answer. I had to. I was writing pages over pages, and receiving the confirmation, day after day, year after year, that nobody was reading them. They still use to call me and ask: "where can I found the manual?". They keep printing it, losing it and printing it again, but never finding the time to read it. I stopped and told to myself: "Either you find valid a reason, in the next 5 minutes, for doing it, or cease writing manuals forever". In the next 2 minutes I realized that, quite often, I consult my own manuals because I forgot how my programs are supposed to work. Consulting the manual is simpler and faster than reading the code of the program
Now I write manuals for myself. I attach the manual to the product because you can't sell a program without any manual (and there's even the risk that somebody checks if the manual actually describes the enclosed program or a different one), but I write the manual for myself. I am not proud of it but, hey, you don't know how difficult it can be to write a good manual.
After years of frustration I finally have a thing in common with Scaruffi. (I seem to remember that he once stated, in an interview, that he writes a lot because his memory has always been week; but being my memory week too, I may be confusing him with another person...).
A well-written manual it's hard to find today. If people were to choose program on the clearness of their manuals, the documentation writers would be as rich as Bill Gates and our kids would aspire to become doc writers instead of football players. That's not the case. I myself have maintained, for years, that programmers can't neither be the testers nor the doc writers of their own programs. Today I have changed opinion, not because my idea was bad, but just because a bad manual is better than no manual.
Let's hope that, at least, the manuals are up-to-date. Have you ever found a manual that refers to an old version of the program? It easily happen that they change the program, even drastically, but forget to update the manual. That's the worst thing that can happen. A less sad situation, yet still annoying, is when you buy the Mac version of a program and all the figures of the manual refer to the Windows version.
Are they to blame? They are not, because they have been told that nobody reads the manuals, so why should they invest time into the job of writing manuals? Why? WHY?
After years I have found the answer. I had to. I was writing pages over pages, and receiving the confirmation, day after day, year after year, that nobody was reading them. They still use to call me and ask: "where can I found the manual?". They keep printing it, losing it and printing it again, but never finding the time to read it. I stopped and told to myself: "Either you find valid a reason, in the next 5 minutes, for doing it, or cease writing manuals forever". In the next 2 minutes I realized that, quite often, I consult my own manuals because I forgot how my programs are supposed to work. Consulting the manual is simpler and faster than reading the code of the program
Now I write manuals for myself. I attach the manual to the product because you can't sell a program without any manual (and there's even the risk that somebody checks if the manual actually describes the enclosed program or a different one), but I write the manual for myself. I am not proud of it but, hey, you don't know how difficult it can be to write a good manual.
After years of frustration I finally have a thing in common with Scaruffi. (I seem to remember that he once stated, in an interview, that he writes a lot because his memory has always been week; but being my memory week too, I may be confusing him with another person...).
Tuesday, 15 April 2008
Beyond blogging: the NMR wiki
While yours truly gets more and more bored of blogging, new blogs on the same subject have appeared, all better looking. The only record remaining to my blog is that of being the oldest blog dedicated to NMR software.
Now it's the time for the NMR wiki. In the intentions of the founder, Evgeny Fadeev, it will be a cooperative effort to share information. At this moment it is still an inferior substitute of the long established NMR information server or the more professional NMR knowledge base.
I admire the efforts of Evgeny and would like to do my best to help him. Unfortunately, the best that I can do is simply to link him from here and elsewhere. Please consider doing the same: let's give a chance to the NMR wiki!
Now it's the time for the NMR wiki. In the intentions of the founder, Evgeny Fadeev, it will be a cooperative effort to share information. At this moment it is still an inferior substitute of the long established NMR information server or the more professional NMR knowledge base.
I admire the efforts of Evgeny and would like to do my best to help him. Unfortunately, the best that I can do is simply to link him from here and elsewhere. Please consider doing the same: let's give a chance to the NMR wiki!
Subscribe to:
Posts (Atom)