It's probably easier to apply boundary conditions when you have the serial mesh. You may consider contributing the reader if it's a format that others use.
"onur.notonur via petsc-users" <petsc-users@mcs.anl.gov> writes: > Hi, > > I hope this message finds you all in good health and high spirits. > > I wanted to discuss an approach problem input file reading/processing in a > solver which is using PETSc DMPlex. In our team we have a range of solvers, > they are not built on PETSc except this one, but they all share a common > problem input format. This format includes essential data such as node > coordinates, element connectivity, boundary conditions based on elements, and > specific metadata related to the problem. I create an array for boundary > points on each rank and utilize them in our computations, I am doing it > hardcoded currently but I need to start reading those input files, But I am > not sure about the approach. > > Here's what I have in mind: > > - - Begin by reading the node coordinates and connectivity on a single core. > - Utilize the DMPlexCreateFromCellListPetsc() function to construct the > DMPlex. > - Distribute the mesh across processors. > - Proceed to read and process the boundary conditions on each processor. If > the global index of the boundary element corresponds to that processor, we > process it; otherwise, we pass. > > Additionally, maybe I need to reorder the mesh. In that case I think I can > use the point permutation IS obtained from the DMPlexGetOrdering() function > while processing boundary conditions. > > Also I have another approach in my mind but I don't know if it's possible: > Read/construct DMPlex on single core including boundary conditions. Store BC > related data in Vec or another appropriate data structure. Then distribute > this BC holding data structure too as well as DMPlex. > > I would greatly appreciate your thoughts and any suggestions you might have > regarding this approach. Looking forward to hearing your insights. > > Best regards, > > Onur
