By essence,
QSoas works with \(y = f(x)\) datasets. However, in practice, when working with experimental data (or data generated from simulations), one has often more than one experimental parameter (\(x\)). For instance, one could record series of spectra (\(A = f(\lambda)\)) for different pH values, so that the absorbance is in fact a function of both the pH and \(\lambda\). QSoas has different ways to deal with such situations, and we'll describe one today, using
meta-data.
Setting meta-data
Meta-data are simply series of name/values attached to a dataset. It can be numbers, dates or just text. Some of these are automatically detected from certain type of data files (but that is the topic for another day). The simplest way to set meta-data is to use the
set-meta command:
QSoas> set-meta pH 7.5
This command sets the meta-data
pH to the value
7.5. Keep in mind that QSoas does not know anything about the meaning of the meta-data
[1]. It can keep track of the meta-data you give, and manipulate them, but it will not interpret them for you. You can set several meta-data by repeating calls to
set-meta, and you can display the meta-data attached to a dataset using the command
show. Here is an example:
QSoas> generate-buffer 0 10
QSoas> set-meta pH 7.5
QSoas> set-meta sample "My sample"
QSoas> show 0
Dataset generated.dat: 2 cols, 1000 rows, 1 segments, #0
Flags:
Meta-data: pH = 7.5 sample = My sample
Note here the use of quotes around
My sample since there is a space inside the value.
Using meta-data
There are many ways to use meta-data in QSoas. In this post, we will discuss just one: using meta-data in the
output file. The output file can collect data from several commands, like peak data, statistics and so on. For instance, each time the command
1 is run, a line with the information about the largest peak of the current dataset is written to the output file. It is possible to automatically add meta-data to those lines by using the
/meta= option of the
output command. Just listing the names of the meta-data will add them to each line of the output file.
As a full example, we'll see how one can take advantage of meta-data to determine the position of the peak of the function \(x^2 \exp (-a\,x)\) depends on \(a\). For that, we first create a script that generates the function for a certain value of \(a\), sets the meta-data
a to the corresponding value, and find the peak. Let's call this file
do-one.cmds (all the script files can be found in the
GitHub repository):
generate-buffer 0 20 x**2*exp(-x*$ 1 )
set-meta a $ 1
1
This script takes a single argument, the value of \(a\), generates the appropriate dataset, sets the meta-data
a and writes the data about the largest (and only in this case) peak to the output file. Let's now run this script with
1 as an argument:
QSoas> @ do-one.cmds 1
This command generates a file
out.dat containing the following data:
## buffer what x y index width left_width right_width area
generated.dat max 2.002002002 0.541340590883 100 3.4034034034 1.24124124124 2.162162162161.99999908761
This gives various information about the peak found: the name of the dataset it was found in, whether it's a maximum or minimum, the x and y positions of the peak, the index in the file, the widths of the peak and its area. We are interested here mainly in the
x position.
Then, we just run this script for several values of \(a\) using
run-for-each, and in particular the option
/range-type=lin that makes it interpret values like
0.5..5:80 as
80 values evenly spread between 0.5 and 5
. The script is called
run-all.cmds:
output peaks.dat /overwrite=true /meta=a
run-for-each do-one.cmds /range-type=lin 0.5..5:80
V all /style=red-to-blue
The first line sets up the output to the output file
peaks.dat. The option
/meta=a makes sure the meta
a is added to each line of the output file, and
/overwrite=true make sure the file is overwritten just before the first data is written to it, in order to avoid accumulating the results of different runs of the script. The last line just displays all the curves with a color gradient. It looks like this:
Running this script (with
@ run-all.cmds) creates a new file
peaks.dat, whose first line looks like this:
## buffer what x y index width left_width right_width area a
The column
x (the 3rd) contains the position of the peaks, and the column
a (the 10th) contains the meta
a (this column wasn't present in the output we described above, because we had not used yet the
output /meta=a command). Therefore, to load the peak position as a function of
a, one has just to run:
QSoas> load peaks.dat /columns=10,3
This looks like this:
Et voil !
To train further, you can:
- improve the resolution in x;
- improve the resolution in y;
- plot the magnitude of the peak;
- extend the range;
- derive the analytical formula for the position of the peak and verify it !
[1] this is not exactly true. For instance, some commands like unwrap interpret the sr meta-data as a voltammetric scan rate if it is present. But this is the exception.
About QSoasQSoas is a powerful open source data analysis program that focuses on flexibility and powerful fitting capacities. It is released under the GNU General Public License. It is described in Fourmond, Anal. Chem., 2016, 88 (10), pp 5050 5052. Current version is 2.2. You can download its source code there (or clone from the GitHub repository) and compile it yourself, or buy precompiled versions for MacOS and Windows there.
Stick figure by Sanitary Panels on SC
Here is my monthly update covering what I have been doing in the free software world during November 2020 (
Once a year folks interested in Netfilter technologies gather together to discuss past, ongoing and
future works. The Netfilter Workshop is an opportunity to share and discuss new ideas, the state of
the project, bring people together to work & hack and to put faces to people who otherwise are just
email names. This is an event that 
Stefano Bravio commented on several open topics for nftables that he is interested on working on.
One of them, issues related to concatenations + vmap issues. He also addressed concerns with
people s expectations when migrating from ipset to nftables. There are several corner features in
ipset that aren t currently supported in nftables, and we should document them. Stefano is also
wondering about some tools to help in the migration. A translation layer like there is in place
for iptables. Eric Gaver commented there are a couple of semantics that will not be suitable for
translation, such as global sets, or sets of sets. But ipset is way simpler than iptables, so a
translation mechanism should probably be created. In any case, there was agreement that anything
that helps people migrate is more than welcome, even if it doesn t support 100% of the use cases.
Stefano is planning to write documentation in the 
Sneakers was much more interesting for me because in that you got the best key which can unlock any lock, something like quantum computing is supposed to do. One could equate both the first movies in either as a White hat or a Grey hat . A Grey hat is more flexible in his/her moral values, and they are plenty of such people. For e.g. Julius Assange could be described as a Grey hat, but as you can see and understand those are moral issues. 
I've make a presentation about "How to hack debexpo (mentors.
A first update of the 
My maybe most impactful piece of code is 
In Emacs, you can use 
The KDE Bugzilla handles a lot of projects and they often match with the repo name, but not always.
For instance we have ancient products and components at Bugzilla, as projects have a lifecycle from playground into Release Service, or Frameworks, sometimes with a change of name.
So you may end up searching Bugzilla quite awhile for the correct product and component to be able to confirm or create bug reports against an application.
Let's have a look at