Tuesday, January 10, 2017

Version 2.1 of QSoas is out

I have just released QSoas version 2.1. It brings in a new solve command to solve arbitrary non-linear equations of one unknown. I took advantage of this command in the figure to solve the equation for . It also provides a new way to reparametrize fits using the reparametrize-fit command, a new series of fits to model the behaviour of an adsorbed 1- or 2-electrons catalyst on an electrode (these fits are discussed in great details in our recent review (DOI: 10.1016/j.coelec.2016.11.002), improvements in various commands, the possibility to now compile using Ruby 2.3 and the most recent version of the GSL library, and sketches for an emacs major mode, which you can activate (for QSoas script files, ending in .cmds) using the following snippet in $HOME/.emacs:

(autoload 'qsoas-mode "$HOME/Prog/QSoas/misc/qsoas-mode.el" nil t)
(add-to-list 'auto-mode-alist '("\\.cmds$" . qsoas-mode))

Of course, you'll have to adapt the path $HOME/Prog/QSoas/misc/qsoas-mode.el to the actual location of qsoas-mode.el.

As before, you can download the source code from our website, and purchase the pre-built binaries following the links from that page too. Enjoy !

Friday, January 6, 2017

RFH: screen that hurts my eyes

Short summary:

My eyes hurt when I use my home desktop computer - but only with this computer. This has been very long and frustrating for me, so if you think you can help, read the whole story just below, or skip to what I've tried and what I suspect might be the problem, and post comments below, or send me a mail (my adress should be quite obvious in this page).

Whole story:

Two years ago, I bought myself a new fancy motherboard (a Asus B85M-G C2) with a new fancy Intel-based processor with built-in graphics (an Intel Core i7-4770) and memory to go with it. I installed it in the place of my old AMD-based motherboard, keeping everything else (my hoard of hard drives and such) excepted the graphics card, which was not needed anymore. I immediately noticed my eyes were aching when using the computer. I was quite surprised since I had been using the screen very heavily for almost 10 years before that, without any problems. I attributed that to Intel Graphics, so I tried putting back the old graphics card, but it did not help. The situation was very frustrating, since working on the computer for an hour or so was making my eyes hurt for several days. This problem was specific to this computer, I could keep on using my computer at work and my laptop without problems.

I could use the computer using SSH from my laptop, so I could profit from the faster processor, but, hey, that wasn't how it was meant to happen. I bought another screen, also tried with one from the work, without any change. I tried using two screens at the same time (this is what I have at work), also without success, so I just kept not using the computer directly. I moved recently to a new place and tried to get that working back again, but didn't get any luck. Frustrated, I got another desktop computer and another screen, and I still have the same problem ! I also tried remounting the old motherboard with the AMD processor and the old graphics card, but that didn't bring any improvement. I just don't get it. This situation is rather frustrating for me, and it's been holding me back in my software projects for two years now (which partly explains my lack of involvement in Debian over the past few years). This post is here in the hope someone will have a idea, but also for me to keep track of what I've done and what I should.

What is puzzling me is that the computer I had before was perfectly fine, and that I have a very very similar setup at work (also with a NVIDIA graphics card) that doesn't hurt my eyes at all.

What I've tried:

Here is what I tried, you need to keep in mind that when a trial fails, my eyes keep on hurting for several days, and might trigger false positives.
  • putting back the old (NVIDIA) graphics card, buying a new one (NVIDIA as well);
  • putting back the old motherboard (but with a new OS, but maybe my eyes were too sore for a clean test);
  • using another screen (a new one from the same brand, Samsung), a Dell and a HP from my work, and a brand new Phillips;
  • using two screens at the same time;
  • using a completely different (new, based on Xeon processors and a NVIDIA graphics card) computer (with new mouse, keyboard, hard drives and so on);
  • changing house, including changing the lighting conditions, the desk, the internet provider (no, I didn't do that just because of my computer problems !);
  • changing the way I drive the screens between VGA, DVI and HDMI;
  • copying the system I have in my workplace to the new computer and booting from that system (after a few adaptations, though).

As you can guess, none of those brought any improvement.

Wild hypotheses:

  • Is that a software thing ? Is there something wrong for me in the versions of Debian dating from August 2014 and after ?
  • Is that a BIOS problem with recent computers ?
  • Is that linked to some waves (bluetooth shoudln't be on, but maybe I didn't check well enough ?)
  • Is that linked to EFI (but I also have the problems when I use legacy BIOS for booting)
  • Something weird in my home ?
  • Anything else ?

Any help will be greatly appreciated, but please don't advise going to see a doctor, I don't see how this could be a medical condition specific to my home desktop computer, unless this is a very specific psychosomatic problem.

Thursday, November 24, 2016

Finding zeros of data using QSoas

QSoas does not provide by default commands to detect zeros of data, and the reason for that is that it is simple, using the integrate command to convert this problem into a peak-finding problem, which can be solved using the find-peaks command. Here is that strategy applied to determining the zeros of the 0-th order bessel function:

QSoas> generate-buffer -10 10 bessel_j0(x) /samples=100001
QSoas> integrate
Current buffer now is: 'generated_int.dat'
QSoas> find-peaks
Found 6 peaks
buffer what x y index width left_width right_width
generated_int.dat min -8.6538 -0.201157042341714 6731 1.7798 0.905999999999999 0.873800000000001
generated_int.dat max -5.52 0.398165469321319 22400 2.2854 1.1862 1.0992
generated_int.dat min -2.4048 -0.403288737672291 37976 1.8232 0.973 0.850199999999999
generated_int.dat max 2.4048 2.53731134529594 62024 nan 2.2026 nan
generated_int.dat min 5.52 1.73585713830231 77600 nan 5.7198 nan
generated_int.dat max 8.6538 2.33517964996535 93269 nan 8.5532 nan

Compare that with the values given on Mathematica's website. This strategy is reasonably resistant to noise, since integration decreases high-frequency noise, but you may have to play with the /window option to find-peaks to avoid detecting the same zero (peak) several times.

Hopefully, I'll come back with more regular postings of tips and tricks !

Thursday, July 21, 2016

QSoas version 2.0 is out / QSoas paper

I thought it would come before that, but I've finally gotten around releasing version 2.0 of my data analysis program, QSoas !


It provides significant improvements to the fit interface, in particular for multi-buffer fits, with a “Multi” fit engine that performs very well for large multibuffer fits, a spreadsheet editor for fit parameters, and more usability improvements. It also features the definition of fits with distribution of values of one of the fit parameter, and new built-in fits. In addition, QSoas version 2.0 features new commands to derive data, to flag buffers and handle large multi-column datasets, and improvements of existing commands. The full list of changes since version 1.0 can be found there.

As before, you can download the source code from our website, and purchase the pre-built binaries following the links from that page too.

In addition, I am glad to announce that QSoas is now described in a recent publication, Fourmond, Anal. Chem., 2016, 88, 5050-5052. Please cite this publication if you used QSoas to process your data.

Tuesday, March 29, 2016

Release 0.14.1 of ctioga2

With the (relatively, sorry) recent switch to ruby2.3 as default Ruby version, I realized that my plotting program ctioga2 crashed with ruby 2.3 (due to a rather ugly lazy hack). I have just fixed this in release 0.14.1. Update as usual with:
~ gem update ctioga2
If you're not using Ruby 2.3, you probably don't need to update soon, though. Enjoy !

Thursday, February 18, 2016

Release of ctioga2 version 0.14

The day has finally come again to release a new version of my plotting program, ctioga2. Version 0.14 features, among others:
  • a new binner, useful to make histograms;
  • a command to hide elements already presents, that can be very useful to make animations;
  • a whole set of functionalities to make it easier to draw complex grids, including easy ways to style grid elements and a way to switch to the next grid element (picture);
  • a whole series of command-file functions to obtain informations about loaded datasets;
  • a way to draw legends separately by hand;
  • and more, including bugfixes, better error reporting, such as when some of the numbers are infinite, and much much faster debug output.
As usual, the best way to update the package is running:
~ gem update ctioga2
An updated Debian package should find its way to the archive later on today. Have fun !

Tuesday, February 16, 2016

QSoas tips and tricks: better baselines using the "save points" feature

During data processing in our team, we often subtract plain polynomial baselines to our data, drawn by hand using the b command. Note that this is legitimate because we know that the signal we are looking for quickly drops to 0 outside a given range. The usual workflow is to just load the data, use b to draw a baseline and subtract it, and then have further fun with the baseline-subtracted data. This was the only possibility in the old SOAS. However, I don't like so much this kind of workflow, because such a baseline is arbitrary, and once it's subtracted, it's hard to reassess the baseline afterwards.

This is why I've designed a better way in QSoas: when you are done creating a baseline, push p: this exits pushing only the interpolation nodes:

Above, the baseline subtraction interface, and below, the resulting nodes:
The nodes can be reloaded by hitting uppercase L from within b and giving a buffer number (admittedly, the interface as of now isn't that good, I'll have to work on it). Alternatively, you can greenerate the baseline by using interpolate, and then further subtract it using S:
QSoas> interpolate 1 0
where 1 is the original buffer (in fact, only its X values will be used, so you don't have to use the same buffer) and 0 is the buffer containing the interpolation nodes. Saving only the interpolation nodes makes it possible to reedit the baseline easily, and regenerate the baseline-subtracted data using a script. This is my favorite approach, because I like to be able to trace every single step from the raw data to processed data. Another neat feature is that, from within b, you can reload only the X values of nodes using lowercase l (and giving buffer number): the Y values are computed as if you had clicked at the corresponding positions. This is very useful is you have a whole series of similar baselines to make: most often, you won't even need manual adjustment to get a good baseline. I hope you'll find this tip useful !