Replication Multiplexing

Replication Multiplexing

This page will describe how replication multiplexing or RM is implemented


In an isobarically labelled experiment one might choose to represent their different replicates or conditions as different tags or rawfiles. This restricts the usual way of adding the experimental structure to PS and creates the need of a new more sophisticated way to do so. In case an isobarically labelled experiment is detected, the floating menu on raw files data table is populated with another option “Replication Multiplexing”. Hitting this button shows the ReplicationMultiplexingDialog. The structure of it in terms of HTML is described in the respective page. stepRM1 contains 3 pairs of radio boxes to allow the user to choose how their breps treps and conditions are represented. The buttons in the bottom are the same in all steps of RM: A screenshot of RM Hitting the next button will call onRMDialogNext_click. This function uses 3 global variables stepRM2initialized stepRM3initialized and RM_RMstep. In case we are in RM_RMstep 1, PS checks whether the steps 2 - 3 have already been initialized and in this case it makes sure that the step 1 options are set to the same values. This should be done because the user might get back to RM dialog box to alter the options in RM2 or RM3. In case RM1 is changed then the next steps should ne reinitialized and PS prompts the user if they really want this, otherwise, it resets the RM1 options to the initially chosen. If we are not in RM1 or we are there and the steps further were never initialized, onRMDialogNext_click simply executes the lines below:

RM_RMstep++;
showstepRMDialog();

to advance a step further. showstepRMDialog is quite complicated function that shows an RM step as needed. Showing RM1 is quite easy. Showing RM2 first validates that at least something is represented by the user’s tags (breps treps or conditions - lets call these RMarguments) and if this happens, it advances to RM2. First it parses the user’s options of how each RMargument is represented in 3 global variables: RMbrepsRepInRawFiles, RMtrepsRepInRawFiles and RMconditionsRepInRawFiles that are true/false. For example if RMconditionsRepInRawFiles is set to true then the conditions are represented as different raw files and not differenet tags. PS alters the prompt on the top of RM2 to suit the current needs and describe the procedure needed to complete RM2 by setting the infotodisplay variable. It then alters the interface of RM2 to suit the current needs. RM2 is responsible for setting the RM arguments to their respective rawfiles. RMrawfilesDT is a datatable initialized in proteosignInit that has 5 columns. 0 is the name, 1 is the brep, 2 is the trep, 3 is the frac and 4 is the condition. showstepRMDialog hides or shows the necessary columns depending on the users options in RM1. For example if the user chose to represent the treps in rawfiles the data table will be like this: A screenshot of RM The container in the bottom contains all necessary text boxes to assign breps treps and conditions to the rawfiles. In this case obviously only the trep box is shown. Assignment is done as usual and each time the Assign (btnAssignExpStructCoord) button is pressed the stepRM2Assign_click function is called. RM stores its data in 2 main variables, RMrawfilesdata and RMtagsdata. these are two dimension arrays that have 8 columns: counter, rawfilename, brep, trep, frac, cond, used, selected an example of RMrawfilesdata’s structure before setting it is:

// +---------+-----------------------------------------------------------+------+------+------+------+------+----------+
// | counter | rawfilename                                               | brep | trep | frac | cond | used | selected |
// +---------+-----------------------------------------------------------+------+------+------+------+------+----------+
// | 1       | M456-E04-O207-T87S1-T87S2-T87S3-T88S1-T88S2-T88S3-P5329-1 | -    | -    | -    | -    | true | false    |
// +---------+-----------------------------------------------------------+------+------+------+------+------+----------+
// | 2       | M456-D10-O207-T87S1-T87S2-T87S3-T88S1-T88S2-T88S3-P5329-1 | -    | -    | -    | -    | true | false    |
// +---------+-----------------------------------------------------------+------+------+------+------+------+----------+
// | 3       | M456-E08-O207-T87S1-T87S2-T87S3-T88S1-T88S2-T88S3-P5329-1 | -    | -    | -    | -    | true | false    |
// +---------+-----------------------------------------------------------+------+------+------+------+------+----------+
// | 4       | M456-C09-O207-T87S1-T87S2-T87S3-T88S1-T88S2-T88S3-P5329-1 | -    | -    | -    | -    | true | false    |
// +---------+-----------------------------------------------------------+------+------+------+------+------+----------+
// | 5       | M456-D05-O207-T87S1-T87S2-T87S3-T88S1-T88S2-T88S3-P5329-1 | -    | -    | -    | -    | true | false    |
// +---------+-----------------------------------------------------------+------+------+------+------+------+----------+

stepRM2Assign_click first changes the respective value in RMrawfilesdata calling the RM_set_row that takes 3 arguments, the name of the rawfile, the value and the index of the column in the table above. e.g. to change the state of “selected” to true of raw file “WTb12”, we write RM_set_row("WTb12", true, 7). RM_redraw_table gets all data from RMrawfilesdata using RM_get_row and redraws the RM table. RM_check_next_enable finaly checks if all necessary data in RM2 were set to move to RM3. If so it enables the next button. Hitting the next button will alter again the prompt and the interface to set the RMarguments to their respective tags. The RM data table is cleared and repopulated with the tags and its columns are hidden / shown to suit the current needs. A screenshot of RM3 All the tools in RM3 work exactly as in RM2. The smart part of it is that hitting the assign button calls again RM_set_row and this function is smart enough to now alter the RMtagsdata array and not the RMrawfilesdata. The same happens with RM_get_row that is used to redraw the RM data table so the same blocks of code in stepRM2Assign_click and RM_redraw_table do their job correctly by calling the same functions. RM_check_next_enable checks again if RM3 is ready and if so enables the next button. Hitting it will hide the dialog box and alter the interface of Step 2 making it seem like this: A screenshot of RM3 This is done by calling set_RMisused(true) that in fact hides the usual prompt in Step 2 and displays the container shown above that allows the user to show the RM dialog again (Review) or set RM to not used (calling set_RMisused(false) by hitting Undo) to review RM or get back to the usual experimental structure setting. When settin RM set_RMisused(true) also refreshes the conditions list executing RefreshConditionsList(RM_getRMconditions()); RM_getRMconditions gets all conditions contained in RMrawfilesdata or RMtagsdata - depending in the options of the user in RM1 - and populates the conditions list with them. In conclusion, the main goal of RM is to set the variables RMrawfilesdata and RMtagsdata properly. These variables will simply be sent to the server when performing the analysis and will be used there to analyse the data properly.