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

Damage model - fix #89

Closed
mark-hobbs opened this issue Jul 12, 2021 · 2 comments
Closed

Damage model - fix #89

mark-hobbs opened this issue Jul 12, 2021 · 2 comments
Assignees

Comments

@mark-hobbs
Copy link
Collaborator

PeriPy does not correctly capture softening damage. There are also issues with numerical stability when using finer meshes. It is possible that these issues are linked. The damage model implementation in PeriPy is almost certainly the source of these issues and requires further examination.

The attached image illustrates the predicted load-CMOD curve for an unnotched beam in three-point bending (Fig. 14 in the PeriPy manuscript). Equivalent results obtained using my Matlab/C code are included (trilinear model, surface corrections).

Beam_4_UN_PeriPy

@mark-hobbs mark-hobbs self-assigned this Jul 12, 2021
@mark-hobbs mark-hobbs changed the title Damage model Damage model - fix Jul 12, 2021
@bb515
Copy link
Collaborator

bb515 commented Jul 26, 2021

If stiffness corrections were applied, note that incorrect stiffness corections could also be the issue. A unit test for the bilinear and trilinear damage models would be a good test for this.

Perhaps test one single peridynamic bond and see if it behaves as expected.

Alternatively construct a very simple 2D trilinear example with exactly the same geometry/boundary conditions on MATLAB and PeriPy. Save the MATLAB data as "expected.mat". Does the PeriPy simulation data match exactly the data "expected.mat" (within machine tolerance? - i.e., use np.allclose(actual, expected) and set an appropriate tolerance).

In constructing the test it may become clear what is wrong exactly.

@mark-hobbs
Copy link
Collaborator Author

I think this issue was due to a poorly constructed input file and is not related to the damage model. This could have easily been avoided by visually verifying that the correct nodes were constrained etc. See discussion (Post-processing #111) for ideas on avoiding this issue again.

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

No branches or pull requests

2 participants