-
Notifications
You must be signed in to change notification settings - Fork 50
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
Particle-grid periodic communication #263
base: master
Are you sure you want to change the base?
Conversation
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.
We should discuss but my thoughts are that this should be in core
. We should also discuss whether or not to include the halo region at this point in the communication. I think we could have one general cartesian communication structure (both for halo and migration) which incorporates the halo information if needed. We could do this now or treat this as a good start and do more PRs to generalize it.
|
||
// Create a grid local_grid. | ||
auto local_grid = Cajita::createLocalGrid( global_grid, 1 ); | ||
auto local_mesh = Cajita::createLocalMesh<TEST_DEVICE>( *local_grid ); |
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.
Does it seem reasonable to have to make all of these objects for cases like MD with short-range only where you don't need a mesh? I could see automating how often migrate
is called based on setting some halo in MD. That would then eliminate the need to tune how often migrate happens (e.g. every 100 time steps or something). It would instead be based on some distance criterion which would correspond to a halo width. In that case you would want to create all of these objects then as your cell size would have some distance relative to something meaningful in the simulation (like the interaction distance).
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.
Note this extra grid we would use to choose communications would also be the same grid from which we would build LinkedCellList
objects.
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.
And now that I think about it we need a LinkedCellList
that uses Cajita instead of the grid we have as an implementation detail. Even more reason for all of this stuff to just be in core
.
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 guess I'm not sure how to get around creating all these objects, but I have considered specializations of the mesh/grid that don't hold as much information since we basically only need the bounds of the box in MD
And since we have to rebuild the neighbor list every so often, we do the same with migration, but you're right that it could potentially be done automatically with a check for anything crossing halo boundaries.
I have the LinkedCellList
on my list after the PeriodicHalo
fea92a3
to
7fe48af
Compare
I think I addressed everything except for how to potentially generalize for other particle-grid methods. Now that I did it as you suggested, this makes much more sense than a separate particle-grid section |
64db1ca
to
fc4eb4e
Compare
fc4eb4e
to
a3c8aef
Compare
73e13cb
to
73966be
Compare
6efa3c4
to
e724c72
Compare
e724c72
to
dd5cfd5
Compare
@streeve that helped with the build, but now the |
Thanks - that's expected at the moment. |
95a61b3
to
d519cc0
Compare
This will fail until rebased with 295 in master; after that, probably a few more fixes to pass halo tests and it will be ready for review. |
#295 has been merged - let's proceed with this one and see if it resolves our comm seg faults. |
e322c43
to
b24a18c
Compare
Let's rebase this one to get the latest changes for the number of testing ranks and see what the CI does. We likely still have a UVM error though. |
7164526
to
0cd812e
Compare
0cd812e
to
271b352
Compare
271b352
to
89e8276
Compare
89e8276
to
9a59977
Compare
Codecov Report
@@ Coverage Diff @@
## master #263 +/- ##
========================================
- Coverage 93.5% 93.3% -0.3%
========================================
Files 37 38 +1
Lines 2797 2842 +45
========================================
+ Hits 2617 2653 +36
- Misses 180 189 +9
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
6b0827e
to
05f3ca3
Compare
05f3ca3
to
7f5b0e4
Compare
@sslattery this is ready for another review. @junghans codecov is telling me I reduced coverage for |
*/ | ||
template <class LocalGridType, class PositionSliceType> | ||
Distributor<typename PositionSliceType::device_type> | ||
gridDistributor( const LocalGridType& local_grid, PositionSliceType& positions ) |
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 would prefer this be named createGridDistributor
to indicate the creation mechanism.
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.
Done
*/ | ||
template <class LocalGridType, class PositionSliceType, | ||
std::size_t PositionIndex> | ||
auto gridHalo( |
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.
These should also be named createGridHalo
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.
Done
// Create the Shifts. | ||
auto periodic_shift = PeriodicShift<device_type, PositionIndex>( shifts ); | ||
|
||
return std::make_pair( halo, periodic_shift ); |
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.
Instead of a pair we should just have a new struct
which holds a Halo
and the functor the user wants to apply. These would eliminate a user needed to store multiple objects and think about using the pair. In addition, it would allow the user to have an object they could easily append other modification functions if they wanted to for some reason.
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.
Done - although I'm not sure if it's composed to be extensible in the way you mentioned
auto center_z = width_z + lo_z; | ||
auto shift_x = width_x - ( halo_width - 0.1 ) * dx; | ||
auto shift_y = width_y - ( halo_width - 0.1 ) * dy; | ||
auto shift_z = width_z - ( halo_width - 0.1 ) * dz; |
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.
All of the setup code looks the same for both tests - perhaps it can be combined.
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.
Combined
Cabana::AoSoA<DataTypes, TEST_MEMSPACE> data_src( "data_src", num_data ); | ||
Cabana::deep_copy( data_src, data_host ); | ||
|
||
if ( test_type == 0 ) |
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.
Did you anticipate adding other values for test_type
?
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 added a slice variant of gridGather
for a second test_type
bool within_y = true; | ||
bool within_z = true; | ||
// Make sure all ghosts are in halo region in at least one direction. | ||
if ( pos_host( i, Cajita::Dim::I ) < lo_x ) |
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.
Could you add a particle field which contains the original MPI rank and then use that to back-calculate what the position should be exactly?
78b287e
to
47fe0a8
Compare
47fe0a8
to
afb82ac
Compare
This adds the first direct particle-grid capability in Cabana within
core
, with dependency on Cajita.This is all inparticle_grid/
for now, but I'm open to any reorganization and renaming.CabanaPG
directly relies on Core and Cajita and is enabled by default if Cajita is.This wraps calls to
Distributor
,migrate
,Halo
, andgather
to simplify things for any user with periodic boundaries or load balancing needs.New options include:
gridDistributor
(stolen from ExaMPM), determining new ranks destinations and wrapping through periodic boundariesgridMigrate
usinggridDistributor
and callingmigrate
gridHalo
determining particles to be ghosted and any necessary periodic shiftsPeriodicHalo
inheriting fromHalo
with functor to add periodic shiftsPeriodicShift
functor to modify buffer (cannot inherit fromHalo
because CommPlan contains std member variables, an issue for NVCC)gridGather
usingPeriodicShift
andgridHalo
and callinggather
gather
for modifying the send buffer with periodic shiftsCloses #77