Skip to content
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

Merged
merged 23 commits into from
Nov 15, 2022
Merged

Adds demo using DMPlex #7

merged 23 commits into from
Nov 15, 2022

Conversation

bishtgautam
Copy link
Contributor

@bishtgautam bishtgautam commented Nov 8, 2022

  • Adds a demo that uses TS and DMPlex
  • Only works serially
  • The 2D partial dam break problem is implemented
  • The code can be run via
./ex2 -dm_view  -hu 10.0 -hd 5.0 -save -dt 0.01 \
-ts_max_time 0.01 -ts_monitor -Nx 200 -Ny 200 -save -b -ts_max_time 0.1

and the output will be nearly identical with O(1-e-14) differences between ex1.c that is run via

./ex1 -dt 0.01 -ts_max_time 0.1 -dm_view -save -Lx 200 -Ly 200 -save 1 -ts_monitor -b

@bishtgautam bishtgautam changed the title [WIP] Adds demo using DMPlex Adds demo using DMPlex Nov 9, 2022
swe_roe/ex2.c Outdated Show resolved Hide resolved
ierr = PetscOptionsBegin(user->comm, NULL, "2D Mesh Options", "");
PetscCall(ierr);
{
PetscCall(PetscOptionsInt("-Nx", "Number of cells in X", "", user->Nx, &user->Nx, NULL));
Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Collaborator

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).

@jeff-cohere
Copy link
Collaborator

jeff-cohere commented Nov 9, 2022

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.

Copy link
Collaborator

@jeff-cohere jeff-cohere left a 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;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about RDyPoint?

Copy link
Contributor

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.

Copy link
Collaborator

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 {
Copy link
Collaborator

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;
Copy link
Collaborator

@jeff-cohere jeff-cohere Nov 10, 2022

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) {
Copy link
Collaborator

@jeff-cohere jeff-cohere Nov 10, 2022

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.

Copy link
Contributor

@donghuix donghuix left a 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.

swe_roe/ex2.c Outdated Show resolved Hide resolved
swe_roe/ex2.c Outdated Show resolved Hide resolved
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;
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

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?

Copy link
Contributor Author

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).

close all

if ~exist('PetscBinaryRead')
error(['Please add PETSc MATLAB files before calling this script via: ' char(10) ...
Copy link
Contributor

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/']);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

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;
Copy link
Contributor

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.

@bishtgautam bishtgautam merged commit 2805d44 into main Nov 15, 2022
@bishtgautam bishtgautam deleted the bishtgautam/dmplex branch November 15, 2022 17:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants