Dear Doug, Some time ago we e-mailed about the optimazation of the timing ou our experimental design. Based on that conversation I have used the folling command line: --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
After piloting our task and inspecting the output of Optseq, it seemd that this code does not generate what we are actually looking for. We use 72 stimuli of 4 sec duration each, followed by a fixed null event of 1 sec. This sums to 360 sec. We then would like to add 25% extra null events (i.e., 90 sec), summing to a total scan time of 450 sec. If I am not mistaken this gives ntp = 225. However, by using the above code, Optseq insert null events for over 200 sec. I might have overlooked someting. Can you please advise on how we should change the code so Optseq is actually using 162 sec for insertion of null events? Thank you in advance! Best, Laura 2013/6/27 Laura Dekkers <lmsdekk...@gmail.com> > Dear Doug, > > Thank you for your explanations and suggestions. I tested the code under > the new Optseq version and it seems to generate proper output now. > > Thanks a lot! > > Best regards, > Laura > > > > 2013/6/21 Douglas Greve <gr...@nmr.mgh.harvard.edu>: > > > > 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 <gr...@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 <gr...@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 <gr...@nmr.mgh.harvard.edu > >>>> <mailto:gr...@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: lmsdekk...@gmail.com <mailto:lmsdekk...@gmail.com> > >>>> <mailto:lmsdekk...@gmail.com <mailto:lmsdekk...@gmail.com>> > >>>> > >>>> > > >>>> > > >>>> > _______________________________________________ > >>>> > Freesurfer mailing list > >>>> > 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 > >>>> gr...@nmr.mgh.harvard.edu <mailto:gr...@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/ > >>>> > >>>> _______________________________________________ > >>>> Freesurfer mailing list > >>>> 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: lmsdekk...@gmail.com <mailto:lmsdekk...@gmail.com> > >>> > >>> > >>> -- > >>> Douglas N. Greve, Ph.D. > >>> MGH-NMR Center > >>> gr...@nmr.mgh.harvard.edu > >>> Phone Number: 617-724-2358 > >>> Fax: 617-726-7422 > >>> > >>> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > >>> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 > >>> 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: lmsdekk...@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: lmsdekk...@gmail.com > > > > > > > >
_______________________________________________ Freesurfer mailing list 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.
