External Email - Use Caution
Dear experts:
I'm using the optseq2 version 2.15 2009/05/26. I have three questions:
1. How does the [PSDmin, PSDmax] relate to the jittered intertrial intervals? 2. I have stimuli of between 12 and 20 seconds, where the part of my stimulus that I want to measure is in the last 5 seconds or so. What should I put my dPSD window to? It's both a matter of that the signal starts later than the stimulus presentation, so I guess I would have a PSDmin of a couple of seconds, but how do I handle the variation in stimuli lengths? 3. As mentioned above I have quite a large variation between my stimuli. When I try to specify them individually (about 25) I always get that all schedules are ill-conditioned. Is this because such schedules are generally hard to optimize? 4. I quite often get that all schedules are ill-conditioned, but there is no information in the log file that tells me what is wrong. Example:
./optseq2 --ntp 1500 --tr 1.86 --psdwin 0 22.32 0.93 --nkeep 3 --nsearch 1000 --o test --ev control_trial_1 16.74 1 --ev control_trial_3 18.6 1 --ev control_trial_7 18.6 1 --ev test_trial_11 16.74 1
I get:
NFO: searched 1000 iterations for 0.010556 hours INFO: 26.3158 iterations per second INFO: 1000/1000 schedules were ill-conditioned ERROR: all schedules found were ill-conditioned. This probably means that you need more scan time (ie, a greater number of time points) or fewer repetitions.
(I'm running on a macOS Mojave version 10.14.3. )
But it's obviously not the ntp that is the problem since I put an extra long time there that cover the event durations by far.
Is there any way I can troubleshoot more efficiently myself? The log file doesn't tell me anything.
Very happy for any advice,
All the best,
Katarina
Katarina Bendtz, Ph.D. (particle physics) Postdoctoral researcher in cognitive neuroscience Department of Psychology, Stockholm University
On 5/29/19 1:05 PM, Katarina Bendtz wrote:
External Email - Use Caution
Dear experts:
I'm using the optseq2 version 2.15 2009/05/26. I have three questions:
- How does the [PSDmin, PSDmax] relate to the jittered intertrial intervals?
The PSDmax sets the maximum window overwhich jitter needs to be considered. It is assumed that the hemodyn response will be 0 after PSDmax and so that jitter will not matter beyond this time.
- I have stimuli of between 12 and 20 seconds, where the part of my stimulus that I want to measure is in the last 5 seconds or so. What should I put my dPSD window to? It's both a matter of that the signal starts later than the stimulus presentation, so I guess I would have a PSDmin of a couple of seconds, but how do I handle the variation in stimuli lengths?
You need to have the PSD window completely cover the hemodyn response regardless of what you are interested in.
- As mentioned above I have quite a large variation between my stimuli. When I try to specify them individually (about 25) I always get that all schedules are ill-conditioned. Is this because such schedules are generally hard to optimize?
Schedules with lots of different conditions are hard to optimize.
- I quite often get that all schedules are ill-conditioned, but there is no information in the log file that tells me what is wrong. Example:
./optseq2 --ntp 1500 --tr 1.86 --psdwin 0 22.32 0.93 --nkeep 3 --nsearch 1000 --o test --ev control_trial_1 16.74 1 --ev control_trial_3 18.6 1 --ev control_trial_7 18.6 1 --ev test_trial_11 16.74 1
You only have 1 event for each condition. Surely you must have more?
I get:
NFO: searched 1000 iterations for 0.010556 hours INFO: 26.3158 iterations per second INFO: 1000/1000 schedules were ill-conditioned ERROR: all schedules found were ill-conditioned. This probably means that you need more scan time (ie, a greater number of time points) or fewer repetitions.
(I'm running on a macOS Mojave version 10.14.3. )
But it's obviously not the ntp that is the problem since I put an extra long time there that cover the event durations by far.
Is there any way I can troubleshoot more efficiently myself? The log file doesn't tell me anything.
Very happy for any advice,
All the best,
Katarina
Katarina Bendtz, Ph.D. (particle physics) Postdoctoral researcher in cognitive neuroscience Department of Psychology, Stockholm University
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
External Email - Use Caution
Dear Douglas:
Thank you so much for your reply. It is however still not clear to me how this works. Pls see my replies below.
All the best and many thanks for your time,
Katarina
PS. I'm registered to the list so I don't know why my mail is listed as external, sorry.
On 5/29/19 1:05 PM, Katarina Bendtz wrote:
External Email - Use CautionDear experts:
I'm using the optseq2 version 2.15 2009/05/26. I have three questions:
- How does the [PSDmin, PSDmax] relate to the jittered intertrial intervals?
The PSDmax sets the maximum window overwhich jitter needs to be considered. It is assumed that the hemodyn response will be 0 after PSDmax and so that jitter will not matter beyond this time.
Why then do I get schedules with intertrial breaks (NULLs) with durations longer than PSDmax? Isn't that just a waste of time then?
- I have stimuli of between 12 and 20 seconds, where the part of my stimulus that I want to measure is in the last 5 seconds or so. What should I put my dPSD window to? It's both a matter of that the signal starts later than the stimulus presentation, so I guess I would have a PSDmin of a couple of seconds, but how do I handle the variation in stimuli lengths?
You need to have the PSD window completely cover the hemodyn response regardless of what you are interested in.
This is counting from the onset time of the stimuli right? In that case I will have to put the PSDmin to the time when my target starts?(My stimuli are dialogues: Context (appr. 12 s) + Q (appr. 3 s) + A (appr. 3 s), and I only want to measure the answer, so I should then put PSDmin to 12 s + 3 s = 15 s? And then PSDmax to PSDmin + (HRF response time)?
- As mentioned above I have quite a large variation between my stimuli. When I try to specify them individually (about 25) I always get that all schedules are ill-conditioned. Is this because such schedules are generally hard to optimize?
Schedules with lots of different conditions are hard to optimize.
- I quite often get that all schedules are ill-conditioned, but there is no information in the log file that tells me what is wrong. Example:
./optseq2 --ntp 1500 --tr 1.86 --psdwin 0 22.32 0.93 --nkeep 3 --nsearch 1000 --o test --ev control_trial_1 16.74 1 --ev control_trial_3 18.6 1 --ev control_trial_7 18.6 1 --ev test_trial_11 16.74 1
You only have 1 event for each condition. Surely you must have more?
I have 20 trials, and two conditions, "test" and "control", with 10 trials of each condition. In this example I only had 4 trials since I wanted to test if the large number of events was yielding my problem. The reason why I specify all trials as individual events is that the trials differ greatly in duration (between 12 s and 20 s) and *all* have individual durations. I was assuming this would be important information for the schedule optimization, but maybe you think it is better to use the average duration of each condition (even though that will differ from individual event durations with up to 6 s) and then I randomimze the order of events myself?
I get:
NFO: searched 1000 iterations for 0.010556 hours INFO: 26.3158 iterations per second INFO: 1000/1000 schedules were ill-conditioned ERROR: all schedules found were ill-conditioned. This probably means that you need more scan time (ie, a greater number of time points) or fewer repetitions.
(I'm running on a macOS Mojave version 10.14.3. )
But it's obviously not the ntp that is the problem since I put an extra long time there that cover the event durations by far.
Is there any way I can troubleshoot more efficiently myself? The log file doesn't tell me anything.
Very happy for any advice,
All the best,
Katarina
Katarina Bendtz, Ph.D. (particle physics) Postdoctoral researcher in cognitive neuroscience Department of Psychology, Stockholm University
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
On 5/31/2019 2:18 AM, Katarina Bendtz wrote:
External Email - Use Caution
Dear Douglas:
Thank you so much for your reply. It is however still not clear to me how this works. Pls see my replies below.
All the best and many thanks for your time,
Katarina
PS. I'm registered to the list so I don't know why my mail is listed as external, sorry.
On 5/29/19 1:05 PM, Katarina Bendtz wrote:
External Email - Use CautionDear experts:
I'm using the optseq2 version 2.15 2009/05/26. I have three questions:
- How does the [PSDmin, PSDmax] relate to the jittered intertrial intervals?
The PSDmax sets the maximum window overwhich jitter needs to be considered. It is assumed that the hemodyn response will be 0 after PSDmax and so that jitter will not matter beyond this time.
Why then do I get schedules with intertrial breaks (NULLs) with durations longer than PSDmax? Isn't that just a waste of time then? Yes, it depends on how long the scan is (TR*NumberOfTRs) and how many trials you have. If you have too few trials, then you will get "empty" space.
- I have stimuli of between 12 and 20 seconds, where the part of my stimulus that I want to measure is in the last 5 seconds or so. What should I put my dPSD window to? It's both a matter of that the signal starts later than the stimulus presentation, so I guess I would have a PSDmin of a couple of seconds, but how do I handle the variation in stimuli lengths?
You need to have the PSD window completely cover the hemodyn response regardless of what you are interested in.
This is counting from the onset time of the stimuli right? In that case I will have to put the PSDmin to the time when my target starts?(My stimuli are dialogues: Context (appr. 12 s) + Q (appr. 3 s) + A (appr. 3 s), and I only want to measure the answer, so I should then put PSDmin to 12 s + 3 s = 15 s? And then PSDmax to PSDmin + (HRF response time)? No, you have to put PSDMin=0. All those other events will produce a hemodyn response regardless of whether you want to measure it or not.
- As mentioned above I have quite a large variation between my stimuli. When I try to specify them individually (about 25) I always get that all schedules are ill-conditioned. Is this because such schedules are generally hard to optimize?
Schedules with lots of different conditions are hard to optimize.
- I quite often get that all schedules are ill-conditioned, but there is no information in the log file that tells me what is wrong. Example:
./optseq2 --ntp 1500 --tr 1.86 --psdwin 0 22.32 0.93 --nkeep 3 --nsearch 1000 --o test --ev control_trial_1 16.74 1 --ev control_trial_3 18.6 1 --ev control_trial_7 18.6 1 --ev test_trial_11 16.74 1
You only have 1 event for each condition. Surely you must have more?
I have 20 trials, and two conditions, "test" and "control", with 10 trials of each condition. In this example I only had 4 trials since I wanted to test if the large number of events was yielding my problem. The reason why I specify all trials as individual events is that the trials differ greatly in duration (between 12 s and 20 s) and *all* have individual durations. I was assuming this would be important information for the schedule optimization, but maybe you think it is better to use the average duration of each condition (even though that will differ from individual event durations with up to 6 s) and then I randomimze the order of events myself? No, you are right, it is important. I'm not sure what is going wrong here without the full command line. optseq was not designed with this type of application in mind, so it might not be possible.
I get:
NFO: searched 1000 iterations for 0.010556 hours INFO: 26.3158 iterations per second INFO: 1000/1000 schedules were ill-conditioned ERROR: all schedules found were ill-conditioned. This probably means that you need more scan time (ie, a greater number of time points) or fewer repetitions.
(I'm running on a macOS Mojave version 10.14.3. )
But it's obviously not the ntp that is the problem since I put an extra long time there that cover the event durations by far.
Is there any way I can troubleshoot more efficiently myself? The log file doesn't tell me anything.
Very happy for any advice,
All the best,
Katarina
Katarina Bendtz, Ph.D. (particle physics) Postdoctoral researcher in cognitive neuroscience Department of Psychology, Stockholm University
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edumailto:Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edumailto:Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edumailto:Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
External Email - Use Caution
Dear Douglas:
Thanks so much for your quick reply! I appreciate your help a lot! Please see my answer below.
I have 20 trials, and two conditions, "test" and "control", with 10 trials of each condition. In this example I only had 4 trials since I wanted to test if the large number of events was yielding my problem. The reason why I specify all trials as individual events is that the trials differ greatly in duration (between 12 s and 20 s) and *all* have individual durations. I was assuming this would be important information for the schedule optimization, but maybe you think it is better to use the average duration of each condition (even though that will differ from individual event durations with up to 6 s) and then I randomimze the order of events myself? No, you are right, it is important. I'm not sure what is going wrong here without the full command line. optseq was not designed with this type of application in mind, so it might not be possible.
Ok thanks, I see. Here’s a full command line (also attaching all output) where I specified all different trials (with their specific durations but rounded to the nearest multiple of the TR = dPSD). I do get some schedules but the efficiency is very low. What would you recommend for me to do?
eduroam-10-200-35-57:Downloads bendtz$ ./optseq2 --ntp 1500 --tr 1.86 --psdwin 11.16 48.36 1.86 --nkeep 3 --nsearch 1000 --o test --ev control_trial_3 18.6 1 --ev control_trial_4 14.88 1 --ev control_trial_16 20.46 1 --ev control_trial_18 13.02 1 --ev test_trial_26 18.6 1 --ev control_trial_29 16.74 1 --ev test_trial_31 18.6 1 --ev test_trial_36 20.46 1 --ev test_trial_41 16.74 1 --ev test_trial_43 18.6 1 --ev test_trial_45 16.74 1 --ev test_trial_47 18.6 1 --ev control_trial_48 16.74 1 --ev test_trial_53 13.02 1 --ev control_trial_60 13.02 1 --ev test_trial_67 18.6 1 --ev control_trial_69 26.04 1 --ev control_trial_71 18.6 1 --ev control_trial_75 18.6 1 --ev control_trial_79 18.6 1 INFO: Setting srand48() seed to 999910 optseq2 $Id: optseq2.c,v 2.15 2009/05/26 18:13:45 greve Exp $ NoSearch = 0 nSearch = 1000 nKeep = 3 PctUpdate = 10.000000 nCB1Opt = 0 seed = 999910 Ntp = 1500 TR = 1.86 TPreScan = 0 PSD Window = 11.16 48.36 1.86 nEvTypes = 20 EvNo Label Duration nRepsNom 1 control_trial_3 18.600 1 2 control_trial_4 14.880 1 3 control_trial_16 20.460 1 4 control_trial_18 13.020 1 5 test_trial_26 18.600 1 6 control_trial_29 16.740 1 7 test_trial_31 18.600 1 8 test_trial_36 20.460 1 9 test_trial_41 16.740 1 10 test_trial_43 18.600 1 11 test_trial_45 16.740 1 12 test_trial_47 18.600 1 13 control_trial_48 16.740 1 14 test_trial_53 13.020 1 15 control_trial_60 13.020 1 16 test_trial_67 18.600 1 17 control_trial_69 26.040 1 18 control_trial_71 18.600 1 19 control_trial_75 18.600 1 20 control_trial_79 18.600 1 PctVarEvReps = 0 VarEvRepsPerCond = 0 PolyOrder = -1 tNullMax = -1 tNullMin = 0 outstem = test AR1 = 0 No refractory penalty Cost = eff OutStem = test Summary File = test.sum nTaskAvgs = 400 INFO: LogFile is test.log outstem = test 5 59 0.6 8.42937e-09 8.42937e-09 1.8550 0.975 0.15632 8.42937e-08 1 1 40.9436 0 22 226 2.4 8.42937e-09 8.42937e-09 1.8550 0.975 0.15632 8.42937e-08 1 1 40.9436 0 75 756 8.4 0.0025 0.0025 1.8550 1 0 1 1 0 30.9512 0 75 1000 11.1 0.0025 0.0025 1.8550 1 0 1 1 0 30.9512 0 INFO: searched 1000 iterations for 0.185833 hours INFO: 1.49477 iterations per second INFO: 997/1000 schedules were ill-conditioned outstem = test
I get:
NFO: searched 1000 iterations for 0.010556 hours INFO: 26.3158 iterations per second INFO: 1000/1000 schedules were ill-conditioned ERROR: all schedules found were ill-conditioned. This probably means that you need more scan time (ie, a greater number of time points) or fewer repetitions.
(I'm running on a macOS Mojave version 10.14.3. )
But it's obviously not the ntp that is the problem since I put an extra long time there that cover the event durations by far.
Is there any way I can troubleshoot more efficiently myself? The log file doesn't tell me anything.
Very happy for any advice,
All the best,
Katarina
Katarina Bendtz, Ph.D. (particle physics) Postdoctoral researcher in cognitive neuroscience Department of Psychology, Stockholm University
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edumailto:Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edumailto:Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edumailto:Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
The efficiency is low in part because you have only one presentation for each event type. The efficiency will scale with number of events for a given type and will decrease when you have more overlap in the HRFs. Whether it matters or not depends on how you are going to analyze your data. The optseq efficiency calculation assumes that you will use an FIR; if you are going to assume a shape, then it does not matter so much. If you are going to combine events into a single event type, then it does not matter so much.
On 6/3/2019 4:55 AM, Katarina Bendtz wrote:
External Email - Use Caution Dear Douglas:
Thanks so much for your quick reply! I appreciate your help a lot! Please see my answer below.
I have 20 trials, and two conditions, "test" and "control", with 10 trials of each condition. In this example I only had 4 trials since I wanted to test if the large number of events was yielding my problem. The reason why I specify all trials as individual events is that the trials differ greatly in duration (between 12 s and 20 s) and *all* have individual durations. I was assuming this would be important information for the schedule optimization, but maybe you think it is better to use the average duration of each condition (even though that will differ from individual event durations with up to 6 s) and then I randomimze the order of events myself? No, you are right, it is important. I'm not sure what is going wrong here without the full command line. optseq was not designed with this type of application in mind, so it might not be possible.
Ok thanks, I see. Here’s a full command line (also attaching all output) where I specified all different trials (with their specific durations but rounded to the nearest multiple of the TR = dPSD). I do get some schedules but the efficiency is very low. What would you recommend for me to do?
eduroam-10-200-35-57:Downloads bendtz$ ./optseq2 --ntp 1500 --tr 1.86 --psdwin 11.16 48.36 1.86 --nkeep 3 --nsearch 1000 --o test --ev control_trial_3 18.6 1 --ev control_trial_4 14.88 1 --ev control_trial_16 20.46 1 --ev control_trial_18 13.02 1 --ev test_trial_26 18.6 1 --ev control_trial_29 16.74 1 --ev test_trial_31 18.6 1 --ev test_trial_36 20.46 1 --ev test_trial_41 16.74 1 --ev test_trial_43 18.6 1 --ev test_trial_45 16.74 1 --ev test_trial_47 18.6 1 --ev control_trial_48 16.74 1 --ev test_trial_53 13.02 1 --ev control_trial_60 13.02 1 --ev test_trial_67 18.6 1 --ev control_trial_69 26.04 1 --ev control_trial_71 18.6 1 --ev control_trial_75 18.6 1 --ev control_trial_79 18.6 1 INFO: Setting srand48() seed to 999910 optseq2 $Id: optseq2.c,v 2.15 2009/05/26 18:13:45 greve Exp $ NoSearch = 0 nSearch = 1000 nKeep = 3 PctUpdate = 10.000000 nCB1Opt = 0 seed = 999910 Ntp = 1500 TR = 1.86 TPreScan = 0 PSD Window = 11.16 48.36 1.86 nEvTypes = 20 EvNo Label Duration nRepsNom 1 control_trial_3 18.600 1 2 control_trial_4 14.880 1 3 control_trial_16 20.460 1 4 control_trial_18 13.020 1 5 test_trial_26 18.600 1 6 control_trial_29 16.740 1 7 test_trial_31 18.600 1 8 test_trial_36 20.460 1 9 test_trial_41 16.740 1 10 test_trial_43 18.600 1 11 test_trial_45 16.740 1 12 test_trial_47 18.600 1 13 control_trial_48 16.740 1 14 test_trial_53 13.020 1 15 control_trial_60 13.020 1 16 test_trial_67 18.600 1 17 control_trial_69 26.040 1 18 control_trial_71 18.600 1 19 control_trial_75 18.600 1 20 control_trial_79 18.600 1 PctVarEvReps = 0 VarEvRepsPerCond = 0 PolyOrder = -1 tNullMax = -1 tNullMin = 0 outstem = test AR1 = 0 No refractory penalty Cost = eff OutStem = test Summary File = test.sum nTaskAvgs = 400 INFO: LogFile is test.log outstem = test 5 59 0.6 8.42937e-09 8.42937e-09 1.8550 0.975 0.15632 8.42937e-08 1 1 40.9436 0 22 226 2.4 8.42937e-09 8.42937e-09 1.8550 0.975 0.15632 8.42937e-08 1 1 40.9436 0 75 756 8.4 0.0025 0.0025 1.8550 1 0 1 1 0 30.9512 0 75 1000 11.1 0.0025 0.0025 1.8550 1 0 1 1 0 30.9512 0 INFO: searched 1000 iterations for 0.185833 hours INFO: 1.49477 iterations per second INFO: 997/1000 schedules were ill-conditioned outstem = test
I get:
NFO: searched 1000 iterations for 0.010556 hours INFO: 26.3158 iterations per second INFO: 1000/1000 schedules were ill-conditioned ERROR: all schedules found were ill-conditioned. This probably means that you need more scan time (ie, a greater number of time points) or fewer repetitions.
(I'm running on a macOS Mojave version 10.14.3. )
But it's obviously not the ntp that is the problem since I put an extra long time there that cover the event durations by far.
Is there any way I can troubleshoot more efficiently myself? The log file doesn't tell me anything.
Very happy for any advice,
All the best,
Katarina
Katarina Bendtz, Ph.D. (particle physics) Postdoctoral researcher in cognitive neuroscience Department of Psychology, Stockholm University
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edumailto:Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edumailto:Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edumailto:Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edumailto:Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
External Email - Use Caution
Dear Douglas:
The efficiency is low in part because you have only one presentation for each event type. The efficiency will scale with number of events for a given type and will decrease when you have more overlap in the HRFs. Whether it matters or not depends on how you are going to analyze your data. The optseq efficiency calculation assumes that you will use an FIR; if you are going to assume a shape, then it does not matter so much. If you are going to combine events into a single event type, then it does not matter so much. Thank you, I understand. So I need to choose between optseq not taking into account the differences in duration (by specifying an average duration) or not taking into account that my trials are of the same type and will be combined. I think the latter will affect the optimization much more so I think taking the average duration is the best option, do you agree? Thank you! On 6/3/2019 4:55 AM, Katarina Bendtz wrote:
External Email - Use Caution Dear Douglas:
Thanks so much for your quick reply! I appreciate your help a lot! Please see my answer below.
I have 20 trials, and two conditions, "test" and "control", with 10 trials of each condition. In this example I only had 4 trials since I wanted to test if the large number of events was yielding my problem. The reason why I specify all trials as individual events is that the trials differ greatly in duration (between 12 s and 20 s) and *all* have individual durations. I was assuming this would be important information for the schedule optimization, but maybe you think it is better to use the average duration of each condition (even though that will differ from individual event durations with up to 6 s) and then I randomimze the order of events myself? No, you are right, it is important. I'm not sure what is going wrong here without the full command line. optseq was not designed with this type of application in mind, so it might not be possible.
Ok thanks, I see. Here’s a full command line (also attaching all output) where I specified all different trials (with their specific durations but rounded to the nearest multiple of the TR = dPSD). I do get some schedules but the efficiency is very low. What would you recommend for me to do?
eduroam-10-200-35-57:Downloads bendtz$ ./optseq2 --ntp 1500 --tr 1.86 --psdwin 11.16 48.36 1.86 --nkeep 3 --nsearch 1000 --o test --ev control_trial_3 18.6 1 --ev control_trial_4 14.88 1 --ev control_trial_16 20.46 1 --ev control_trial_18 13.02 1 --ev test_trial_26 18.6 1 --ev control_trial_29 16.74 1 --ev test_trial_31 18.6 1 --ev test_trial_36 20.46 1 --ev test_trial_41 16.74 1 --ev test_trial_43 18.6 1 --ev test_trial_45 16.74 1 --ev test_trial_47 18.6 1 --ev control_trial_48 16.74 1 --ev test_trial_53 13.02 1 --ev control_trial_60 13.02 1 --ev test_trial_67 18.6 1 --ev control_trial_69 26.04 1 --ev control_trial_71 18.6 1 --ev control_trial_75 18.6 1 --ev control_trial_79 18.6 1 INFO: Setting srand48() seed to 999910 optseq2 $Id: optseq2.c,v 2.15 2009/05/26 18:13:45 greve Exp $ NoSearch = 0 nSearch = 1000 nKeep = 3 PctUpdate = 10.000000 nCB1Opt = 0 seed = 999910 Ntp = 1500 TR = 1.86 TPreScan = 0 PSD Window = 11.16 48.36 1.86 nEvTypes = 20 EvNo Label Duration nRepsNom 1 control_trial_3 18.600 1 2 control_trial_4 14.880 1 3 control_trial_16 20.460 1 4 control_trial_18 13.020 1 5 test_trial_26 18.600 1 6 control_trial_29 16.740 1 7 test_trial_31 18.600 1 8 test_trial_36 20.460 1 9 test_trial_41 16.740 1 10 test_trial_43 18.600 1 11 test_trial_45 16.740 1 12 test_trial_47 18.600 1 13 control_trial_48 16.740 1 14 test_trial_53 13.020 1 15 control_trial_60 13.020 1 16 test_trial_67 18.600 1 17 control_trial_69 26.040 1 18 control_trial_71 18.600 1 19 control_trial_75 18.600 1 20 control_trial_79 18.600 1 PctVarEvReps = 0 VarEvRepsPerCond = 0 PolyOrder = -1 tNullMax = -1 tNullMin = 0 outstem = test AR1 = 0 No refractory penalty Cost = eff OutStem = test Summary File = test.sum nTaskAvgs = 400 INFO: LogFile is test.log outstem = test 5 59 0.6 8.42937e-09 8.42937e-09 1.8550 0.975 0.15632 8.42937e-08 1 1 40.9436 0 22 226 2.4 8.42937e-09 8.42937e-09 1.8550 0.975 0.15632 8.42937e-08 1 1 40.9436 0 75 756 8.4 0.0025 0.0025 1.8550 1 0 1 1 0 30.9512 0 75 1000 11.1 0.0025 0.0025 1.8550 1 0 1 1 0 30.9512 0 INFO: searched 1000 iterations for 0.185833 hours INFO: 1.49477 iterations per second INFO: 997/1000 schedules were ill-conditioned outstem = test
I get:
NFO: searched 1000 iterations for 0.010556 hours INFO: 26.3158 iterations per second INFO: 1000/1000 schedules were ill-conditioned ERROR: all schedules found were ill-conditioned. This probably means that you need more scan time (ie, a greater number of time points) or fewer repetitions.
(I'm running on a macOS Mojave version 10.14.3. )
But it's obviously not the ntp that is the problem since I put an extra long time there that cover the event durations by far.
Is there any way I can troubleshoot more efficiently myself? The log file doesn't tell me anything.
Very happy for any advice,
All the best,
Katarina
Katarina Bendtz, Ph.D. (particle physics) Postdoctoral researcher in cognitive neuroscience Department of Psychology, Stockholm University
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edumailto:Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edumailto:Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edumailto:Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edumailto:Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
freesurfer@nmr.mgh.harvard.edu
-
Greve, Douglas N.,Ph.D. -
Katarina Bendtz