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.
