Millisecond Forums

Batch File Crashing

https://forums.millisecond.com/Topic25055.aspx

By desiree80 - 6/8/2018

We have about 7-8 Inquisit tests we would like to administer back to back. The problem our team is having is figuring out why the batch file crashes after the third test. I have attached the batch file below ( you will have to change the file directories). The box link is a copy of our stimuli and tests. 


Link with files: https://usf.box.com/s/ftzziiym26jdwl412hgxnwy0a8viuua2

Let me know if you need any other information! I cannot help but feel that the solution is something simple that I've overlooked. Thanks for your help. 
By desiree80 - 6/8/2018

https://www.millisecond.com/forums/Uploads/Images/3ea087aa-9b8a-4ab5-ac79-8704.png

These are the errors we are getting. 
By Dave - 6/8/2018

desiree80 - Friday, June 8, 2018
https://www.millisecond.com/forums/Uploads/Images/3ea087aa-9b8a-4ab5-ac79-8704.png

These are the errors we are getting. 

These errors point to an issue with the 4th script. Specifically, it points to a graphics issue. Reasons could be:
- Some misspecification of stimulus size / position, or canvas size position in the 3rd or 4th script.
- An issue with the system's display driver.
- The system running out of graphics memory.

I'm having trouble locating the relevant files in the Box link you posted since there's so much extraneous stuff.

Would it be possible for you to just upload a _clean_ copy somewhere, i.e. just the batch script, the scripts (+ any files the scripts require such as images) the batch attempts to run, all in the expected directory structure with names etc. matching what's in the batch? Please leave out all extraneous stuff such as Word or Excel documents, data files, and other scripts not required by the batch at issue. Thanks.
By jmwotw - 6/9/2018

Dave - Friday, June 8, 2018
desiree80 - Friday, June 8, 2018
https://www.millisecond.com/forums/Uploads/Images/3ea087aa-9b8a-4ab5-ac79-8704.png

These are the errors we are getting. 

These errors point to an issue with the 4th script. Specifically, it points to a graphics issue. Reasons could be:
- Some misspecification of stimulus size / position, or canvas size position in the 3rd or 4th script.
- An issue with the system's display driver.
- The system running out of graphics memory.

I'm having trouble locating the relevant files in the Box link you posted since there's so much extraneous stuff.

Would it be possible for you to just upload a _clean_ copy somewhere, i.e. just the batch script, the scripts (+ any files the scripts require such as images) the batch attempts to run, all in the expected directory structure with names etc. matching what's in the batch? Please leave out all extraneous stuff such as Word or Excel documents, data files, and other scripts not required by the batch at issue. Thanks.

Sorry for the mess, Dave. It's all cleaned out now, and the batch file is also in the root folder. Thanks! 

Jeff

By jmwotw - 6/9/2018

We've been doing some testing and figured out a few things.
  • The batch file seems to work if you remove the EMATHFR test from the batch code, which is the only test that uses a second monitor. Currently, we're using this monitor
  • If you run the EMATHFR code by itself, it also seems to work, but embedding it in the middle of the test like it is now does not. 
  • If you start the test with EMATHFR (IDInfo is a one-pager that we don't remove because it's where we input the batch-level parameter, age), then it will run and so will the remaining tests.
Not sure if this gives you any clues, but I wanted to let you know what we've learned in case it helps. 

Thanks,
Jeff

By Dave - 6/11/2018

jmwotw - Saturday, June 9, 2018
We've been doing some testing and figured out a few things.
  • The batch file seems to work if you remove the EMATHFR test from the batch code, which is the only test that uses a second monitor. Currently, we're using this monitor
  • If you run the EMATHFR code by itself, it also seems to work, but embedding it in the middle of the test like it is now does not. 
  • If you start the test with EMATHFR (IDInfo is a one-pager that we don't remove because it's where we input the batch-level parameter, age), then it will run and so will the remaining tests.
Not sure if this gives you any clues, but I wanted to let you know what we've learned in case it helps. 

Thanks,
Jeff


Thanks, this is very helpful. Based on what you describe, the switch from single-monitor to dual-monitor in the middle of things is what throws things off (not sure yet whether the problem originates in Inquisit itself or the graphics card driver refusing to switch / returning an error).

A workaround might be to put a small script that uses both monitors at the very start of the batch -- that script need not do anything, need not take any input or last long (it can just time out after a second or two). I'll be looking into your files later on (the download is taking a while) and let you know what I find.
By jmwotw - 6/12/2018

Dave - Monday, June 11, 2018
jmwotw - Saturday, June 9, 2018
We've been doing some testing and figured out a few things.
  • The batch file seems to work if you remove the EMATHFR test from the batch code, which is the only test that uses a second monitor. Currently, we're using this monitor
  • If you run the EMATHFR code by itself, it also seems to work, but embedding it in the middle of the test like it is now does not. 
  • If you start the test with EMATHFR (IDInfo is a one-pager that we don't remove because it's where we input the batch-level parameter, age), then it will run and so will the remaining tests.
Not sure if this gives you any clues, but I wanted to let you know what we've learned in case it helps. 

Thanks,
Jeff


Thanks, this is very helpful. Based on what you describe, the switch from single-monitor to dual-monitor in the middle of things is what throws things off (not sure yet whether the problem originates in Inquisit itself or the graphics card driver refusing to switch / returning an error).

A workaround might be to put a small script that uses both monitors at the very start of the batch -- that script need not do anything, need not take any input or last long (it can just time out after a second or two). I'll be looking into your files later on (the download is taking a while) and let you know what I find.

We tried to add a second monitor to our first file (IDInfo), and I'm afraid that didn't work. 
By desiree80 - 6/18/2018

Dave - Monday, June 11, 2018
jmwotw - Saturday, June 9, 2018
We've been doing some testing and figured out a few things.
  • The batch file seems to work if you remove the EMATHFR test from the batch code, which is the only test that uses a second monitor. Currently, we're using this monitor
  • If you run the EMATHFR code by itself, it also seems to work, but embedding it in the middle of the test like it is now does not. 
  • If you start the test with EMATHFR (IDInfo is a one-pager that we don't remove because it's where we input the batch-level parameter, age), then it will run and so will the remaining tests.
Not sure if this gives you any clues, but I wanted to let you know what we've learned in case it helps. 

Thanks,
Jeff


Thanks, this is very helpful. Based on what you describe, the switch from single-monitor to dual-monitor in the middle of things is what throws things off (not sure yet whether the problem originates in Inquisit itself or the graphics card driver refusing to switch / returning an error).

A workaround might be to put a small script that uses both monitors at the very start of the batch -- that script need not do anything, need not take any input or last long (it can just time out after a second or two). I'll be looking into your files later on (the download is taking a while) and let you know what I find.

Hi Dave, 
Would you happen to know anything about batch file discrepancies between different types of computers (if that even exists)? At the moment our batch file runs through most of the files when we run it on our desktops. However, on our surface pros they crash somewhere in the middle. Let me know if you have any ideas, thank you!
By Dave - 6/18/2018

desiree80 - Monday, June 18, 2018
Dave - Monday, June 11, 2018
jmwotw - Saturday, June 9, 2018
We've been doing some testing and figured out a few things.
  • The batch file seems to work if you remove the EMATHFR test from the batch code, which is the only test that uses a second monitor. Currently, we're using this monitor
  • If you run the EMATHFR code by itself, it also seems to work, but embedding it in the middle of the test like it is now does not. 
  • If you start the test with EMATHFR (IDInfo is a one-pager that we don't remove because it's where we input the batch-level parameter, age), then it will run and so will the remaining tests.
Not sure if this gives you any clues, but I wanted to let you know what we've learned in case it helps. 

Thanks,
Jeff


Thanks, this is very helpful. Based on what you describe, the switch from single-monitor to dual-monitor in the middle of things is what throws things off (not sure yet whether the problem originates in Inquisit itself or the graphics card driver refusing to switch / returning an error).

A workaround might be to put a small script that uses both monitors at the very start of the batch -- that script need not do anything, need not take any input or last long (it can just time out after a second or two). I'll be looking into your files later on (the download is taking a while) and let you know what I find.

Hi Dave, 
Would you happen to know anything about batch file discrepancies between different types of computers (if that even exists)? At the moment our batch file runs through most of the files when we run it on our desktops. However, on our surface pros they crash somewhere in the middle. Let me know if you have any ideas, thank you!

Assuming the scripts are those available under the Box link, the only thing I can think of would be resource-exhaustion on the Surface Pros. The scripts involve lots and lots of files, so I can imagine that the Surface devices *might* for example run out of memory somewhere along the way whereas more powerful desktop machines can cope with the overall load. Can you give me a better sense of when / where crashes occur, i.e. is it always during a particular script or even a particular trial or block in a script, or does it seem somewhat random, i.e. sometimes happens sooner in script X, other times it happens later in a different script Y? The latter would support the idea that the Surface devices can't quite cope with the combined load imposed by the scripts.
By jmwotw - 6/18/2018

Dave - Monday, June 18, 2018
desiree80 - Monday, June 18, 2018
Dave - Monday, June 11, 2018
jmwotw - Saturday, June 9, 2018
We've been doing some testing and figured out a few things.
  • The batch file seems to work if you remove the EMATHFR test from the batch code, which is the only test that uses a second monitor. Currently, we're using this monitor
  • If you run the EMATHFR code by itself, it also seems to work, but embedding it in the middle of the test like it is now does not. 
  • If you start the test with EMATHFR (IDInfo is a one-pager that we don't remove because it's where we input the batch-level parameter, age), then it will run and so will the remaining tests.
Not sure if this gives you any clues, but I wanted to let you know what we've learned in case it helps. 

Thanks,
Jeff


Thanks, this is very helpful. Based on what you describe, the switch from single-monitor to dual-monitor in the middle of things is what throws things off (not sure yet whether the problem originates in Inquisit itself or the graphics card driver refusing to switch / returning an error).

A workaround might be to put a small script that uses both monitors at the very start of the batch -- that script need not do anything, need not take any input or last long (it can just time out after a second or two). I'll be looking into your files later on (the download is taking a while) and let you know what I find.

Hi Dave, 
Would you happen to know anything about batch file discrepancies between different types of computers (if that even exists)? At the moment our batch file runs through most of the files when we run it on our desktops. However, on our surface pros they crash somewhere in the middle. Let me know if you have any ideas, thank you!

Assuming the scripts are those available under the Box link, the only thing I can think of would be resource-exhaustion on the Surface Pros. The scripts involve lots and lots of files, so I can imagine that the Surface devices *might* for example run out of memory somewhere along the way whereas more powerful desktop machines can cope with the overall load. Can you give me a better sense of when / where crashes occur, i.e. is it always during a particular script or even a particular trial or block in a script, or does it seem somewhat random, i.e. sometimes happens sooner in script X, other times it happens later in a different script Y? The latter would support the idea that the Surface devices can't quite cope with the combined load imposed by the scripts.

I think you're right, Dave. We were just about to post with some tests we've run. When we first posted, the script would run if only MATHFR were removed. We added a very small script at the end to collect the timing of the last test, and that was too much. So we then tried breaking up the batch file even further; roughly half of the tests in one batch, half in another, and MATHFR by itself. So far, this is the only way that it works. Am I understanding correctly that Inquisit needs memory for the entire series of tests, not just the one it is currently running? This is unfortunate because one of the key reasons why we purchased Inquisit 5 was for the ability to pass a common, randomly-generated code across all tests administered during a batch. Every time we break up the batch file means it's harder to merge a participant's individual tests back together when there's a problem with the subject id. 

By Dave - 6/18/2018

jmwotw - Monday, June 18, 2018
Dave - Monday, June 18, 2018
desiree80 - Monday, June 18, 2018
Dave - Monday, June 11, 2018
jmwotw - Saturday, June 9, 2018
We've been doing some testing and figured out a few things.
  • The batch file seems to work if you remove the EMATHFR test from the batch code, which is the only test that uses a second monitor. Currently, we're using this monitor
  • If you run the EMATHFR code by itself, it also seems to work, but embedding it in the middle of the test like it is now does not. 
  • If you start the test with EMATHFR (IDInfo is a one-pager that we don't remove because it's where we input the batch-level parameter, age), then it will run and so will the remaining tests.
Not sure if this gives you any clues, but I wanted to let you know what we've learned in case it helps. 

Thanks,
Jeff


Thanks, this is very helpful. Based on what you describe, the switch from single-monitor to dual-monitor in the middle of things is what throws things off (not sure yet whether the problem originates in Inquisit itself or the graphics card driver refusing to switch / returning an error).

A workaround might be to put a small script that uses both monitors at the very start of the batch -- that script need not do anything, need not take any input or last long (it can just time out after a second or two). I'll be looking into your files later on (the download is taking a while) and let you know what I find.

Hi Dave, 
Would you happen to know anything about batch file discrepancies between different types of computers (if that even exists)? At the moment our batch file runs through most of the files when we run it on our desktops. However, on our surface pros they crash somewhere in the middle. Let me know if you have any ideas, thank you!

Assuming the scripts are those available under the Box link, the only thing I can think of would be resource-exhaustion on the Surface Pros. The scripts involve lots and lots of files, so I can imagine that the Surface devices *might* for example run out of memory somewhere along the way whereas more powerful desktop machines can cope with the overall load. Can you give me a better sense of when / where crashes occur, i.e. is it always during a particular script or even a particular trial or block in a script, or does it seem somewhat random, i.e. sometimes happens sooner in script X, other times it happens later in a different script Y? The latter would support the idea that the Surface devices can't quite cope with the combined load imposed by the scripts.

I think you're right, Dave. We were just about to post with some tests we've run. When we first posted, the script would run if only MATHFR were removed. We added a very small script at the end to collect the timing of the last test, and that was too much. So we then tried breaking up the batch file even further; roughly half of the tests in one batch, half in another, and MATHFR by itself. So far, this is the only way that it works. Am I understanding correctly that Inquisit needs memory for the entire series of tests, not just the one it is currently running? This is unfortunate because one of the key reasons why we purchased Inquisit 5 was for the ability to pass a common, randomly-generated code across all tests administered during a batch. Every time we break up the batch file means it's harder to merge a participant's individual tests back together when there's a problem with the subject id. 


While memory is *mostly* consumed by the currently running script, running several scripts via <batch> causes some additional overhead -- the <batch> script runs in its own thread, has to keep track of things (which script is currently running, is it over, which script is next, etc.?) and the <batch> element also needs to preserve some state beyond that for <batch> <parameters> and <values> used to pass information from script to script.

If you can forego the <paramaters> and <values>, you could get rid of the <batch> and its overhead and execute your script's via a command line script instead -- that command line script could generate a random subject ID which would be identical across all scripts it executes, and thus allow for relatively easy data matching and merging of all tests as before. Since technically Inquisit would shut down briefly between scripts and would not need to keep <batch> state and do housekeeping, the memory consumption overall should be lower.

https://www.millisecond.com/support/docs/v5/html/howto/howtocommandline.htm

https://www.millisecond.com/support/docs/v5/html/articles/batchscripts.htm

Might that be an option?
By jmwotw - 6/20/2018

Dave - Monday, June 18, 2018
jmwotw - Monday, June 18, 2018
Dave - Monday, June 18, 2018
desiree80 - Monday, June 18, 2018
Dave - Monday, June 11, 2018
jmwotw - Saturday, June 9, 2018
We've been doing some testing and figured out a few things.
  • The batch file seems to work if you remove the EMATHFR test from the batch code, which is the only test that uses a second monitor. Currently, we're using this monitor
  • If you run the EMATHFR code by itself, it also seems to work, but embedding it in the middle of the test like it is now does not. 
  • If you start the test with EMATHFR (IDInfo is a one-pager that we don't remove because it's where we input the batch-level parameter, age), then it will run and so will the remaining tests.
Not sure if this gives you any clues, but I wanted to let you know what we've learned in case it helps. 

Thanks,
Jeff


Thanks, this is very helpful. Based on what you describe, the switch from single-monitor to dual-monitor in the middle of things is what throws things off (not sure yet whether the problem originates in Inquisit itself or the graphics card driver refusing to switch / returning an error).

A workaround might be to put a small script that uses both monitors at the very start of the batch -- that script need not do anything, need not take any input or last long (it can just time out after a second or two). I'll be looking into your files later on (the download is taking a while) and let you know what I find.

Hi Dave, 
Would you happen to know anything about batch file discrepancies between different types of computers (if that even exists)? At the moment our batch file runs through most of the files when we run it on our desktops. However, on our surface pros they crash somewhere in the middle. Let me know if you have any ideas, thank you!

Assuming the scripts are those available under the Box link, the only thing I can think of would be resource-exhaustion on the Surface Pros. The scripts involve lots and lots of files, so I can imagine that the Surface devices *might* for example run out of memory somewhere along the way whereas more powerful desktop machines can cope with the overall load. Can you give me a better sense of when / where crashes occur, i.e. is it always during a particular script or even a particular trial or block in a script, or does it seem somewhat random, i.e. sometimes happens sooner in script X, other times it happens later in a different script Y? The latter would support the idea that the Surface devices can't quite cope with the combined load imposed by the scripts.

I think you're right, Dave. We were just about to post with some tests we've run. When we first posted, the script would run if only MATHFR were removed. We added a very small script at the end to collect the timing of the last test, and that was too much. So we then tried breaking up the batch file even further; roughly half of the tests in one batch, half in another, and MATHFR by itself. So far, this is the only way that it works. Am I understanding correctly that Inquisit needs memory for the entire series of tests, not just the one it is currently running? This is unfortunate because one of the key reasons why we purchased Inquisit 5 was for the ability to pass a common, randomly-generated code across all tests administered during a batch. Every time we break up the batch file means it's harder to merge a participant's individual tests back together when there's a problem with the subject id. 


While memory is *mostly* consumed by the currently running script, running several scripts via <batch> causes some additional overhead -- the <batch> script runs in its own thread, has to keep track of things (which script is currently running, is it over, which script is next, etc.?) and the <batch> element also needs to preserve some state beyond that for <batch> <parameters> and <values> used to pass information from script to script.

If you can forego the <paramaters> and <values>, you could get rid of the <batch> and its overhead and execute your script's via a command line script instead -- that command line script could generate a random subject ID which would be identical across all scripts it executes, and thus allow for relatively easy data matching and merging of all tests as before. Since technically Inquisit would shut down briefly between scripts and would not need to keep <batch> state and do housekeeping, the memory consumption overall should be lower.

https://www.millisecond.com/support/docs/v5/html/howto/howtocommandline.htm

https://www.millisecond.com/support/docs/v5/html/articles/batchscripts.htm

Might that be an option?


By jmwotw - 6/20/2018

jmwotw - Wednesday, June 20, 2018
Dave - Monday, June 18, 2018
jmwotw - Monday, June 18, 2018
Dave - Monday, June 18, 2018
desiree80 - Monday, June 18, 2018
Dave - Monday, June 11, 2018
jmwotw - Saturday, June 9, 2018
We've been doing some testing and figured out a few things.
  • The batch file seems to work if you remove the EMATHFR test from the batch code, which is the only test that uses a second monitor. Currently, we're using this monitor
  • If you run the EMATHFR code by itself, it also seems to work, but embedding it in the middle of the test like it is now does not. 
  • If you start the test with EMATHFR (IDInfo is a one-pager that we don't remove because it's where we input the batch-level parameter, age), then it will run and so will the remaining tests.
Not sure if this gives you any clues, but I wanted to let you know what we've learned in case it helps. 

Thanks,
Jeff


Thanks, this is very helpful. Based on what you describe, the switch from single-monitor to dual-monitor in the middle of things is what throws things off (not sure yet whether the problem originates in Inquisit itself or the graphics card driver refusing to switch / returning an error).

A workaround might be to put a small script that uses both monitors at the very start of the batch -- that script need not do anything, need not take any input or last long (it can just time out after a second or two). I'll be looking into your files later on (the download is taking a while) and let you know what I find.

Hi Dave, 
Would you happen to know anything about batch file discrepancies between different types of computers (if that even exists)? At the moment our batch file runs through most of the files when we run it on our desktops. However, on our surface pros they crash somewhere in the middle. Let me know if you have any ideas, thank you!

Assuming the scripts are those available under the Box link, the only thing I can think of would be resource-exhaustion on the Surface Pros. The scripts involve lots and lots of files, so I can imagine that the Surface devices *might* for example run out of memory somewhere along the way whereas more powerful desktop machines can cope with the overall load. Can you give me a better sense of when / where crashes occur, i.e. is it always during a particular script or even a particular trial or block in a script, or does it seem somewhat random, i.e. sometimes happens sooner in script X, other times it happens later in a different script Y? The latter would support the idea that the Surface devices can't quite cope with the combined load imposed by the scripts.

I think you're right, Dave. We were just about to post with some tests we've run. When we first posted, the script would run if only MATHFR were removed. We added a very small script at the end to collect the timing of the last test, and that was too much. So we then tried breaking up the batch file even further; roughly half of the tests in one batch, half in another, and MATHFR by itself. So far, this is the only way that it works. Am I understanding correctly that Inquisit needs memory for the entire series of tests, not just the one it is currently running? This is unfortunate because one of the key reasons why we purchased Inquisit 5 was for the ability to pass a common, randomly-generated code across all tests administered during a batch. Every time we break up the batch file means it's harder to merge a participant's individual tests back together when there's a problem with the subject id. 


While memory is *mostly* consumed by the currently running script, running several scripts via <batch> causes some additional overhead -- the <batch> script runs in its own thread, has to keep track of things (which script is currently running, is it over, which script is next, etc.?) and the <batch> element also needs to preserve some state beyond that for <batch> <parameters> and <values> used to pass information from script to script.

If you can forego the <paramaters> and <values>, you could get rid of the <batch> and its overhead and execute your script's via a command line script instead -- that command line script could generate a random subject ID which would be identical across all scripts it executes, and thus allow for relatively easy data matching and merging of all tests as before. Since technically Inquisit would shut down briefly between scripts and would not need to keep <batch> state and do housekeeping, the memory consumption overall should be lower.

https://www.millisecond.com/support/docs/v5/html/howto/howtocommandline.htm

https://www.millisecond.com/support/docs/v5/html/articles/batchscripts.htm

Might that be an option?



Thanks, Dave. We've looked into the strategies you've proposed, and although they solve the multiple experiment in a row problem, we just don't think they're feasible for us. This is primarily because our participants are young children and the people who administer the tests to these children have a wide-ranging ability level in technology. Therefore, using command line and batch capabilities just isn't an option. 

Furthermore, we were really hoping that Inquisit 5's new batch file capabilities would solve a couple of issues for us. Most importantly, due to human error with our examiners, we end up with a sizable number of mis-entered subject IDs. This is bound to happen in research with many subjects, but when you have several duplicate subject IDs, it would be nice to have an additional ID that joined the various tests during an assessment. We were hoping to add a randomly-generated assessment ID to complement the subject ID that would persist across all of the scripts of a batch file. Therefore, even if someone mis-entered child #3's subject id as 4 so that we had two assessments with subjectid=4, then we could at least easily keep the multiple tests from each one separate. This would facilitate all of the data merging on the back end. 

Also, I'm a little surprised at the overhead of the batch file. We're only running about 7-8 tests, and the parameters we're trying to use across scripts is minimal so it's hard for me to understand how it might take up a lot of memory. Given our testing results, it seems like the memory load is increasingly roughly linearly with the number of scripts we add to the batch file and the number of files associated with each script, as if it's trying to load all of the files at one time, instead of one at a time. At the present moment, given the number of items we have, there doesn't seem to be a way to administer all of the scripts back-to-back. Instead we have to break up the batch files into 2-3 parts, which eliminates the benefits of an assessment ID to join scripts from the same assessment session. 

I hope this makes sense.

Jeff


By Dave - 6/20/2018

jmwotw - Wednesday, June 20, 2018

Thanks, Dave. We've looked into the strategies you've proposed, and although they solve the multiple experiment in a row problem, we just don't think they're feasible for us. This is primarily because our participants are young children and the people who administer the tests to these children have a wide-ranging ability level in technology. Therefore, using command line and batch capabilities just isn't an option. 

Furthermore, we were really hoping that Inquisit 5's new batch file capabilities would solve a couple of issues for us. Most importantly, due to human error with our examiners, we end up with a sizable number of mis-entered subject IDs. This is bound to happen in research with many subjects, but when you have several duplicate subject IDs, it would be nice to have an additional ID that joined the various tests during an assessment. We were hoping to add a randomly-generated assessment ID to complement the subject ID that would persist across all of the scripts of a batch file. Therefore, even if someone mis-entered child #3's subject id as 4 so that we had two assessments with subjectid=4, then we could at least easily keep the multiple tests from each one separate. This would facilitate all of the data merging on the back end. 

Also, I'm a little surprised at the overhead of the batch file. We're only running about 7-8 tests, and the parameters we're trying to use across scripts is minimal so it's hard for me to understand how it might take up a lot of memory. Given our testing results, it seems like the memory load is increasingly roughly linearly with the number of scripts we add to the batch file and the number of files associated with each script, as if it's trying to load all of the files at one time, instead of one at a time. At the present moment, given the number of items we have, there doesn't seem to be a way to administer all of the scripts back-to-back. Instead we have to break up the batch files into 2-3 parts, which eliminates the benefits of an assessment ID to join scripts from the same assessment session. 

I hope this makes sense.

Jeff



The <batch> overhead isn't huge, but when you have a system that's already operating near its limit resource-wise (because, among other things the scripts themselves are relatively demanding / resource-heavy), even small things can make a difference (such as e.g. adding one more script; cf. https://www.millisecond.com/forums/FindPost25111.aspx ). One possible strategy might be to make the scripts themselves a little less resource heavy; for example, you could try using MP3s in conjunction with <video> elements instead of relatively large WAVs in conjunction with <sound> elements. Avoiding massive image rescaling can also save considerable amounts of memory, i.e. you could try converting any images to a resolution near where it needs to be instead of relying on Inquisit to scale e.g. a high-resolution image down to fit a relatively small space on the screen. I haven't reviewed all the images involved in your scripts enough to really say whether there is much to be gained in this particular case, but at least the MP3 vs WAV modification seems worthwhile and may well make a noticeable difference.
By Dave - 6/20/2018

Dave - Wednesday, June 20, 2018
jmwotw - Wednesday, June 20, 2018

Thanks, Dave. We've looked into the strategies you've proposed, and although they solve the multiple experiment in a row problem, we just don't think they're feasible for us. This is primarily because our participants are young children and the people who administer the tests to these children have a wide-ranging ability level in technology. Therefore, using command line and batch capabilities just isn't an option. 

Furthermore, we were really hoping that Inquisit 5's new batch file capabilities would solve a couple of issues for us. Most importantly, due to human error with our examiners, we end up with a sizable number of mis-entered subject IDs. This is bound to happen in research with many subjects, but when you have several duplicate subject IDs, it would be nice to have an additional ID that joined the various tests during an assessment. We were hoping to add a randomly-generated assessment ID to complement the subject ID that would persist across all of the scripts of a batch file. Therefore, even if someone mis-entered child #3's subject id as 4 so that we had two assessments with subjectid=4, then we could at least easily keep the multiple tests from each one separate. This would facilitate all of the data merging on the back end. 

Also, I'm a little surprised at the overhead of the batch file. We're only running about 7-8 tests, and the parameters we're trying to use across scripts is minimal so it's hard for me to understand how it might take up a lot of memory. Given our testing results, it seems like the memory load is increasingly roughly linearly with the number of scripts we add to the batch file and the number of files associated with each script, as if it's trying to load all of the files at one time, instead of one at a time. At the present moment, given the number of items we have, there doesn't seem to be a way to administer all of the scripts back-to-back. Instead we have to break up the batch files into 2-3 parts, which eliminates the benefits of an assessment ID to join scripts from the same assessment session. 

I hope this makes sense.

Jeff



The <batch> overhead isn't huge, but when you have a system that's already operating near its limit resource-wise (because, among other things the scripts themselves are relatively demanding / resource-heavy), even small things can make a difference (such as e.g. adding one more script; cf. https://www.millisecond.com/forums/FindPost25111.aspx ). One possible strategy might be to make the scripts themselves a little less resource heavy; for example, you could try using MP3s in conjunction with <video> elements instead of relatively large WAVs in conjunction with <sound> elements. Avoiding massive image rescaling can also save considerable amounts of memory, i.e. you could try converting any images to a resolution near where it needs to be instead of relying on Inquisit to scale e.g. a high-resolution image down to fit a relatively small space on the screen. I haven't reviewed all the images involved in your scripts enough to really say whether there is much to be gained in this particular case, but at least the MP3 vs WAV modification seems worthwhile and may well make a noticeable difference.

To add, I do think the issues and demands (random assessment code independent of the subject ID as a data matching fall-back) are solvable via a command line script, too. That command line script can be made relatively user-friendly and pretty, requiring no more than a double-click to execute essentially. It would then prompt the experimenter to enter a subject and group ID as usual. To generate the fall-back assessment code, the command line script could generate a random number (just like your <batch> does currently) write that to a small file, and that file could then be <include>d in all the actual scripts, i.e. the assessment code would be present in and consistent across all the participant's data files.

I'll see if I can code up a small demo of the above a little later today and post it here to better illustrate what I mean.
By Dave - 6/20/2018

Dave - Wednesday, June 20, 2018
Dave - Wednesday, June 20, 2018
jmwotw - Wednesday, June 20, 2018

Thanks, Dave. We've looked into the strategies you've proposed, and although they solve the multiple experiment in a row problem, we just don't think they're feasible for us. This is primarily because our participants are young children and the people who administer the tests to these children have a wide-ranging ability level in technology. Therefore, using command line and batch capabilities just isn't an option. 

Furthermore, we were really hoping that Inquisit 5's new batch file capabilities would solve a couple of issues for us. Most importantly, due to human error with our examiners, we end up with a sizable number of mis-entered subject IDs. This is bound to happen in research with many subjects, but when you have several duplicate subject IDs, it would be nice to have an additional ID that joined the various tests during an assessment. We were hoping to add a randomly-generated assessment ID to complement the subject ID that would persist across all of the scripts of a batch file. Therefore, even if someone mis-entered child #3's subject id as 4 so that we had two assessments with subjectid=4, then we could at least easily keep the multiple tests from each one separate. This would facilitate all of the data merging on the back end. 

Also, I'm a little surprised at the overhead of the batch file. We're only running about 7-8 tests, and the parameters we're trying to use across scripts is minimal so it's hard for me to understand how it might take up a lot of memory. Given our testing results, it seems like the memory load is increasingly roughly linearly with the number of scripts we add to the batch file and the number of files associated with each script, as if it's trying to load all of the files at one time, instead of one at a time. At the present moment, given the number of items we have, there doesn't seem to be a way to administer all of the scripts back-to-back. Instead we have to break up the batch files into 2-3 parts, which eliminates the benefits of an assessment ID to join scripts from the same assessment session. 

I hope this makes sense.

Jeff



The <batch> overhead isn't huge, but when you have a system that's already operating near its limit resource-wise (because, among other things the scripts themselves are relatively demanding / resource-heavy), even small things can make a difference (such as e.g. adding one more script; cf. https://www.millisecond.com/forums/FindPost25111.aspx ). One possible strategy might be to make the scripts themselves a little less resource heavy; for example, you could try using MP3s in conjunction with <video> elements instead of relatively large WAVs in conjunction with <sound> elements. Avoiding massive image rescaling can also save considerable amounts of memory, i.e. you could try converting any images to a resolution near where it needs to be instead of relying on Inquisit to scale e.g. a high-resolution image down to fit a relatively small space on the screen. I haven't reviewed all the images involved in your scripts enough to really say whether there is much to be gained in this particular case, but at least the MP3 vs WAV modification seems worthwhile and may well make a noticeable difference.

To add, I do think the issues and demands (random assessment code independent of the subject ID as a data matching fall-back) are solvable via a command line script, too. That command line script can be made relatively user-friendly and pretty, requiring no more than a double-click to execute essentially. It would then prompt the experimenter to enter a subject and group ID as usual. To generate the fall-back assessment code, the command line script could generate a random number (just like your <batch> does currently) write that to a small file, and that file could then be <include>d in all the actual scripts, i.e. the assessment code would be present in and consistent across all the participant's data files.

I'll see if I can code up a small demo of the above a little later today and post it here to better illustrate what I mean.

So here's a small example. The CMD file could look along the following lines:

@echo off
set INQUISITPATH="C:\Program Files\Millisecond Software\Inquisit 5\Inquisit.exe"
set SCRIPT_1_PATH="C:\Users\David\Desktop\example\iat\iat.iqx"
set SCRIPT_2_PATH="C:\Users\David\Desktop\example\spr\spr.iqx"

set /p SID=Enter subject ID:
set /p GID=Enter group ID:

set /a CODE=%RANDOM%

@echo ^<values^> > code.txt
@echo /code = %CODE% >> code.txt
@echo ^</values^> >> code.txt

start "" /wait %INQUISITPATH% %SCRIPT_1_PATH% -s %SID% -g %GID%
start "" /wait %INQUISITPATH% %SCRIPT_2_PATH% -s %SID% -g %GID%


At the top the path to the Inquisit executable is defined, and then the paths for the respective scripts that are supposed to be executed (here: just two for the sake of simplicity).

set INQUISITPATH="C:\Program Files\Millisecond Software\Inquisit 5\Inquisit.exe"
set SCRIPT_1_PATH="C:\Users\David\Desktop\example\iat\iat.iqx"
set SCRIPT_2_PATH="C:\Users\David\Desktop\example\spr\spr.iqx"

Then the file prompts the experimenter for both the subject and group number.

set /p SID=Enter subject ID:
set /p GID=Enter group ID:

Then a random number is generated and the result is written to a file:

set /a CODE=%RANDOM%

@echo ^<values^> > code.txt
@echo /code = %CODE% >> code.txt
@echo ^</values^> >> code.txt

The contents resulting file "code.txt" would look like this, for example:

<values>
/code = 1120
</values>

Then the script fires up the actual scripts in order, passing in the subject and group id

start "" /wait %INQUISITPATH% %SCRIPT_1_PATH% -s %SID% -g %GID%
start "" /wait %INQUISITPATH% %SCRIPT_2_PATH% -s %SID% -g %GID%

The randomly generated code.txt is <include>d by the scripts per

<include>
/ file = "C:\Users\David\Desktop\example\code.txt"
</include>

and values.code is logged to all data file.

I'm attaching the full example files below, if you would like to run it on your system, you would have to adjust the file paths accordingly first. (It's of course possible to have the command line script do even more, but hopefully this relatively small / simple example is sufficient to determine whether something like this may be viable for your purposes.)