|
|
Skype meeting: Denilson, Patrick, Susan, Tyson
Patrick summarized what he's garnered so far from looking at the data and code of the Orlando viz tool: it's been loading the entire file into memory; drawing on libraries for loading and parsing it wd speed things up a lot, and allow it to be modular and therefore, when needed, parallelized so that sep jobs could be parsing the file
Denilson summarized what he has been doing with his social network viz tool system, Reason, which is to decouple back from front end, modularize etc. in very much the same way we are thinking needs to be done for the Orlando viz tool The pieces:
system is data agnostic: will take in range of forms of data so long as expressed as nodes and edges including graphML
Reason's workflow also includes taking in data, cleaning, removing duplicates, etc.: this may be useful for CWRC down line, when people will want to pull in/upload other materials than stuff resident in ORCA db
Orlando data to use reason would need to be defined in terms of Reason's terminology, but this is probably pretty easy to do with the semantic markup
Denilson needs more work on network analysis algorithms; Orlando tool needs that too: one possible area of collaboration in longer term: caching works right now on web server level but the analysis for all communities in larger data sets is going to be computationally intensive enough that the queries could be handed off to HPC for analysis; don't want to do that analysis w/i the dbase
network analytics in Java Patrick wants to keep Orlando viz tool in c/c++
Timeline: Would probably be too much of a push to try to really bring the two systems together by late Sept when we would hope to be doing some user testing; easier to share components at this stage? e.g. Denilson cd package up the visualization quickly
TO DO:
NEXT STEPS:
QUESTIONS: Can we fit Mark (who is going to be working up an experimental viz prototype) usefully into this process somehow, and have him build the viz prototype using this back end? or would that get too complicated? Jeff can advise on this once back. Consideration is desire to have something working to test in fall. Could just try to speed up what we have with use of libraries and see if that would be enough of an improvement in speed to get feedback on current interface.