Millisecond Forums

Removing the noreplacenorepeat() in /stimulusframes has no bearing on how the respective stimulus elements (here: <picture> elements) sample their items. That's controlled by the stimulus elements' /select attributes (the default is random sampling without replacement, i.e. noreplace).

To illustrate the difference, take run this code:

<block myblock>
/ trials = [1-10  = mytrial]
</block>

<trial mytrial>
/ stimulusframes = [1=noreplace(a,b)]
/ validresponse = (57)
</trial>

<text a>
/ items = ("A1", "A2", "A3", "A4", "A5", "A6", "A7", "A8", "A9", "A10")
/ select = sequence
</text>

<text b>
/ items = ("B1", "B2", "B3", "B4", "B5", "B6", "B7", "B8", "B9", "B10")
/ select = sequence
</text>


Here,

/ stimulusframes = [1=noreplace(a,b)]

determines whether the trial _displays_ <text a> OR <text b>.

However, this has nothing to do with how <text a> or <text b> sample their items. Both, for illustration purposes here, sample items _sequentially_ per

/ select = sequence


I've also attached a revision of your script below with the redundant noreplacenorepeat() calls stripped out and the stimuli all displayed in the 1st frame.

Hi Dave,

Thank you so much for helping optimize the code, I am trying it now to see if the load is improved. 

However,since "noreplacenorepeat" is deleted from the stimulusframe, I wonder where random sampling of the pictures is going to happen? 

/ stimulusframes = [1= pairs40_50_f_r_pic, pairs40_50_m_l_pic, femalenames_right_cap, malenames_left_cap, address_left_cap, address_right_cap, occupation_right_cap, occupation_left_cap, statement_left_cap, statement_right_cap]

Best,
Alicia

Thanks for making the files available. A couple of things stand out as problematic with respect to unnecessarily consuming resources:
#1: Some of the image files are exceedingly large, much larger than you need them to be. For example
- IOWA_M_R_Chelgren.jpg with a size in excess of 7MB and a resolution of 3456 x 5184 pixels.
- IOWA_F_D_Ragan.jpg with a size in excess of 6.8MB and a resolution of 3456 x 5184 pixels.
- MI_M_R_Bumstead.jpg with a size in excess of 2MB and a resolution of 1750 x 2450 pixels.
- MI_F_R_Jenkins.jpg with a size in excess of 1.5MB and a resolution of 1750 x 2450 pixels.

I'd recommend resizing those files to be more in line with the remaining ones, which have sizes in the KB range (nowhere near 1MB) and resolutions in the area of 300 x 400 or so pixels. The extremely large images listed above will otherwise consume an inordinate amount of memory.

#2: There are various unnecessary complications in your <surveypage>s' /stimulusframes which can adversely affect performance when the system is already under strain. For example,

<surveypage f_m_40_50>
/ stimulusframes = [1= noreplacenorepeat(pairs40_50_f_r_pic);2= noreplacenorepeat(pairs40_50_m_l_pic) ; 3 = noreplacenorepeat(femalenames_right_cap); 4 = noreplacenorepeat(malenames_left_cap); 5 = noreplacenorepeat(address_left_cap); 6 = noreplacenorepeat(address_right_cap); 7= noreplacenorepeat(occupation_right_cap); 8 = noreplacenorepeat(occupation_left_cap); 9 = noreplacenorepeat(statement_left_cap);10 = noreplacenorepeat(statement_right_cap)]
/ caption = ""
/ fontstyle = ("Verdana", -16, true, false, false, false, 5, 0)
/ questions = [1=f_m_40_50; 1 =  pairs40_50_f_r; 1 =  pairs40_50_m_l;1 = femalenames_right;1 = malenames_left;1 = address_left;1=address_right;1 = occupation_right;1 = statement_left;1 = statement_right;1 = occupation_left]
/ nextbuttonposition = (93, 93)
/ finishlabel = "Next"
/ showpagenumbers = false
/ showquestionnumbers = false
</surveypage>

The noreplacenorepeat() calls are entirely unnecessary and don't serve any purpose / have no effect. All they do is create memory overhead and consume resources. Using a selection function only makes sense if there actually are several elements to select from, as in noreplacenorepeat(a,b).

noreplacenorepeat(a), on the other hand, is equivalent to simply stating a without any selection function -- there is only one element, namely "a", i.e. there is nothing to select from without replacement, and there is nothing that could repeat either.

Displaying the various stimuli in subsequent frames is similarly unnecessary, you can display them all in the 1st frame, which will put far less strain on the system. In other words, you can revise the above to read:

<surveypage f_m_40_50>
/ stimulusframes = [1= pairs40_50_f_r_pic, pairs40_50_m_l_pic, femalenames_right_cap, malenames_left_cap, address_left_cap, address_right_cap, occupation_right_cap, occupation_left_cap, statement_left_cap, statement_right_cap]
/ caption = ""
/ fontstyle = ("Verdana", -16, true, false, false, false, 5, 0)
/ questions = [1=f_m_40_50; 1 =  pairs40_50_f_r; 1 =  pairs40_50_m_l;1 = femalenames_right;1 = malenames_left;1 = address_left;1=address_right;1 = occupation_right;1 = statement_left;1 = statement_right;1 = occupation_left]
/ nextbuttonposition = (93, 93)
/ finishlabel = "Next"
/ showpagenumbers = false
/ showquestionnumbers = false
</surveypage>

without any change in the script's behavior while avoiding unnecessary overhead and resource consumption at the same time.

Hi Dave,
Thanks for offering me to look into this, this happens after you run the experiment more than a couple of times on my computer (Macbook pro Sierra OS). 
With all the pictures, think the file is a bit too big for the forum. Just in case I attached it in the dropbox link here: https://www.dropbox.com/s/hq7uuymhhugqzq1/ForDaveInquisit.zip?dl=0
~Alicia

Hmm, no idea offhand. The error doesn't sound like it's directly caused by the script, the error you cited originates from the underlying operating system and suggests it's running out of resources. Now, it is possible that your script is set up in such a way as to provoke that (i.e. there may be inefficiencies in the code which can be mitigated), but I'd have to see the actual script for that. Can you put the script and all files it requires (images, etc.) in a ZIP and attach it here? (Click +Insert -> Add File to attach files to a post)

Hi Dave,
Thanks a lot for your response! This does solve part of the problem. However, after I changed my survey into a block, my experiment won't run through. 

Specifically, it throws the error "random_device" failed to open dev/urandom: Too many open files".

This error would happen after 16-17 trials. I have tried dividing those trials to present in different blocks, and it doesn't seem to help. 

I wonder if you might have any insight into why this is happening?

Thanks,
Alicia

Those things are or can be captured when you run your <surveypage>s as /trials in a <block> instead of running them as /pages via a <survey> element:

<block myblock>
/ trials = [1-3 = mypage]
</block>

<surveypage mypage>
/ stimulusframes = [1=a, b, c]
/ questions = [1=myquestion]
</surveypage>

<text a>
/ items = ("A1", "A2", "A3")
/ position = (40%, 50%)
</text>

<text b>
/ items = ("B1", "B2", "B3")
/ position = (50%, 50%)
</text>

<text c>
/ items = ("C1", "C2", "C3")
/ position = (60%, 50%)
</text>

<radiobuttons myquestion>
/ options = ("A", "B", "C")
/ orientation = horizontal
/ position = (45%,75%)
</radiobuttons>

The information is captured in the stimulusitem columns of the resulting raw data file (see the attached data file generated with the above code).

If you have a <data> element with /columns specified in your script, make sure to include a sufficient amount of stimulusitem columns to capture all the stimuli presented in the /stimulusframes sequence (you would need at least 10 given your <surveypage>'s /stimulusframes).