Il 23/12/22 17:14, Matthew Knepley ha scritto:
On Thu, Dec 22, 2022 at 3:08 PM Matteo Semplice
<matteo.sempl...@uninsubria.it> wrote:
Il 22/12/22 20:06, Dave May ha scritto:
On Thu 22. Dec 2022 at 10:27, Matteo Semplice
<matteo.sempl...@uninsubria.it> wrote:
Dear Dave and Matt,
I am really dealing with two different use cases in a
code that will compute a levelset function passing through a
large set of points. If I had DMSwarmSetMigrateType() and if
it were safe to switch the migration mode back and forth in
the same swarm, this would cover all my use cases here. Is it
safe to add it back to petsc? Details below if you are curious.
1) During preprocessing I am loading a point cloud from disk
(in whatever order it comes) and need to send the particles
to the right ranks. Since the background DM is a DMDA I can
easily figure out the destination rank. This would be covered
by your suggestion not to attach the DM, except that later I
need to locate these points with respect to the background
cells in order to initialize data on the Vecs associated to
the DMDA.
2) Then I need to implement a semilagrangian time evolution
scheme. For this I'd like to send particles around at the
"foot of characteristic", collect data there and then send
them back to the originating point. The first migration would
be based on particle coordinates
(DMSwarmMigrate_DMNeighborScatter and the restriction to only
neighbouring ranks is perfect), while for the second move it
would be easier to just send them back to the originating
rank, which I can easily store in an Int field in the swarm.
Thus at each timestep I'd need to swap migrate types in this
swarm (DMScatter for moving them to the feet and BASIC to
send them back).
When you use BASIC, you would have to explicitly call the point
location routine from your code as BASIC does not interact with
the DM.
Based on what I see in the code, switching migrate modes between
basic and dmneighbourscatter should be safe.
If you are fine calling the point location from your side then
what you propose should work.
If I understood the code correctly, BASIC will just migrate
particles sending them to what is stored in DMSwarmField_rank,
right? That'd be easy since I can create a SWARM with all the data
I need and an extra int field (say "original_rank") and copy those
values into DMSwarmField_rank before calling migrate for the
"going back" step. After this backward migration I do not need to
locate particles again (e.g. I do not need DMSwarmSortGetAccess
after the BASIC migration, but only after the DMNeighborScatter one).
Thus having back DMSwarmSetMigrateType() should be enough for me.
Hi Matteo,
I have done this in
https://gitlab.com/petsc/petsc/-/merge_requests/5941
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fpetsc%2Fpetsc%2F-%2Fmerge_requests%2F5941&data=05%7C01%7Cmatteo.semplice%40uninsubria.it%7C8b12eb28eaa74ac776aa08dae500d712%7C9252ed8bdffc401c86ca6237da9991fa%7C0%7C0%7C638074089022508394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T2Sp019DMQi%2BarRKTdwRVY7%2F%2FaGVbwCJjBpzOta1yoM%3D&reserved=0>
I also hope to get the fix for your DMDA issue in there.
Hi.
I have finally got round to testing the updates and, using the main
branch, my issues are fixed.
Only, I have noticed that, after a DMSwarmMigrate_DMNeighborScatter, the
field DMSwarmField_rank has the same content as the field
DMSwarmPICField_cellid. It does not affect me, but it seems a little
strange and might surprise users... In the long term, a word in the docs
about the names/content of the fields that are automatically created in
a swarm would be helpful.
Thanks!
Matteo
