parallel-in-time / time4apint

Mixing GFM method with PinT task scheduling

Call of PinTy : BlockOps

Motivations

Develop a python code based on a generic framework allowing to investigate and analyze the performance of iterative parallel-in-time (PinT) algorithms : blockops

In addition to this code, a website framework is provided to allow building of Application Webpage (or WebApp), that uses the code for specific applications and experiments.

See the current online demo website, that has a few WebApps implemented :

• Performance Analysis of Scheduling Strategies for different PinT Algorithms
• Analysis of Sequential Time-Integration Methods (accuracy, order, ...)

🔔 The WebApps are now under development : current will be improved, and other WebApps will be added soon ... Also note that most of the links below do not work on the website (yet), so you'll have to see this page on the github repository to follow them.

Base Convention

Represent an iterative PinT algorithm with a block iteration of the form

$$u_{n+1}^{k+1} = B_1^0 u_{n+1}^k + B_0^0 u_{n}^k + B_0^1 u_{n}^{k+1} + ...$$

with $B_i^j$ the block coefficient, built using one or a combination of block operators (addition, substraction, multiplication, inverse). For instance, looking at the Parareal algorithm, we have

$$u_{n+1}^{k+1} = (F - G) u_{n}^k + G u_{n}^{k+1},$$

with $F$ and $G$ the block operators. Then we have two block coefficients $B_0^0 = F-G$ and $B_0^1 = G$. Note that the same block operator can be present in several block coefficients.

🔔 Note : block coefficients indices don't depend on $k$ and $n$, but on the offset. Hence, $B_1^0$ is the block coefficient for the $u_{n+1}^{k+0}$ term, and the block coefficient for the $u_{n-1}^{k+1}$ term would then be $B_{-1}^{1}$.

Any combination of block operators can be seen as a unique block operator, hence a block coefficient is itself a combination of block operators and also a block operator. This aspect is fully used in the framework implementation.

Core Concepts

⚠️ As this project is currently in continuous development, this part may be partially incomplete or outdated. Don't hesitate to use the project's Discussions Forum to ask for more details.

1. BlockOperator : base object, used to represents, manipulate and evaluate block operators and block coefficients. Implemented here, with some documentation details provided here.
2. BlockIteration : object implementing a block iteration (i.e one given algorithm), using a given set of block coefficients. Implemented here, with some documentation details provided here.
3. BlockProblem : object representing a given problem, i.e the numerical solution of the ODE problem represented as a linear system where each time solution is an unknown of the problem. Implemented here, with some documentation details provided here.
4. Task Graph: TODO
5. Schedule: TODO

📜 Important notes :

• BlockOperator objects can be either symbolic or numerical block operator. Symbolic block operator only have a given cost and symbol, and can be used for speedup analysis. Numerical block operator have a cost and a matrix representation (more details here), and can be used for error and speedup analysis.
• BlockIteration objects depend only on BlockOperator objects, and are enough alone o define and analyse the speedup of a given block iteration (if relying only on symbolic BlockOperator)
• BlockProblem represent the time-integration of a Dahlquist problem on a given time interval with a given number of blocks. It defines the appropriate numerical BlockOperator, and can be used to generate some classical BlockIteration objects.

Project structure

Base library :

• blockops : the main library developped for this project
• old : some previous implementations (:ghost: to be integrated/removed later in the current code ...)

🔔 requires at minimum Python 3.10, check requirements.txt for packages dependencies

Scripts and Notebook

Those shows from basic to complexe usage example of the library. It uses relative symbolic link to the blockops directory, directly integrated in the following subdirectory, to avoid any modification of the local PYTHONPATH or else.

• notebook : sub-directory for Jupyter Notebook. Those are basic examples that can be used for starters.
• scripts : sub-directory for Python scripts. Those are more complex examples of use, with less documentation, mostly developped when a new functionnality is added to the blockops library.

Additional scripts :

• main.py : some classical Block Iterations and their representation (:ghost: to be removed ...)
• testing.py : some basic testing of the framework with Parareal (:ghost: to be removed ...)
• test_FCF.py : some basic testing of the framework with FCF relaxation (:ghost: to be removed ...)

Acknowledgements

This repository results from a collaboration between University of Wuppertal (Jens HAHNE) and Hamburg University of Technology (Thibaut LUNET), as part of the Time-X project.

                 

This project has received funding from the European High-Performance Computing Joint Undertaking (JU) under grant agreement No 955701 (Time-X). The JU receives support from the European Union’s Horizon 2020 research and innovation programme and Belgium, France, Germany, and Switzerland. This project also received funding from the German Federal Ministry of Education and Research (BMBF) grant 16HPC048.

                 

Web Interface

• wepps
• current web apps

You can run the website on your own computer : install the dependencies stated in the requirements.txt and then open a browser at 127.0.0.1:8000 after running

python web.py

time4apint's Issues

Hybrid doc and result column

Would be useful to be able to add either plot or markdown stage in the results stages (right column, formerly plot stages) and also in the docs stages (left column).

Presentation details

Hey @JensHahne, just writing here some idea(s) for siam presentation :

• maybe don't represent in task graph the tasks that cost nothing. This should allow a simpler/clearer representation while making explicit only the costly operations (a bit like the scheduling graph)

Sponsors logo from main markdown page not showing

Should be a small fix, to be done as soon as possible (would be better for the demos tomorrow 😅)

Missing mardown support for code snippets

See bottom of the index page :

Inline code is rendered, but not code blocks ...

Possibility to add caption text (markdown format) for the plots

Some additional caption string argument for the PlotsStage constructor, that would be used to display a caption below the figure, and could support markdown format (for instance, when using latex inline formula)

Allow folder structure for Webapps

Currently all webapps are stored in the same web_apps folder. As new apps are currently added, we need them to follow some repository structure in order to sort them (into categories, algorithms, etc ...).
It would be great that the dynamic_site code take into account such folder structure for the app :

- categ1 : folder for first category
    - index.md : small markdown page describing the categories and associated apps
    - app1.py : source code for app1
    - app1.md : extended documentation for app1
    - app2.py : source code for app2
    - app2.md : extended documentation for app2
- categ2 : folder for second category
    - ...

Then the API path should be like this :

baseURL : access to the main page, based on the README.md file from the git repo
baseURL/categ1 : access to the index page of categ1
baseURL/categ1/app1 : access to the webapp app1
...

In particular, this should be recursive and allow to define subcategories, with categories able to have simultaneously subcategories and webapps.

PintRun expensive even for nBlocks=10 and nIter=10

The construction of the PintRun quickly becomes very expensive, for example with N=10 and K=10. It seems that the calls to simplify() and subs() from sympy are quite expensive. The functions are called for every n,k combination in the PinTRun, resulting in very expensive generations. Even for N=10 and K=10, this can easily lead to 4-5 seconds to create the PintRun.

I don't have a good idea at the moment how to fix this, but with these long runtimes for simulating relatively small block iterations, it is not really reasonable.

Cannot get apps webpage in local dev website

@MichelKrispin after installing a clean environment with the requirements.txt, when launching the website with

python web.py

the index webpage is displayed, but the accuracy or demo app shows a blank page. Here is the firefox console log for accuracy for instance :

Vector computation not compatible with grid coarsening (yet ...)

For now, matrix multiplication for the following cases

• $(N_{dof}, M_1, M_2) \times (N_{dof}, M_2, M_3) \Rightarrow (N_{dof}, M_1, M_3)$
• $(1, M_1, M_2) \times (N_{dof}, M_2, M_3) \Rightarrow (N_{dof}, M_1, M_3)$
• $(N_{dof}, M_1, M_2) \times (1, M_2, M_3) \Rightarrow (N_{dof}, M_1, M_3)$
• $(1, M_1, M_2) \times (1, M_2, M_3) \Rightarrow (N_{dof}, M_1, M_3)$

Does not work. This need to be implemented in specific function of the vectorize.py module, fully tested, and used for the block multiplication in block.py.

Arguments for `BlockIteration.speedup` method

Hey @JensHahne, just to check with you : I would like to make the speedup method return a tuple (speedup / efficiency) (and eventually, rename it getPerformance, so this would simplify the implementation and use.

I see that for now you provide also the number of processors nProc as argument : but shouldn't this be already determined from the number of block and the schedule_type argument ? Like for BLOCK-BY-BLOCK, nProc=N, for LCF, nProc is determined by the scheduler, etc ... ?

Task costs are partially hardcoded in `taskGraph.py`

Just as a reminder for myself:

Sometimes hardcoded values are used to set the cost of a task in the file taskGraph.py . Currently a warning is generated to not forget this, but needs to be fixed.

Factor with cost-relevant operator

Hi @JensHahne,

following our discussion, here is the image with the correct task factorization for PFASST :

And I pushed a sympy testing script that can serve as basis to find the good sympy manipulation ...

Speedup for $K=0$

Currently the speedup method of BlockIteration returns a very high value for $K=0$ (for instance, in the 03_pinIter.py script, it gives a speedup of 20 for 10 blocks, independently on the schedule_type.

Normally it should be

$$\frac{C_{serial}}{C_{initialGuess}}$$

is it possible to implement this easily @JensHahne ?

Problem with relative path for the app

There is a bug since then with the paths : local version works, but server version only allows to access the index pages,
but not the app pages (or the favicon, etc ...). Using the last commit 48d9b34 on the server now.

Response from @MichelKrispin :

yes I've seen it yesterday and the problem relates to the relative/absolute paths of js/css files. Without a recursive structure the assets path were all relative and in the same route/folder structure. Now, they have to access the same files which are usually at the index route /.
But on the server this absolute path index route maps to the URL https://jupyterhub.mat.tu-harburg.de/ while we would need the URL https://jupyterhub.mat.tu-harburg.de/blockops/.
I tried to fix it with absolute paths that get generated at runtime by Flask which might already fix the problem. So if you upload the latest updates, it might work.