Add cubed sphere test cases #199
Conversation
add parameter index and only get averaged of the variable at position index
proof of concept for creating data vectors in libelixirs which can be filled later by external applications
required in this PR, subject to change
demonstrates source terms via database
…ility.jl Co-authored-by: Michael Schlottke-Lakemper <[email protected]>
…i into more-data-access
benegee
changed the title
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #199 +/- ##
===========================================
+ Coverage 82.43% 95.71% +13.28%
===========================================
Files 21 23 +2
Lines 905 1096 +191
Branches 52 63 +11
===========================================
+ Hits 746 1049 +303
+ Misses 155 43 -112
Partials 4 4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
Finally! 🎉 @jmark's cubed sphere fix was released with t8code v3.0.1. which made it into t8code_jll.jll v3.0.1, which made it into T8code v0.7.4, which made it into Trixi 0.9.12, and is finally here! |
| @@ -198,6 +196,7 @@ jobs: | |||
| cd build | |||
| cmake .. -DCMAKE_INSTALL_PREFIX=../install \ | |||
| -DCMAKE_BUILD_TYPE=Debug \ | |||
| -DT8CODE_ROOT=$PWD/../t8code-local/prefix \ | |||
| # provide some data because calc_sources! will already be called during initialization | ||
| zero_data = zeros(Float64, nelements*nnodes) | ||
| registry[1] = zero_data | ||
| registry[2] = zero_data | ||
| registry[3] = zero_data | ||
| registry[4] = zero_data |
There was a problem hiding this comment.
The current implementation does not seem correct. All entries of registry are assigned the same vector zero_data, i.e., they point to a single data structure.
I see that they will be overwritten later again. However, my feeling is that it would be better to make sure that this is not accidentally considered a valid implementation:
| # provide some data because calc_sources! will already be called during initialization | |
| zero_data = zeros(Float64, nelements*nnodes) | |
| registry[1] = zero_data | |
| registry[2] = zero_data | |
| registry[3] = zero_data | |
| registry[4] = zero_data | |
| # provide some data because calc_sources! will already be called during initialization | |
| # Note: the data pointers in the registry will be overwritten before the first real use | |
| zero_data = zeros(Float64, nelements*nnodes) | |
| registry[1] = zero_data | |
| registry[2] = zero_data | |
| registry[3] = zero_data | |
| registry[4] = zero_data |
There was a problem hiding this comment.
As a side note, I am starting to wonder if storage for source terms should maybe live on the Trixi.jl side instead of the C side. This goes against previous statements I made, and I wouldn't change it now before we have gathered more experience with it. However, it seems to me that it is overly convoluted this way, especially since it's effectively Trixi.jl that needs and controls the memory, not the C side
| mesh = Trixi.T8codeMeshCubedSphere(lat_lon_levels, layers, 6.371229e6, 30000.0, | ||
| polydeg = 5, initial_refinement_level = 0) | ||
|
|
||
| # create the data registry and three vectors for the source terms |
There was a problem hiding this comment.
| # create the data registry and three vectors for the source terms | |
| # create the data registry and four vectors for the source terms |
New test cases:
Requires: trixi-framework/Trixi.jl#1918
To test this in the meantime:
mainbg/baroclinic-instabilitylibtrixi-julia-baro./libtrixi-baro/bin/libtrixi-init-julia --t8code-library ../t8code/lib/libt8.so ../libtrixi-baroJULIA_DEPOT_PATH=./julia-depot julia --project=.]pkg> dev --local Trixicd dev/Trixi,git switch feature-t8code-cubed-sphere-setup,cd -JULIA_DEPOT_PATH=./julia-depot julia --project=.]updateXML2_jll:add [email protected]precompile