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
ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/optseq2
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
2013/6/15 Douglas Greve <greve@nmr.mgh.harvard.edu mailto:greve@nmr.mgh.harvard.edu>
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 2013/6/7 Douglas N Greve <greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>> 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 2013/6/5 Douglas N Greve <greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> <mailto:greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>>> 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 > E-mail: lmsdekkers@gmail.com <mailto:lmsdekkers@gmail.com> <mailto:lmsdekkers@gmail.com <mailto:lmsdekkers@gmail.com>> <mailto:lmsdekkers@gmail.com <mailto:lmsdekkers@gmail.com> <mailto:lmsdekkers@gmail.com <mailto:lmsdekkers@gmail.com>>> > > > _______________________________________________ > Freesurfer mailing list > Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu>> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer -- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> <mailto:greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>> Phone Number: 617-724-2358 <tel:617-724-2358> <tel:617-724-2358 <tel:617-724-2358>> Fax: 617-726-7422 <tel:617-726-7422> <tel:617-726-7422 <tel:617-726-7422>> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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 http://www.partners.org/complianceline . If the e-mail was sent to 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 E-mail: lmsdekkers@gmail.com <mailto:lmsdekkers@gmail.com> <mailto:lmsdekkers@gmail.com <mailto:lmsdekkers@gmail.com>> -- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> Phone Number: 617-724-2358 <tel:617-724-2358> Fax: 617-726-7422 <tel:617-726-7422> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ -- Laura M.S. Dekkers, MSc Research assistant University of Amsterdam - Department of Developmental Psychology Weesperplein 4 1018 XA Amsterdam - The Netherlands E-mail: lmsdekkers@gmail.com <mailto:lmsdekkers@gmail.com>-- Laura M.S. Dekkers, MSc Research assistant University of Amsterdam - Department of Developmental Psychology Weesperplein 4 1018 XA Amsterdam - The Netherlands E-mail: lmsdekkers@gmail.com mailto:lmsdekkers@gmail.com