>
> On 6/20/13 5:55 AM, Laura Dekkers wrote:
>
> Dear Doug,
>
> Thank you for your e-mail.
> As you suggested, we changed tnullmax to 6 sec and run the following code in
> Optseq:
> --ntp 255 --tr 2.0 --tprescan 4.0 --psdwin 0.0 16.0 1.0 --ev Gain2 4.0 8.0
> --ev Gain4 4.0 8.0 --ev Gain6 4.0 8.0 --ev Gain8 4.0 8.0 --ev Loss2 4.0 8.0
> --ev Loss4 4.0 8.0 --ev Loss6 4.0 8.0 --ev Loss8 4.0 8.0 --ev Catch 4.0 8.0
> --tnullmin 1.0 --tnullmax 7.0 --tsearch .25 -–focb 10 –-ar1 .37 --evc 1 1 1
> 1 -1 -1 -1 -1 0 --evc -1.5 -.5 .5 1.5 -1.5 -.5 .5 1.5 0 --evc -1.5 -.5 .5
> 1.5 1.5 .5 -.5 -1.5 0 --cost eff --nkeep 3 --o output_test5
>
> Although, this yielded no errors, I have several questions as to whether we
> got the results we actually wanted to.
>
> First, we repeatedly got a matrix rank-deficient message, like:
> /usr/pubsw/packages/vxl/1.13.0/src/core/vnl/algo/vnl_qr.txx:
> vnl_qr<T>::solve() : matrix is rank-deficient by 94
> I am not sure whether this of a fundamental problem. Could you please give
> your opinion on that?
>
> Not necessarily a problem. optseq tries lots of designs, and it does not
> know that they are bad until it tries to invert them. It is not a problem
> unless all of them are like that. It would be better to not print that
> error, but it is in some 3rd party code, and I don't have control over it.
>
>
> Second, you advised u to change tnullmax from 6 to 7 sec in the above code,
> so that it would be a mathematically equivant of the code below.
> --ntp 255 --tr 2.0 --tprescan 4.0 --psdwin 0.0 16.0 1.0 --ev Gain2 5.0 8.0
> --ev Gain4 5.0 8.0 --ev Gain6 5.0 8.0 --ev Gain8 5.0 8.0 --ev Loss2 5.0 8.0
> --ev Loss4 5.0 8.0 --ev Loss6 5.0 8.0 --ev Loss8 5.0 8.0 --ev Catch 5.0 8.0
> --tnullmin 0.0 --tnullmax 6.0 --tsearch .25 -–focb 10 –-ar1 .37 --evc 1 1 1
> 1 -1 -1 -1 -1 0 --evc -1.5 -.5 .5 1.5 -1.5 -.5 .5 1.5 0 --evc -1.5 -.5 .5
> 1.5 1.5 .5 -.5 -1.5 0 --cost eff --nkeep 3 --o output_test2
>
> However, we are not sure why this would be true. Could you please help to
> explain this?
>
> In the original cmd (tnullmin=0, max=6, stim=5), the stim is 4s stim + 1s
> hidden null. With a tnullmax=6, it means that you could have a null that was
> as long as 1+6=7s long (but least 1s long). In the new cmd, stim=4, min=1,
> max=7, which explicitly does the same thing.
>
>
>
> Finally, we originally wanted null events of at maximum 6 sec. You then
> advised us to change tnullmax from 6 to 7 sec. However, this does not
> restrict Optseq to insert null events of 7 sec at maximum. We occationally
> found Optseq to insert null events of 8 sec. Furthermore, the last null
> event Optseq inserts, allways is of a 12 sec duration. Do you have any idea
> why this is the case and hou we could change this?
>
> I might have fixed this. Try using this version
>
>
> let me know if you still have a problem.
> doug
>
>
> I am aware that I am posting a lot of questions at once. I hope you can find
> the possibility and time to help us out.
> Thank you in advance.
>
> Best,
> Laura
>
>
>
>>
>>
>> Hi Donna, on the 2nd command line you need to change --tnullmax to 7 sec
>> to be compatible with the 1st command line. I ran this and it works.
>> doug
>>
>>
>>
>>
>> On 6/11/13 8:45 AM, Laura Dekkers wrote:
>>
>> Dear Doug,
>>
>> Thanks you for your e-mail and sorry for the inconvenience. Here is the
>> code again.
>>
>> In this line of code we included the fixed duartion of the fix (1.0) in
>> the event duration specification (summing to 5.0) and asked Optseq to insert
>> null events of a minimum duration of 0.0 in 25% of the total scanning time:
>> --ntp 255 --tr 2.0 --tprescan 4.0 --psdwin 0.0 16.0 1.0 --ev Gain2 5.0 8.0
>> --ev Gain4 5.0 8.0 --ev Gain6 5.0 8.0 --ev Gain8 5.0 8.0 --ev Loss2 5.0 8.0
>> --ev Loss4 5.0 8.0 --ev Loss6 5.0 8.0 --ev Loss8 5.0 8.0 --ev Catch 5.0 8.0
>> --tnullmin 0.0 --tnullmax 6.0 --tsearch .25 -–focb 10 –-ar1 .37 --evc 1 1 1
>> 1 -1 -1 -1 -1 0 --evc -1.5 -.5 .5 1.5 -1.5 -.5 .5 1.5 0 --evc -1.5 -.5 .5
>> 1.5 1.5 .5 -.5 -1.5 0 --cost eff --nkeep 3 --o output_test2
>>
>> In this line of code we did not include the fixed duration of the fix
>> (1.0) in the event duration specification, but instead asked Opseq to insert
>> null events of at minimum 1.0 sec:
>> --ntp 255 --tr 2.0 --tprescan 4.0 --psdwin 0.0 16.0 1.0 --ev Gain2 4.0 8.0
>> --ev Gain4 4.0 8.0 --ev Gain6 4.0 8.0 --ev Gain8 4.0 8.0 --ev Loss2 4.0 8.0
>> --ev Loss4 4.0 8.0 --ev Loss6 4.0 8.0 --ev Loss8 4.0 8.0 --ev Catch 4.0 8.0
>> --tnullmin 1.0 --tnullmax 6.0 --tsearch .25 -–focb 10 –-ar1 .37 --evc 1 1 1
>> 1 -1 -1 -1 -1 0 --evc -1.5 -.5 .5 1.5 -1.5 -.5 .5 1.5 0 --evc -1.5 -.5 .5
>> 1.5 1.5 .5 -.5 -1.5 0 --cost eff --nkeep 3 --o output_test3
>> Since the former code yielded an error, we cut down the number of time
>> points, in the following code. This worked, but no longer yielded extra null
>> events in 25% of the scan time, because scan down was less now.
>> --ntp 180 --tr 2.0 --tprescan 4.0 --psdwin 0.0 16.0 1.0 --ev Gain2 4.0 8.0
>> --ev Gain4 4.0 8.0 --ev Gain6 4.0 8.0 --ev Gain8 4.0 8.0 --ev Loss2 4.0 8.0
>> --ev Loss4 4.0 8.0 --ev Loss6 4.0 8.0 --ev Loss8 4.0 8.0 --ev Catch 4.0 8.0
>> --tnullmin 1.0 --tnullmax 6.0 --tsearch .25 -–focb 10 –-ar1 .37 --evc 1 1 1
>> 1 -1 -1 -1 -1 0 --evc -1.5 -.5 .5 1.5 -1.5 -.5 .5 1.5 0 --evc -1.5 -.5 .5
>> 1.5 1.5 .5 -.5 -1.5 0 --cost eff --nkeep 3 --o output_test4
>> I hope this is helpful in understanding our problem and helping us out.
>> Thank you for your time!
>>
>> Best,
>> Laura
>>
>>>
>>> Hi Laura, can you just cut and paste the command line into the email?
>>> There are some funny characters in that file you sent
>>> doug
>>>
>>> On 06/07/2013 12:09 PM, Laura Dekkers wrote:
>>>>
>>>> Dear Doug,
>>>> Thank you for your e-mail. Please find attached our command line.
>>>> We felt that the first two lines of code should essentially yield the
>>>> same timing of events. In the first we included the fixed duration of the
>>>> fix (1.0) in our event duration (4.0) and meant to ask for extra null events
>>>> of a minimum duration of 0.0 sec. In the second, we did not include the
>>>> fixed duration of the fix in our event duration (4.0) and meant to ask for
>>>> this by inserting null events of at least 1.0 sec.
>>>> Since the second line of code yielded an error, we run the third line.
>>>> Is this helpful?
>>>> Best,
>>>> Laura
>>>>
>>>>
>>>>
>>>> Hi Laura, what is your command line?
>>>> doug
>>>>
>>>> On 06/04/2013 09:02 AM, Laura Dekkers wrote:
>>>> >
>>>> > Dear Dr Greve,
>>>> >
>>>> > Together with Dr Hilde Huizenga I am implementing an fMRI study in
>>>> > which we would like to optimize the design by using Optseq2. We
>>>> have a
>>>> > few questions. Could you please help us out?
>>>> >
>>>> > Our task consists of 3 runs of 72 trails each, in which
>>>> participants
>>>> > are presented with a fixation cross that remains on the screen for
>>>> a
>>>> > fixed duration of 1 sec, followed by one out of nine different
>>>> stimuli
>>>> > that remains on the screen for a fixed duration of 4 sec.
>>>> > This gives a scan duration of 360 sec. We would then like to add
>>>> 25%
>>>> > jitter, which results in a scan duration of 450 sec, and as TR =
>>>> 2.0,
>>>> > this results in 225 time points.
>>>> > However, Optseq yields an error if ntp is set to 225, ev
>>>> duration set
>>>> > to 4.0, psdwin dPSD to 1.0 , tnullmin to 1.0 and tnullmax to 6.0
>>>> > ERROR: could not enforce tNullMax=6 (ntries=100000)
>>>> > You will need to reduce the number of time points
>>>> > or increase the number of presentations.
>>>> > However, reducing the number of time points makes Optseq to only
>>>> > insert null events of 1.0 or rarely 2.0 sec without much
>>>> variation.
>>>> > Optimization with ntp set to 225, ev duration set to 5.0 (=fixed
>>>> > duration of fix + stimulus), psdwin dPSD to 1.0 , tnullmin to
>>>> 0.0 (1.0
>>>> > does not work) and tnullmax to 6.0 does work. However, this
>>>> renders
>>>> > Optseq to insert null events of a fixed duration op 1.0 sec,
>>>> which is
>>>> > not what we want.
>>>> > Could you please advise us in how to set these parameters?
>>>> > Thank you in advance.
>>>> > Best regards,
>>>> > Laura Dekkers
>>>> >
>>>> > --
>>>> > Laura M.S. Dekkers, MSc
>>>> > Research assistant
>>>> > University of Amsterdam - Department of Developmental Psychology
>>>> > Weesperplein 4
>>>> > 1018 XA Amsterdam - The Netherlands
>>>>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Freesurfer mailing list
>>>>
>>>>
>>>> --
>>>> Douglas N. Greve, Ph.D.
>>>> MGH-NMR Center
>>>>
>>>>
>>>> Outgoing:
>>>>
>>>> _______________________________________________
>>>> Freesurfer mailing list
>>>>
>>>>
>>>>
>>>> The information in this e-mail is intended only for the person to
>>>> whom it is
>>>> addressed. If you believe this e-mail was sent to you in error and
>>>> the e-mail
>>>> contains patient information, please contact the Partners
>>>> Compliance HelpLine at
>>>> you in error
>>>> but does not contain patient information, please contact the
>>>> sender and properly
>>>> dispose of the e-mail.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Laura M.S. Dekkers, MSc
>>>> Research assistant
>>>> University of Amsterdam - Department of Developmental Psychology
>>>> Weesperplein 4
>>>> 1018 XA Amsterdam - The Netherlands
>>>
>>>
>>> --
>>> Douglas N. Greve, Ph.D.
>>> MGH-NMR Center
>>>
>>>
>>
>>
>>
>> --
>> Laura M.S. Dekkers, MSc
>> Research assistant
>> University of Amsterdam - Department of Developmental Psychology
>> Weesperplein 4
>> 1018 XA Amsterdam - The Netherlands
>>
>>
>>
>
>
>
> --
> Laura M.S. Dekkers, MSc
> Research assistant
> University of Amsterdam - Department of Developmental Psychology
> Weesperplein 4
> 1018 XA Amsterdam - The Netherlands
>
>
>