Hi everyone,

I'm sorry for the very stupid question but I'm stuck and I need some helping
hand...
  I'm simulating ROCSA on carbonyls (basing on the tar file downloaded from this
group) and I'm getting folded profiles. How can I increase the spectral width
and get rid of this problem?
(i tried increasing the sw parameter but it seems not to affect anything)

regards

E.

 

Thanks for the quick reply Thomas, and that clears that issue up.

Kris

--- In simpson-simmol@yahoogroups.com, Thomas Vosegaard <tv@...> wrote:
>
> Hi,
>
> The issue you're observing is due to the fact that when propagating a pulse sequence, only the propagator is calculated. To save matrix multiplications, the propagator is only applied to evolve the density operator when the "acq" command is invoked. Thus, if you are using "matrix get density" for debugging, you should always put in an "acq" command before.
>
> By the way, the sequence
>
> > pulseid 8 62500 x
> > store 5
> > prop 5
> >
>
> corresponds to two 180 deg. pulses, one by the pulseid command, the second from "prop 5".
>
> Thomas
>
> On Jan 12, 2011, at 20:21 , kjharris_ssnmr wrote:
>
> > Hello all,
> >
> > I would like to follow changes in the density matrix at various points using the "putmatrix" command, but I'm having trouble. I can print out the current density matrix, but I can't control when it is propagated forward in time by the pulses/delays. I'm trying to use the "prop" command to do this, but can't figure the syntax.
> >
> > e.g. a 180 degree pulse on a single 1H nucleus:
> > -------------------------------------
> > spinsys {
> > channels 1H
> > nuclei 1H
> > }
> >
> > par {
> > method direct
> > spin_rate 0
> > proton_frequency 400.0e6
> > crystal_file alpha0beta0
> > start_operator I1z
> > detect_operator I1p
> > }
> >
> > proc pulseq {} {
> > reset
> >
> > putmatrix [matrix get density] #Just print starting p, = Iz
> >
> > pulseid 8 62500 x
> > store 5
> > prop 5
> > putmatrix [matrix get density] #Should print p after evolving with pulse
> >
> > acq
> > putmatrix [matrix get density] #Print p after acq command to see the difference
> > }
> >
> > proc main {} {
> > set f [fsimpson]
> > funload $f
> > }
> > -------------------------------------
> >
> > The result is:
> > -------------------------------------
> > ( 0.5, 0) ( 0, 0)
> > ( 0, 0) ( -0.5, 0)
> >
> > ( 0.5, 0) ( 0, 0)
> > ( 0, 0) ( -0.5, 0)
> >
> > ( -0.5, 0) ( 0, 2.83e-16)
> > ( 0,-2.83e-16) ( 0.5, 0)
> > -------------------------------------
> >
> > So the propagator doesn't alter the current density matrix after the "prop" command, only
> > after the "acq" command is called
> >
> > thanks for any tips,
> > Kris
> >
> >
>

 

Hello SIMPSON users,

Hopefully you guys can spot what I'm doing wrong here, I'm a little confused. When simulating an echo in a 14N spectrum, it only works when the quadrupolar interaction is set to 1st order, not 2nd. I get a weird lineshape that can't be phased in the second case.

With direct acquisition (no echo) the exact same lineshape results at 1st/2nd order (as expected, the 2nd-order contribution for spin-1 nucleus isn't much against the large 1st-order). So... if the lineshape is the same, I don't think the 2nd order perturbation should affect the formation of an echo.

Anybody know what might be going on here?

Here's the simulation code I used, where I (Start as Ix)-(delay 50 &#956;s)-(ideal &#960;/2 pulse)-(delay 50 &#956;s)-observe I+.
This version works fine, but fails if I swap in this line:
quadrupole 1 2 1.14e6 0.3 0.0 0.0 0.0

-----------------
spinsys {
channels 14N
nuclei 14N
shift 1 0.0 0.0 0.0 0.0 0.0 0.0
quadrupole 1 1 1.14e6 0.3 0.0 0.0 0.0
}

par {
method direct
spin_rate 0
sw 12.0e6
np 512
proton_frequency 400.0e6
crystal_file zcw28656.cry
start_operator I1x
detect_operator I1p
verbose 1111
}

proc pulseq {} {
global par
set dw [expr 1.0e6/$par(sw)]

set d1 50.0

reset
delay $dw
store 1

reset
delay $d1
pulseid 4 62500 x
delay $d1

acq $par(np) 1

}

proc main {} {
global par
set f [fsimpson]
fsave $f $par(name).fid
fft $f
fsave $f $par(name).spe
funload $f
}

Thomas,

on the mac version I still can't get it to pass the frms call. It just returns
"Abort" and stops.

Andy

On Mar 25, 2011, at 8:08 AM, vosegaard wrote:



Dear all

It is a pleasure for me to announce the release of SIMPSON version 3.1.0. This
is a bug fix release that fixes a few bugs in the OC routines and for
quadrupolar nuclei with second-order effects. Furthermore, the Makefile has been
shined up a little for those compiling SIMPSON on their own. Otherwise, just
download the installers.

<http://www.bionmr.chem.au.dk/simpson>
http://www.bionmr.chem.au.dk/simpson

Thomas

 

Dear ALL,
  Does anyone have met this problem when compiling SIMPSON 3.1 with INTEL MKL 11.1:

/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `omp_in_parallel'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_end_critical'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_end_ordered'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_atomic_fixed4_add'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `omp_get_num_threads'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_dispatch_fini_8'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_for_static_fini'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `ompc_set_nested'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_end_serialized_parallel'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_atomic_fixed8_add'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_reduce_nowait'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_ordered'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_dispatch_fini_4'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `omp_get_nested'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `omp_get_thread_num'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_dispatch_next_8'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_for_static_init_4'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `omp_get_num_procs'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_flush'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_barrier'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_end_reduce_nowait'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_serialized_parallel'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_dispatch_init_4'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_single'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_critical'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_dispatch_init_8'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_fork_call'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_for_static_init_8'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_dispatch_next_4'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_push_num_threads'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_end_single'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_global_thread_num'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `__kmpc_ok_to_fork'
/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64t/libmkl_intel_thread.so: undefined reference to `omp_get_max_threads'
make: *** [simpson] Error 1


Conditions:
INCLUDES = -I/usr/include/ -I/data/soft/compiler/intel/Compiler/11.1/056/mkl/include/ -I/data/soft/compiler/mpi/openmpi/1.3.3/gcc.pgf90/include/

LIBRARIES = -L/data/soft/compiler/intel/Compiler/11.1/056/mkl/lib/em64 -L/data/soft/compiler/mpi/openmpi/1.3.3/gcc.pgf90/lib -lmkl_intel_lp64 -lmkl_core -lmkl_lapack -fopenmp -ltcl8.4 -lmkl_intel_thread -lm

CC =gcc
EXTRA_FLAGS = -DMKL_INTEL -DMPI

  Looking forward to your reply.

Best
Bingwen

Thanks very much for the info, I wasn't aware of that bug, but I'll keep it in
mind now.

thanks,
Kris


--- In simpson-simmol@yahoogroups.com, Julien TREBOSC <simpson.trebosc@...>
wrote:
>
> There is a long standing bug in simpson since they introduced the
> ability of changing the MAS axis during the sequence (maybe not related
> to the bug). All versions 1.2 and later (2, 3) have this bug.
>
> Check this message to make a test:
> http://tech.groups.yahoo.com/group/simpson-simmol/message/815?gi=0
>
> Basically the time origin is wrong when using quadrupole to the second
> order. This makes impossible to simulate more than one pulse.
>
> Personnally I use simpson 1.1.1 whenever I simulate quadrupolar nuclei.
> However there is a lot of work to clean the code for compilation with
> modern API.
>
> I have an update version. If you need it I can send the archive. However
> many things are disabled (minuit, simmol) and I tested it only under linux.
>
> Best,
>
> Julien TREBOSC
>
> Le 27/01/2011 18:24, kjharris_ssnmr a écrit :
> >
> > Hello SIMPSON users,
> >
> > Hopefully you guys can spot what I'm doing wrong here, I'm a little
> > confused. When simulating an echo in a 14N spectrum, it only works
> > when the quadrupolar interaction is set to 1st order, not 2nd. I get a
> > weird lineshape that can't be phased in the second case.
> >
> > With direct acquisition (no echo) the exact same lineshape results at
> > 1st/2nd order (as expected, the 2nd-order contribution for spin-1
> > nucleus isn't much against the large 1st-order). So... if the
> > lineshape is the same, I don't think the 2nd order perturbation should
> > affect the formation of an echo.
> >
> > Anybody know what might be going on here?
> >
> > Here's the simulation code I used, where I (Start as Ix)-(delay 50
> > μs)-(ideal π/2 pulse)-(delay 50 μs)-observe I+.
> > This version works fine, but fails if I swap in this line:
> > quadrupole 1 2 1.14e6 0.3 0.0 0.0 0.0
> >
> > -----------------
> > spinsys {
> > channels 14N
> > nuclei 14N
> > shift 1 0.0 0.0 0.0 0.0 0.0 0.0
> > quadrupole 1 1 1.14e6 0.3 0.0 0.0 0.0
> > }
> >
> > par {
> > method direct
> > spin_rate 0
> > sw 12.0e6
> > np 512
> > proton_frequency 400.0e6
> > crystal_file zcw28656.cry
> > start_operator I1x
> > detect_operator I1p
> > verbose 1111
> > }
> >
> > proc pulseq {} {
> > global par
> > set dw [expr 1.0e6/$par(sw)]
> >
> > set d1 50.0
> >
> > reset
> > delay $dw
> > store 1
> >
> > reset
> > delay $d1
> > pulseid 4 62500 x
> > delay $d1
> >
> > acq $par(np) 1
> >
> > }
> >
> > proc main {} {
> > global par
> > set f [fsimpson]
> > fsave $f $par(name).fid
> > fft $f
> > fsave $f $par(name).spe
> > funload $f
> > }
> >
> >
>

Hi Thomas,

I just downloaded and tried the new version (3.1.0 for mac), but I get the same
result, so I guess that wasn't the issue.  Here's a link of the results of
straight observation versus echo for 1st and 2nd order quadrupolar interactions:
http://img684.imageshack.us/i/picture10gm.png/

cheers,
Kris


--- In simpson-simmol@yahoogroups.com, Thomas Vosegaard <tv@...> wrote:
>
> Could you try to run it with the latest release 3.1.0 and see if the problem
persists? In this release, we have fixed a bug related to quadrupolar nuclei, so
hopefully your problem is also solved.
>
> Thomas
>
>
> On Apr 20, 2011, at 20:54 , Kris Harris wrote:
>
> > Thanks very much for the info, I wasn't aware of that bug, but I'll keep it
in mind now.
> >
> > thanks,
> > Kris
> >
> > --- In simpson-simmol@yahoogroups.com, Julien TREBOSC <simpson.trebosc@>
wrote:
> > >
> > > There is a long standing bug in simpson since they introduced the
> > > ability of changing the MAS axis during the sequence (maybe not related
> > > to the bug). All versions 1.2 and later (2, 3) have this bug.
> > >
> > > Check this message to make a test:
> > > http://tech.groups.yahoo.com/group/simpson-simmol/message/815?gi=0
> > >
> > > Basically the time origin is wrong when using quadrupole to the second
> > > order. This makes impossible to simulate more than one pulse.
> > >
> > > Personnally I use simpson 1.1.1 whenever I simulate quadrupolar nuclei.
> > > However there is a lot of work to clean the code for compilation with
> > > modern API.
> > >
> > > I have an update version. If you need it I can send the archive. However
> > > many things are disabled (minuit, simmol) and I tested it only under
linux.
> > >
> > > Best,
> > >
> > > Julien TREBOSC
> > >
> > > Le 27/01/2011 18:24, kjharris_ssnmr a écrit :
> > > >
> > > > Hello SIMPSON users,
> > > >
> > > > Hopefully you guys can spot what I'm doing wrong here, I'm a little
> > > > confused. When simulating an echo in a 14N spectrum, it only works
> > > > when the quadrupolar interaction is set to 1st order, not 2nd. I get a
> > > > weird lineshape that can't be phased in the second case.
> > > >
> > > > With direct acquisition (no echo) the exact same lineshape results at
> > > > 1st/2nd order (as expected, the 2nd-order contribution for spin-1
> > > > nucleus isn't much against the large 1st-order). So... if the
> > > > lineshape is the same, I don't think the 2nd order perturbation should
> > > > affect the formation of an echo.
> > > >
> > > > Anybody know what might be going on here?
> > > >
> > > > Here's the simulation code I used, where I (Start as Ix)-(delay 50
> > > > μs)-(ideal π/2 pulse)-(delay 50 μs)-observe I+.
> > > > This version works fine, but fails if I swap in this line:
> > > > quadrupole 1 2 1.14e6 0.3 0.0 0.0 0.0
> > > >
> > > > -----------------
> > > > spinsys {
> > > > channels 14N
> > > > nuclei 14N
> > > > shift 1 0.0 0.0 0.0 0.0 0.0 0.0
> > > > quadrupole 1 1 1.14e6 0.3 0.0 0.0 0.0
> > > > }
> > > >
> > > > par {
> > > > method direct
> > > > spin_rate 0
> > > > sw 12.0e6
> > > > np 512
> > > > proton_frequency 400.0e6
> > > > crystal_file zcw28656.cry
> > > > start_operator I1x
> > > > detect_operator I1p
> > > > verbose 1111
> > > > }
> > > >
> > > > proc pulseq {} {
> > > > global par
> > > > set dw [expr 1.0e6/$par(sw)]
> > > >
> > > > set d1 50.0
> > > >
> > > > reset
> > > > delay $dw
> > > > store 1
> > > >
> > > > reset
> > > > delay $d1
> > > > pulseid 4 62500 x
> > > > delay $d1
> > > >
> > > > acq $par(np) 1
> > > >
> > > > }
> > > >
> > > > proc main {} {
> > > > global par
> > > > set f [fsimpson]
> > > > fsave $f $par(name).fid
> > > > fft $f
> > > > fsave $f $par(name).spe
> > > > funload $f
> > > > }
> > > >
> > > >
> > >
> >
> >
>

 

Hi Thomas,

I just downloaded and tried the new version (3.1.0 for mac), but I get the same result, so I guess that wasn't the issue. Here's a link of the results of straight observation versus echo for 1st and 2nd order quadrupolar interactions:
http://img684.imageshack.us/i/picture10gm.png/

cheers,
Kris

--- In simpson-simmol@yahoogroups.com, Thomas Vosegaard <tv@...> wrote:
>
> Could you try to run it with the latest release 3.1.0 and see if the problem persists? In this release, we have fixed a bug related to quadrupolar nuclei, so hopefully your problem is also solved.
>
> Thomas
>
>
> On Apr 20, 2011, at 20:54 , Kris Harris wrote:
>
> > Thanks very much for the info, I wasn't aware of that bug, but I'll keep it in mind now.
> >
> > thanks,
> > Kris
> >
> > --- In simpson-simmol@yahoogroups.com, Julien TREBOSC <simpson.trebosc@> wrote:
> > >
> > > There is a long standing bug in simpson since they introduced the
> > > ability of changing the MAS axis during the sequence (maybe not related
> > > to the bug). All versions 1.2 and later (2, 3) have this bug.
> > >
> > > Check this message to make a test:
> > > http://tech.groups.yahoo.com/group/simpson-simmol/message/815?gi=0
> > >
> > > Basically the time origin is wrong when using quadrupole to the second
> > > order. This makes impossible to simulate more than one pulse.
> > >
> > > Personnally I use simpson 1.1.1 whenever I simulate quadrupolar nuclei.
> > > However there is a lot of work to clean the code for compilation with
> > > modern API.
> > >
> > > I have an update version. If you need it I can send the archive. However
> > > many things are disabled (minuit, simmol) and I tested it only under linux.
> > >
> > > Best,
> > >
> > > Julien TREBOSC
> > >
> > > Le 27/01/2011 18:24, kjharris_ssnmr a écrit :
> > > >
> > > > Hello SIMPSON users,
> > > >
> > > > Hopefully you guys can spot what I'm doing wrong here, I'm a little
> > > > confused. When simulating an echo in a 14N spectrum, it only works
> > > > when the quadrupolar interaction is set to 1st order, not 2nd. I get a
> > > > weird lineshape that can't be phased in the second case.
> > > >
> > > > With direct acquisition (no echo) the exact same lineshape results at
> > > > 1st/2nd order (as expected, the 2nd-order contribution for spin-1
> > > > nucleus isn't much against the large 1st-order). So... if the
> > > > lineshape is the same, I don't think the 2nd order perturbation should
> > > > affect the formation of an echo.
> > > >
> > > > Anybody know what might be going on here?
> > > >
> > > > Here's the simulation code I used, where I (Start as Ix)-(delay 50
> > > > &#956;s)-(ideal &#960;/2 pulse)-(delay 50 &#956;s)-observe I+.
> > > > This version works fine, but fails if I swap in this line:
> > > > quadrupole 1 2 1.14e6 0.3 0.0 0.0 0.0
> > > >
> > > > -----------------
> > > > spinsys {
> > > > channels 14N
> > > > nuclei 14N
> > > > shift 1 0.0 0.0 0.0 0.0 0.0 0.0
> > > > quadrupole 1 1 1.14e6 0.3 0.0 0.0 0.0
> > > > }
> > > >
> > > > par {
> > > > method direct
> > > > spin_rate 0
> > > > sw 12.0e6
> > > > np 512
> > > > proton_frequency 400.0e6
> > > > crystal_file zcw28656.cry
> > > > start_operator I1x
> > > > detect_operator I1p
> > > > verbose 1111
> > > > }
> > > >
> > > > proc pulseq {} {
> > > > global par
> > > > set dw [expr 1.0e6/$par(sw)]
> > > >
> > > > set d1 50.0
> > > >
> > > > reset
> > > > delay $dw
> > > > store 1
> > > >
> > > > reset
> > > > delay $d1
> > > > pulseid 4 62500 x
> > > > delay $d1
> > > >
> > > > acq $par(np) 1
> > > >
> > > > }
> > > >
> > > > proc main {} {
> > > > global par
> > > > set f [fsimpson]
> > > > fsave $f $par(name).fid
> > > > fft $f
> > > > fsave $f $par(name).spe
> > > > funload $f
> > > > }
> > > >
> > > >
> > >
> >
> >
>

Dear all,

I'm wondering if any one might have a SIMPSON input file to simulate the
spectrum of a system with a very large quadrupolar coupling constant > 15 MHz;
something like:

-----------
quadrupole       1 2 18e6 0.9 0 0 0
-----------

Also, if one ends up having large quadrupolar coupling constants from a
Density-Functional-Theory simulation of the NMR parameters of a molecular solid,
what NMR technique is the most appropriate to get significant NMR information
with the SIMPSON code?

Every time that I change the quadrupolar coupling constant to something like 16
or 18 MHz, my NMR gets too broad. So, I'm curious to know if people in the
community have done similar simulations and will be willing to share their
SIMPSON input files and/or provide some feedback as to how to simulate/predict
the NMR spectrum of system with very large quadrupolar coupling constants.

Thanks,
rs

Hello,

SIMPSON for windows filters backslashes from command line parameters, which is
improper behavior on windows. Please fix it.

 

Hello,

SIMPSON for windows filters backslashes from command line parameters, which is improper behavior on windows. Please fix it.

Say, I am trying to start a simulation like this:
    ?>simpson.exe C:\DATA\SEDOR\SEDOR.in
Instead of starting the simulation, it issues an error:
    error: unable to open input file 'C:DATASEDORSEDOR.in',
where all backslashes have been filtered out. This is what one would expect on
Linux, but should never been done on Windows.



--- In simpson-simmol@yahoogroups.com, Zdenek Tosner <tosner@...> wrote:
>
> Can you please give me an example? (both correct behavior and improper
> behavior) Command line parameters are not receiving special treatment
> inside simpson, it is operating system and Tcl job...
>
> Zdenek
>
> On 08/29/2011 07:01 PM, evgeny.markhasin wrote:
> >
> > Hello,
> >
> > SIMPSON for windows filters backslashes from command line parameters,
> > which is improper behavior on windows. Please fix it.
> >
> >
>

 

Say, I am trying to start a simulation like this:
?>simpson.exe C:\DATA\SEDOR\SEDOR.in
Instead of starting the simulation, it issues an error:
error: unable to open input file 'C:DATASEDORSEDOR.in',
where all backslashes have been filtered out. This is what one would expect on Linux, but should never been done on Windows.

--- In simpson-simmol@yahoogroups.com, Zdenek Tosner <tosner@...> wrote:
>
> Can you please give me an example? (both correct behavior and improper
> behavior) Command line parameters are not receiving special treatment
> inside simpson, it is operating system and Tcl job...
>
> Zdenek
>
> On 08/29/2011 07:01 PM, evgeny.markhasin wrote:
> >
> > Hello,
> >
> > SIMPSON for windows filters backslashes from command line parameters,
> > which is improper behavior on windows. Please fix it.
> >
> >
>

Hello,

I have modified the "Simplex.c" file and emailed the updated version to
Professor Vosegaard. I was wondering if my message made it through.

Thanks,
Evgeny Markhasin

If I have, say, {13C 13C 1H} spin system. Is it possible to detect
simultaneously multiple operators, e.g. I1p, I2p, I3x, rather than just their
sum?

Can SIMPSON do cosine transform of real data?

Could you please comment on implicit acquisition employed by gcompute?

Specifically, how does acquisition occur when the pulse sequence only consists
of something like "delay 9999" Does it start at t=0? When I have other pulses
and delays, when does acquisition start?

Also if I do not have "delay 9999" and leave the pulse sequence empty, all fid
points will be the same and equal to the first point of fid detected with "delay
9999" in place. Why does it happen?

What is significance of "9999" in "delay 9999"? Can I pick a different number? I
need to understand where this number comes from, what the logic is behind it.

Thank you very much.

Hello, I come up with a couple more questions.

If I put "delay 20" in the pulse sequence, the result is the same as with "delay
9999". If I put "delay 2" or two delays "delay 10", the results will be
different. Could you please explain this behavior and what the different results
mean? (My dwell time is 10 usec.)

Also, if I want to have a specific propagator during acquisition, e.g. I want to
apply decoupling or disable some terms of the internal Hamiltonian, can I do it
with gcompute and how?

 

Hello, I come up with a couple more questions.

If I put "delay 20" in the pulse sequence, the result is the same as with "delay 9999". If I put "delay 2" or two delays "delay 10", the results will be different. Could you please explain this behavior and what the different results mean? (My dwell time is 10 usec.)

Also, if I want to have a specific propagator during acquisition, e.g. I want to apply decoupling or disable some terms of the internal Hamiltonian, can I do it with gcompute and how?

Thank you for your suggestion. I have actually tried the new igcompute a little
bit. This new version is indeed very intuitive and and allows perform
simulations, which, as far as I understand, are not possible using the old
gcompute. So far, I have not experienced any issues. I will give more feedback
as I run more simulations.

I understand that the new modes are in the development. I am missing the ability
to run a 2D experiment, thus, having acq_block{} in a cycle. Also, I wished I
could use multiple acq_block{}, with each acquiring a specified number of points
like "acq n". This feature would be convenient for CPMG experiment, though, I
understand that this application may not be sufficiently important.

--- In simpson-simmol@yahoogroups.com, Zdenek Tosner <tosner@...> wrote:
>
> I agree, this is very confusing. My suggestion is to forget about delay
> 9999 and use the current version of simpson with igcompute method
> described on the web
>
> http://www.bionmr.chem.au.dk/bionmr/software/simpson.php
>
> We are preparing new version with somewhat enhanced fool-proof checks
> and different inner code design,  but will be grateful for your
> experience with the acq_block command! Here you can put your decoupling
> or Hamiltonian manipulation - please give me feedback...
>
> Zdenek T.
>
> Dne 11.10.2011 15:12, evgeny.markhasin napsal(a):
> >
> > Hello, I come up with a couple more questions.
> >
> > If I put "delay 20" in the pulse sequence, the result is the same as
> > with "delay 9999". If I put "delay 2" or two delays "delay 10", the
> > results will be different. Could you please explain this behavior and
> > what the different results mean? (My dwell time is 10 usec.)
> >
> > Also, if I want to have a specific propagator during acquisition, e.g.
> > I want to apply decoupling or disable some terms of the internal
> > Hamiltonian, can I do it with gcompute and how?
> >
> >
>