<div dir="ltr">Thank you for the corrections. It works. <br><br>However, I still have a problem. <br>I tested zero stratum for DMGetStratumIS() with the default depth label, since the graph of vertex is needed. Then, PetscSFGetGraph() from the Natural SF is crashed. I checked that pBcCompIS contains proper set of integers via ISView(). <br><br>On the other hand, it works okay if DMGetStratumIS() is with dim stratum, which is for cell stratum. <br>The problem is that if the dim stratum is used, the number of entry in ileaves(i)% pointer does not match with the actual number of vertex that each processor has. That is why I tried to put the zero stratum on DMGetStratumIS(), instead of the stratum for cell (i.e., "dim") to see if any changes on the graph. Can I get comments? <br><br>Best<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 17, 2022 at 9:59 AM Matthew Knepley <<a href="mailto:knepley@gmail.com">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 Fri, Jul 15, 2022 at 7:05 PM Bora Jeong <<a href="mailto:boraj1021@gmail.com" target="_blank">boraj1021@gmail.com</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 dir="ltr">I found that iroots() and ileaves() have size of nleaves and tested through the attached sample code with the grid previously shared. Then I get the results written in the attached monitor file. <br><br>It seems ileaves(i)%rank and ileaves(i)%index at line 127 of the attached code have garbage values, different from displayed values by PetscSFView() at line 113. <br><br>It is tough to get it why the garbage values are returned from PetscSFGetGraph(). Any comments will be very appreciated.<br></div></blockquote><div><br></div><div>Unfortunately, Fortran is not very good at reporting declaration errors. The problem is that you did not include or use the Vec module. I have done this and your example runs for me. I have included the modified code.</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 dir="ltr">Best<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 15, 2022 at 3:53 PM 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 Fri, Jul 15, 2022 at 2:25 PM Bora Jeong <<a href="mailto:boraj1021@gmail.com" target="_blank">boraj1021@gmail.com</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 dir="ltr"><div dir="ltr">Thank you for the comments. Updated sample code is attached here; DMPlexDistribute() is explicitly called and by defining a section before mesh distribution, a Natural SF was able to be defined as found from PetscSFView(). <br><br>However, I am still struggling to call PetscSFGetGraph() <a href="https://petsc.org/main/docs/manualpages/PetscSF/PetscSFGetGraph/" target="_blank">https://petsc.org/main/docs/manualpages/PetscSF/PetscSFGetGraph/</a><br>due to data type definition of ilocal and iremote. What is the proper size allocation for those two variables? Does this size for the number of processors? or the number of vertex?<br></div></div></blockquote><div><br></div><div>Since we need to pass back arrays, you need to pass us in F90 pointers. Here is an example of doing such a thing:</div><div><br></div><div>  <a href="https://gitlab.com/petsc/petsc/-/blob/main/src/vec/is/sf/tutorials/ex1f.F90#L94" target="_blank">https://gitlab.com/petsc/petsc/-/blob/main/src/vec/is/sf/tutorials/ex1f.F90#L94</a></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 dir="ltr"><div dir="ltr">Best<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 15, 2022 at 9:09 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 Fri, Jul 15, 2022 at 8:46 AM Bora Jeong <<a href="mailto:boraj1021@gmail.com" target="_blank">boraj1021@gmail.com</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 dir="ltr"><div>Okay, I got it what's happening. First, this very bright functionality of petsc (the natural-global converting) needs to be documented in a better way for sure. Currently, it is very difficult to use/follow this features as an external user. Hope this will move forward in a better way. </div><div><br></div><div>Then next question is if I load/distribute mesh just like I am doing right now shown in the sample code, can I assume that my code does not create natural sf during the distribution(always)? In other words, can I always get the natural order of each node by simply stacking the preceding processor's number of node? For example, for proc=0, natural node ID might be just 1 to nnode_proc_0, </div><div>for proc=1, it might be {nnode_proc_0 + 1 to nnode_proc_0 + nnode_proc_1} and so on. </div><div><br></div><div>Does that always make sense in this case? </div></div></blockquote><div><br></div><div>No, but if you call DMPlexDistribute() yourself, rather than having it called automatically by DMSetFromOptions(), you can</div><div>preserve the mapping:</div><div><br></div><div>  <a href="https://petsc.org/main/docs/manualpages/DMPLEX/DMPlexDistribute/" target="_blank">https://petsc.org/main/docs/manualpages/DMPLEX/DMPlexDistribute/</a></div><div><br></div><div>The SF returned maps the original point distribution, which is in the same order as the file, to the redistributed points, which are determined</div><div>by the mesh partitioner.</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 dir="ltr"><div>Best</div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 15, 2022 at 8:07 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 Fri, Jul 15, 2022 at 7:17 AM Bora Jeong <<a href="mailto:boraj1021@gmail.com" target="_blank">boraj1021@gmail.com</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 dir="ltr"><div>A sample code for loading dm and declaring Natural SF from a sphere mesh is attached here. PetscSFView() returns NULL from sf_nat. </div></div></blockquote><div><br></div><div>The Global-to-Natural mapping relates global dofs to natural dofs. Thus, in order to compute this mapping the DM has to know</div><div>about the dof layout before distribution. This means you need to setup a local section before distributing, as we do for example in</div><div>Plex test ex15. This makes things more complicated since everything cannot be packaged up into DMSetFromOptions(), but we need</div><div>user input so I do not see a simpler way to do things.</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 dir="ltr"><div>Best</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 15, 2022 at 6:39 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 Thu, Jul 14, 2022 at 8:25 PM Bora Jeong <<a href="mailto:boraj1021@gmail.com" target="_blank">boraj1021@gmail.com</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 dir="ltr"><div>Okay, I checked it and you are correct. In my case, simply, natural node index can be identified by stacking all the preceding processor's numbers of nodes for a particular processor, which is good due to simplicity. However, one serious question is why this is happening in my code? In other words, why the natural SF is not created during the mesh distribution? My code wants to have consistency in dealing with this natural indexing for several different kinds of mesh files. So there is a necessity to guarantee of consistency in this weird behavior.<br></div></div></blockquote><div><br></div><div>I can't tell what is going on in your code unless I can run it. Do you have a simple example?</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 dir="ltr"><div></div><div>Best,</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 14, 2022 at 6:43 PM 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 Thu, Jul 14, 2022 at 5:47 PM Bora Jeong <<a href="mailto:boraj1021@gmail.com" target="_blank">boraj1021@gmail.com</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 dir="ltr"><div dir="ltr">Thank you for the comments. I have these errors when I call PetscSFView() after DMGetNaturalSF()<br><br>[2]PETSC ERROR: --------------------- Error Message --------------------------------------------------------------<br>[2]PETSC ERROR: Null argument, when expecting valid pointer<br>[2]PETSC ERROR: Null Pointer: Parameter # 1<br>[2]PETSC ERROR: See <a href="https://petsc.org/release/faq/" target="_blank">https://petsc.org/release/faq/</a> for trouble shooting.<br>[2]PETSC ERROR: Petsc Release Version 3.17.0, unknown <br>[2]PETSC ERROR: #1 PetscSFView() at <br>[2]PETSC ERROR: #2 User provided function() at User file:0<br>Abort(85) on node 2 (rank 0 in comm 16): application called MPI_Abort(MPI_COMM_SELF, 85) - process 0<br></div></div></blockquote><div><br></div><div>Clearly NULL was returned, which means no natural SF was created.</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 dir="ltr"><div dir="ltr">Below is the structure to load a mesh file from gmsh; <br><br>  call DMCreate(PETSC_COMM_WORLD, dm, ierr);CHKERRA(ierr)<br>  call DMSetType(dm, plex, ierr);CHKERRA(ierr)<br>  call DMSetUseNatural(dm, PETSC_TRUE, ierr);CHKERRA(ierr)<br>  call DMSetFromOptions(dm, ierr);CHKERRA(ierr)<br>  call DMGetNaturalSF(dm, sf_nat, ierr);CHKERRA(ierr)<br>  call PetscSFView(sf_nat, PETSC_VIEWER_STDOUT_WORLD, ierr);CHKERRA(ierr)<br></div></div></blockquote><div><br></div><div>The natural SF is created during mesh distribution. That has not happened here. This means that</div><div>the order of cells is identical to the file it was read from.</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 dir="ltr"><div dir="ltr">Best<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 14, 2022 at 10:49 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 Wed, Jul 13, 2022 at 10:17 PM Bora Jeong <<a href="mailto:boraj1021@gmail.com" target="_blank">boraj1021@gmail.com</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 dir="ltr">Dear petsc team,<div>  <br>I am a user of DMPlex for a finite volume code and there is a necessity to know global index of each cell. Here the global index means the indexing that can be found from a mesh file itself without distribution over processors. It seems petsc community denotes this indexing term as "natural". <br><br>What I want to do is to create a local array (not petsc vector but just an array variable in the program) to map distributed cell ID to natual cell ID, for example, an array "A"; <br>A(distributed_node_ID) = natural_node_ID<br><br>There are some petsc functions to support mapping between global and natural vectors. However, I just need to define the array "A" as above example. To achieve this, what is a proper/smart way? In other words, how can I extract the natural_cell_ID from a distributed local_cell_ID? <br><br>I turned on DMSetUseNatural(DM, PETSC_TRUE) before distribution, but after this, defining all the required section and star forest objects to get natural and global vectors seems not that direct way for my purpose, which is just to extract the above mapping array "A". Can I get any comments about it?<br></div></div></blockquote><div><br></div><div>There is only one thing created, the sfNatural PetscSF object, which you can get with DMGetNaturalSF(). The roots of this SF are</div><div>the global numbers of dofs stored in PETSc vectors, and the leaves are natural numbers for these dofs. Thus, when we map global</div><div>vectors to natural vectors in DMPlexGlobalToNaturalBegin/End(), we call PetscSFBcastBegin/End(). Mapping natural to global we call</div><div>PetscSFReduceBegin/End(). You could pull the information out of the SF using PetscSFGetGraph() if you want.</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 dir="ltr"><div>Regards<br>Mo<br></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><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="http://www.cse.buffalo.edu/~knepley/" 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>-- <br><div dir="ltr"><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="http://www.cse.buffalo.edu/~knepley/" 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>-- <br><div dir="ltr"><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="http://www.cse.buffalo.edu/~knepley/" 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>-- <br><div dir="ltr"><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="http://www.cse.buffalo.edu/~knepley/" 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>-- <br><div dir="ltr"><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="http://www.cse.buffalo.edu/~knepley/" 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>-- <br><div dir="ltr"><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="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><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="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>