<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Il 23/12/22 17:14, Matthew Knepley ha
scritto:<br>
</div>
<blockquote type="cite" cite="mid:CAMYG4GkK8rMrf+DHgcyCgCfH+GO98YUEf4w5CBfq84m=R9bHig@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">On Thu, Dec 22, 2022 at 3:08 PM Matteo Semplice
<<a href="mailto:matteo.semplice@uninsubria.it" moz-do-not-send="true" class="moz-txt-link-freetext">matteo.semplice@uninsubria.it</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<div>Il 22/12/22 20:06, Dave May ha scritto:<br>
</div>
<blockquote type="cite">
<div><br>
</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu 22. Dec
2022 at 10:27, Matteo Semplice <<a href="mailto:matteo.semplice@uninsubria.it" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">matteo.semplice@uninsubria.it</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>Dear Dave and Matt,</p>
<p> 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.<br>
</p>
<p>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.<br>
</p>
<p>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).</p>
</div>
</blockquote>
<div dir="auto"><br>
</div>
<div dir="auto">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. </div>
<div dir="auto"><br>
</div>
<div dir="auto">Based on what I see in the code,
switching migrate modes between basic and
dmneighbourscatter should be safe.</div>
<div dir="auto"><br>
</div>
<div dir="auto">If you are fine calling the point
location from your side then what you propose
should work.</div>
</div>
</div>
</blockquote>
<p>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).</p>
<p>Thus having back DMSwarmSetMigrateType() should be
enough for me.<br>
</p>
</div>
</blockquote>
<div>Hi Matteo,</div>
<div><br>
</div>
<div>I have done this in</div>
<div><br>
</div>
<div> <a href="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" originalsrc="https://gitlab.com/petsc/petsc/-/merge_requests/5941" shash="jliFtiMdUgw+u+HurODr6FNUaiXFs7lBBaI8j6cZ685DBJW7mMNOEZLLPScdbWfd2pkOirMug7HxAhLK/LaNB7YF/MmSKYtAy0bo1zlfdC4l9RuBx1jAqtGa1c/eO10usGqKNYg8cOIJxfhQvStUJNt+7zcnGB06r2/ctbE4qWo=" moz-do-not-send="true">https://gitlab.com/petsc/petsc/-/merge_requests/5941</a></div>
<div><br>
</div>
<div>I also hope to get the fix for your DMDA issue in there.</div>
</div>
</div>
</blockquote>
<p>Hi.</p>
<p>I have finally got round to testing the updates and, using the
main branch, my issues are fixed.</p>
<p>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.<br>
</p>
<p>Thanks!</p>
<p> Matteo<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>