<head><!-- BaNnErBlUrFlE-HeAdEr-start -->
<style>
#pfptBannergdof20f { all: revert !important; display: block !important;
visibility: visible !important; opacity: 1 !important;
background-color: #D0D8DC !important;
max-width: none !important; max-height: none !important }
.pfptPrimaryButtongdof20f:hover, .pfptPrimaryButtongdof20f:focus {
background-color: #b4c1c7 !important; }
.pfptPrimaryButtongdof20f:active {
background-color: #90a4ae !important; }
</style>
<!-- BaNnErBlUrFlE-HeAdEr-end -->
</head><!-- BaNnErBlUrFlE-BoDy-start -->
<!-- Preheader Text : BEGIN -->
<div style="display:none !important;display:none;visibility:hidden;mso-hide:all;font-size:1px;color:#ffffff;line-height:1px;height:0px;max-height:0px;opacity:0;overflow:hidden;">
On Wed, Jul 31, 2024 at 10: 08 AM Mark Adams <mfadams@ lbl. gov> wrote: Just a thought, but perhaps he may want to use just sparse matrices, AIJ. He Manages the connectivity And we manage ghost values. He is reconfiguring the neighborhood
</div>
<!-- Preheader Text : END -->
<!-- Email Banner : BEGIN -->
<div style="display:none !important;display:none;visibility:hidden;mso-hide:all;font-size:1px;color:#ffffff;line-height:1px;height:0px;max-height:0px;opacity:0;overflow:hidden;">ZjQcmQRYFpfptBannerStart</div>
<!--[if ((ie)|(mso))]>
<table border="0" cellspacing="0" cellpadding="0" width="100%" style="padding: 16px 0px 16px 0px; direction: ltr" ><tr><td>
<table border="0" cellspacing="0" cellpadding="0" style="padding: 0px 10px 5px 6px; width: 100%; border-radius:4px; border-top:4px solid #90a4ae;background-color:#D0D8DC;"><tr><td valign="top">
<table align="left" border="0" cellspacing="0" cellpadding="0" style="padding: 4px 8px 4px 8px">
<tr><td style="color:#000000; font-family: 'Arial', sans-serif; font-weight:bold; font-size:14px; direction: ltr">
This Message Is From an External Sender
</td></tr>
<tr><td style="color:#000000; font-weight:normal; font-family: 'Arial', sans-serif; font-size:12px; direction: ltr">
This message came from outside your organization.
</td></tr>
</table>
</td></tr></table>
</td></tr></table>
<![endif]-->
<![if !((ie)|(mso))]>
<div dir="ltr" id="pfptBannergdof20f" style="all: revert !important; display:block !important; text-align: left !important; margin:16px 0px 16px 0px !important; padding:8px 16px 8px 16px !important; border-radius: 4px !important; min-width: 200px !important; background-color: #D0D8DC !important; background-color: #D0D8DC; border-top: 4px solid #90a4ae !important; border-top: 4px solid #90a4ae;">
<div id="pfptBannergdof20f" style="all: unset !important; float:left !important; display:block !important; margin: 0px 0px 1px 0px !important; max-width: 600px !important;">
<div id="pfptBannergdof20f" style="all: unset !important; display:block !important; visibility: visible !important; background-color: #D0D8DC !important; color:#000000 !important; color:#000000; font-family: 'Arial', sans-serif !important; font-family: 'Arial', sans-serif; font-weight:bold !important; font-weight:bold; font-size:14px !important; line-height:18px !important; line-height:18px">
This Message Is From an External Sender
</div>
<div id="pfptBannergdof20f" style="all: unset !important; display:block !important; visibility: visible !important; background-color: #D0D8DC !important; color:#000000 !important; color:#000000; font-weight:normal; font-family: 'Arial', sans-serif !important; font-family: 'Arial', sans-serif; font-size:12px !important; line-height:18px !important; line-height:18px; margin-top:2px !important;">
This message came from outside your organization.
</div>
</div>
<div style="clear: both !important; display: block !important; visibility: hidden !important; line-height: 0 !important; font-size: 0.01px !important; height: 0px"> </div>
</div>
<![endif]>
<div style="display:none !important;display:none;visibility:hidden;mso-hide:all;font-size:1px;color:#ffffff;line-height:1px;height:0px;max-height:0px;opacity:0;overflow:hidden;">ZjQcmQRYFpfptBannerEnd</div>
<!-- Email Banner : END -->
<!-- BaNnErBlUrFlE-BoDy-end -->
<div dir="ltr"><div dir="ltr"><div>On Wed, Jul 31, 2024 at 10:08 AM Mark Adams <<a href="mailto:mfadams@lbl.gov">mfadams@lbl.gov</a>> wrote:<br></div></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 dir="auto">Just a thought, but perhaps he may want to use just sparse matrices, AIJ. He Manages the connectivity And we manage ghost values.</div></blockquote><div><br></div><div>He is reconfiguring the neighborhood (row) each time, so you would essentially create a new matrix at each step with different sparsity. It would definitely function, but I wonder if he would have enough local information to construct the rows?</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 31, 2024 at 6:25 AM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</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 dir="ltr"><div dir="ltr">On Tue, Jul 30, 2024 at 11:32 PM Marco Seiz <<a href="mailto:marco@kit.ac.jp" target="_blank">marco@kit.ac.jp</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">Hello,<br>
<br>
maybe to clarify a bit further: I'd essentially like to solve heat transport between particles only, without solving the transport on my voxel mesh since there's a large scale difference between the voxel size and the particle size and heat transport should be fast enough that voxel resolution is unnecessary. Basically a discrete element method just for heat transport. The whole motion/size change part is handled separately on the voxel mesh.<br>
Based on the connectivity, I can make a graph (attached an example from a 3D case, for description see [1]) and on each vertex (particle) of the graph I want to account for source terms and conduction along the edges. What I'd like to avoid is managing the exchange for non-locally owned vertices during the solve (e.g. for RHS evaluation) myself but rather have the DM do it with DMGlobalToLocal() and friends. Thinking a bit further, I'd probably also want to associate some data with the edges since that will enter the conduction term but stays constant during a solve (think contact area between particles).<br>
<br>
Looking over the DMSwarm examples, the coupling between particles is via the background mesh, so e.g. I can't say "loop over all local particles and for each particle and its neighbours do X". I could use the projection part to dump the the source terms from the particles to a coarser background mesh but for the conduction term I don't see how I could get a good approximation of the contact area on the background mesh without having a mesh at a similar resolution as I already have, kinda destroying the purpose of the whole thing.<br></blockquote><div><br></div><div>The point I was trying to make in my previous message is that DMSwarm does not require a background mesh. The examples use one because that is what we use to evaluate particle grouping. However, you have an independent way to do this, so you do not need it.</div><div><br></div><div>Second, the issue of replicated particles. DMSwarmMigrate allows you to replicate particles, using the input flag. Of course, you would have to manage removing particles you no longer want.</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[1] Points represent particles, black lines are edges, with the color indicating which worker "owns" the particle, with 3 workers being used and only a fraction of edges/vertices being displayed to keep it somewhat tidy. The position of the points corresponds to the particles' x-y position, with the z position being ignored. Particle ownership isn't done via looking where the particle is on the voxel grid, but rather by dividing the array of particle indices into subarrays, so e.g. particles [0-n/3) go to the first worker and so on. Since my particles can span multiple workers on the voxel grid this makes it much easier to update edge information with one-sided communication. As you can see the "mesh" is quite irregular with no nice boundary existing for connected particles owned by different workers. <br>
<br>
Best regards,<br>
Marco<br>
<br>
On 30.07.24 22:56, Mark Adams wrote:<br>
> * they do have a vocal mesh, so perhaps They want DM Plex.<br>
> <br>
> * they want ghost particle communication, that also might want a mesh<br>
> <br>
> * DM swarm does not have a notion of ghost particle, as far as I know, but it could use one<br>
> <br>
> On Tue, Jul 30, 2024 at 7:58 AM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a> <mailto:<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>>> wrote:<br>
> <br>
> On Tue, Jul 30, 2024 at 12: 24 AM Marco Seiz <marco@ kit. ac. jp> wrote: Hello, I'd like to solve transient heat transport at a particle scale using TS, with the per-particle equation being something like dT_i / dt = (S(T_i) + sum(F(T_j,<br>
> ZjQcmQRYFpfptBannerStart<br>
> __<br>
> This Message Is From an External Sender<br>
> This message came from outside your organization.<br>
> <br>
> __<br>
> ZjQcmQRYFpfptBannerEnd<br>
> On Tue, Jul 30, 2024 at 12:24 AM Marco Seiz <<a href="mailto:marco@kit.ac.jp" target="_blank">marco@kit.ac.jp</a> <mailto:<a href="mailto:marco@kit.ac.jp" target="_blank">marco@kit.ac.jp</a>>> wrote:<br>
> <br>
> __<br>
> Hello, I'd like to solve transient heat transport at a particle scale using TS, with the per-particle equation being something like dT_i / dt = (S(T_i) + sum(F(T_j, T_i), j connecting to i)) with a nonlinear source term S and a conduction term<br>
> ZjQcmQRYFpfptBannerStart<br>
> __<br>
> This Message Is From an External Sender<br>
> This message came from outside your organization.<br>
> <br>
> __<br>
> ZjQcmQRYFpfptBannerEnd<br>
> <br>
> Hello,<br>
> <br>
> I'd like to solve transient heat transport at a particle scale using TS, with the per-particle equation being something like<br>
> <br>
> dT_i / dt = (S(T_i) + sum(F(T_j, T_i), j connecting to i))<br>
> <br>
> with a nonlinear source term S and a conduction term F. The particles can move, deform and grow/shrink/vanish on a voxel grid, but for the temperature a particle-scale resolution should be sufficient. The particles' connectivity will change during the simulation, but is assumed constant during a single timestep. I have a data structure tracking the particles' connectivity, so I can say which particles should conduct heat to each other. I exploit symmetry and so only save the "forward" edges, so e.g. for touching particles 1->2->3, I only store [[2], [3], []], from which the full list [[2], [1, 3], [2]] could be reconstructed but which I'd like to avoid. In parallel each worker would own some of the particle data, so e.g. for the 1->2->3 example and 2 workers, worker 0 could own [[2]] and worker 1 [[3],[]].<br>
> <br>
> Looking over the DM variants, either DMNetwork or some manual mesh build with DMPlex seem suited for this. I'd especially like it if the adjacency information is handled by the DM automagically based on the edges so I don't have to deal with ghost particle communication myself. I already tried something basic with DMNetwork, though for some reason the offsets I get from DMNetworkGetGlobalVecOffset() are larger than the actual network. I've attached what I have so far but comparing to e.g. src/snes/tutorials/network/ex1.c I don't see what I'm doing wrong if I don't need data at the edges. I might not be seeing the trees for the forest though. The output with -dmnetwork_view looks reasonable to me. Any help in fixing this approach, or if it would seem suitable pointers to using DMPlex for this problem, would be appreciated.<br>
> <br>
> To me, this sounds like you should built it with DMSwarm. Why?<br>
> <br>
> 1) We only have vertices and edges, so a mesh does not buy us anything.<br>
> <br>
> 2) You are managing the parallel particle connectivity, so DMPlex topology is not buying us anything. Unless I am misunderstanding.<br>
> <br>
> 3) DMNetwork has a lot of support for vertices with different characteristics. Your particles all have the same attributes, so this is unnecessary.<br>
> <br>
> How would you set this up?<br>
> <br>
> 1) Declare all particle attributes. There are many Swarm examples, but say ex6 which simulates particles moving under a central force.<br>
> <br>
> 2) That example decides when to move particles using a parallel background mesh. However, you know which particles you want to move,<br>
> so you just change the _rank_ field to the new rank and call DMSwarmMigrate() with migration type _basic_.<br>
> <br>
> It should be straightforward to setup a tiny example moving around a few particles to see if it does everything you want.<br>
> <br>
> Thanks,<br>
> <br>
> Matt<br>
> <br>
> <br>
> Best regards,<br>
> Marco<br>
> <br>
> -- <br>
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> -- Norbert Wiener<br>
> <br>
> <a href="https://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eru_lbEwlvhK2Nbu6OsMVCn27QSZS67cnVfZgM-_OSyUCm_OPRqO4HSgfcDBzj2a9C4AC8cb_OVLajN1Jsba$" rel="noreferrer" target="_blank">https://www.cse.buffalo.edu/~knepley/</a> <<a href="https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!bLVHnoUGooYpdfGD8zNQrHTY2ln70W082hEc6pG7vdjA2fCvs77tcI9d7QOA0i_FjGK1of3nNOKXCE-4Rwb0$" rel="noreferrer" target="_blank">https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!bLVHnoUGooYpdfGD8zNQrHTY2ln70W082hEc6pG7vdjA2fCvs77tcI9d7QOA0i_FjGK1of3nNOKXCE-4Rwb0$</a>><br>
> </blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eru_lbEwlvhK2Nbu6OsMVCn27QSZS67cnVfZgM-_OSyUCm_OPRqO4HSgfcDBzj2a9C4AC8cb_OVLalTr8ibI$" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div></div>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!eru_lbEwlvhK2Nbu6OsMVCn27QSZS67cnVfZgM-_OSyUCm_OPRqO4HSgfcDBzj2a9C4AC8cb_OVLalTr8ibI$" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>