[MPM] Moving enforcement of nonconforming SLIP from MPMBoundaryRotationUtility to to the relevant Condition #12018

gzjing · 2024-02-05T19:09:58Z

Currently, the MPMBoundaryRotationUtility is used to enforce both conforming and non-conforming slip Dirichlet conditions. While this makes sense in the conforming case, for which the contributions of all conditions and elements need to be modified, this makes little sense in the case of non-conforming boundary conditions. Here, the modifications only concerns the relevant particle-based condition and may be implementation-specific. Hence, it is better for this to be done within the condition itself, especially since the current development of another particle Dirichlet condition based on Langrange multipliers would otherwise further complicate the code in the rotation utility.

To do so, however, requires access to the Rotate method of the utility instance from all relevant condition objects. This is not possible in the current code, since this utility class is not static (because the base class in the core is not static) and the instance is currently only available as a member of the MPMResidualBasedBossakScheme object.

This PR presents a possible way of providing access via a static member pointer in MPMParticleBaseCondition to the MPMBoundaryRotationUtility instance held by the scheme. This way, the pointer just needs to be set once in the Initialize method call of the scheme to be made available to all condition instances.

What are your thoughts on this? Are there any better ways that this can be done?

…nd setting a static pointer

VeronikaSinger · 2024-02-06T06:56:53Z

Thanks Guozhen for creating this PR to discuss the topic. We like to refactor/clean the boundary rotation utility in MPM application and therefore move the rotations needed for the particle based conditions locally to the conditions. This is the idea we came up with.
We are happy for any feedback or other suggestions.
@ncrescenzio , @philbucher, @sunethwarna

VeronikaSinger · 2024-02-26T13:09:17Z

Hi @philbucher hi @sunethwarna
do you think the pointer to the rotation utility in the particle base condition is a suitable solution to do the rotations locally on the condition level or are there any other suggestions?

philbucher · 2024-02-29T10:38:37Z

I dont recommend static here, since this will be shared among ALL instances of this class. Probably ok for standard sims, but perhaps one would want different ones in the future

Instead I recommend to check out how NEIGHBOR_ELEMENTS etc are handled in the fluid-app. Perhaps you can introduce a new variable that can point to the rotation utility that should be used for a particular entity. Ofc needs to be set upfront

philbucher · 2024-02-29T10:40:56Z

Check for NEIGHBOUR_ELEMENTS

what do you think @rubenzorrilla ? Seems like a similar application to me

gzjing · 2024-03-01T14:27:10Z

Thanks @philbucher for the feedback!

I tried out your suggestion; unfortunately, a similar implementation to NEIGHBOUR_ELEMENTS turned out to be difficult for the rotation utility because it cannot be meaningfully serialized, as its base rotation class has all of its members marked const. This prevented the definition of its pointer as an application variable, unless I define a dummy serialization for the rotation utility.

I understand your concern with the use of static, though I suppose a scenario where different rotation utilities are required would be unlikely, since that implies the DoFs and/or dimensions are different in different parts of the simulation. The only other solution I can think of would be to make the pointer an instance member, and to call a member function on the relevant Condition instance to set the pointer in Initialize(). Since this function is not present in the base class, this would necessitate the use of dynamic_cast.

What are your thoughts on this? Do you have any other suggestions?

philbucher · 2024-03-03T19:37:17Z

I see, this is indeed a problem

Can you post the error that you get when trying to add the serialization? I was not aware that this is not working, perhaps this needs a more global change.

Other than that I also dont have good suggestions. It is indeed static vs dynamic_cast

gzjing · 2024-03-04T10:37:53Z

The issue lies with the const Variable<double>& mrFlagVariable member of the rotation utility, which causes a -fpermissive error to be reported (namely that qualifiers would be discarded in the load method) when attempting to save/load this member.

However, even if this had worked, I'm personally not very comfortable with the idea since the current implementation of the rotation utility (with all members as const) suggests that it can neither be copied nor moved. There's two main issues I see here:

Serialization requires the definition of a default constructor, which makes no sense for the rotation utility since its functionality depends on the proper specification of its const members, including a reference member that cannot be reseated later on.
It feels wrong to load changes to modify a const members of the class. I realized that the serializer is using a const_cast to cast away the constness for some types, but I'm concerned that this might lead to undefined behaviour. The IMB C++ documentation suggests that "if you cast away the constness of an object that has been explicitly declared as const, and attempt to modify it, the results are undefined".

Perhaps a better solution would be to change the implementation of the rotation utility (including the base class) instead, i.e. to remove the const qualifications on the members and instead relying on ensuring all its methods are marked const.

Otherwise, I'm more inclined to the static approach for its simplicity (I'll leave a comment in the code linking to this discussion, so that the neccessary changes can be made in the future should it ever become neccessary).

…rming SLIP to condition

philbucher

Some general recommendations

philbucher · 2024-03-11T23:17:58Z

applications/ParticleMechanicsApplication/custom_utilities/mpm_boundary_rotation_utility.h

+    }
+
+    // Checking whether it is normal element or penalty element
+    bool IsParticleBased(GeometryType& rGeometry) const


Input should be const, otherwise you might accidentally allocate some data

philbucher · 2024-03-11T23:18:07Z

applications/ParticleMechanicsApplication/custom_utilities/mpm_boundary_rotation_utility.h

-
-		return is_penalty;
-	}
+    bool IsParticleBased(NodeType& rNode) const


philbucher · 2024-03-11T23:19:11Z

applications/ParticleMechanicsApplication/custom_utilities/mpm_boundary_rotation_utility.h

+    {
+        if(this->IsSlip(rNode) )
+        {
+            const double identifier = rNode.FastGetSolutionStepValue(mrFlagVariable);


The usage of flag variables is outdated in favor of actual flags (like SLIP)

Since there's no existing Kratos flag that corresponds to this use case I guess I should define a new local flag via KRATOS_DEFINE_LOCAL_APPLICATION_FLAG ?

you could do that, but flags are a bit delicate in their usage (local and global flags that use the same bit will conflict with each other)

You could still use similar code, but I recommend a variable of type bool and saved in the non-historical data. This can be accesses with GetValue. The double in your current case is a leftover from when variables could not have other types

Understood, thanks!

philbucher · 2024-03-11T23:20:06Z

...ion/custom_conditions/particle_based_conditions/mpm_particle_penalty_dirichlet_condition.cpp

+            }
+
+            if (CalculateStiffnessMatrixFlag == true) {
+                MatrixType temp_matrix = ZeroMatrix(rLeftHandSideMatrix.size1(),rLeftHandSideMatrix.size2());


Allocating such a large matrix on the fly can have a performance impact.
Maybe you can reuse an existing variable or modify in-place?

I'll modify it in-place instead.

philbucher · 2024-03-11T23:20:43Z

applications/ParticleMechanicsApplication/custom_utilities/mpm_boundary_rotation_utility.h

+    // Checking whether it is normal element or penalty element
+    bool IsParticleBased(GeometryType& rGeometry) const
+    {
+        for(unsigned int itNode = 0; itNode < rGeometry.PointsNumber(); ++itNode)


Better iterate over the nodes directly with geometry.Points

# Conflicts: # applications/MPMApplication/custom_conditions/particle_based_conditions/mpm_particle_base_condition.h

…global frame

… elements

…g for SLIP

… RHS contributions from particle-based slip boundaries are expected to result in correct tangential contributions)

…f-ed RotationToolType

gzjing · 2024-03-25T20:18:45Z

After some discussion with @VeronikaSinger, we decided to rotate the contributions of particle-based conditions back to the global frame of reference after correcting for SLIP to avoid complications with mis-aligned frames of reference. The cleanest way to do this involves minor modifications of the base transformation utility seen in the pull request here. I hope this is okay - the changes made do not affect the existing interface and functionality as far as I'm aware.

I have also added a test case for penalty-based nonconforming slip, involving the motion of a block down a 15 degree incline with g = 10 m/s2.

I'm currently facing some issues that only crops up in Windows: there's a linking error related to the SetRotationUtility static method and its use in the scheme (see below). I've checked the relevant code, but still can't figure out where this error is coming from, especially since it doesn't show up in Ubuntu. Does anyone have an idea about how to solve this?

unity_0_cxx.obj : error LNK2019: unresolved external symbol "public: static void __cdecl Kratos::MPMParticleBaseCondition::SetRotationUtility(class Kratos::MPMBoundaryRotationUtility<class boost::numeric::ublas::matrix<double,struct boost::numeric::ublas::basic_row_major<unsigned __int64,__int64>,class boost::numeric::ublas::unbounded_array<double,class std::allocator<double> > >,class boost::numeric::ublas::vector<double,class boost::numeric::ublas::unbounded_array<double,class std::allocator<double> > > > const *)" (?SetRotationUtility@MPMParticleBaseCondition@Kratos@@SAXPEBV?$MPMBoundaryRotationUtility@V?$matrix@NU?$basic_row_major@_K_J@ublas@numeric@boost@@V?$unbounded_array@NV?$allocator@N@std@@@234@@ublas@numeric@boost@@V?$vector@NV?$unbounded_array@NV?$allocator@N@std@@@ublas@numeric@boost@@@234@@2@@Z) referenced in function "public: virtual void __cdecl Kratos::MPMResidualBasedBossakScheme<class Kratos::UblasSpace<double,class boost::numeric::ublas::compressed_matrix<double,struct boost::numeric::ublas::basic_row_major<unsigned __int64,__int64>,0,class boost::numeric::ublas::unbounded_array<unsigned __int64,class std::allocator<unsigned __int64> >,class boost::numeric::ublas::unbounded_array<double,class std::allocator<double> > >,class boost::numeric::ublas::vector<double,class boost::numeric::ublas::unbounded_array<double,class std::allocator<double> > > >,class Kratos::UblasSpace<double,class boost::numeric::ublas::matrix<double,struct boost::numeric::ublas::basic_row_major<unsigned __int64,__int64>,class boost::numeric::ublas::unbounded_array<double,class std::allocator<double> > >,class boost::numeric::ublas::vector<double,class boost::numeric::ublas::unbounded_array<double,class std::allocator<double> > > > >::Initialize(class Kratos::ModelPart &)" (?Initialize@?$MPMResidualBasedBossakScheme@V?$UblasSpace@NV?$compressed_matrix@NU?$basic_row_major@_K_J@ublas@numeric@boost@@$0A@V?$unbounded_array@_KV?$allocator@_K@std@@@234@V?$unbounded_array@NV?$allocator@N@std@@@234@@ublas@numeric@boost@@V?$vector@NV?$unbounded_array@NV?$allocator@N@std@@@ublas@numeric@boost@@@234@@Kratos@@V?$UblasSpace@NV?$matrix@NU?$basic_row_major@_K_J@ublas@numeric@boost@@V?$unbounded_array@NV?$allocator@N@std@@@234@@ublas@numeric@boost@@V?$vector@NV?$unbounded_array@NV?$allocator@N@std@@@ublas@numeric@boost@@@234@@2@@Kratos@@UEAAXAEAVModelPart@2@@Z) [D:\a\Kratos\Kratos\build\Custom\applications\MPMApplication\KratosMPMApplication.vcxproj]
D:\a\Kratos\Kratos\build\Custom\applications\MPMApplication\Custom\KratosMPMApplication.pyd : fatal error LNK1120: 1 unresolved externals [D:\a\Kratos\Kratos\build\Custom\applications\MPMApplication\KratosMPMApplication.vcxproj]

gzjing · 2024-03-26T05:26:17Z

Thanks @philbucher :)

philbucher

Looks good to me, minor comment

philbucher · 2024-04-21T16:39:43Z

kratos/utilities/coordinate_transformation_utilities.h

can you please make a separate PR for the core changes?
This is the standard procedure, then it usually gets reviewed and merged much faster

PR created for core changes (#12327)

# Conflicts: # applications/MPMApplication/custom_strategies/schemes/mpm_residual_based_bossak_scheme.hpp # applications/MPMApplication/custom_utilities/mpm_boundary_rotation_utility.h # applications/MPMApplication/python_scripts/apply_mpm_slip_boundary_process.py

… into mpm/refactor_nonconforming_slip

# Conflicts: # kratos/utilities/coordinate_transformation_utilities.h

…RotationUtility

gzjing · 2024-07-27T07:05:25Z

The core changes have been merged to master in #12327 and the resulting conflicts with the changes in this PR have been resolved. This PR, which now no longer contain core changes, is now ready to be merged.

VeronikaSinger · 2024-08-02T06:52:15Z

Thanks @gzjing for the changes. I tested several examples and it works as expected.

Allow MPMParticleBaseCondition access to rotationUtility by passing a…

95c3915

…nd setting a static pointer

gzjing added Discussion Proposal Suggestion of a concept for further development in a new field of application Refactor When code is moved or rewrote keeping the same behavior labels Feb 5, 2024

gzjing assigned gzjing and VeronikaSinger Feb 5, 2024

gzjing added 2 commits March 11, 2024 14:53

Refactor MPMBoundaryRotationUtility, shifting imposition of non-confo…

7676c3a

…rming SLIP to condition

Rename IsPenalty to IsParticleBased

50f9b25

philbucher reviewed Mar 11, 2024

View reviewed changes

gzjing added 10 commits March 16, 2024 14:20

Merge branch 'master' into mpm/refactor_nonconforming_slip

a91aeba

# Conflicts: # applications/MPMApplication/custom_conditions/particle_based_conditions/mpm_particle_base_condition.h

Replace legacy IS_STRUCTURE by PARTICLE_BASED_SLIP

b26a403

Modify RotateAux and extract RotateRHSAux to enable easy rotation to …

0e967cf

…global frame

Prevent rotation for particle-based slip in scheme for conditions and…

f615db1

… elements

Rotate penalty-based contributions back to global frame after updatin…

3355f81

…g for SLIP

Move ApplySlipCondition inside the if statement for clarity

cb5cbfc

Merge branch 'master' into mpm/refactor_nonconforming_slip

c2049f4

Add test for penalty-based nonconforming slip

d6348db

Remove CalculateReactionForces from MPMBoundaryRotationUtility (since…

fced2ec

… RHS contributions from particle-based slip boundaries are expected to result in correct tangential contributions)

specify "MPMParticleBaseCondition::" in cpp file involving the typede…

0f990de

…f-ed RotationToolType

philbucher added 2 commits March 26, 2024 00:09

missing KRATOS_API

73d0e69

leftover

fc9a6af

gzjing marked this pull request as ready for review March 26, 2024 05:26

gzjing requested review from a team as code owners March 26, 2024 05:26

philbucher reviewed Apr 21, 2024

View reviewed changes

gzjing mentioned this pull request Apr 27, 2024

[Core] Modify coordinate_transformation_utilities.h to allow transformation back to global coordinates #12327

Merged

gzjing added 4 commits June 28, 2024 19:11

rename non-conforming slip test case to particle_based_slip_test

9c8bb42

Merge remote-tracking branch 'origin/mpm/refactor_nonconforming_slip'…

29b5382

… into mpm/refactor_nonconforming_slip

Cleanup after merge

7b6caa8

gzjing closed this Jun 28, 2024

gzjing reopened this Jun 28, 2024

gzjing added 3 commits July 26, 2024 18:50

Merge branch 'master' into mpm/refactor_nonconforming_slip

e9011fd

# Conflicts: # kratos/utilities/coordinate_transformation_utilities.h

Cleanup after merging

2e8f24c

Make available overloaded RevertRotate from base class in MPMBoundary…

1880549

…RotationUtility

gzjing removed the request for review from a team July 27, 2024 06:58

VeronikaSinger added 2 commits August 1, 2024 14:26

Merge branch 'master' into mpm/refactor_nonconforming_slip

d2cb8a3

update analysis file

ed3b53f

VeronikaSinger approved these changes Aug 2, 2024

View reviewed changes

gzjing merged commit b37159e into master Aug 9, 2024
9 of 11 checks passed

gzjing deleted the mpm/refactor_nonconforming_slip branch August 9, 2024 18:48

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[MPM] Moving enforcement of nonconforming SLIP from MPMBoundaryRotationUtility to to the relevant Condition #12018

[MPM] Moving enforcement of nonconforming SLIP from MPMBoundaryRotationUtility to to the relevant Condition #12018

gzjing commented Feb 5, 2024

VeronikaSinger commented Feb 6, 2024

VeronikaSinger commented Feb 26, 2024

philbucher commented Feb 29, 2024

philbucher commented Feb 29, 2024

gzjing commented Mar 1, 2024 •

edited

Loading

philbucher commented Mar 3, 2024

gzjing commented Mar 4, 2024

philbucher left a comment

philbucher Mar 11, 2024

gzjing Mar 12, 2024

philbucher Mar 11, 2024

philbucher Mar 11, 2024

gzjing Mar 12, 2024

philbucher Mar 14, 2024

gzjing Mar 14, 2024

philbucher Mar 11, 2024

gzjing Mar 12, 2024

philbucher Mar 11, 2024

gzjing Mar 12, 2024

gzjing commented Mar 25, 2024

gzjing commented Mar 26, 2024

philbucher left a comment

philbucher Apr 21, 2024

gzjing Apr 28, 2024

gzjing commented Jul 27, 2024

VeronikaSinger commented Aug 2, 2024

[MPM] Moving enforcement of nonconforming SLIP from MPMBoundaryRotationUtility to to the relevant Condition #12018

[MPM] Moving enforcement of nonconforming SLIP from MPMBoundaryRotationUtility to to the relevant Condition #12018

Conversation

gzjing commented Feb 5, 2024

VeronikaSinger commented Feb 6, 2024

VeronikaSinger commented Feb 26, 2024

philbucher commented Feb 29, 2024

philbucher commented Feb 29, 2024

gzjing commented Mar 1, 2024 • edited Loading

philbucher commented Mar 3, 2024

gzjing commented Mar 4, 2024

philbucher left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gzjing commented Mar 25, 2024

gzjing commented Mar 26, 2024

philbucher left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gzjing commented Jul 27, 2024

VeronikaSinger commented Aug 2, 2024

gzjing commented Mar 1, 2024 •

edited

Loading