-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds demo using DMPlex #7
Conversation
Presently, a DM (of type DMPlex) is created and then information from it is extracted in saved in RDy<*> mesh data structures.
3215f55
to
9d9b794
Compare
ierr = PetscOptionsBegin(user->comm, NULL, "2D Mesh Options", ""); | ||
PetscCall(ierr); | ||
{ | ||
PetscCall(PetscOptionsInt("-Nx", "Number of cells in X", "", user->Nx, &user->Nx, NULL)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we really supposed to call PetscCall
for every call to a PETSc function? I wonder if we can configure PETSc to fail on unsuccessful operations instead of having to check ierr
everywhere. This isn't an issue with this PR, just something I've been curious about lately. I can look more into this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we might be able to use this error handler to abort when an error is encountered. That would preclude the need for all the error flag checking. Just an idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use the abort handler, but then you don't get a reliable stack trace. Some day we'll use Rust for systems programming and then it's the ?
operator. It's true that stack traces can be obtained using libunwind
, but PETSc hasn't gone all-in on that route (it adds complexity to the build and may not work everywhere).
Looks pretty good so far (and I've verified for myself that it builds and runs). I will take a closer look at this tomorrow early in the day if that works for you. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good to me. I've left some comments for your consideration, but I don't see anything that should prevent this from going in.
|
||
typedef struct { | ||
PetscReal X[3]; | ||
} RDyCoordinate; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about RDyPoint?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or maybe RDyNode? We should also store other attributes in the Node or Point type, such as boundary code to define boundary and outlet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of storing only the coordinates in a "point" type. We could then have a "node" type that associates other information with a point, embedding the point in the node like this:
typedef struct {
RDyPoint point;
// (other stuff)
} RDyNode;
Then functions that only care about the coordinates could focus on RDyPoint
, and anything that needs the additional data could use RDyNode
instead.
CELL_QUAD_TYPE /* hexahedron cell for a 3D cell */ | ||
} RDyCellType; | ||
|
||
typedef struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Several of the comments for fields in this struct are copy-pasted and should probably be made more specific.
|
||
PetscReal *area; /* area of the cell */ | ||
|
||
} RDyCell; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about RDyCells, RDyVertices, and RDyEdges for these three structs, instead of the singular forms? That makes clear that they are arrays of data for several items instead of one. (Not a big deal, but naming is hard, so I think it deserves some thought.)
RDyMesh *mesh; | ||
}; | ||
|
||
PetscErrorCode RDyInitialize_IntegerArray_1D(PetscInt *array_1D, PetscInt ndim_1, PetscInt init_value) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some thoughts on arrays that we could discuss when we talk about the library itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks great to me. I just have some minor comments.
PetscReal xc = cells->centroid[icell].X[1]; | ||
PetscReal yc = cells->centroid[icell].X[0]; | ||
if (yc < bu && xc >= bl && xc < br) { | ||
b_ptr[icell * 3 + 0] = 1.0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we set the dof=3 to account for 3 unknowns in the equations, the global vector size is number_of_cells * dof. But the boundary code (b_ptr) suppose to have dof=1. It is OK for the demo code, but it will be better in the future if we can allocate b_ptr with the size = number_of_cells. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree we need a better way to have no-flow boundaries embedded in the domain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make them as physical curves (Face Sets
) in the mesh?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Face set was exactly what I was thinking of using. We had a similar discussion on TDycores-Project/TDycore#225.
In the RDycore lib repo (which we haven't created yet), we would go with TDycores-Project/TDycore#225 (comment) and TDycores-Project/TDycore#225 (comment).
swe_roe/show_results.m
Outdated
close all | ||
|
||
if ~exist('PetscBinaryRead') | ||
error(['Please add PETSc MATLAB files before calling this script via: ' char(10) ... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am now getting the PETSC_DIR though [~,PETSC_DIR] = system('echo $PETSC_DIR');
Then we can add path to PetscBinaryRead: addpath([PETSC_DIR(1:end-1) '/share/petsc/matlab/']);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@donghuix What do you think about a6887fa#diff-d78a0fbb7b2633122c4842162cbc315ff849e79a59ee8c9d8931aa1ecac04cd3R11-R19?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks great to me. Thanks.
|
||
typedef struct { | ||
PetscReal X[3]; | ||
} RDyCoordinate; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or maybe RDyNode? We should also store other attributes in the Node or Point type, such as boundary code to define boundary and outlet.
…roblems into bishtgautam/dmplex * 'bishtgautam/dmplex' of https://github.com/RDycore/toy-problems: Minor fixes for PETScv3.18.1
and the output will be nearly identical with O(1-e-14) differences between
ex1.c
that is run via