simulation of decoupling

I can write a function that would project all interactions of a specified type out of the Liouvillian and put them back when necessary. Something like

[L,C]=decouple(L,spin1,spin2);

…

… running with ‘decoupled’ L

…

L=recouple(L,C);

Would that be good enough?

Dear Illya,

a nice suggestion, but does not seem like a solution. The actual decoupling is performed with a sequence of (phase, amplitude modulated) finite pulses run in parallel with all other events on the other remaining channels. Of course, proper simulation of the effect of such a perturbation would require numeric propagation of the density operator through such a complex sequence. If decoupling sequence is suboptimal , it might inflict severe losses of sensitivity. Therefore, adequate simulation of decoupling is an important issue. In fact, in solid state NMR decoupling is an essence of everything with just a slightest misset of power resulting in no signal at all.

I do not see any simple solution at the moment, since this problem belongs to “musician book” (parallel events) category. At some point we have to make an object oriented formal representation of NMR experiment taking care of such an intrinsic parallelism. What bothers me now really is that in the manuscript we have to indicate that composite decoupling is not implemented or implemented as just continuous irradiation droping modulation part whatsoever. This is not devastating but not nice either.

Generally, we do not have an effective (and universal) language describing multi channel sequence of parallel events. I am sure you have seen my inputs to Spinach, they do not look even 1/2 way attractive or elegant to an external user.

Dear Konstantin,

I am in the process thinking about the human-readable input style for Spinach (something along the lines of Gaussian or GAMESS inputs, a stub enclosed – your comments would be appreciated), for both the spin system and the experiment to be run. Gareth Charnock in my group is developing a user-friendly GUI for Spinach (currently a GaussView-style point-and-click spin system specification aid).

We’ll have to think long and hard about pulse sequence specification language. It looks like the most straightforward way would be to implement a “compiler” — a function that would read the user sequence input and generate a stack of Liouvillians through which the spin system has to be propagated (the time grid would probably need to be non-uniform). The propagation as such then would be a straightforward loop.

I’ll look at the way Bruker, Varian, Simpson, Spinevolution etc implement their sequence language and try putting together something neat and flexible. Meanwhile, having a neat spin system specification would be a start – please take a look at the enclosed file. I will write a read_ss.m function that would read it.

While that’s in progress, the “algebraic” decoupling described below should serve as a crutch.

Best wishes,

Ilya.

Dear Ilya,

> I’ll look at the way Bruker, Varian, Simpson, Spinevolution etc implement their sequence language and try putting together something neat and flexible. Meanwhile, having a neat spin system specification would be a start – please take a look at the enclosed file. I will write a read_ss.m function that would read it.

The tagged XML-like description appears to be the natural representation of spin system data. I’d suggest to render it is a class with formal properties, states and associated methods built in this class. This will be totally in style with object oriented programming, reusable and flexible. The actual rendering (point-and-click or anything else) can vary, depending on the platform. This brings the question of the general use of the system.

Strategically I suggest:

1. To make Spinach a server side application.

2. To use ASP.NET with C# as implementation tools. This requires porting Spinach algebraic core to C#, which should be not that difficult to achieve.

Advantages: 1) drastically lowering barrier of the use of the simulator since no local installations are needed just web access. 2) we can use powerful GUI of the web browser to setup analysis and representation of experiments. 3) We can use .NET infrastructure for object oriented programming, access to databases, commonly accepted server side GUI. 4) We add a crucial enhancement to the system in the form of social networked community of users. We can have a public database of experiments, results, documentation, a wiki as well as private sub-collections in development which can be easily exchanged.

NMR generator on ASP.NET

Google SVN wiki link

http://code.google.com/p/nmrgenerator/wiki/NewSetup?ts=1229446245&updated=NewSetup

Introduction

All the tools are free of charge.

What you will need

1. .NET Framework 3.5 SP1 and ASP.NET 2.0 (http://msdn.microsoft.com/en-us/netframework/aa569263.aspx)
2. Visual Web Developer 2008 Express Edition (http://www.microsoft.com/express/vwd/)
3. TortoiseSVN (http://tortoisesvn.tigris.org/)
4. MySQL (http://www.mysql.com/) or MSSQL 2008 Express (http://www.microsoft.com/express/sql/default.aspx) – second will be used at the end
5. MySql Gui Tools (http://dev.mysql.com/downloads/gui-tools/5.0.html)
6. MySQL ODBC connector (http://dev.mysql.com/downloads/connector/odbc/5.1.html)
7. MySQL .NET Connector (http://dev.mysql.com/downloads/connector/net/5.2.html)
8. ILMerge (http://www.microsoft.com/downloads/details.aspx?familyid=22914587-b4ad-4eae-87cf-b14ae6a939b0&displaylang=en)
9. Straight hands

What you will do

1. Install .NET framework. ASP.NET will be installed together with it
2. Install Visual Web Developer 2008
3. Install TortoiseSVN. This will add additional content to the right click menu.
4. Find the default folder for your VWD projects. Default is \Documents\Visual Studio 2008\Projects. Right click the folder and do SVN Checkout. In the new window: URL of repository – https://nmrgenerator.googlecode.com/svn/trunk/ nmrgenerator; Checkout Depth – Fully recursive; revision – HEAD revision. When you click ok, you will be asked for credentials to access the repository. Use you gmail account username (the gmail email) you password you will find on this page (http://code.google.com/hosting/settings).
5. Install MySql, when asked specify root password
6. Install MySQL GUI Tools
7. Install All MySQL Connectors
8. Run ODBC Data Source Administrator – there setup two new DSNs. 1 – Data Source Name = “NMR Experiments”, Server = “localhost”; Port=”3306″ (or the one u set when installed MySQL); user = “nmr”; password = “v rot mne nogi”; Database =”nmrexperiments”. 2 – Data Source Name = “NMR UserData”; Database = “nmruserdata” , the rest is the same.
9. In the NMR generator project folder locate the folder MySQLDatabase. It contains a backup of DB.
10. Run “MySQL Administrator” (component of mysql gui tools) with root credentials. In restore tab initiate db restore, when asked select the file from previously located folder. After process is finished the must be three new databases shown in Catalogs tab. In users tab create new user: name – nmr, password – “v rot mne nogi”. Specify SELECT and INSERT permisions for nmrexperiments database and SELECT,INSERT, DELETE, REPLACE and UPDATE for nmruserdata database.
11. Install ILMerge into default directory
12. If things work, don’t touch anything, otherwise write here.

New NMR language

With the graphs, the only possible issue is that not everyone would have the Bioinformatics Toolbox — in fact, most people that run Matlab would not. A solution would be to copy that function from Bioinformatics Toolbox into the Spinach code tree and adapt it more closely to the problem at hand:

This will be indeed a solution. I will try to implement it. I find graphs to be particularly usefull and tangible in understanding of the experiment.

1. One idea would be to set the normalized coefficient amplitude as a transparency and line thickness parameter and the coefficient phase as a colour — in that way the prominent paths would be visually identifiable without the need to analyze the numbers printed around.

I am not sure transparency can be controlled in biograph object. The line thickness may render the figure messy, but of course one has o try beforehand.

2. Another would be to create plots similar to the traditional coherence order diagrams, with lines jumping between different orders of coherence.

3. A third would be to order the states by their coherence order, assign each state a line of pixels in the picture and generate something resembling a running Fourier transform in acoustic analysis — waves of color would be moving between those lines as the dynamics proceeds. Subspace grouping (see below) would help there.

In fact that was my original idea. However, this would require a substantial effort in programming while biograph is out of box solution. We can ticket it for the future.

The most pressing is parallel programming of events, since without it it seems to be very tricky to correctly model real NMR experiments. Maybe indeed, each event (pulse or delay) might be snapped to the fixed time grid on multiple channels. To calculate real propagators we need to sum up events at this time point from all channels.
I have here in Biozentrum a smart postdoc working on the implementation of the NMR experiments database as the web service (along Web2.0 lines, with the hope to build community of user/developers). We soon make a prototype public. There of course a gateway to Spinach will be implemented. We pondered about comming up with a new syntax for description of NMR experiments like an object model with methods and attributes associated with each class like for example pulse with attributes of length, rotations, shape, point of synchrinization with time grid and methods like relate to calibration data. These classes can be assembled in parallel time lines with a possibility to overlay with complementray methods to resolve overlays. My impression is that this new languge for NMR experiments is bare nessessity. This will make NMR experiments portable across spectrometers and simulators as well.

The similarity metric is a problem. If we define similarity as a scalar product of the two trajectories, then it’s way too strict — a simple phase twist or a half-wave delay would make the two trajectories look completely dissimilar, whereas in reality they are very similar. So…

This brings us very close to analysis of trajectory optimality under given controls. This is a fundamental problem of course. I agree that my metric might be too strict, however, it might be still suitble of we analyse just effects of relaxation keeping all other controls identical for two analyzed trajectories. More thought though should be given..

1. For a given state rho, all its Lz-neighborhood (all states in the exp(-i*Lz*t)*rho orbit) should be deemed equivalent. In practical terms that means that certain coefficients would have to be grouped before taking a scalar product. This deals with the phase issue — if the trajectory passes through a spin in Lx polarization, another trajectory where the same happens in Ly polarization should reasonably be considered similar. In other words, similarity would mean that the trajectory passes through the same subspaces rather than through exactly the same states.

2. The metric should be tolerant to reasonable mismatch of event timings. I do not currently know of any way to implement this robustly (variable Gaussian smoothing? covariation analysis? temporal invariants?). Matthew (who has recently started as a postdoc in Durham) might have some insight into this from his diffractometry and functional analysis background.

3. The metric should be implemented in the Hilbert space sense — as an integral rather than vector scalar product, since the two trajectories might have a different number of points. Interpolation and resampling blues.

4. It might be an idea to only use a small subspace of the full state space for similarity monitoring — in other words, we may want to match up the dynamics of LzSz between the two trajectories, but would not particularly worry about mismatch in the dynamics of third order coherences.

Anyway, a tool created to the above spec (and I can program all four reasonably quickly) would assume quite a lot about the level of user expertise. There might be ways of “black-boxifying” it, but we’d have to make the code proportionally more sophisticated then.

We should first clearly define the problem which we agoing tackle. Say, how different is the actual trajectory from optimal tube of trajectories? This is a very different from the problem of whether relaxation drives the trajectory away besides just attenuating of the magentization. Would be really nice to say something about optimality of experiments.

Time snapping of NMR events

Time grid and snapping to time grid will require a new formal description of NMR experiments. New language?

Bioinformatics toolbox graph

Attached is the graph of magnetization flow generated from a part of HSQC experiment using bioinformatics toolbox’s graph functions. I think it is rather tangible and helpful in order to understand what a particular experiment is doing. Shall we integrate this feature into the generic Spinach frame?

Hz to HzCz transfer

This is for one full inept (events 1-9) with a p1*300 pulse. Exactly this pulse makes big mess.

1 pp=set_power_kope(v.pl1,pp, 1,11.41,5);pp=set_power_kope(v.pl2,pp, 2,17.5,0.5);pp=set_power_kope(v.pl3,pp, 3,38.2,-2.9);
2 [rho,pp]=pulse_kope(spinsys, rho,pp,v.p1, v.ph20,k, 1);
3 [rho,pp]=delay_kope(spinsys, rho,pp, v.p21);
4 [rho,pp]=delay_kope(spinsys, rho,pp, v.INEPT_1);
5 [rho,pp]=pulse_kope(spinsys, rho,pp,v.p2, v.ph20,k, 1); [rho,pp]=pulse_kope(spinsys, rho,pp,v.p3, v.ph20,k, 2);[rho,pp]=pulse_kope(spinsys, rho,pp,v.p4, v.ph21,k, 2);[rho,pp]=pulse_kope(spinsys, rho,pp,v.p3, v.ph20,k, 2);
6 [rho,pp]=delay_kope(spinsys, rho,pp, v.p21);
7 [rho,pp]=delay_kope(spinsys, rho,pp, v.INEPT_1);
8 [rho,pp]=pulse_kope(spinsys, rho,pp,v.p1*300, v.ph20,k, 1);
9 [rho,pp]=pulse_kope(spinsys, rho,pp,v.p1, v.ph21,k, 1);

I think Cartesian product operators might produce simpler graph for the same flow.
Maybe we can keep Cartesian basis in spinsys as well and interconvert rho by request?

A leaf out of musicians’ book

Ilya wrote:

I’ve scratched my head for a while and it looks like we might take a leaf out of musicians’ book – they also have multiple overlapping events on many channels, and the key there is that all events stick to the common time grid. So…

Assuming we run one common clock throughout the experiment at the frequency of the biggest Liouvillian eigenvalue (that can be estimated efficiently), and discretize the events at every channel onto that time grid. On each channel we then have a stack of N Liouvillian matrices, where N is the number of points in time. Each, Liouvillian is, in general, different, but because the time grid is common, Liouvillians from different channels can be added together and we then have one timeline with one stack of Liouvillians to push the system through.
Implementing that efficiently would mean quite some coding, but the challenges are mostly technical – i.e. mapping the data structures that your functions produce onto a common time grid and avoiding the need to store the entire Liouvillian stack at once. Different events might be merged for efficiency etc, etc.

me:
Yes, indeed, a stack of Liouvillians on the different tracks (channels) followed by merging them before propagation might be a good way to go. However, the problem is we’d need fine enough time grid, translating into many expv operations. On the other hand, much better defined rho trajectory will be available for analysis. Currently we outputting rho trajectory at every 0.1 ms along the pulse sequence. So far it seems fine enough for tracking relaxation induced trajectory deviations from the decorrelation-free path. As you can see, multichannel programming will require completely different syntax and overall representation of NMR experiment. However, this is much closer to how NMR experiment is really represented and executed inside the NMR spectrometer. Notions of pulses and delays as programming atoms were built in the past as ad hoc attempt to simplify and generalize. Albeit helpful, now it seems to be too restrictive. I am doing a bit of electronic music programming in Cubase. NMR experiment looks cunningly similar to a typical musical multichannel project with time-grid snapped events synchronized on many channels, or in your words – a musician’s book, a stave.

Graph theory.

I feel like I have to start digging into the graph theory in order to construct and analysis coherence transfer pathways in experiment.
Namely, it seems reasonable to track evolution of each individual product operator in order to construct hierarchical graphs, on which different paths can be defined and colored. Looking at this graph non productive pathways can be easily traced (colored). The branches which lead to the detectable operator constitute productive pathways and simultaneously will serve the purpose of annotating the experiment (in other words what this experiment is doing). It might be quiet intriguing to apply graph analytical measures to those constructs such as say graph diameter and shortest pathways etc. Do you have any experience with graph theory?

In order to construct this graph, only one basis element of rho must be propagated at the time. Is it possible to reduce computation time for computing

rho1 = rho expv(L)

if we a priori know that the vector rho consists of only one nonzero element?

Pulse sequence syntax in Spinach

The most important is the ability to deal with parallel programming of different rf- channels, which is a built in feature in the Bruker syntax (ubiquitously used!). In the latter the flow of events is arranged not only from top to bottom, like this:

Syntax 1:

Pulse(1)

Delay(2)

Pulse(3)

With the consecutive execution order 1,2,3

But from left to right as well:

Syntax 2:

Pulse(1); Delay(2); Pulse(3);

With the same effect on the execution order 1,2,3.

Now they extended Syntax 2 to enable parallelism like this

[Pulse(1.1); Delay(2.1); Pulse(3.1);] :channel_1 [Pulse(1.2); Delay(2.2); Pulse(3.2)];channel_2

Events in brackets are executed simultaneously and aligned to the left. This requires breakdown of the event calls into sub-events, e.g. more than 4 calls of the function Pulse() will be needed if we still use our linear programming.

I do not know really how it might be the best to represent NMR experiments, but I have a hunch, that something like 2D event tables should be devised with bidirectional and parallel execution of flow of events.