In GitLab by @sloede on Mar 21, 2020, 12:10

ArgParse really takes a long time to compile (time-to-help: >20s vs. <5s if used manually) and does not make much sense for something as simple as Trixi

In GitLab by @sloede on Mar 21, 2020, 22:47

This should be fairly easy, e.g., with a @distributed loop over all files to convert. The only part that is not inherently thread-safe is the writing of the PVD file. This could be achieved, however, by returning the resulting VTK file (currently named vtk) as an array [vtk] and then use vcat as the reduction operator. This should result in an array of VTK files, that can then be written serially to the PVD file.

In GitLab by @sloede on Mar 27, 2020, 17:59

Some of the following information would be helpful:

• number of elements (!)
• number of adaptations since last analysis (?)
• number of surfaces/mortars (?)

@gregorgassner Feel free to add more...

In GitLab by @sloede on May 11, 2020, 14:28

@ranocha started a discussion in #42 about the (mis-)use of type annotations for function parameters, e.g. in src/solvers/dg.jl:

function calc_surface_flux!(surface_flux::Array{Float64, 4}, neighbor_ids::Matrix{Int},
                            u_surfaces::Array{Float64, 4}, dg::Dg, ::Val{true},
                            orientations::Vector{Int})
   ...
end

He suggested to remove type annotations that purely serve documentation purposes and are not required for multiple dispatch (in the example: all but ::Val{true}), and to instead capture the documentation aspects in a docstring instead. To me, this seems like a very reasonable proposal. However, before changing anything in Trixi, it would help (at least me) to have these two questions answered first:

1. What are best practices in the Julia community regarding type annotations for function parameters?
2. What is a good approach for us in Trixi, taking into account added complexity, required effort, and what can be reasonably implemented in practice?

As far as I understand, there are only two cases where you must use type annotations: If it is required for multiple dispatch, or if you use parametric types for which you need to access/use the actual type. In all other cases I can think of, type annotations are optional and, quoting the Julia manual:

Adding annotations serves three primary purposes: to take advantage of Julia's powerful multiple-dispatch mechanism, to improve human readability, and to catch programmer errors.

I think most cases in Trixi belong to the second or third category (or a mixture thereof): We often use type annotations like the ones above to show a user/programmer what kind of function parameters are expected, and to immediately throw an error if a programmer violates this. For example, in DG code we often have methods like flux or cons2prim that could very well work on the entire DG dataset (i.e., all elements, all nodes) or just on a single point.

Thus, back to my questions: What are the best practices ("the Julian way") and how do we want handle this in Trixi? The biggest advantages of the current style (annotations-as-documentation) are IMHO that

1. They are always up to date.
2. They are always use the same "formatting".

The biggest advantages of using docstrings are IMHO

1. It does not abuse the type annotations for documentation, leaving the code more generic in the process.
2. It allows to use Julia's internal doc mechanisms on the REPL
3. Documentation is not just in the code but also on the GitLab Pages website.
   If we start to move towards using non-annotated function parameters together with docstrings, we would have to consider what our own guidelines would be, such that it is easy for students (and for ourselves) to decide when and how to put documentation in docstrings.

I have not yet made up my mind yet about the way we want to handle it in Trixi, but would be very interested in your ideas! Also, I'd by very interested in learning about the "true" Julian way - maybe @ranocha can shed some more light on this, since he is by far the most experienced Julia developer here ;-)

In GitLab by @gregorgassner on Mar 30, 2020, 11:46

I have the feeling that a constant number of visu nodes per element causes artefacts in the paraview visualisation.

It would be more natural, to have a "uniform" visu resolution accross the grid. Say, you choose

6 visu nodes for the finest level, the next level should have 12 nodes, the next level 24 nodes...such that that "data pixels" have the same size.

I have currently in my AMR results some artefacts, and I think (hope) these are related to visualisation issues...

In GitLab by @gregorgassner on May 4, 2020, 10:28

Viscous Terms can be found in https://arxiv.org/abs/1212.5566

Explicit form and numerical tests are here

http://user.it.uu.se/~nazar000/publications/preprints/Nazarov_Larcher.pdf

In GitLab by @sloede on Mar 14, 2020, 22:22

Extend plot2d.jl and trixi2vtu to visualize element-wise data in an easy and intuitive manner. That is, it should be straightforward to, e.g., add the current blending factors to the solution files and then plot them just as regular node-based data would be shown.

In GitLab by @sloede on Mar 17, 2020, 15:54

Extend the current EC mortar capabilities to support ES (entropy-stable) mortars as well.

In GitLab by @gregorgassner on Apr 1, 2020, 16:25

We should update the README, regarding the new visu tool.

Furthermore, is it really necessary to have this extra step:

julia --project='postprocessing/pkg/Trixi2Vtk' -e 'import Pkg; Pkg.instantiate()'

Couldn't we just integrate this step in the first, Trixi setup step?

We always need postprocessing when using Trixi I guess, so no need to separate those two things imo?

In GitLab by @sloede on Mar 27, 2020, 08:35

Fix bin/trixi to always use --project=$PROJECT_DIR when calling Julia. This way, the ] activate . ; instantiate procedure should work to install all required dependencies for Trixi.

In GitLab by @sloede on Mar 17, 2020, 11:41

Currently, the coarsen_elements!/refine_element! use the l2mortar 1D projection matrices and multiply them each time. They could be pre-multiplied to save computing time - check if that makes sense from a performance perspective and if yes, implement it.

In GitLab by @sloede on Mar 15, 2020, 08:23

Depends on #9

In GitLab by @sloede on Mar 15, 2020, 08:20

In GitLab by @sloede on Mar 15, 2020, 08:24

That is, can we just pass dg vs dg.u, dg.ut, ... to functions without a performance penalty? And if yes, how to implement this properly?

In GitLab by @sloede on Mar 23, 2020, 06:25

Right now the installation instructions in the README.md do not work: If you run ] activate . and call instantiate, you can only access the installed packages if you always use --project=path when you start a Julia script. This begs the question, how we want to handle student installation and/or the development workflow for us.

In GitLab by @sloede on Mar 27, 2020, 07:05

This can be helpful if Trixi output data is needed for postprocessing by other programs. It should basically write CSV files in the following format:

# filename = "solution_0000123.h5"
# time = 1.2345
# polydeg = 4
# <other global attributes follow>
x       y       rho     u       v
0.0     0.1     1.0     0.0     0.0
0.0     0.1     1.0     0.0     0.0
...

x and y refer to the node coordinates. In case of solution files with element variables, these should by default not be written (as they would have a different length). Provide a --separate-celldata/-s flag to write this data to a separate file instead, using the element coordinates (not node coordinates!) for x and y.

Mesh files should be handled in a similar way.

The original issue

Id: 39
Title: Add tool for automated EOC analysis

could not be created.
This is a dummy issue, replacing the original one. It contains everything but the original issue description. In case the gitlab repository is still existing, visit the following link to show the original issue:

TODO

In GitLab by @sloede on Mar 15, 2020, 08:26

• split equations into multiple files/folders?
• split DG methods in multiple files?

In GitLab by @sloede on Mar 14, 2020, 22:25

This is necessary...

• for automated testing of the repository using CI/CD pipelines
• to remain sane when new features are developed that are not orthogonal to existing features anymore
• to remain sane when students and other collaborators start contributing code

In GitLab by @sloede on Mar 15, 2020, 08:21

In GitLab by @ranocha on May 13, 2020, 13:22

For packages registered in the general Julia registry, a [compat] section in Project.toml is necessary for automatic merging. This will also allow to drop the Manifest.toml without losing reproducibility. On GitHub, CompatHelper can be used to automate the process of adding/updating the [compat] section but it is not available on Gitlab.

Xref https://gitlab.mi.uni-koeln.de/numsim/code/Trixi.jl/-/merge_requests/43#note_651.

In GitLab by @gregorgassner on Mar 29, 2020, 18:10

It would be good to have the capability to store single quantities in every time step, to make a time series plot. entropy over time, kinetic energy, etc...

In GitLab by @andrewwinters5000 on May 4, 2020, 12:55

The hyperbolic form of the diffusion equation (along with numerical tests) are given in the paper "Reconstructed Discontinuous Galerkin Methods for Hyperbolic Diffusion Equations on Unstructured Grids" found here

In GitLab by @erik-f on May 13, 2020, 13:49

At the moment it seems like there are no parameter files for EOC testing with Euler and MHD.

In GitLab by @sloede on Mar 22, 2020, 17:00

Since dt is generally non-constant for non-linear simulations, writing solution files at constant time step intervals does not make much sense.

In GitLab by @sloede on Mar 14, 2020, 12:25

Store all regular output plus additional debug information in a log file such
that it can be recovered later, e.g., in out/trixi_YYYMMDDHHmmss.log

The logging mechanism of Julia (https://docs.julialang.org/en/v1/stdlib/Logging/) should be used. The idea is the following (roughly as discussed with Gregor):

• All output to console or log files actually goes through logging infrastructure
• We use only two standard log levels, i.e., @info and @debug
  • @info is the normal runtime output
  • @debug is additional output that can help with debugging
• By default, @info goes to stdout while @debug is not evaluated at all.
• If log=True or log=<filename> is provided to run(), all @info messages go additionally to out/trixi.log or out/<filename>.log
• If debug=True is provided to run() (or ENV["JULIA_DEBUG"] is set appropriately), all @debug messages are shown at stdout as well. In combination with log=True/<filename>, however, debug messages will only be shown in the log file.

It might be interesting to enable other default output if logging-to-file is enabled, e.g., to copy the parameters file used to the beginning of the log file, or some information on when and where and with which command line arguments trixi was started.

Potential use cases where it might be interesting to have a permanent log:

• AMR: current number of elements; elements added/removed; number of elements at each level
• shock capturing: information about minimum/maximum alpha values; number of pure DG/blended DG-FV elements

In GitLab by @sloede on Mar 29, 2020, 08:45

Use this issue to discuss and track possible implementations for entropy-stable AMR.

The original issue

Id: 49
Title: Increase test coverage

could not be created.
This is a dummy issue, replacing the original one. It contains everything but the original issue description. In case the gitlab repository is still existing, visit the following link to show the original issue:

TODO

In GitLab by @andrewwinters5000 on Mar 26, 2020, 21:39

should be clarified in the documentation that there is a postprocessing tool for the *.h5 files. Also, there should be another Project.toml because the postprocessing step requires the installation of two additional packages:

• WriteVTK
• ProgressMeter

Also, on my machine running the postprocessing requires the deactivation of saving PVD, tex

postprocessing/trixi2vtu -s --save-pvd=no out/*.h5

In GitLab by @sloede on Apr 6, 2020, 13:01

Right now we use the GaussQuadrature module only for calculating the LG and LGL nodes and weights. I feel like we could just add the implementations here (they were implemented at some point in the very beginning) and drop the dependence on the GaussQuadrature.jl package, which should also slightly improve startup times.

In GitLab by @ranocha on May 7, 2020, 17:07

Hi! I'm totally new to this project and haven't been involved in the discussions and the work resulting in the current version. Hence, I hesitate a bit to start discussions that can possibly necessitate huge changes to your workflow and/or the code. On the other hand, I couldn't find such discussions online (since they probably happened in person) and the resulting comments may be of interest for future users of Trixi.

My first impression of Trixi is that it's heavily inspired by monolithic Fortran codes like Flexi/Fluxo, which is totally natural, of course. In my opinion, a different approach might be useful in Julia: Instead of providing a single executable running a parameter file, an approach to create a library of tools might be of interest.
For example, if a student shall run some experiments with a slightly different initial condition, Trixi itself has to be modified, e.g. at https://gitlab.mi.uni-koeln.de/numsim/code/Trixi.jl/-/blob/master/src/equations/linearscalaradvection.jl#L46.
An alternative to parameter files could be to supply the parameters as pure Julia code using the Trixi library. In that case, students could write the initial condition as a Julia function without the need to modify Trixi itself. Since functions are first-class citizens in Julia, they can be passed around as arguments (or as part of structs).

The structure of Trixi using many modules and global variables reminds me of Fortran modules etc. While using constant global variables is okay (type stable) in Julia, passing parameters is more encouraged.

Another reminder of Fortran and co are the type annotations for function arguments. Unless they direct multiple dispatch, they shouldn't be used in Julia.

function calc_surface_flux!(surface_flux, neighbor_ids,
                            u_surfaces, dg::D, ::Val{true},
                            orientations)
   ...
end

is compiled to exactly the same machine code as

function calc_surface_flux!(surface_flux::Array{Float64, 4}, neighbor_ids::Matrix{Int},
                            u_surfaces::Array{Float64, 4}, dg::Dg, ::Val{true},
                            orientations::Vector{Int})
   ...
end

if the arguments are the same. The first version is more general, since the array type can be exchanged. For example, it is possible to use the same code to run a simulation with Float32 (or possibly some floating point type with higher accuracy), which can be useful sometimes. I prefer to include the additional kind of documentation provided by the type annotations in docstrings for the functions.

The multiple dispatch feature of Julia seems to be abused sometimes in the current version, e.g. in https://gitlab.mi.uni-koeln.de/numsim/code/Trixi.jl/-/blob/master/src/solvers/dg.jl#L1171. Such type-unstable code results in a possibly huge performance impact.
For example, I started from the current master branch with this git diff.

diff --git a/parameters_ec.toml b/parameters_ec.toml
index 8cd35d1..3bf5612 100644
--- a/parameters_ec.toml
+++ b/parameters_ec.toml
@@ -18,7 +18,7 @@ volume_flux_type = "chandrashekar_ec"
 # volume_flux_type = "central"
 # sources = 
 t_start = 0.0
-t_end   = 0.4
+t_end   = 4.0 # 0.4
 
 # restart = true
 # restart_filename = "out/restart_000100.h5"
diff --git a/src/equations/euler.jl b/src/equations/euler.jl
index c3978b9..5fdc582 100644
--- a/src/equations/euler.jl
+++ b/src/equations/euler.jl
@@ -670,62 +670,67 @@ function Equations.riemann!(surface_flux::AbstractArray{Float64, 1},
   calcflux1D!(f_ll, equation, rho_ll, rho_v1_ll, rho_v2_ll, rho_e_ll, orientation)
   calcflux1D!(f_rr, equation, rho_rr, rho_v1_rr, rho_v2_rr, rho_e_rr, orientation)
 
-  if equation.surface_flux_type == :laxfriedrichs
-    λ_max = max(v_mag_ll, v_mag_rr) + max(c_ll, c_rr)
-    surface_flux[1] = 1/2 * (f_ll[1] + f_rr[1]) - 1/2 * λ_max * (rho_rr    - rho_ll)
-    surface_flux[2] = 1/2 * (f_ll[2] + f_rr[2]) - 1/2 * λ_max * (rho_v1_rr - rho_v1_ll)
-    surface_flux[3] = 1/2 * (f_ll[3] + f_rr[3]) - 1/2 * λ_max * (rho_v2_rr - rho_v2_ll)
-    surface_flux[4] = 1/2 * (f_ll[4] + f_rr[4]) - 1/2 * λ_max * (rho_e_rr  - rho_e_ll)
-  elseif equation.surface_flux_type in (:central, :kennedygruber, :chandrashekar_ec, :yuichi)
-    symmetric_twopoint_flux!(surface_flux, Val(equation.surface_flux_type),
-                             equation, orientation,
-                             rho_ll, rho_v1_ll, rho_v2_ll, rho_e_ll,
-                             rho_rr, rho_v1_rr, rho_v2_rr, rho_e_rr)
-
-  elseif equation.surface_flux_type == :hllc
-    error("not yet implemented or tested")
-    v_tilde = (sqrt(rho_ll) * v_ll + sqrt(rho_rr) * v_rr) / (sqrt(rho_ll) + sqrt(rho_rr))
-    h_ll = (rho_e_ll + p_ll) / rho_ll
-    h_rr = (rho_e_rr + p_rr) / rho_rr
-    h_tilde = (sqrt(rho_ll) * h_ll + sqrt(rho_rr) * h_rr) / (sqrt(rho_ll) + sqrt(rho_rr))
-    c_tilde = sqrt((equation.gamma - 1) * (h_tilde - 1/2 * v_tilde^2))
-    s_ll = v_tilde - c_tilde
-    s_rr = v_tilde + c_tilde
-
-    if s_ll > 0
-      surface_flux[1, surface_id] = f_ll[1]
-      surface_flux[2, surface_id] = f_ll[2]
-      surface_flux[3, surface_id] = f_ll[3]
-    elseif s_rr < 0
-      surface_flux[1, surface_id] = f_rr[1]
-      surface_flux[2, surface_id] = f_rr[2]
-      surface_flux[3, surface_id] = f_rr[3]
-    else
-      s_star = ((p_rr - p_ll + rho_ll * v_ll * (s_ll - v_ll) - rho_rr * v_rr * (s_rr - v_rr))
-                / (rho_ll * (s_ll - v_ll) - rho_rr * (s_rr - v_rr)))
-      if s_ll <= 0 && 0 <= s_star
-        surface_flux[1, surface_id] = (f_ll[1] + s_ll *
-            (rho_ll * (s_ll - v_ll)/(s_ll - s_star) - rho_ll))
-        surface_flux[2, surface_id] = (f_ll[2] + s_ll *
-            (rho_ll * (s_ll - v_ll)/(s_ll - s_star) * s_star - rho_v_ll))
-        surface_flux[3, surface_id] = (f_ll[3] + s_ll *
-            (rho_ll * (s_ll - v_ll)/(s_ll - s_star) *
-            (rho_e_ll/rho_ll + (s_star - v_ll) * (s_star + rho_ll/(rho_ll * (s_ll - v_ll))))
-            - rho_e_ll))
-      else
-        surface_flux[1, surface_id] = (f_rr[1] + s_rr *
-            (rho_rr * (s_rr - v_rr)/(s_rr - s_star) - rho_rr))
-        surface_flux[2, surface_id] = (f_rr[2] + s_rr *
-            (rho_rr * (s_rr - v_rr)/(s_rr - s_star) * s_star - rho_v_rr))
-        surface_flux[3, surface_id] = (f_rr[3] + s_rr *
-            (rho_rr * (s_rr - v_rr)/(s_rr - s_star) *
-            (rho_e_rr/rho_rr + (s_star - v_rr) * (s_star + rho_rr/(rho_rr * (s_rr - v_rr))))
-            - rho_e_rr))
-      end
-    end
-  else
-    error("unknown Riemann solver '$(string(equation.surface_flux_type))'")
-  end
+  symmetric_twopoint_flux!(surface_flux, Val(:chandrashekar_ec),
+                           equation, orientation,
+                           rho_ll, rho_v1_ll, rho_v2_ll, rho_e_ll,
+                           rho_rr, rho_v1_rr, rho_v2_rr, rho_e_rr)
+
 end
 
 # Original riemann! implementation, non-optimized but easier to understand

If I understood the code correctly, the result should be the same since I use surface_flux_type = "chandrashekar_ec" in parameters_ec.toml. (Of course, this code is less general but it serves the purpose to demonstrate type stability in a simple way.)
Running the current master with this parameters_ec.toml, I get

              trixi                     Time                   Allocations      
                                ----------------------   -----------------------
        Tot / % measured:            18.1s / 99.5%            589MiB / 83.5%    

 Section                ncalls     time   %tot     avg     alloc   %tot      avg
 -------------------------------------------------------------------------------
 main loop                   1    18.0s   100%   18.0s    480MiB  97.5%   480MiB
   rhs                   1.75k    17.3s  95.8%  9.88ms   99.2MiB  20.2%  58.1KiB
     surface flux        1.75k    13.6s  75.5%  7.78ms   10.2MiB  2.06%  5.95KiB
     volume integral     1.75k    2.89s  16.0%  1.65ms   76.3MiB  15.5%  44.6KiB
     ...

With the type stable version from git diff, I get

        Tot / % measured:            5.22s / 90.0%            675MiB / 73.0%    

 Section                ncalls     time   %tot     avg     alloc   %tot      avg
 -------------------------------------------------------------------------------
 main loop                   1    4.70s   100%   4.70s    480MiB  97.5%   480MiB
   rhs                   1.75k    3.99s  84.8%  2.28ms   99.3MiB  20.2%  58.1KiB
     volume integral     1.75k    2.92s  62.2%  1.67ms   76.3MiB  15.5%  44.6KiB
     ...
     surface flux        1.75k    235ms  4.99%   134μs   10.2MiB  2.07%  5.97KiB

That impact is way more than I expected - I hope I didn't code bullshit here...
The additional git diff

diff --git a/src/equations/euler.jl b/src/equations/euler.jl
index c3978b9..b1f1b73 100644
--- a/src/equations/euler.jl
+++ b/src/equations/euler.jl
@@ -358,7 +358,9 @@ end
                                               equation::Euler,
                                               u::AbstractArray{Float64},
                                               element_id::Int, n_nodes::Int)
-  calcflux_twopoint!(f1, f2, f1_diag, f2_diag, Val(equation.volume_flux_type),
+  # calcflux_twopoint!(f1, f2, f1_diag, f2_diag, Val(equation.volume_flux_type),
+  #                    equation, u, element_id, n_nodes)
+  calcflux_twopoint!(f1, f2, f1_diag, f2_diag, Val(:chandrashekar_ec),
                      equation, u, element_id, n_nodes)
 end

improves the performance for the volume terms to

        Tot / % measured:            3.13s / 97.4%            576MiB / 83.2%    

 Section                ncalls     time   %tot     avg     alloc   %tot      avg
 -------------------------------------------------------------------------------
 main loop                   1    3.04s   100%   3.04s    467MiB  97.5%   467MiB
   rhs                   1.75k    2.25s  73.9%  1.29ms   85.6MiB  17.9%  50.1KiB
     volume integral     1.75k    1.20s  39.5%   687μs   62.6MiB  13.1%  36.6KiB
     ...
     surface flux        1.75k    237ms  7.79%   136μs   10.2MiB  2.13%  5.97KiB

A general solution to get type stable code in a library like approach could be to use parametric types and supply the fluxes as Julia functions instead of strings or symbols.

I saw the additional repositories Abraxas and trixi-tests but haven't looked at them yet. In Julia, it is pretty common to include some (unit) tests in every package which are triggered for every PR on GitHub (merge request on GitLab). In this way, some additional example code is provided and some basic functionality is guaranteed to work with new changes. While I didn't like that approach at the beginning (since I wasn't used to it), I really started to like it while developing more complex code, in particular if some time has passed between development cycles. I think it would be really nice if some small/basic tests are included here in test/runtests.jl etc. They could be triggered for every merge request as GitLab pipeline, I think. If Trixi shall be registered as Julia package (as hinted to in https://gitlab.mi.uni-koeln.de/numsim/code/Trixi.jl/-/issues/20#note_276), running tests and reporting coverage results (e.g. via Travis and Codecov/Coveralls) is usually seen as a requirement and sign of good coding standards.

Okay, this grew into a lot of text. I hope we can start a constructive discussion and improve Trixi, building on your nice work :)

In GitLab by @sloede on May 9, 2020, 07:55

As suggested by @ranocha in #42, it would be great to have tests run automatically whenever a MR is created/updated or once master is changed. Right now, the only testing tool we have is Abraxas.jl, with tests being defined in trixi-tests. However, since it requires a setup process for testing (i.e., clone & instantiate external packages), it is somewhat cumbersome to set up for testing and not very Julian.

A more Julian way would be to follow @ranocha's lead and use (abuse) Julia's canonical unit testing capabilities for packages, which uses test/runtests.jl to set up automated testing (docs) and employs the unit testing capabilities in Julia Base with @test and @testset (docs).

One reason I have shunned away from this approach so far is that it does not allow to do full integration testing in a sane manner. That is, for a full-fledged test of Trixi, you should run an entire simulation setup and then compare all output files with some references. However, for this to work, you have to be able to store (and more importantly, update) reference files, which quickly and significantly increases the repository size. However, @erik-f has started to implement a convtest function for easy h-convergence testing in !41. Among other changes, run now returns the final L2/Linf errors calculated. Therefore, we could use this information together with the already-present parameter files to set up some simple Trixi tests in a Julian way and without the need for a more sophisticated testing infrastructure. It would only be able to confirm that the L2/Linf errors are correct, but in many cases that is enough to detect breaking changes (or errors) in an implementation.

Therefore, I propose the following changes:

1. Move all parameters file from the root directory to a separate directory, e.g., examples/.
2. Once !41 is merged, create tests in test/runtests.jl that cover a broad range of "features" in Trixi by running the appropriate parameter files from examples/ and comparing the resulting L2/Linf errors (with a tolerance, of course).
3. Set up our CI/CD pipelines to run these tests at least for every MR and every push to master.

Trixi "features" that should be tested are:

• All systems of equations: linear scalar advection, Euler, MHD
• Static local refinement/mortars
• AMR
• Shock capturing
• EC/ES
• Source terms
• ... (feel free to add to this list!)

While this will not provide us with anything like absolute quality assurance, I see this as a quick way forward towards improving confidence that we do not break existing functionality with new commits. In the future, we can even use this to show code coverage results for the automated testing.

As usual, please feel free to discuss and improve!

In GitLab by @sloede on Mar 15, 2020, 08:22

• u_t -> ut for consistency with FLUXO
• weights -> weights1d (also add weights2d)
• nodes -> nodes1d (also add nodes2d)
• inverse_jacobian -> inverse_jacobian1d (also add jacobian1d, jacobian2d
• All "getter" methods that obtain a certain attribute from an object should be prefixed by get such that the original name is free to be used as the variable name.
  Examples: nnodes, polydeg, nelements, nsurfaces,

In GitLab by @sloede on Mar 12, 2020, 09:20

Currently, our timings/allocations for parameters_ec.toml for our two most expensive kernels look like this:

     volume integral        190    13.2s  54.3%  69.2ms   4.33GiB  81.6%  23.4MiB
     surface flux           190    9.20s  38.0%  48.4ms    718MiB  13.2%  3.78MiB

This should be improved considerably if we want to

In GitLab by @ranocha on May 18, 2020, 12:35

Right now, the volume and surface fluxes are part of the equations/models. In my opinion, they belong more to the specific discretization (DG) and a lax_friedrichs_flux can be used for all models/equations (with specific methods implemented there).

In GitLab by @sloede on Mar 10, 2020, 14:38

Separate differentiation_matrix into individual matrices and keep all matrices around all the time (i.e., D, Dhat, Dsplit)

In GitLab by @gregorgassner on Apr 6, 2020, 13:40

The goal is to bring over new technology from Fluxo, based on the shock capturing to implement automatic positivity preservation.

The original issue

Id: 47
Title: Add L2/Linf checking to tests

could not be created.
This is a dummy issue, replacing the original one. It contains everything but the original issue description. In case the gitlab repository is still existing, visit the following link to show the original issue:

TODO

In GitLab by @sloede on Apr 14, 2020, 07:24

From time to time it is useful to twiddle with a parameter to figure out what its optimal setting is to just remain stable. Examples: CFL number for different time integration schemes, solution resolution, intensity of shock capturing etc.
Instead of figuring this out manually, it would be nice to automate this in an easy-to-use and robust way.

As a starting point for thoughts on an implementation:

Instead of starting Trixi with

Trixi.run("parameters.toml")

we add a new run-like method bisect, e.g., like this

Trixi.bisect("parameters.toml", :CFL, (0.4, 1.4), max_l2=1.0, max_linf=nothing, precision=0.01)

This should run Trixi multiple times with a bisection algorithm, using parameters.toml as the base configuration, always changing (= overriding) the value of CFL, which should range between 0.4 and 1.4, and optimize it with a precision of up to 2 decimal places. As a stability indicator, we define "unstable" as the L2 error being > 1.0, and we use no criterion on Linf.

Feel free to chime in if you have thoughts on a possible implementation or if you find other cases where such a feature might be interesting.

In GitLab by @andrewwinters5000 on Mar 30, 2020, 20:43

Just add the capability to solve the standard MHD equations with LLF or HLLC type numerical fluxes. No GLM or entropy stuff. Those features come next...

In GitLab by @sloede on Mar 25, 2020, 09:05

In GitLab by @sloede on Apr 3, 2020, 08:11

Someone accidentally committed a 70M file (ffmpeg) to the amr_finetuning branch. I found a way that probably fixes it and will keep the rest of the repo's history intact:

https://rtyley.github.io/bfg-repo-cleaner/

However, to minimize the chances for any screw ups, we should follow the following strategy:

1. Commit all current work to the amr_finetuning branch.
2. Delete ffmpeg from the amr_finetuning branch.
3. Delete MR !24 since it will be affected by the cleanup and I don't know if GitLab will break as a result
4. I do the cleanup
5. Everyone has to git fetch/git pull their amr_finetuning branch.

@gregorgassner I think you are the only one affected by 1), so please let me know once you've done that (afterwards you need to stop working on the branch). Steps 2) - 4) I will be able to do alone, but we can also do it in a shared session if you prefer.

In GitLab by @sloede on Apr 9, 2020, 07:33

Current we are tracking a specific commit of https://github.com/KristofferC/TimerOutputs.jl in Manifest.toml. Once the @notimeit functionality has made it into a proper new release of the TimerOutputs package, we should again track the regular release and not a specific commit.

In GitLab by @sloede on Mar 18, 2020, 13:01

That is, first apply 1D projections for each line in the x-direction, then in the y-direction. Probably interpolate_nodes can already be used for this. This should be much cheaper than the current approach, which does the full projection.

Maybe there is also potential to use this for mortar projections (probably not, since they are already 1D).

In GitLab by @ranocha on May 14, 2020, 16:05

Since Julia allows us to use unicode (which I really like), we might consider making use of that possibility. For example, we could write l∞ instead of linf for errors in the maximum norm. Another use case is γ instead of gamma for the Euler equations and its siblings.

In the REPL and most major editors, you can use LaTeX extensions, e.g. l\infty and TAB to get l∞.

In GitLab by @sloede on Mar 24, 2020, 13:27

In GitLab by @andrewwinters5000 on Apr 9, 2020, 07:20

Look into FLUXO to decipher (and simplify) how to implement the nonconservative terms for MHD. Right now the goal of this if the following:

1. If you run MHD the GLM will always be activated so there are no if statements in the code to deactivate it.

2. Only implement the Powell term because it is the most physically consistent (removes fictious Lorentz force).

3. Both nonconservative terms are proportional to div(B) and related to the cleaning of it. Therefore, the Powell term and Galilean term should always be active and work with the standard or split DG

4. Nonconservative terms should only alter the flux computation (in the volume and on the boundary) within the MHD module. In this sense the new implementation will not touch the dg.jl or dg_amr.jl portion. This way the nonconservative contribution will not spoil the non-conforming/AMR capabilities

5. Exploit the Cartesian simplicity of the normals and metrics such that everything (hopefully) comes down to an orientation check (similar to the physical flux)

6. After the nonconservative terms are implemented and tested, implement the entropy conservative and entropy stable fluxes for MHD

In GitLab by @sloede on Mar 22, 2020, 08:08

Similar to what is done in FLUXO, FLEXI, ZFS.

In GitLab by @andrewwinters5000 on Mar 27, 2020, 08:13

On line 116 of README.md I think there is a typo. It says to use a file "postprocessing/plotfast.jl" and I think this needs to be "postprocessing/plot2d.jl". Also, these instructions for plotting do not work for me (I use Atom for my Julia coding). When I run TrixiPlot.main() it says that the main is not defined (see below):

In GitLab by @sloede on Mar 14, 2020, 09:58

Currently, rhs! contains duplicated code: one version with timers, one without timers. The reason is that a call to rhs! is needed for the entropy time derivative to work (from calc_entropy_timederivative). Optimally, it should be possible to either

• pass an argument to rhs! that disables timing without duplicated code, or
• write a macro that can disable timers from "outside", i.e., from the call site.

Corresponding question on Discourse: https://discourse.julialang.org/t/disable-timeroutputs-jl-timers-selectively-within-function/35957