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

MateriаlIDs based solid models in phasefield processes #2262

Merged
merged 4 commits into from Nov 13, 2018

Conversation

Projects
None yet
3 participants
@endJunction
Copy link
Member

endJunction commented Nov 11, 2018

Two main points:

  • MaterialIDs based solid models, and
  • Remove diamond polymorphism and the PhaseFieldExtension I/F.

Usage is now simpler; one needs to implement a damage function for specific material. The current is for LinearElasticIsotropic.

@chleh
Copy link
Collaborator

chleh left a comment

Only small comments on the implementation. Some other things:

  • shouldn't the tests be updated or some new ones created?
  • now material ID based material models are implemented for a single process. What's the plan to do the same for other processes (in particular SD) and for models other than solid models?
  • the PF process seems to be strongly linked to linear elasticity ATM. What's the plan to implement other material models for PF? Otherwise material IDs don't make much sense IMHO.
@@ -137,7 +152,7 @@ class PhaseFieldLocalAssembler : public PhaseFieldLocalAssemblerInterface
for (unsigned ip = 0; ip < n_integration_points; ip++)
{
// displacement (subscript u)
_ip_data.emplace_back(*_process_data.material);
_ip_data.emplace_back(solid_material);

This comment has been minimized.

@chleh

chleh Nov 12, 2018

Collaborator

The comment in the line above seems to be outdated/confusing. ✔️

@@ -126,6 +128,19 @@ class PhaseFieldLocalAssembler : public PhaseFieldLocalAssemblerInterface
_ip_data.reserve(n_integration_points);
_secondary_data.N.resize(n_integration_points);

auto& solid_material =

This comment has been minimized.

@chleh

chleh Nov 12, 2018

Collaborator

Is that a pointer? Then please use auto*, because below you emplace that in a vector.

This comment has been minimized.

@endJunction

endJunction Nov 12, 2018

Author Member

It's a ref indeed. The IPData ctor stores that reference...

This comment has been minimized.

@chleh

chleh Nov 13, 2018

Collaborator

OK, but that's pretty intransparent at that point (i.e., not visible from these few lines of code.)

@@ -137,7 +152,7 @@ class PhaseFieldLocalAssembler : public PhaseFieldLocalAssemblerInterface
for (unsigned ip = 0; ip < n_integration_points; ip++)
{
// displacement (subscript u)
_ip_data.emplace_back(*_process_data.material);
_ip_data.emplace_back(solid_material);

This comment has been minimized.

@chleh

chleh Nov 12, 2018

Collaborator

Will that copy the solid_model? Is it necessary to store the element-wise solid_model in each integration point?

This comment has been minimized.

@endJunction

endJunction Nov 12, 2018

Author Member

No copy. As discussed, we don't need to store the solid_model for every ip, only its state.
The solid_model could be kept in process data, then accessed through the material id, or in the assembler as a reference.

This comment has been minimized.

@chleh

chleh Nov 13, 2018

Collaborator

OK

std::map<int,
std::unique_ptr<
MaterialLib::Solids::MechanicsBase<DisplacementDim>>>&&
solid_materials_,

This comment has been minimized.

@chleh

chleh Nov 12, 2018

Collaborator

If one assumes few MaterialIDs, contiguous, starting from 0 (one can check the latter two), an std::vector might be better and one could use solid_materials_[MatID] in the integration loop w/o caching the value of solid_materials_[MatID] in the ip data.

This comment has been minimized.

@endJunction

endJunction Nov 12, 2018

Author Member

Agree, that on often access a vector would perform much better, but for now it is only one time lookup during initialization.

DisplacementDim> /* C_compressive */,
double /* strain_energy_tensile */,
double /* elastic_energy */
>

This comment has been minimized.

@chleh

chleh Nov 12, 2018

Collaborator

IMHO this tuple cries "I wanna be a struct!"

This comment has been minimized.

@endJunction

endJunction Nov 12, 2018

Author Member

As discussed, implementation is not simple for this.

This comment has been minimized.

@chleh

chleh Nov 13, 2018

Collaborator

OK

}
EIGEN_MAKE_ALIGNED_OPERATOR_NEW;

static constexpr int kelvin_vector_size =
MathLib::KelvinVector::KelvinVectorDimensions<DisplacementDim>::value;

This comment has been minimized.

@chleh

chleh Nov 12, 2018

Collaborator

Adding such an "alias" to all structs does not seem to be a good solution in the long run.

This comment has been minimized.

@endJunction

endJunction Nov 12, 2018

Author Member

Speaking to myself: "Where did it come from? Did I pushed that?"

@@ -154,7 +178,7 @@ class ThermoMechanicalPhaseFieldLocalAssembler
for (unsigned ip = 0; ip < n_integration_points; ip++)
{
// displacement (subscript u)
_ip_data.emplace_back(*_process_data.material);
_ip_data.emplace_back(solid_material);

This comment has been minimized.

@chleh

chleh Nov 12, 2018

Collaborator

Maybe the same "copy" problem as in the PF process.

@endJunction endJunction force-pushed the endJunction:MaterialIdsBasedSolidModelsPhasefield branch from 32d6046 to d43ed14 Nov 12, 2018

@wenqing
Copy link
Member

wenqing left a comment

Looks good.

@@ -12,7 +12,9 @@
#include <memory>
#include <vector>

#include "MaterialLib/SolidModels/PhaseFieldExtension.h"
#include "MaterialLib/SolidModels/LinearElasticIsotropic.h"

This comment has been minimized.

@wenqing

wenqing Nov 13, 2018

Member

This include is not needed because it is included in /LinearElasticIsotropic.h too.

This comment has been minimized.

@endJunction

endJunction Nov 13, 2018

Author Member

The LinearElasticIsotropicPhaseField.h does not include the LinearElasticIsotropic.h any longer. The bulk modulus etc. is passed to the function directly.

@endJunction endJunction force-pushed the endJunction:MaterialIdsBasedSolidModelsPhasefield branch from d43ed14 to 4825cc6 Nov 13, 2018

endJunction added some commits Nov 9, 2018

[MatL] Extract calculateDegradedStress().
The multiple inheritance for the phase field extension
is not actually needed and can be completely avoided.
[PL] TMPF; MaterialIDs based solid models.
Same changes as in PhaseField process.

@endJunction endJunction force-pushed the endJunction:MaterialIdsBasedSolidModelsPhasefield branch from 4825cc6 to 92a573a Nov 13, 2018

@endJunction endJunction merged commit 1c06275 into ufz:master Nov 13, 2018

3 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/jenkins/pr-merge This commit looks good
Details
deploy/netlify Deploy preview ready!
Details

@endJunction endJunction deleted the endJunction:MaterialIdsBasedSolidModelsPhasefield branch Nov 13, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.