Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some networks are not properly drawn in D3.jsy #6

Open
honghaoli42 opened this issue Apr 2, 2020 · 2 comments
Open

Some networks are not properly drawn in D3.jsy #6

honghaoli42 opened this issue Apr 2, 2020 · 2 comments
Labels

Comments

@honghaoli42
Copy link
Collaborator

honghaoli42 commented Apr 2, 2020

Original report by Marcel Ribeiro-Dantas (Bitbucket: mribeirodantas_, ).


Hervé noticed that some orientations are incorrectly drawn by D3.js. He pointed out, for example:

height_cm 0.500 1 body_surface_area_dubois_m2 1 0.697 bmi_kgperm -990.060 0
height_cm 0.500 0.963 gender 0.963 0.552 coronary_disease -3.926 0
body_surface_area_dubois_m2 1 0.697 bmi_kgperm 0.697 1 left_ventricule_stroke_volume_ml -1.284 0

This is a v-structure, but is not drawn as a v-structure in the graph.

@honghaoli42
Copy link
Collaborator Author

honghaoli42 commented Apr 2, 2020

Original comment by Marcel Ribeiro-Dantas (Bitbucket: mribeirodantas_, ).


I'm checking the edgesList.miic.summary.txt for the job Hervé mentioned. It's the file that the make_json_graph.py function reads and generates the JSON for D3.js draw the graph. I was checking the v-structure height_cm -> gender <- coronary_disease. In the probability tab, we see a negative NI3 (NI3=-3.926), a v-structure, but the arrow from coronary_disease to gender is not properly drawn, though the one from height_cm is.

By checking the edgesList.miic.summary.txt, I see the infoOrt variable for height_cm → gender is 2, as expected, but for coronary_disease → gender it’s 1. Therefore the issue is not when preparing the JSON file for the graph generation, but the writing of the edgesList.miic.summary.txt file, if I understood correctly the manpage for miic, that reads:

  • 1: (xy) edge is undirected
  • 2: (xy) edge is directed as x →y
  • -2: (xy) edge is directed as x ←y
  • 6: (xy) edge is bidirected

By checking the miic_run_analysis.R file, the only thing it does is to write to edgesList.miic.summary.txt the content of the field all.edges.summary, created by the miic function in the miic R package, as you can see below:

## Edges summary
cat("# -> Writing edges summary ...\n")
write.table(res$all.edges.summary,
            file.path(args$output_dir, "edgesList.miic.summary.txt"),
            quote = F, sep = "\t",
            row.names = F
)

Therefore, the issue seems to be in the miic R package.

@honghaoli42
Copy link
Collaborator Author

honghaoli42 commented Apr 28, 2020

Original comment by Marcel Ribeiro-Dantas (Bitbucket: mribeirodantas_, ).


By @{5a295594f34f355105637e6e} :
Concerning the orientation probabilities that do not correspond to the visual graph, we found that the correct consistent orientations are indeed those that are shown in the graph (and adjacency matrix), but the orientations tab corresponds only to the last iteration. We think there can be only discrepancies where an edge is non-oriented after the consistent cycle union but appears oriented in the orientation probabilities. One solution would be to set to zero the probabilities of this edge to reflect the fact that it becomes non-oriented after the union, or we could also show the probabilities of each iteration in the limit cycle.
Same thing for the V-structure scores that we could also set to 0 when they are "broken" by the union

By Hervé:
One quick and dirty way to "fix" the orientation mismatch between the union graph and the probability tab would be to keep the orientations of the last graph, ie corresponding to the probability tab,  (and add missing edges from the union keeping them undirected). Then we could have an additional "consistency" column in the summary tab after the type of edge code (0,1,2,-2,6) where we post the fraction of graphs in the union with that type of edge for this pair, ie if it's a type 1 edge, the fraction of graphs in the union with the same edge type=1. The fraction should be 100% without consistency option and some percent number informing on the consensus status of that edge within the graphs in the union.

@honghaoli42 honghaoli42 added critical bug Something isn't working labels Jul 24, 2020
@honghaoli42 honghaoli42 added minor and removed bug Something isn't working critical labels Aug 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant