ftsrg/graph-analyzer

Library for analyzing typed graphs.

Graph analyzer

Analysis and metric visualisation toolkit for typed graphs, based on our MODELS 2016 paper (ACM DL, DBLP).

Prerequisites

Java 8

Getting Started

To run the analysis, edit the analyzer-app/src/Analyzer.groovy file and issue the following command:

./gradlew analyze

Make sure the Gradle process has enough memory - the more the better.

export JAVA_OPTS=-Xmx4G

License

This project is distributed under the Eclipse Public License 1.0. The project was supported by the MONDO EU FP7 project (EU ICT-611125) and is currently developed by the MTA-BME Lendület Research Group on Cyber-Physical Systems.

graph-analyzer's Issues

Review compile dependencies and use testCompile where it is possible

Currently, every dependency is in the compile configuration even those which are not necessary at runtime (typically test libraries). We should use testCompile configuration for these.

Fix Train Benchmark tests

Remove separate *.test projects and merge them with the sut ones

For example, we have a separate *modelmetrics.test project for *.modelmetrics which is not necessary anymore to be in a different project.

Add dependency for calculating KS distance

Add EditorConfig

http://editorconfig.org/

Remove testutils from mba.base

The parent project should be renamed

Instead of model-analyzer, we should name the parent project as hu.bme.mit.bma, following the convention of its child projects.

Improve R scripts

• Fix refactoring-related artifacts (TypedTyped, etc.)
• Remove containment-related analysis as its not relevant for many graphs

Implement first guide based on Degrees

Change the interface of ModelAdapter

First, extract the initialization part to a ModelProvider, and second, implement a ModelIndexBuilder interface. Then the ModelProvider would provide the model via ModelIndexBuilder by using atomic EdgeOperations. On the other hand, the ModelAdapter would be responsible for providing data that are necessary for the metric calculations (like before, based on the index) but doing it with a different interface.

With this approach, the user shouldn't implement a custom ModelAdapter, and the template parameters could be removed from the Adapter (a bit tricky though because of the Indexer).

Project renaming considerations

I think we should simplify project names, e.g.

• test.model -> testmodels
• modeladapters -> adapters
• modelmetrics -> metrics

Run from command line

Allow command line execution.

Convert build to Gradle

Customize KS test

...in a way to extract the x value where the biggest difference can be observed between the distributions. Currently, for example with math3 library, only the value of the difference can be obtained.

Create the first prototype of model generator

Tidy naming conventions

I think typed stuff should be called dimensional, including the generics params. So <N, T> would become <N, D>, etc.

Simplify naming coventions

model* is superfluous in a lot of places (e.g. modelmetrics, modelanalyzer) - removing it would make things shorter.

Exact semantics of dimensional metrics

DC2, DC3, Q...

Replace testng with tngtech

Add Neo4j driver

Add license

Serializing EdgeOverlap throws NPE

Use matrix multiplication-based methods for calculations

We should look into the possibility of using a sparse matrix library and formulate our metrics as multiplications.

Serialize results between calculations

We perform many iterations for calculating a set of metrics and load the data each time. This is quite time-consuming, so we should consider dumping the node/edge sets to binaries with Kryo's Guava serializers.