Commit 32c045a3 authored by Olga Glogowska's avatar Olga Glogowska
Browse files

Chapter 2: Demonstrator Applications (finished) - imporved: configuration file...

Chapter 2: Demonstrator Applications (finished) - imporved: configuration file description, parts of Chapter 3 regarding configuration file moved to Chapter 2 for clarity and to avoid content repetition
parent 9d0e9582
\section{High-level overview of \exahype\ workflow}
\exahype\ is designed in such a way that most of the implementation details are hidden away from the user in the heart of an engine, i.e. \texttt{ExaHyPE} directory. A connecting piece between the user defined application \texttt{UserApplication} and \texttt{ExaHyPE} engine is the \texttt{Toolkit} utility. \texttt{Toolkit} fulfils the purpose of the 'configure' step present in some tools and thus comes before the compilation. \texttt{Toolkit} is responsible for decoding of \textit{configuration file} and generating \textit{glue code} and \textit{make system} for your \exahype\ applications. The so called \textit{glue code} establishes all appropriate connections between \texttt{UserApplication} and \texttt{ExaHyPE} intrinsics to make sure \texttt{UserApplication} can run smoothly. Among files generated by the \texttt{Toolkit}, some are meant for you to interact with, i.e. you need to provide in these files your implementation of a system of PDEs to be solved. Once it is done, you are ready to compile the application using a \texttt{Makefile} generated by the \texttt{Toolkit}. This will result in an executable \texttt{ExaHyPE-UserApplication} appearing in your project's directory. At this point you can run your application from \texttt{UserApplication} directory by typing in \texttt{./ExaHyPE-UserApplication} and passing your \textit{configuration file} as an argument.In term of code, you can refer to a generic template shown in section below.\\
\exahype\ is designed in such a way that most of the implementation details are hidden away from the user in the heart of an engine, i.e. \texttt{ExaHyPE} directory. A connecting piece between the user defined application \texttt{UserApplication} and \texttt{ExaHyPE} engine is the \texttt{Toolkit} utility. \texttt{Toolkit} fulfils the purpose of the 'configure' step present in some tools and thus comes before the compilation. \texttt{Toolkit} is responsible for decoding of \textit{configuration file} and generating \textit{glue code} and \textit{make system} for your \exahype\ applications. The so called \textit{glue code} establishes all appropriate connections between \texttt{UserApplication} and \texttt{ExaHyPE} intrinsics to make sure \texttt{UserApplication} can run smoothly. Among files generated by the \texttt{Toolkit}, some are meant for you to interact with, i.e. you need to provide in these files your implementation of a system of PDEs to be solved. Once it is done, you are ready to compile the application using a \texttt{Makefile} generated by the \texttt{Toolkit}. This will result in an executable \texttt{ExaHyPE-UserApplication} appearing in your project's directory. At this point you can run your application from \texttt{UserApplication} directory by typing in \texttt{./ExaHyPE-UserApplication} and passing your \textit{configuration file} as an argument. In terms of command line the process is realised as shown in the code snippet below:
\begin{code}
> cd ExaHyPE-Engine
> ./Toolkit/toolkit.sh UserApplication/*.exahype
......@@ -7,72 +7,132 @@
> make
> ./ExaHyPE-UserApplication *.exahype
\end{code}
\vspace{0.3cm}
\noindent
The process has been additionally visualised in Figure \ref{fig:workflow}.
\vspace{0.5cm}
\begin{figure}[H]
\begin{center}
\includegraphics[width=.9\textwidth]{tikz/demonstrators-workflow.pdf}
\includegraphics[width=.9\textwidth]{tikz/demonstrators-legend.pdf}
\end{center}
\caption[Sketch (tikz): High-level overview of \exahype\ workflow]{High-level overview of \exahype\ workflow and files generated by the application. \label{fig:workflow}}
\end{figure}
Depending on your system, you might have to change some environment variables. \exahype\ by default for example wants to use an Intel compiler and builds a release mode, i.e. a highly optimised code variant. To change this, type in before \texttt{make}:
\begin{code}
export MODE=Asserts
export COMPILER=GNU
\end{code}
\noindent
All these environment variables are enlisted by the toolkit, together with recommended settings for your system as specification file co-determines which variant of
the \exahype\ engine is actually built. You can always check / reconstruct these settings by passing in \texttt{--version} to your executable instead of the configuration file:
\begin{code}
./ExaHyPE-UserApplicaiton --version
\end{code}
\noindent
The high-level overview of the \exahype\ workflow has been visualised in Figure \ref{fig:workflow}.
\vfill
\afterpage{\clearpage}
\begin{sidewaysfigure}
\centering
\includegraphics[width=.8\textwidth]{tikz/demonstrators-workflow.pdf}
\includegraphics[width=.8\textwidth]{tikz/demonstrators-legend.pdf}
\caption[Sketch (tikz): High-level overview of \exahype\ workflow]{High-level overview of \exahype\ workflow and files generated by the application. \label{fig:workflow}}
\end{sidewaysfigure}
\newpage
\subsection{Configuration file}
\todo[inline]{Make sure this description is more or less ok. What exactly is mexa and how to use its CLI? What is exa and how to use its CLI to translate the files?}
Configuration file is a centrepiece of the \textit{workflow}. As mentioned, it is used for two purposes:
An \exahype\ configuration / specification is a text file where you specify exactly what you want to solve in which way. This file\footnote{Some examples can be found in the Toolkit directory or on the \exahype\ webpage. They have the extension \texttt{.exahype}.} is handed over to our \exahype\ \texttt{Toolkit}, a small python 3 application generating all required code. This code (also linking to all other required resources such as parameter sets or input files) then is handed over to a compiler. Depending on the option used, see \ref{chapter:a-toolkit}, you end up with an executable that may run without the python toolkit or any additional sources from \exahype. It however rereads the specification file again for input files or some
parameters. We could have worked with two different files, a specification file used to generate code and a config file, but decided to have everything in one place.\\
\vspace{0.1cm}
\noindent
\textit{Configuration file is hence a centrepiece of the workflow.} As mentioned, it is used for two purposes:
\begin{enumerate}
\vspace{0.1cm}
\item to provide configuration for \texttt{Toolkit} so that the correct context can be generated
\item to provide \textbf{configuration} for \texttt{Toolkit} so that the correct context can be generated
\vspace{0.1cm}
\item to provide specification to \texttt{ExaHyPE-YourApplication} executable at runtime
\item to provide \textbf{specification} to \texttt{ExaHyPE-UserApplication} executable at runtime
\end{enumerate}
\vspace{0.3cm}
\vspace{0.2cm}
\noindent
For now it should not be any reason to worry, but it is a good place to mention, that for the user's convenience, \exahype\ supports multiple configuration file formats, such as:
An \exahype\ specification file acts on the one hand as classic configuration files passed into the executable for a run. It holds all the constants (otherwise often passed via command lines),
output file names, core numbers, and so forth. On the other hand, a specification file defines the solver's characteristics such as numerical scheme used, polynomial order, used postprocessing steps, and so forth. Specification files translate the \exahype\ engine into an \exahype\ application. As they realise a single point-of-contact policy, \exahype\ fosters reproducability. We minimise the number of files required to uniquely define and launch an application. As the specification files also describe the used machine (configurations), they enable \exahype\ to work with machine-tailored engine instances. The engine can, at hands of the specification, optimise aggressively. If in doubt, \exahype\ prefers to run the compiler rather than to work with few generic executables.
\begin{design}
\exahype\ users typically write one code specification per file experiment plus machine plus setup combination.
\end{design}
\subsubsection{Supported configuration file formats}
For now it should not be any reason to worry, but it is a good place to mention, that \exahype\ currently supports two main configuration file formats, i.e.:
\begin{enumerate}
\vspace{0.1cm}
\item \textbf{\texttt{*.exahype}}\\
\textit{legacy specification file format}
\vspace{0.1cm}
\item \textbf{\texttt{*.json / *.exahype2}}\\
\item \textbf{\texttt{*.exahype2 (*.json / *.hjson}})\\
\textit{recommended new specification file format}
\vspace{0.1cm}
\item \textbf{\texttt{*.hjson}}\\
\textit{more human friendly \texttt{*.json} equivalent}
\vspace{0.1cm}
\item \textbf{\texttt{*.mexa / *.mexahype}}\\
\textit{\exahype\ specific configuration file language utility}
\vspace{0.1cm}
\item \textbf{\texttt{*.yml}}\\
\textit{support will be provided, currently work in progress}
\end{enumerate}
\vspace{0.3cm}
\vspace{0.1cm}
\noindent
For each of the configuration file formats, \texttt{Toolkit} provides a separate \textit{reader}, which interprets the syntax and returns a data structure in the form of a dictionary or a list. In the new version of the \texttt{Toolkit}, this structure is subsequently validated against a defined JSON-Schema and enriched with default values from the schema, if needed.\\
The need to develop support for a new configuration file format was dictated by the technical limitations of the previous version of the \texttt{Toolkit} written in \texttt{Java}, which put some restrictions on configuration files in terms of their size and number of variables that could be processed. A new \texttt{Toolkit} has been developed in \texttt{Python}, among other reasons, also in order to reduce the number of \exahype\ dependencies and becasue it provides conveniant means of handling popular configuration file formats.\\
\noindent
When coming into contact with a new programme, users often need to familiarise themselves with an application specific syntax for writing configuration files, which makes the learning curve steeper. However, there also exist some well established configuration file languages, which are commonly used across many \textit{open source} projects. By providing support for both flavours, \exahype\ specific configuration file syntax as well as other known configuration file formats, \exahype\ hopes to flatten the learning curve for new users. Please do not hesitate to choose and use the configuration file language, which best suits your knowledge and/or needs.
\begin{info}
\small For more details regarding the \textit{legacy} configuration file format \texttt{*.exahype}, users can refer to provided jinja template. It can be found under the following path: \texttt{ExaHyPE-Engine/Toolkit/exahype/} \texttt{specfiles/templates/} \texttt{specfile1.exahype.template}.
\end{info}
Typically, when coming into contact with a new programme, users often need to familiarise themselves with an application specific syntax for writing configuration files, as was the case with \texttt{*.exahype} configuration files. This makes the learning curve for the new application steeper. However, there exist some well established configuration file languages, which are commonly used across many \textit{open source} projects. One of such configuration file languages is \texttt{JSON}. Because \texttt{Python} provides \texttt{JSON} support and there is a high chance that many of the new \exahype\ developers and users are already familiar with the syntax, \texttt{JSON} has been chosen as the new configuration file format.\\
\noindent
For now, the \texttt{Toolkit} still supports both flavours of configuation files, i.e. the legacy \texttt{*.exahype} as well as the new and preferred \texttt{*.exahype2}. For each of the configuration file formats, \texttt{Toolkit} provides a separate \textit{reader}, which interprets the syntax and returns a data structure in the form of a dictionary. This structure is subsequently validated against a defined \texttt{JSON}-Schema and enriched with default values from the schema, if needed. In other words, internally, the \texttt{*.exahype} syntax is translated to \texttt{*.exahype2} anyway before the validation step is performed. Hence, \texttt{*.exahype2} should be seen as the preferred configuration file format and it can be expected that in future \exahype\ releases support for the legacy configuration file format will be gone!
\begin{info}
\small The \textit{recommended} configuration file format for the new version of the \texttt{Toolkit} is \texttt{*.json} or otherwise called \texttt{*.exahype2} configuration file format. To familiarise yourself with its syntax, users can have a look at a provided \textit{json} schema. It can be found under the following path: \texttt{ExaHyPE-Engine/} \texttt{Toolkit/exahype-specfile.schema.json}.
\small For details regarding the \textit{legacy} configuration file format \texttt{*.exahype}, users can refer to provided \texttt{JINJA} template. It can be found under the following path: \texttt{ExaHyPE-Engine/Toolkit/exahype/} \texttt{specfiles/templates/} \texttt{specfile1.exahype.template}.
\end{info}
\begin{info}
\small To get an idea about how to write configuration files using \texttt{*.mexa} format, visit: \url{http://bitbucket.org/svek/mexa}. Some examples are also to be found in \texttt{ApplicationExamples} directory of \exahype.
\label{note:mexa}
\small For details regarding the \textit{new recommended} configuration file format \texttt{*.exahype2}, users can have a look at a provided \texttt{JSON}-Schema. It can be found under the following path: \texttt{ExaHyPE-Engine/} \texttt{Toolkit/exahype-specfile.schema.json}.
\end{info}
\noindent
Due to abundance of configuration file formats supported, \exahype\ also provides a means of translating between them. In particular, all \textit{legacy} configuration files with extension \texttt{*.exahype} can be converted into \texttt{*.exahype2} format using the \texttt{specfile1\_reader.py} module. In order to translate your \textit{legacy} file into the \textit{new recommended} format, you can run \texttt{specfile1\_reader.py} as a \texttt{\_\_main\_\_} module with the following command line arguments:
\subsubsection{Exploring the syntax}
As an example illustrating the basic syntax, users might want to analyse a \texttt{TrivialProject} configuration / specification file to be found in \texttt{Demonstrators} subdirectory of \exahype. Most parameters should be rather self-explanatory. For your own projects, you might have to adopt the paths \footnote{You may specify pathes of individual components in more detail (cmp.~Section \ref{chapter:finetuning}), but for most applications working with the three pathes above should be sufficient.}. Note that \exahype\ supports both two- and three-dimensional setups.
\begin{code}
> cd ExaHyPE-Engine/Toolkit/exahype/specfiles
> python3 specfile1_reader.py [exahype] [exahype2]
exahype-project TrivialProject
peano-kernel-path const = ./Peano
exahype-path const = ./ExaHyPE
output-directory const = ./Demonstrators/TrivialProject
computational-domain
dimension const = 2
width = 1.0, 1.0
offset = 0.0, 0.0
end-time = 10.0
end computational-domain
end exahype-project
\end{code}
where \texttt{[exahype]} and \texttt{[exahype2]} are the paths to desired input and output configuration files respectively.\\
\begin{design}
The \texttt{*.exahype} specification file parameters that are interpreted by the toolkit are marked as \texttt{const}. If constant parameters or the structure of the file (all regions terminated by an \texttt{end}) change, you have to rerun the toolkit. All other variables are read at runtime, i.e.~you may alter them without a rerun of the toolkit or a re-compile.
\end{design}
\vspace{0.1cm}
\noindent
If you run various experiments, you start from one specification file and build up your application from hereon. You can either pass the original specification file to your excutable, or you can pass other variants of it as well. That is, you may work with sets of specification files all feeding into one executable. However, the specification files have to match each other in terms of const
variables and their structure. \exahype\ itself checks for consistent files in many places and, for many invalid combinations, complains.
\noindent
Using the \texttt{mexa.py} module and provided \textit{command line interface}, you can also translate your \texttt{*.mexa} configuration files to \texttt{*.exahype}, \texttt{*.json}, \texttt{*.hjson} and \texttt{*.xml}. More about that under the \textit{url} indicated in Note \ref{note:mexa}.
Due to the fact that many users have their cases already set up using the legacy configuration file format, \exahype\ provides a means of translating \texttt{*.exahype} to \texttt{*.exahype2} format. In particular, all legacy configuration files with extension \texttt{*.exahype} can be converted into \texttt{*.exahype2} format using the \texttt{-j} flag of the \texttt{Toolkit}. Using it will write a \texttt{JSON} file with a similar filename and \texttt{*.exahype2} extention, if legacy specification file is read. To keep things simple and expolore some of the syntactic differences between the old and new configuration file format, you might want to first translate \texttt{TrivialProject} configuration file into the new format as follows:
\begin{code}
> cd ExaHyPE-Engine
> ./Toolkit/toolkit.sh -j Demonstrators/TrivialProject/TrivialProject.exahype
\end{code}
\noindent
You should now be able to find \texttt{TrivialProject.exahype2} file in \texttt{TrivialProject} subdirectory. The file should have the following content:
\begin{code}
{
"project_name": "TrivialProject",
"paths": {
"peano_kernel_path": "./Peano",
"exahype_path": "./ExaHyPE",
"output_directory": "./Demonstrators/TrivialProject"
},
"computational_domain": {
"dimension": 2,
"end_time": 10.0,
"offset": [
0.0,
0.0
],
"width": [
1.0,
1.0
]
},
"solvers": []
}
\end{code}
\noindent
More details regarding specification file setup and all the parameters can be found in Section \ref{sec:solver-configuration}. It might still refer to the legacy specification file. However, there is planty of information available in the Internet regarding syntax of \texttt{JSON} configuration file language. If you take into consideration that all dashes ''-'' in legacy parameter names have now been changed into underscres ''\_'' in \texttt{JSON} syntax and that the \texttt{const} indicators are gone, you should be able to find your way and use the new syntax easily.
......@@ -10,16 +10,13 @@ As an introduction into \exahype\ workflow, we provide a complete implementation
\noindent
Finite Volume solver is the simplest one. In its basic version, it relies on a Rusanov flux. With only a few lines, it can be
changed into an ADER-DG-without-limiting scheme later. It can also be used by an ADER-DG scheme as a limiter. You can find all of these
basic implementations in the \texttt{Demonstrators} subdirectory of \texttt{ExaHyPE-Engine}. For simplicity, all demonstrators are based on \texttt{*.exahype} configuration files.\\
In the following we provide an extensive description of how to run your first application based on \textit{Demonstrators/EulerFV} demonstrator.
basic implementations in the \texttt{Demonstrators} subdirectory of \texttt{ExaHyPE-Engine}. For simplicity, all demonstrators are based on \texttt{*.exahype} configuration files.
\subsection{Finite Volume Solver}
\todo[inline]{Why can I not open *.vtu files in Paraview for steps later than 1?}
\noindent
The demonstrator folder \texttt{Demonstrators/EulerFV} contains solely files modified to realise the finite volume solver.
In the following we provide an extensive description of how to run your first application based on \textit{Demonstrators/EulerFV} demonstrator. The demonstrator folder \texttt{Demonstrators/EulerFV} contains solely files modified to realise the finite volume solver.
All \textit{glue code} are to be generated with the \texttt{Toolkit}.
Before you do so, open \texttt{EulerFV.exahype} configuration file.
This simple text file is the of the solver.
This simple text file is the heart of the solver.
It specifies the solver properties, the numerical schemes, and it also holds all
the mandatory paths:
\begin{code}
......@@ -116,11 +113,10 @@ again:
A successful run yields a bunch of \texttt{*.vtu} files that you can open for example with
Paraview\footnote{\url{www.paraview.org}} or
VisIt\footnote{\url{wci.llnl.gov/simulation/computer-codes/visit}}.\\
\todo[inline]{Is $t$ parameter described correctly?}
\noindent
There are two quantites plotted:
\begin{enumerate}
\item The time encodes $t$ per vertex. Quantity $t$ is referring to a time step at which the data has been written to a vertex
\item The time encodes $t$ per vertex. Quantity $t$ is referring to a time step at which the data has been written to a vertex.
For these primitive tests with global time stepping, this information is of
limited value. It however later makes a big difference if parts of the grid are allowed to
advance in time asynchronous to other grid parts.
......@@ -168,15 +164,11 @@ For ADER-DG solvers, the procedure is practically the same as for Finite Volume
> ./Toolkit/toolkit.sh Demonstrators/EulerADERDG-without-limiter/
EulerADERDG-without-limiter.exahype
> cd Demonstrators/EulerADERDG-without-limiter
> make -j8
> make -j4
>./ExaHyPE-EulerADERDG EulerADERDG-without-limiter.exahype
\end{code}
\subsection{ADER-DG Solver with finite volumes limiting}
\todo[inline]{ Is this the right way to run this example?\\
1) vertices plotter does not work so needs to be commented out for it to run\\
2) if commented out and only subcellplotter used, there is no *.vtk output}
\noindent
For ADER-DG solvers with limiting, the procedure is somewhat different. Please refer to Chapter \ref{chapter:coupling-limiter} for more detailed description of how to couple Finite Volume Limiter with ADER-DG solver. Analysing provided overview of files generated for this example can give some hints. Please refer to Figure \ref{fig:demonstrators-EulerADERDG}. You are encouraged to explore the content of these files on your own.
\begin{code}
> cd ExaHyPE-Engine
......
\chapter{A new \exahype\,project}
\label{chapter:new-development-project}
\begin{design}
\exahype\ users typically write one code specification per
file experiment plus machine plus setup combination.
\end{design}
An \exahype\ specification file acts on the one hand as classic
configuration files passed into the executable for a run.
It holds all the constants (otherwise often passed via command lines),
output file names, core numbers, and so forth.
On the other hand, a specification file defines the solver's characteristics
such as numerical scheme used, polynomial order, used postprocessing steps, and
so forth.
Specification files translate the \exahype\ engine into an \exahype\
application.
As they realise a single point-of-contact policy, \exahype\ fosters
reproducability.
We minimise the number of files required to uniquely define and launch an
application.
As the specification files also describe the used machine (configurations), they
enable \exahype\ to work with machine-tailored engine instances.
The engine can, at hands of the specification, optimise aggressively.
If in doubt, \exahype\ prefers to run the compiler rather than to work with few generic executables.
An \exahype\ specification is a text file where you
specify exactly what you want to solve in which way.
This file\footnote{Some examples can be found in the Toolkit directory or
on the \exahype\ webpage. They have the extension \texttt{.exahype}.}
is handed over to our \exahype\ toolkit, a small python 3 application generating all
required code.
This code (also linking to all other required resources such as parameter
sets or input files) then is handed over to a compiler.
Depending on the option used, see \ref{chapter:a-toolkit}, you end up with an executable that
may run without the python toolkit or any additional sources from \exahype.
It however rereads the specification file again for input files or some
parameters, e.g.
We could have worked with two different files, a specification file used to
generate code and a config file, but decided to have everything in one place.
\begin{design}
The specification file parameters that are interpreted by the toolkit are marked
as \texttt{const}. If constant parameters or the structure of the file
(all regions terminated by an \texttt{end}) change, you have to rerun the
toolkit. All other variables are read at runtime, i.e.~you may alter them
without a rerun of the toolkit or a re-compile.
\end{design}
\noindent
If you run various experiments, you start from one specification file and
build up your application from hereon.
Once the executable is available, it can either be passed the original
specification file or variants of it, i.e.~you may work with sets of
specification files all feeding into one executable.
However, the specification files have to match each other in terms of const
variables and their structure.
\exahype\ itself checks for consistent files in many places and, for many
invalid combinations, complains.
\section{A trivial project}
A trivial project in \exahype\ is described by the following specification file:
\begin{code}
exahype-project TrivialProject
peano-kernel-path const = ./Peano
exahype-path const = ./ExaHyPE
output-directory const = ./Demonstrators/TrivialProject
computational-domain
dimension const = 2
width = 1.0, 1.0
offset = 0.0, 0.0
end-time = 10.0
end computational-domain
end exahype-project
\end{code}
\noindent
Most parameters should be rather self-explanatory. You might have to adopt
the paths\footnote{
You may specify pathes of individual components
in more detail (cmp.~Section \ref{chapter:finetuning}), but for most
applications working with the three pathes above should be sufficient.}.
Note that \exahype\ supports both two- and three-dimensional
setups.
We hand the file over to the toolkit
\begin{code}
./Toolkit/toolkit.sh Demonstrators/TrivialProject.exahype
\end{code}
\noindent
Finally, we change into this project's directory and type in
\begin{code}
make
\end{code}
\noindent
which gives us an executable. Depending on your system, you might have to change
some environment variables. \exahype\ by default for examples wants to
use an Intel compiler and builds a release mode, i.e.~a highly optimised code
variant. To change this, type in before \texttt{make}:
\begin{code}
export MODE=Asserts
export COMPILER=GNU
\end{code}
\noindent
All these environment variables are
enlisted by the toolkit, together with recommended settings for your system.
We finally run this first \exahype\ application with
\begin{code}
./ExaHyPE-TrivialProject TrivialProject.exahype
\end{code}
\noindent
As clarified before, the specification file co-determines which variant of
the \exahype\ engine is actually built.
You can always check/reconstruct these settings by passing in \texttt{--version}
instead of the configuration file:
\begin{code}
./ExaHyPE-TrivialProject --version
\end{code}
In this section we provide a detailed overview of configuration file settings, which you can use in order to configure your own project. In the Chapter \ref{chapter:aderdg-user-defined-fluxes} you can find few examples of projects, which you may also use as a reference to build your own solver.
\section{Solver configuration---an overview}
\label{sec:solver-configuration}
......
......@@ -30,6 +30,8 @@
\usepackage{subfig}
\usepackage{verbatim}
\usepackage{float}
\usepackage{rotating}
\usepackage{afterpage}
% Todo notes. You can disable them by enabling this line:
%\def\releasemode{1}
......
......@@ -87,6 +87,7 @@
\node at (\leftpos+0.1*\verticalspace, \startverticalposition-4.9*\verticalspace) (results top) [file] {};
\node at (\leftpos+0.05*\verticalspace, \startverticalposition-4.95*\verticalspace) [file] {};
\node at (\leftpos, \startverticalposition-5*\verticalspace) [file] (results bottom) {\color{black!80}{variables-0.vtu}};
\node at (\leftpos, \startverticalposition-6*\verticalspace) [file] (results bottom) {\color{black!80}{variables.pvd}};
%output files from toolkit which will be overwritten
\node at (0,\startverticalposition) [file] (outputBeingOverwritten top) {\color{black!80}{\begin{tabular}{c}Abstract\\MyEulerSolver.h\end{tabular}}};
\node at (0,\startverticalposition-\verticalspace) [file] {\color{black!80}{\begin{tabular}{c}Abstract\\MyEulerSolver.cpp\end{tabular}}};
......@@ -100,16 +101,16 @@
\node at (\rightpos,\startverticalposition-2*\verticalspace) [file] {\color{black!80}{EulerWriter.h}};
\node at (\rightpos,\startverticalposition-3*\verticalspace) [file] (outputNotBeingOverwritten bottom) {\color{black!80}{EulerWriter.cpp}};
%output files from make system
\node at (\leftpos,\startverticalposition-6.75*\verticalspace) [file] {\color{black!80}{AbstractMyEulerSolver.o}};
\node at (\leftpos,\startverticalposition-7.75*\verticalspace) [file] {\color{black!80}{MyEulerSolver.o}};
\node at (\leftpos,\startverticalposition-8.75*\verticalspace) [file] {\color{black!80}{EulerWriter.o}};
\node at (\leftpos,\startverticalposition-9.75*\verticalspace) [file] (outputMake bottom left) {\color{black!80}{KernelCalls.o}};
\node at (0,\startverticalposition-6.75*\verticalspace) [file] (outputMake top right) {\color{black!80}{buildinfo.h}};
\node at (0,\startverticalposition-7.75*\verticalspace) [file] {\color{black!80}{cfiles.mk}};
\node at (0,\startverticalposition-8.75*\verticalspace) [file] {\color{black!80}{cipofiles.mk}};
\node at (0,\startverticalposition-9.75*\verticalspace) [file] {\color{black!80}{ffiles.mk}};
\node at (\leftpos,\startverticalposition-7.75*\verticalspace) [file] {\color{black!80}{AbstractMyEulerSolver.o}};
\node at (\leftpos,\startverticalposition-8.75*\verticalspace) [file] {\color{black!80}{MyEulerSolver.o}};
\node at (\leftpos,\startverticalposition-9.75*\verticalspace) [file] {\color{black!80}{EulerWriter.o}};
\node at (\leftpos,\startverticalposition-10.75*\verticalspace) [file] (outputMake bottom left) {\color{black!80}{KernelCalls.o}};
\node at (0,\startverticalposition-7.75*\verticalspace) [file] (outputMake top right) {\color{black!80}{buildinfo.h}};
\node at (0,\startverticalposition-8.75*\verticalspace) [file] {\color{black!80}{cfiles.mk}};
\node at (0,\startverticalposition-9.75*\verticalspace) [file] {\color{black!80}{cipofiles.mk}};
\node at (0,\startverticalposition-10.75*\verticalspace) [file] {\color{black!80}{ffiles.mk}};
%output file from make system --> executable
\node at (\rightpos,\startverticalposition-6.75*\verticalspace) [file] (executable) {\color{black!80}{ExaHyPE-EulerFV}};
\node at (\rightpos,\startverticalposition-7.75*\verticalspace) [file] (executable) {\color{black!80}{ExaHyPE-EulerFV}};
\end{scope}
\begin{scope}[on above layer]
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment