prescribed compression [WIP] #3119
Conversation
|
@bangerth can you please take a look if you can find any mistakes in this new assembly? You can ignore the changes in benchmarks/ (this is using it in the burstedde material model as an example). |
add prescribed compression to visco_plastic
| if (prescribed_compression != nullptr) | ||
| { | ||
| const double pi=numbers::PI; | ||
| prescribed_compression->prescribed_compression[i]=3; |
There was a problem hiding this comment.
I know it's just a test, but you don't actually use pi :-)
| @@ -495,6 +495,7 @@ namespace aspect | |||
| */ | |||
| bool include_melt_transport; | |||
| bool enable_additional_stokes_rhs; | |||
| bool enable_prescribed_compression; | |||
There was a problem hiding this comment.
why have a flag? can't you just test whether the material model attached the appropriate additional output?
| *prescribed_compression = | ||
| (this->get_parameters().enable_prescribed_compression) | ||
| ? scratch.material_model_outputs.template get_additional_output<MaterialModel::PrescribedCompressionOutputs<dim> >() | ||
| : nullptr; |
There was a problem hiding this comment.
Just don't use a parameter and instead test whether get_additional_output() returns anything that's non-null to determine whether or not to assemble anything.
There was a problem hiding this comment.
This makes the logic below (const bool update_strain_rate = ...) complicated as I would need to create a fake material model.
| data.local_rhs(i) += ( | ||
| // RHS of - (div u,p) = - (R,p) | ||
| - pressure_scaling | ||
| * prescribed_compression->prescribed_compression[q] |
There was a problem hiding this comment.
had to do a double-take here :-)
|
@naliboff I added the logic to automatically switch between the explicit and implicit version (you can toggle this from Can you let me know if this PR works for you as is or if I need to push the changes to the 2nd invariant of the strain tensor? |
only assemble momentum term if we are incompressible
tjhei
force-pushed
the
prescribed_compression
branch
from
021043c to
c8331ad
Compare
|
explicit: disabled: convergence: |
|
@tjhei - Thanks for doing all these updates! Are the results you posted above with the normal method we use for calculating the second invariant? I'm about to run the tests locally to make sure I get the same results. |
No, this was run with the changes to the computation of the second invariant. Do you want me to push those? I don't know if they are needed or not. |
|
New results using the explicit formulation and the second invariant (standard deal.II definition) of the deviatoric strain rate (rather than full strain rate). Not as clean as the results above, but we are still getting roughly the right angle at low resolutions. Still, probably warrants a full comparison between the two definitions of the strain rate invariant to start.
|
|
@tjhei, @cedrict - I did a few tests with different assumptions regarding the strain rate invariant and it appears we do need to use the full strain rate (e.g., the method we used at the Hackathon). Oddly, using the deal.II The figures below show the extension results for global refinement 3 or 5 and four difference scenarios for calculating the strain rate invariant:
The bottom panel is the same method we used at the Hackathon and appears to give a slightly better fit to the correct angle (60 degrees, white line) for the high resolution case. Fortunately, we are still obtaining roughly the right angle at coarse resolutions. Thoughts on how to proceed? My vote would be to update the PR with the different options for calculating the strain rate invariant (I'll do this) and then re-run these results with the Spiegelman 2016 brick experiment (e.g., setup that was used in the Newton paper). I can write some scripts to automatically measure the shear band angle and width from these experiments. Global refinement 3 (16 vertical elements): Global refinement 5 (64 vertical elements): |
|
@naliboff can we close this or do you want to grab anything else from here? |
No description provided.