Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add type parameter NDIMS_AMBIENT to P4estMesh for dimension of ambient space #2068

Merged
merged 14 commits into from
Sep 11, 2024

Conversation

tristanmontoya
Copy link
Member

@tristanmontoya tristanmontoya commented Sep 5, 2024

This PR supersedes #2046 in order to facilitate the solution of PDEs on two-dimensional manifolds in three-dimensional space using TrixiAtmo.jl and the visualization of such solutions using trixi-framework/Trixi2Vtk.jl#82.

With the proposed change, P4estMesh{NDIMS, NDIMS_AMBIENT} represents a tessellation of a manifold of dimension NDIMS defined within an ambient space of dimension NDIMS_AMBIENT. The parameter NDIMS_AMBIENT is set within the inner constructor of P4estMesh to size(tree_node_coordinates, 1).

Note that I have added NDIMS_AMBIENT as the second type parameter, so all uses of P4estMesh{NDIMS, RealT} and P4estMesh{NDIMS, RealT, IsParallel} are no longer valid, and have been replaced accordingly in this PR. All methods dispatching on such types should be specialized to P4estMesh{NDIMS, NDIMS, ... } if one does not intend to allow manifolds embedded in higher dimensional spaces. For example, this would affect @SimonCan's PR #1761 on this line here.

While calc_node_coordinates! and create_cache_analysis have been updated in both 2D and 3D to allow for NDIMS != NDIMS_AMBIENT, I have specialized init_elements to require P4estMesh{NDIMS, NDIMS}. This is because TrixiAtmo.jl defines its own containers using PtrArray and computes specialized metric terms for the spherical shell using P4estMesh{2, 3}, which we wanted to keep separate from the main Trixi.jl package. So, with this PR, the user is free to define a mesh using P4estMesh{NDIMS, NDIMS_AMBIENT} with NDIMS != NDIMS_AMBIENT, but they would have to define their own init_elements to specialize the metric terms for the desired application, as we do in TrixiAtmo.jl. At some point, we could consider generalizing init_elements and the associated containers to allow for the treatment of arbitrary manifolds (in which case, the functionality could be merged into Trixi.jl, rather than TrixiAtmo), but I have taken the YAGNI approach here and deferred that to future work.

Although I have labelled this as a breaking change, the vast majority of methods using P4estMesh dispatch only on the first type parameter, NDIMS, and this PR does not affect such uses. Therefore, the typical user of Trixi.jl can continue to use P4estMesh{NDIMS} without having to think about NDIMS_AMBIENT at all. Because of this, I have chosen to keep the docstring as P4estMesh{NDIMS}, although I am open to changing this if we decide to document this feature as part of Trixi's public API.

Regarding performance, the type instability from #2046 is now gone, and we get similar runtimes as before when calling calc_node_coordinates!. To see this, let's run the following code:

julia> using Trixi, BenchmarkTools

julia> solver = DGSEM(polydeg = 3, surface_flux = flux_lax_friedrichs);

julia> mesh_2d = P4estMesh((8, 8), polydeg = 3,
                        coordinates_min = (-1.0, -1.0), coordinates_max = (1.0, 1.0),
                        initial_refinement_level = 1);

julia> elements_2d = Trixi.init_elements(mesh_2d, LinearScalarAdvectionEquation2D((1.0, 1.0)), solver.basis, Float64);

julia> mesh_3d = P4estMesh((8, 8, 8), polydeg = 3,
                        coordinates_min = (-1.0, -1.0, -1.0), coordinates_max = (1.0, 1.0, 1.0),
                        initial_refinement_level = 1);

julia> elements_3d = Trixi.init_elements(mesh_3d, LinearScalarAdvectionEquation3D((1.0, 1.0, 1.0)), solver.basis, Float64);

With the current main, we get the following benchmarks:

julia> @benchmark Trixi.calc_node_coordinates!(elements_2d.node_coordinates, mesh_2d, solver.basis.nodes)
BenchmarkTools.Trial: 10000 samples with 1 evaluation.
 Range (min … max):  23.375 μs … 54.334 μs  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     23.666 μs              ┊ GC (median):    0.00%
 Time  (mean ± σ):   23.863 μs ±  1.331 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

    █▅▃█                                                       
  ▂▃████▇▅▆▃▃▃▂▂▂▂▂▄▃▃▃▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▁▂▂▁▂▁▂▂▂▂▂▂▂ ▃
  23.4 μs         Histogram: frequency by time        26.7 μs <

 Memory estimate: 4.23 KiB, allocs estimate: 73.

julia> @benchmark Trixi.calc_node_coordinates!(elements_3d.node_coordinates, mesh_3d, solver.basis.nodes)
BenchmarkTools.Trial: 1266 samples with 1 evaluation.
 Range (min … max):  3.100 ms … 114.796 ms  ┊ GC (min … max):  0.00% … 96.14%
 Time  (median):     3.330 ms               ┊ GC (median):     0.00%
 Time  (mean ± σ):   3.935 ms ±   3.275 ms  ┊ GC (mean ± σ):  13.38% ± 14.97%

  ▇█                                                           
  ██▇▄▃▃▃▃▃▃▃▃▃▄▅▃▃▃▃▂▂▂▂▁▁▂▁▁▂▁▂▁▂▁▂▁▁▂▂▂▂▃▃▃▃▃▃▃▄▃▃▃▃▃▃▃▃▂▂ ▃
  3.1 ms          Histogram: frequency by time         5.9 ms <

 Memory estimate: 16.52 MiB, allocs estimate: 41477.

With the proposed changes, the performance is similar:

julia> @benchmark Trixi.calc_node_coordinates!(elements_2d.node_coordinates, mesh_2d, solver.basis.nodes)
BenchmarkTools.Trial: 10000 samples with 1 evaluation.
 Range (min … max):  23.375 μs …  52.750 μs  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     23.917 μs               ┊ GC (median):    0.00%
 Time  (mean ± σ):   23.944 μs ± 847.041 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

     ▅█▂ ▅▃      ▂▇ ▇▅▃▂                                        
  ▂▃▇███▆███▇▃▄▅▆██▁████▇▄▃▅▅▅▅▃▄▄▄▃▃▁▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▁▂▂▂▂▂▂ ▄
  23.4 μs         Histogram: frequency by time         25.5 μs <

 Memory estimate: 4.23 KiB, allocs estimate: 73.

julia> @benchmark Trixi.calc_node_coordinates!(elements_3d.node_coordinates, mesh_3d, solver.basis.nodes)
BenchmarkTools.Trial: 1254 samples with 1 evaluation.
 Range (min … max):  3.127 ms … 116.124 ms  ┊ GC (min … max):  0.00% … 96.37%
 Time  (median):     3.382 ms               ┊ GC (median):     0.00%
 Time  (mean ± σ):   3.979 ms ±   3.303 ms  ┊ GC (mean ± σ):  13.10% ± 14.73%

   ▆█                                                          
  ▅██▆▄▃▃▃▃▃▃▃▃▄▃▄▄▃▃▂▂▂▂▂▂▂▁▁▁▁▁▁▂▁▁▁▁▁▁▂▂▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▂▂▂ ▃
  3.13 ms         Histogram: frequency by time        5.91 ms <

 Memory estimate: 16.52 MiB, allocs estimate: 41477.

Running a more complete case, examples/p4est_2d_dgsem/elixir_euler_blast_wave_amr.jl, using julia --threads 1 on my MacBook Air M1, we also see no significant change. With the current main, we get the following:

 ──────────────────────────────────────────────────────────────────────────────────────
               Trixi.jl                       Time                    Allocations      
                                     ───────────────────────   ────────────────────────
          Tot / % measured:               25.1s /  97.2%           2.40GiB / 100.0%    

 Section                     ncalls     time    %tot     avg     alloc    %tot      avg
 ──────────────────────────────────────────────────────────────────────────────────────
 rhs!                         15.6k    22.1s   90.7%  1.42ms   85.4KiB    0.0%    5.62B
   volume integral            15.6k    18.3s   75.0%  1.18ms   76.1KiB    0.0%    5.00B
     blended DG-FV            15.6k    13.5s   55.3%   868μs     0.00B    0.0%    0.00B
     pure DG                  15.6k    3.71s   15.2%   238μs     0.00B    0.0%    0.00B
     blending factors         15.6k    1.00s    4.1%  64.4μs   48.2KiB    0.0%    3.17B
     ~volume integral~        15.6k    101ms    0.4%  6.46μs   27.8KiB    0.0%    1.83B
   interface flux             15.6k    1.34s    5.5%  85.8μs     0.00B    0.0%    0.00B
   prolong2interfaces         15.6k    576ms    2.4%  37.0μs     0.00B    0.0%    0.00B
   surface integral           15.6k    560ms    2.3%  36.0μs     0.00B    0.0%    0.00B
   boundary flux              15.6k    395ms    1.6%  25.4μs     0.00B    0.0%    0.00B
   mortar flux                15.6k    370ms    1.5%  23.8μs     0.00B    0.0%    0.00B
   Jacobian                   15.6k    259ms    1.1%  16.6μs     0.00B    0.0%    0.00B
   prolong2mortars            15.6k    178ms    0.7%  11.4μs     0.00B    0.0%    0.00B
   reset ∂u/∂t                15.6k    118ms    0.5%  7.57μs     0.00B    0.0%    0.00B
   prolong2boundaries         15.6k   19.5ms    0.1%  1.25μs     0.00B    0.0%    0.00B
   ~rhs!~                     15.6k   11.8ms    0.0%   757ns   9.33KiB    0.0%    0.61B
   source terms               15.6k    187μs    0.0%  12.0ns     0.00B    0.0%    0.00B
 AMR                            622    1.87s    7.6%  3.00ms   2.34GiB   97.7%  3.85MiB
   refine                       622    915ms    3.7%  1.47ms   1.14GiB   47.8%  1.88MiB
     mesh                       622    462ms    1.9%   743μs   7.29MiB    0.3%  12.0KiB
       rebalance                622    445ms    1.8%   715μs     0.00B    0.0%    0.00B
       ~mesh~                   622   8.57ms    0.0%  13.8μs   7.29MiB    0.3%  12.0KiB
       refine                   622   8.37ms    0.0%  13.5μs     0.00B    0.0%    0.00B
     solver                     622    453ms    1.9%   728μs   1.14GiB   47.5%  1.87MiB
     ~refine~                   622    140μs    0.0%   224ns   1.47KiB    0.0%    2.42B
   coarsen                      622    895ms    3.7%  1.44ms   1.19GiB   49.6%  1.96MiB
     mesh                       622    454ms    1.9%   729μs   29.8MiB    1.2%  49.0KiB
       rebalance                622    412ms    1.7%   663μs     0.00B    0.0%    0.00B
       ~mesh~                   622   32.2ms    0.1%  51.8μs   23.3MiB    0.9%  38.3KiB
       coarsen!                 622   8.85ms    0.0%  14.2μs   6.49MiB    0.3%  10.7KiB
     solver                     622    442ms    1.8%   710μs   1.16GiB   48.4%  1.91MiB
     ~coarsen~                  622    187μs    0.0%   301ns   1.47KiB    0.0%    2.42B
   indicator                    622   49.3ms    0.2%  79.3μs   4.47MiB    0.2%  7.35KiB
   ~AMR~                        622   7.58ms    0.0%  12.2μs   2.86MiB    0.1%  4.70KiB
 analyze solution                33    171ms    0.7%  5.17ms   6.28MiB    0.3%   195KiB
 calculate dt                 3.11k    146ms    0.6%  46.8μs     0.00B    0.0%    0.00B
 I/O                             34   80.7ms    0.3%  2.37ms   43.7MiB    1.8%  1.28MiB
   save solution                 33   38.0ms    0.2%  1.15ms   43.4MiB    1.8%  1.32MiB
   save mesh                     33   35.6ms    0.1%  1.08ms    234KiB    0.0%  7.10KiB
   get element variables         33   4.30ms    0.0%   130μs   3.19KiB    0.0%    98.9B
   ~I/O~                         34   2.81ms    0.0%  82.6μs   49.5KiB    0.0%  1.45KiB
   get node variables            33   1.54μs    0.0%  46.6ns     0.00B    0.0%    0.00B
 initial condition AMR            1   4.91ms    0.0%  4.91ms   7.50MiB    0.3%  7.50MiB
   AMR                            3   4.16ms    0.0%  1.39ms   7.49MiB    0.3%  2.50MiB
     refine                       3   3.94ms    0.0%  1.31ms   6.17MiB    0.3%  2.06MiB
       mesh                       3   2.29ms    0.0%   765μs   25.8KiB    0.0%  8.61KiB
         rebalance                3   2.18ms    0.0%   728μs     0.00B    0.0%    0.00B
         refine                   3   74.5μs    0.0%  24.8μs     0.00B    0.0%    0.00B
         ~mesh~                   3   37.5μs    0.0%  12.5μs   25.8KiB    0.0%  8.61KiB
       solver                     3   1.64ms    0.0%   548μs   6.14MiB    0.3%  2.05MiB
       ~refine~                   3    791ns    0.0%   264ns   1.47KiB    0.0%     501B
     indicator                    3    145μs    0.0%  48.2μs   73.8KiB    0.0%  24.6KiB
     ~AMR~                        3   76.3μs    0.0%  25.4μs   1.25MiB    0.1%   427KiB
     coarsen                      3    166ns    0.0%  55.3ns      192B    0.0%    64.0B
   ~initial condition AMR~        1    754μs    0.0%   754μs      752B    0.0%     752B
 ──────────────────────────────────────────────────────────────────────────────────────

With the new code:

──────────────────────────────────────────────────────────────────────────────────────
              Trixi.jl                       Time                    Allocations      
                                    ───────────────────────   ────────────────────────
         Tot / % measured:               25.2s /  97.2%           2.40GiB / 100.0%    

Section                     ncalls     time    %tot     avg     alloc    %tot      avg
──────────────────────────────────────────────────────────────────────────────────────
rhs!                         15.6k    22.2s   90.4%  1.42ms   85.4KiB    0.0%    5.62B
  volume integral            15.6k    18.3s   74.8%  1.18ms   76.1KiB    0.0%    5.00B
    blended DG-FV            15.6k    13.5s   55.1%   868μs     0.00B    0.0%    0.00B
    pure DG                  15.6k    3.72s   15.2%   239μs     0.00B    0.0%    0.00B
    blending factors         15.6k    1.00s    4.1%  64.4μs   48.2KiB    0.0%    3.17B
    ~volume integral~        15.6k    101ms    0.4%  6.47μs   27.8KiB    0.0%    1.83B
  interface flux             15.6k    1.34s    5.4%  85.8μs     0.00B    0.0%    0.00B
  prolong2interfaces         15.6k    581ms    2.4%  37.3μs     0.00B    0.0%    0.00B
  surface integral           15.6k    559ms    2.3%  35.9μs     0.00B    0.0%    0.00B
  boundary flux              15.6k    396ms    1.6%  25.4μs     0.00B    0.0%    0.00B
  mortar flux                15.6k    370ms    1.5%  23.7μs     0.00B    0.0%    0.00B
  Jacobian                   15.6k    259ms    1.1%  16.6μs     0.00B    0.0%    0.00B
  prolong2mortars            15.6k    174ms    0.7%  11.2μs     0.00B    0.0%    0.00B
  reset ∂u/∂t                15.6k    118ms    0.5%  7.57μs     0.00B    0.0%    0.00B
  prolong2boundaries         15.6k   19.7ms    0.1%  1.27μs     0.00B    0.0%    0.00B
  ~rhs!~                     15.6k   12.7ms    0.1%   814ns   9.33KiB    0.0%    0.61B
  source terms               15.6k    194μs    0.0%  12.4ns     0.00B    0.0%    0.00B
AMR                            622    1.92s    7.8%  3.08ms   2.34GiB   97.7%  3.86MiB
  refine                       622    952ms    3.9%  1.53ms   1.15GiB   47.8%  1.89MiB
    mesh                       622    489ms    2.0%   786μs   7.30MiB    0.3%  12.0KiB
      rebalance                622    466ms    1.9%   749μs     0.00B    0.0%    0.00B
      ~mesh~                   622   13.7ms    0.1%  22.1μs   7.30MiB    0.3%  12.0KiB
      refine                   622   9.35ms    0.0%  15.0μs     0.00B    0.0%    0.00B
    solver                     622    463ms    1.9%   745μs   1.14GiB   47.5%  1.88MiB
    ~refine~                   622    183μs    0.0%   294ns   1.47KiB    0.0%    2.42B
  coarsen                      622    904ms    3.7%  1.45ms   1.19GiB   49.5%  1.96MiB
    solver                     622    456ms    1.9%   733μs   1.16GiB   48.3%  1.91MiB
    mesh                       622    448ms    1.8%   720μs   29.8MiB    1.2%  49.0KiB
      rebalance                622    416ms    1.7%   668μs     0.00B    0.0%    0.00B
      ~mesh~                   622   20.7ms    0.1%  33.3μs   23.3MiB    0.9%  38.3KiB
      coarsen!                 622   11.5ms    0.0%  18.5μs   6.49MiB    0.3%  10.7KiB
    ~coarsen~                  622    204μs    0.0%   327ns   1.47KiB    0.0%    2.42B
  indicator                    622   52.2ms    0.2%  83.9μs   4.47MiB    0.2%  7.35KiB
  ~AMR~                        622   7.97ms    0.0%  12.8μs   2.86MiB    0.1%  4.70KiB
analyze solution                33    178ms    0.7%  5.39ms   6.28MiB    0.3%   195KiB
calculate dt                 3.11k    146ms    0.6%  46.8μs     0.00B    0.0%    0.00B
I/O                             34    114ms    0.5%  3.37ms   43.7MiB    1.8%  1.28MiB
  save solution                 33   67.0ms    0.3%  2.03ms   43.4MiB    1.8%  1.32MiB
  save mesh                     33   39.9ms    0.2%  1.21ms    234KiB    0.0%  7.10KiB
  get element variables         33   4.27ms    0.0%   129μs   3.19KiB    0.0%    98.9B
  ~I/O~                         34   3.19ms    0.0%  93.9μs   49.5KiB    0.0%  1.45KiB
  get node variables            33    710ns    0.0%  21.5ns     0.00B    0.0%    0.00B
initial condition AMR            1   5.55ms    0.0%  5.55ms   7.50MiB    0.3%  7.50MiB
  AMR                            3   4.85ms    0.0%  1.62ms   7.49MiB    0.3%  2.50MiB
    refine                       3   4.46ms    0.0%  1.49ms   6.17MiB    0.3%  2.06MiB
      mesh                       3   2.30ms    0.0%   768μs   25.8KiB    0.0%  8.61KiB
        rebalance                3   2.20ms    0.0%   734μs     0.00B    0.0%    0.00B
        refine                   3   63.9μs    0.0%  21.3μs     0.00B    0.0%    0.00B
        ~mesh~                   3   35.7μs    0.0%  11.9μs   25.8KiB    0.0%  8.61KiB
      solver                     3   2.15ms    0.0%   717μs   6.14MiB    0.3%  2.05MiB
      ~refine~                   3   1.17μs    0.0%   389ns   1.47KiB    0.0%     501B
    ~AMR~                        3    251μs    0.0%  83.8μs   1.25MiB    0.1%   427KiB
    indicator                    3    140μs    0.0%  46.8μs   73.8KiB    0.0%  24.6KiB
    coarsen                      3    207ns    0.0%  69.0ns      192B    0.0%    64.0B
  ~initial condition AMR~        1    705μs    0.0%   705μs      752B    0.0%     752B
──────────────────────────────────────────────────────────────────────────────────────

I would be very grateful for any feedback/comments on these changes or suggestions of further tests to run.

@tristanmontoya tristanmontoya marked this pull request as draft September 5, 2024 20:04
Copy link
Contributor

github-actions bot commented Sep 5, 2024

Review checklist

This checklist is meant to assist creators of PRs (to let them know what reviewers will typically look for) and reviewers (to guide them in a structured review process). Items do not need to be checked explicitly for a PR to be eligible for merging.

Purpose and scope

  • The PR has a single goal that is clear from the PR title and/or description.
  • All code changes represent a single set of modifications that logically belong together.
  • No more than 500 lines of code are changed or there is no obvious way to split the PR into multiple PRs.

Code quality

  • The code can be understood easily.
  • Newly introduced names for variables etc. are self-descriptive and consistent with existing naming conventions.
  • There are no redundancies that can be removed by simple modularization/refactoring.
  • There are no leftover debug statements or commented code sections.
  • The code adheres to our conventions and style guide, and to the Julia guidelines.

Documentation

  • New functions and types are documented with a docstring or top-level comment.
  • Relevant publications are referenced in docstrings (see example for formatting).
  • Inline comments are used to document longer or unusual code sections.
  • Comments describe intent ("why?") and not just functionality ("what?").
  • If the PR introduces a significant change or new feature, it is documented in NEWS.md with its PR number.

Testing

  • The PR passes all tests.
  • New or modified lines of code are covered by tests.
  • New or modified tests run in less then 10 seconds.

Performance

  • There are no type instabilities or memory allocations in performance-critical parts.
  • If the PR intent is to improve performance, before/after time measurements are posted in the PR.

Verification

  • The correctness of the code was verified using appropriate tests.
  • If new equations/methods are added, a convergence test has been run and the results
    are posted in the PR.

Created with ❤️ by the Trixi.jl community.

@tristanmontoya tristanmontoya changed the title Add type parameter to P4estMesh for dimension of ambient space WIP: Add type parameter to P4estMesh for dimension of ambient space Sep 5, 2024
Copy link

codecov bot commented Sep 5, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.32%. Comparing base (98b27b3) to head (36ce767).
Report is 2 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2068   +/-   ##
=======================================
  Coverage   96.32%   96.32%           
=======================================
  Files         470      470           
  Lines       37447    37467   +20     
=======================================
+ Hits        36070    36090   +20     
  Misses       1377     1377           
Flag Coverage Δ
unittests 96.32% <100.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@tristanmontoya tristanmontoya added breaking enhancement New feature or request labels Sep 6, 2024
@tristanmontoya tristanmontoya changed the title WIP: Add type parameter to P4estMesh for dimension of ambient space WIP: Add type parameter NDIMS_AMBIENT to P4estMesh for dimension of ambient space Sep 6, 2024
@tristanmontoya tristanmontoya marked this pull request as ready for review September 6, 2024 16:06
@tristanmontoya tristanmontoya changed the title WIP: Add type parameter NDIMS_AMBIENT to P4estMesh for dimension of ambient space Add type parameter NDIMS_AMBIENT to P4estMesh for dimension of ambient space Sep 6, 2024
@tristanmontoya tristanmontoya removed the enhancement New feature or request label Sep 6, 2024
tristanmontoya added a commit to trixi-framework/TrixiAtmo.jl that referenced this pull request Sep 7, 2024
src/meshes/p4est_mesh.jl Show resolved Hide resolved
src/meshes/p4est_mesh.jl Outdated Show resolved Hide resolved
src/meshes/p4est_mesh.jl Outdated Show resolved Hide resolved
src/meshes/p4est_mesh.jl Outdated Show resolved Hide resolved
src/meshes/p4est_mesh.jl Show resolved Hide resolved
src/solvers/dgsem_p4est/containers_2d.jl Show resolved Hide resolved
Copy link
Member

@ranocha ranocha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. This is fine with me and can be merged when @DanielDoehring approves it, too

@ranocha ranocha merged commit 3df1253 into trixi-framework:main Sep 11, 2024
37 checks passed
tristanmontoya added a commit to trixi-framework/TrixiAtmo.jl that referenced this pull request Sep 12, 2024
…xi.jl (#35)

* make compatible with my PR trixi-framework/Trixi.jl#2068

* update init_elements to use new P4estMesh type parameter
amrueda added a commit to trixi-framework/TrixiAtmo.jl that referenced this pull request Nov 25, 2024
…les (#47)

* linear advection on the sphere

* formatter

* very preliminary implementation of covariant form with p4est

* removed untracked

* removed allocations, now 100x faster

* add DS_Store to gitignore

* add DS_Store to gitignore

* made equations actually 2D

* integrated upstream changes

* analysis callback for covariant form

* cleanup

* separate Andres's spherical shell containers from main Trixi

* Added containers and 2D p4est mesh from my spherical shell implementation in Trixi.jl (cherry-picked from f45378e)

Co-authored-by: Tristan Montoya <[email protected]>

* Added element container with PtrArray for performance and modified the structure

* format

* Fixed bug in the definition of init_elements and added nelements(). eltype() and ndims() functions for new struct

* integrated Andres's new container type with covariant solver

* added flux-differencing kernel for covariant form

* integrated Andrés' PR with covariant solver

* add tests for spherical advection in Cartesian coords

* revert change to moist bubble case

* revert change to moist bubble case

* covariant weak form with tests

* removed shallow water from this branch

* reorganize a bit

* hard-code dimension of node coordinates to avoid type instability

* metric terms for shell of radius != 1

* test for covariant form is now on earth scale

* fix name of cartesian test

* moved i,j,element,cache into flux signatures for covariant form

* added test for flux differencing covariant form

* transformation between local coordinate systems now uses latitude-longitude as intermediate state, not Cartesian

* format

* make compatible with my PR trixi-framework/Trixi.jl#2068

* separate containers to store geometric information specific to covariant form

* add element-local mapping from Guba et al.

* add reference to Guba et al. to docstring

* new mapping works with cartesian solver solver in covariant_form branch

* exact metrics for element-local mapping

* streamline tests and improve readability

* rename default DGSEM mapping

* didn't need new analysis cache

* improve comments

* refactor

* remove DiffEqCallbacks for now

* add better comments

* improve comments

* better documentation

* add NDIMS_AMBIENT parameter to equations

* fix docstring format

* make link in docs work

* fix link in docs

* documentation for the covariant solver

* added surface central flux and test

* fix trixi_compat

* specialize compute_coefficients! to dimension 2

* format

* fix spelling

* remove initial_condition parameter from rhs

* no need to use Float32 for physical constant defaults

* incorporate downstream changes

* format

* standardize test cases

* move covariant form max_dt method to callbacks_step

* Fix comments

* generalize interface between equations and cache

* relax relative tolerance on cartesian advection test)

* improve docs

* streamline initial condition definition and improve docs

* tests for cartesian form now use standard and element-local mapping approaches

* first attempt at aux vars

* works with allocations

* fix allocations

* clean up docs

* format and update comments

* move auxvars into own cache field

* improve comments

* format comments

* revert back to without basis matrix inverse

* add warning for P4estMeshCubedSphere and rename volume->area element

* rename function transforming initial condition

* fix elixir and docs

* poldeg(solver) -> Trixi.polydeg(solver)

* reformat ugly line breaks

* modularize covariant basis calculation for easier testing

* remove duplicated cons2entropy function

---------

Co-authored-by: Andrés Rueda-Ramírez <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants