Skip to content
Snippets Groups Projects
Commit 0aa73b19 authored by Johannes Mey's avatar Johannes Mey
Browse files

last changes

parent 2f95e4bd
No related branches found
No related tags found
No related merge requests found
.gitlab-ci
Dockerfile
.dockerignore
trainbenchmark-docker.tar
models
.git
......@@ -12,10 +12,10 @@ rene.schoene@tu-dresden.de
Görel Hedin
gorel.hedin@cs.lth.se
Emma Söderberg}
Emma Söderberg
emma.soderberg@cs.lth.se
Thomas Kühn}
Thomas Kühn
thomas.kuehn3@tu-dresden.de
Niklas Fors
......
......@@ -18,7 +18,7 @@
The paper discusses the utilization of reference attribute grammars (RAGs) for model validation and presents two specific contributions.
First, the differences between models and trees specified by reference attribute grammars, specifically non-containment references, are discussed and a manual, yet optimised method to efficiently overcome these differences is presented.
Secondly, an extension of RAG grammar specifications is proposed to model noncontainment references automatically.
The proposed modelling techniques are compared to state-of-the-art modelling tools utilizing a benchmarking framwork for continuous model validation, the *Train Benchmark*.
The proposed modelling techniques are compared to state-of-the-art modelling tools utilizing a benchmarking framework for continuous model validation, the *Train Benchmark*.
### Structure of the Supplementary Artifacts
......@@ -139,7 +139,7 @@ These are the important directories:
### Reproducing the Measurements
**Please Note: Reproducing the graphs as presented in the paper and supplied here takes a very long time depending on the utilized hardware. It is strongly suggested to run the benchmark with a smaller maximum problem size, less repetitions, and a shorter timeout.** Most results of the benchmark are observable with more restricted setup as well. In the following, we will provide a suggested way to run the benchmark in different sizes.
**Please Note: Reproducing the graphs as presented in the paper and supplied here takes a very long time depending on the utilized hardware. It is strongly suggested to run the benchmark with a smaller maximum problem size, less repetitions, and a shorter timeout.** Most results of the benchmark are observable with more restricted setup as well. In the following, we will provide a suggested way to run the benchmark in different sizes. Note that running the benchmark requires a significant amount of disk space (up to 10GB when running the full benchmark).
To reproduce the measurements, there are several options. We provide a prepared Docker image that can be run directly.
Alternatively, it is, on course, also possible to simply run the provided gradle build scripts.
......@@ -154,6 +154,7 @@ However, since there are some software requirements imposed by the benchmark, pa
- Steps:
- Unpack the provided archive and open a terminal in the extracted directory
- `docker load --input trainbenchmark-docker.tar`
- `docker run -it trainbenchmark`
- Variant 2: Build the docker image from the provided Dockerfile
- Prerequisites: An installation of Docker in the `PATH`
- Steps:
......@@ -180,7 +181,6 @@ However, since there are some software requirements imposed by the benchmark, pa
- run `./gradlew initScripts`
- configure the scripts either by running `./scripts/configure.sh 1 <MAXSIZE> <TIMEOUT in s> <REPETITIONS>`
- Where MAXSIZE is one of 2,4,8,16,32,64,128,256,512,1024. The larger sizes use **a lot of** disk space!
- *Alternatively*, run ``
- run `./gradlew initScripts`
- run `./gradlew generate`
- run the benchmark
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment