On Tue, Jul 30, 2024 at 12:24 AM Marco Seiz <ma...@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, T_i), j connecting to i)) with a nonlinear source term
> S and a conduction term
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
> This message came from outside your organization.
>
> ZjQcmQRYFpfptBannerEnd
>
> 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 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],[]].
>
> 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.
>
> To me, this sounds like you should built it with DMSwarm. Why?
1) We only have vertices and edges, so a mesh does not buy us anything.
2) You are managing the parallel particle connectivity, so DMPlex topology
is not buying us anything. Unless I am misunderstanding.
3) DMNetwork has a lot of support for vertices with different
characteristics. Your particles all have the same attributes, so this is
unnecessary.
How would you set this up?
1) Declare all particle attributes. There are many Swarm examples, but say
ex6 which simulates particles moving under a central force.
2) That example decides when to move particles using a parallel background
mesh. However, you know which particles you want to move,
so you just change the _rank_ field to the new rank and call
DMSwarmMigrate() with migration type _basic_.
It should be straightforward to setup a tiny example moving around a few
particles to see if it does everything you want.
Thanks,
Matt
> Best regards,
> Marco
>
> --
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
https://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!bLVHnoUGooYpdfGD8zNQrHTY2ln70W082hEc6pG7vdjA2fCvs77tcI9d7QOA0i_FjGK1of3nNOKXCEGdiWx7$
<https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!bLVHnoUGooYpdfGD8zNQrHTY2ln70W082hEc6pG7vdjA2fCvs77tcI9d7QOA0i_FjGK1of3nNOKXCE-4Rwb0$
>
