> On Dec 2, 2021, at 12:55 PM, Matthew Knepley <knep...@gmail.com> wrote: > > On Thu, Dec 2, 2021 at 12:07 PM Barry Smith <bsm...@petsc.dev > <mailto:bsm...@petsc.dev>> wrote: > > I have pushed a branch https://gitlab.com/petsc/petsc/-/merge_requests/4612 > <https://gitlab.com/petsc/petsc/-/merge_requests/4612> that generates the > same edge on two ranks and demonstrates the totally inappropriate PetscSF and > vectors that are generated in this case (just look at the output file in the > MR changes) > > I will go through this carefully. However, I want to note that you are > looking at the Section SF, not the Point SF.
Correct. > How many variables > are there in your problem? In this case I put one variable on each vertex and no variables on the edges (same model as for Neuron's). > Also, can you print the pointSF as well? This can be trivially added to the example. > > Thanks, > > Matt > > Thoughts on what we should do? I think Jed's idea of dummy vertices is very > cumbersome and ugly unless it can be refined somehow. Is there a different > way DMPLEX could be utilized to easily support multiple edges? Maybe not > using DMPlexBuildFromCellListParallel(), but building the plex some other > way? Note that it is clearly theoretically possible to have > DMPlexBuildFromCellListParallel() detect a problem and error but I don't know > how to do it. > > Barry > > > > >> On Dec 1, 2021, at 8:00 PM, Abhyankar, Shrirang G via petsc-dev >> <petsc-dev@mcs.anl.gov <mailto:petsc-dev@mcs.anl.gov>> wrote: >> >> >> >> From: Matthew Knepley <knep...@gmail.com <mailto:knep...@gmail.com>> >> Date: Wednesday, December 1, 2021 at 5:57 PM >> To: "Brown, Jedediah A (VISIT)" <j...@jedbrown.org >> <mailto:j...@jedbrown.org>> >> Cc: "Abhyankar, Shrirang G" <shrirang.abhyan...@pnnl.gov >> <mailto:shrirang.abhyan...@pnnl.gov>>, PETSc Development >> <petsc-dev@mcs.anl.gov <mailto:petsc-dev@mcs.anl.gov>>, Getnet Betrie >> <gbet...@anl.gov <mailto:gbet...@anl.gov>> >> Subject: Re: [petsc-dev] DMPLEX cannot support two different edges for the >> same two vertices, hence DMPLEX cannot? >> >> Check twice before you click! This email originated from outside PNNL. >> >> On Wed, Dec 1, 2021 at 6:55 PM Jed Brown <j...@jedbrown.org >> <mailto:j...@jedbrown.org>> wrote: >>> Matthew Knepley <knep...@gmail.com <mailto:knep...@gmail.com>> writes: >>> >>> > On Wed, Dec 1, 2021 at 5:17 PM Abhyankar, Shrirang G < >>> > shrirang.abhyan...@pnnl.gov <mailto:shrirang.abhyan...@pnnl.gov>> wrote: >>> > >>> >> “You can certainly have many fields on a given edge, but I don't know >>> >> what it would mean to have two edges since no topological query could >>> >> tell >>> >> the difference.” >>> >> >>> >> >>> >> >>> >> The two edges in a power grid represent two parallel power lines that are >>> >> connected between two locations (vertices). There are line ids (stored in >>> >> the component data) to distinguish the two lines. >>> >> >>> > >>> > Yes, so you can tell the difference in the function space (since >>> > difference >>> > current passes down each one), but _topologically_ you cannot. If you put >>> > duplicate cells in, then >>> > some topological queries will give unexpected results, like the join of >>> > the >>> > two vertices. >>> >>> This could be modeled with some ghost vertices. So instead of >>> >>> a ------ b >>> \_____/ >>> >>> you would set up >>> >>> a ---o---- b >>> \___o___/ >>> >>> Those ghost vertices don't have to "do" anything, but they make the edges >>> topologically distinct. >>> >>> Shri, what problems might this cause? >> >> >> I don’t understand the figure you’ve drawn above. Sorry. >> >> As a user, would I need to add anything to the way I am setting up the >> network/plex or any additional equations in the residual evaluation? >> >> I do not have any issue right now for the power grid problem since I don’t >> require DMNetwork or DMPLEX to do the topological distinction between >> parallel edges. There are unique edge identifiers in my dataset through >> which I can make this distinction. >> >> >> Yes, this would work, but it looks like the multiple cells are not causing >> them problems right now with the questions they are asking the mesh. >> >> Matt >> >> -- >> 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://www.cse.buffalo.edu/~knepley/ >> <https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cse.buffalo.edu%2F~knepley%2F&data=04%7C01%7Cshrirang.abhyankar%40pnnl.gov%7Cbcbb40fc51f6428ac17708d9b5264361%7Cd6faa5f90ae240338c0130048a38deeb%7C0%7C0%7C637739998211230005%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Sg7eEbjzkSqVd6Sjg8IpTN3iXxMAvih0UNV0fkolO8w%3D&reserved=0> > > > -- > 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://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
