-
Notifications
You must be signed in to change notification settings - Fork 1
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 cubed sphere test cases #199
base: main
Are you sure you want to change the base?
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
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #199 +/- ##
===========================================
+ Coverage 82.43% 95.62% +13.19%
===========================================
Files 21 23 +2
Lines 905 1097 +192
Branches 52 63 +11
===========================================
+ Hits 746 1049 +303
+ Misses 155 44 -111
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! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very cool example case! Just a few minor notes...
.github/workflows/ci.yml
Outdated
@@ -198,6 +196,7 @@ jobs: | |||
cd build | |||
cmake .. -DCMAKE_INSTALL_PREFIX=../install \ | |||
-DCMAKE_BUILD_TYPE=Debug \ | |||
-DT8CODE_ROOT=$PWD/../t8code-local/prefix \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
At some point I ran t8code elixirs also with PC, but not anymore.
Removed this line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why delete this file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it was temporary, for some demonstration I guess.
It does not have unique features. And it will at some point return when there will be moist air.
# 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True! I now allocate separate arrays to avoid confusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The argument for memory management on C side was that some large software frameworks have their own storage pool and would like to use it.
New test cases:
Requires: trixi-framework/Trixi.jl#1918
To test this in the meantime:
main
bg/baroclinic-instability
libtrixi-julia-baro
./libtrixi-baro/bin/libtrixi-init-julia --t8code-library ../t8code/lib/libt8.so ../libtrixi-baro
JULIA_DEPOT_PATH=./julia-depot julia --project=.
]
pkg> dev --local Trixi
cd dev/Trixi
,git switch feature-t8code-cubed-sphere-setup
,cd -
JULIA_DEPOT_PATH=./julia-depot julia --project=.
]
update
XML2_jll
:add [email protected]
precompile