search

saezlab / CARNIVAL

CAusal Reasoning for Network Identification with integer VALue programming in R
https://saezlab.github.io/CARNIVAL/
57 stars 29 forks source link

[exportResult.R] ZeroAct column missed some values #6

Closed ptrairatphisan closed 5 years ago

ptrairatphisan commented 5 years ago

We observed in the result file 'nodesAttributes_i.txt' that the sum of percentage from 'ZeroAct', 'UpAct' and 'DownAct' columns is not always 100(%). A careful inspection revealed that this issue seems to be arisen from the column 'ZeroAct' and not the other two as the values in this column sometimes didn't fill up to 100% even if the respective node is not included in any solution network.

zeroactissueorig

Taking CARNIVAL Example 3 (InvCARNIVAL-APAP) as an example, the exported node activity of P29320 (EPHA3) on 'ZeroAct' is just 1.266% while being 0 in the other columns.

zeroactissue1

Checking at the variable level, this species takes the variable name 'xb40_1' in the LP description file.

zeroactissue2

In the written LP solution file (result_cplex_i_j.txt), it was shown that the solution of this variable is either "0" in 1 out of 79 (1.266%) while it take values "-0" in the other 78 solutions. It seems to be clear here that the current exportResults.R script takes only the matched string "0" but not "-0" into account. A correction is therefore needed (see commit).

zeroactissue3

zeroactissue4

After the correction, the results are now correctly exported e.g. for the node P29320 where ZeroAct is now at 100(%), see below. Please also note that we revised the column name "nodesP" and the annotation marks "P" and "D" to become "NodeType" with annotation markers "S" and "T" to intuitively represent source and target nodes, respectively.

zeroactissuesolved

@enio23 - could you please double check and merge the branch if there is no further issue? Thanks!

ptrairatphisan commented 5 years ago

I checked with CARNIVAL Ex3 and the results were exported correctly. By turning string into numeric, the round function converts "-0" to 0 so it's ok now to capture only the value zero in the numeric class. It's also a good approach to round up numbers also for the up- and down-regulated nodes (1 and -1) as the bound of these parameters were set to -1 to 1 but they were not specified to be integer values. Note that I also looked into the raw CPLEX result file (result_cplex_i_j.txt) where I couldn't observe the integer glitch for variables that represents the nodes but this integer glitch happens regularly for the variable that represent distance between nodes.

integer_glitch_dist_variables

In a nutshell, the new proposed code is re-evaluated and is safe to be merged into master.