-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add peridynamics module #11562
Add peridynamics module #11562
Conversation
@bwspenc Here is the PR. |
Job Documentation on d603440 wanted to post the following: View the site here This comment will be updated on new commits. |
08d31d8
to
58e7252
Compare
ae1a507
to
a459f42
Compare
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
@hchen139 - Please fix this up. We've had discussions about this and will add it to the modules when it's updated. Thanks for your patience! |
Who will be working on this now that @hchen139 is gone? |
@dschwen I will continue to work on getting it merged into MOOSE. |
dacf2ec
to
e0d5644
Compare
I'll get to this early next week, stale bot. |
Real Y = (_pdnode[i].coord)(1); | ||
Real Z = (_pdnode[i].coord)(2); | ||
Real dis = std::sqrt(X * X + Y * Y + Z * Z); | ||
if (dis < 0.001) |
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.
@hchen139 Instead of hard coding in a length parameter like 0.001 here, you think it would be better to make it a function of horizon (1/3 or 1/2 horizon or something like that) ?
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 are right, but we need to pre calculate a quantity such as average horizon size for the irregular mesh. Sometimes this may be problematic since a global average horizon size may not necessarily presenting the local horizon size accurately for some irregular meshes.
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 can calculate the minimum spacing between two material points for a irregular discretization, and use this value to assign boundary ids. Will do this.
virtual RankTwoTensor computeDSDU(unsigned int component, unsigned int nd); | ||
|
||
///@{ Material point based material properties | ||
const MaterialProperty<Real> & _multi; |
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.
@hchen139 Not able to figure out what 'multi' does (?)
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 is a "factor" for the force state and its value is calculated in material class. Its value is calculated as: weight function * v_i * v_j * bond_associated_horizon_volume / horizon_volume.
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.
Ok got it, so it is a factor for the irregular discretization I'm guessing ?
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.
This factor is not specific to irregular discretization. But the expression, weight function * v_i * v_j * bond_associated_horizon_volume / horizon_volume, is specific to bond-associated correspondence formulation. For conventional correspondence formulation, it is "weight function * v_i * v_j".
|
||
std::vector<RankTwoTensor> nodal_force(_nnodes); | ||
for (unsigned int nd = 0; nd < _nnodes; ++nd) | ||
nodal_force[nd] = (_dgrad[nd].det() * _stress[nd] * _dgrad[nd].inverse().transpose()) * |
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.
@hchen139 Referring to your other comment, where does the 'multi' here for the finite strain mechanics get calculated ?
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.
We have it on the line 55.
for (unsigned int nd = 0; nd < _nnodes; ++nd) | ||
nodal_force[nd] = (_dgrad[nd].det() * _stress[nd] * _dgrad[nd].inverse().transpose()) * | ||
_shape[nd].inverse() * _multi[nd]; | ||
|
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.
// Residual = - (T * xi - T' * -xi )
// = - (T * xi + T' * xi )
// = - (T + T') * xi
// T, T' are nodal 'forces' (but are rank two and operate on _origin_vec_ij)
I'm not sure what's up with all the merge commits. Do 'git pull --rebase upstream devel', and then push -f this, and you should just have just your commits. |
0650d54
to
517d39b
Compare
@bwspenc I thought this was what I have done for my previous commit. Anyway, redid that and this one looks right now. |
517d39b
to
449d9a2
Compare
@bwspenc @hchen139 @naveen-pr How is this PR going? Think it can be merged sometime soon? @naveen-pr has some enhancements he's been working on he'd like to merge after it's all in. |
@tophmatthews We don't have exact time when this will be merged. It all depends on the review process. If someone besides Ben can help to review the code, it will definitely shorten the time. @naveen-pr For now, I think you can submit your changes to my repo and I will push your changes into the main PR. |
SmallStrainNOSPD::computeQpTotalStrain() | ||
{ | ||
// the green-lagrange strain tensor | ||
_total_strain[_qp] = 0.5 * (_deformation_gradient[_qp].transpose() * _deformation_gradient[_qp] - |
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.
Why use the green-lagrange strain for small strain ?
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 it is small strain, it should doesn't matter which measure you choose. And the green-lagrange strain was use here.
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.
True, but if by some chance you use small strain NOSPD but with large deformation, won't this calculate large strains but do the rest the of mechanics with the small strain assumption ?
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.
This is possible. But we have the FiniteStrainNOSPD for large/finite strain case.
@hchen139 Would you mind rebasing, resolving the comments, and force-pushing this branch to resolve the conflicts? |
…cs userobject for multi-threading (idaholab#11561)
74fb671
to
2b19bd1
Compare
2b19bd1
to
d603440
Compare
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Closing due to 30 days of inactivity. See http://mooseframework.org/moose/framework_development/patch_to_code.html |
closes #11561