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:
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:
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.
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:
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.