A few questions about the mechanical [Contact] block

[Rachel Waxman]

Hello MOOSE users,

I am a mechanical engineering PhD student who just started using MOOSE this semester, so I'm a pretty new user. Also, I'm definitely not a computer scientist/programmer, so please bear with me.

1. First, a simple question: When using the [Contact] block, is there a way to get displacement components as output? It seems like even if my variables are defined as disp_x, disp_y, and disp_z, the variables I can display in Paraview from the exodus output file do not include components, but instead a displacement magnitude (same with contact pressure). I'm assuming that's a default for the Contact block. Is there a way to change that?

The pre-existing input file I'm currently working with can be found in:
moose > modules > combined > tests > frictional contact > sliding elastic blocks 2d > sliding elastic blocks 2d.i

I have also noticed this in multiple other pre-existing input files that use the Contact block (including simpler problems, like glued penalty in the mechanical contact constraint folder).

2. I have tried expanding the sliding elastic blocks into 3d using my own mesh file. It will not converge (kicks me out once it hits dt_min, even if I massively lower dt_min). I've attached the input file (glued_new3d.i) along with the mesh file made using CUBIT/Trelis (blocks3d2.e). The mesh file is good, as I've used with other input files successfully.

3. A vague question I can follow up with more detail after I understand the above better: Is there a reason the [Solid Mechanics] block cannot work with the [heat] kernel? When writing a problem with thermal expansion and mechanical displacement, these blocks do not cooperate. Instead I had to use the [solid_x/y/z] and [solid_x/y/z_ie] kernels.

Thanks in advance for any help, and for your patience.

—Rachel.

[Andrew....@csiro.au]

Hi Rachel,

 

Re (1): there is a drop-down box in paraview that allows you to visualise the components of a vector, but paraview defaults to “magnitude”.   Is that your problem?

 

a

 

 

Ph: +61 7 3327 4497.  Fax: +61 7 3327 4666
Queensland Centre for Advanced Technologies
PO Box 883, Kenmore, Qld, 4069 
 

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at http://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/5fd3ff21-4676-4b6f-aed6-131629d4a03b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rachel Waxman]

Yes, thank you. Apologies—I think since other outputs have included disp_x,y,z as separate variables, I did not notice the magnitude dropdown. I had a feeling there would be something obvious/simple I was missing.

[Cody Permann]

First and foremost, Welcome to the MOOSE community!

It looks like Andy already took care of 1) for you, Thanks Andy

2) I'll let one of the solid mechanics guys chime in on this one. However, in general this should work and there are a few 3D tests in the modules that demonstrate how to make contact work in 3D.

3) It's important to understand what's going on in each input file. The [Contact], [SolidMechanics] and other extended blocks can be a little confusing for new users because they hide some of the details of what PDE operators are being added to the equation systems. Each block in the input file triggers one or more "Actions" in MOOSE that programmatically add several objects as an alternative to listing several more objects in an input file. 

See http://mooseframework.org/wiki/MooseSystems/ActionsSystem/ 

Some of these physics modules are well documented while others are not. To briefly answer your question, the SolidMechanics block simply adds the kernels necessary for StressDivergence:

See modules/solid_mechanics/src/actions/SolidMechanicsAction.C and can handle expansion due to thermal effects:

See modules/tests/combined/thermo_mech/thermo_mech_test.i

However diving right into the source can be a bit challenging too so reading the documentation can be helpful (when it exists) To get started, take a look here: http://mooseframework.org/wiki/PhysicsModules/

There are other thermomechanics examples in the combined module so just start looking around and feel free to ask more questions as you explore.

Cody

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/e12d7adc-436a-4046-ad17-c8a406a4a3c3%40googlegroups.com.

[Rachel Waxman]

Thanks for the info, Cody—and for the welcome. I will look into those links and no doubt be back with more questions. Appreciate the help.

[Benjamin Spencer]

Rachel,

  It looks like you're trying to run a frictional contact problem. How important is it to you to include friction?

  The reason I ask is that while we do have a limited capability frictional contact, it is somewhat rough around the edges still, and much less robust/tested/used than frictionless or glued contact, as you have already noticed. You will have an order of magnitude more difficult time getting a solution than with frictionless or glued contact. If you can live with frictionless or glued contact, I would start with one of those.

  If you really need frictionless contact, I can help you, but just be aware that it is still under development. It's an area where we will be actively working this year.

-Ben

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/6f44bd7a-e71a-454d-b6ba-12ed5dd3a6b5%40googlegroups.com.

[Rachel Waxman]

Hi Ben, thanks for the response. I actually do not need to include friction. That was just the first problem I came across that was anything other than glued/no-slip. I'm looking for frictionless contact. I attempted to use the glued_penalty code and change the model to 'frictionless' (and also delete the zero-slip conditions) but ran into trouble. I have just now found the frictionless_penalty code (under sliding block > sliding > constraint). I'll attempt to incorporate that into my file instead and see what happens. The problem is, I keep running into either divergence, or an error of: "MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD with errorcode 1." I'm not really sure what the second one means, except possibly an issue with memory? This is my first foray into Unix (Terminal on my Mac) so I have a relatively steep learning curve.

The problem I am eventually trying to solve is a rod-cladding model (a cylinder inside a shell cylinder with a very small gap). The rod/pellet will be given a higher coefficient of thermal expansion than the cladding, which will lead to contact and stress. From there I'll work on a missing-pellet problem (where the rod has a portion taken out and therefore sharp edges will make contact with the cladding when it expands, leading to stress concentration). I'm trying to work my way up in stages, both to learn the input file syntax and to not over-complicate things too quickly.

I have gotten the rod-cladding model working so far as thermal expansion, but not once I try to incorporate [Contact] and slip. For that reason, I am simplifying into 2d or 3d blocks first. Once I try to incorporate the frictionless_penalty code, I can probably raise more specific questions/attach an input file for reference.

Thanks again for your help and patience.

[Benjamin Spencer]

We happen to do a lot of solving problems like you describe, so you should be able to get this working for your problem.  I'd use the following test as a starting point:

modules/combined/tests/mechanical_contact_constraint/blocks_2d/frictionless_kinematic.i

This test uses a new version of contact enforcement that is based on a system in MOOSE called Constraint. The choice of which system is used for contact enforcement is controlled by the "system=Constraint" line in the input file. We construct a far better Jacobian matrix for preconditioning with that system than the old system (which is still what you get by default).

The test is also set up to use the "default", formulation for contact, which strictly enforces the constraint, rather than using a penalty formulation. We still have a penalty parameter that is used in the enforcement of the constraint, but it is used in a different way than penalty contact, so you won't have any penetration of the surfaces in the converged solution.

The major drawback of Constraint-based contact enforcement is that it doesn't work well with the algebraic multigrid preconditioner that we typically use to scale up to very large numbers of processors. We are working on scalable preconditioning strategies that will work better on contact problems, but currently, your best bet is to use a direct solver for the preconditioner. We have had very good luck using superlu, which is a parallel direct solver, on these problems, but it only scales well up to about 12 processors. This still allows you to solve reasonably large engineering problems, but we'd like to be able to run much larger problems with contact.

The test problem I referred to is set up to use the 'lu' preconditioning method, which uses a direct solver, and only works in serial. If you want to run in parallel, you can use the following options in your executioner block to use superlu:

  petsc_options_iname = '-pc_type -pc_factor_mat_solver_package'

  petsc_options_value = 'lu       superlu_dist'

Note that you will have to use a version of PETSc that has been compiled with superlu support, but as I understand, the current versions of the MOOSE packages have that enabled.

-Ben

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/7ff308fc-9830-4c46-bf0d-00e409f86796%40googlegroups.com.

[Rachel Waxman]

I have tried to simply expand the code you mentioned (blocks_2d > frictionless_kinematic.i) into 3d, and it will not converge. It gives me the MPI_ABORT error, or the dt_min error. I'm not sure why it won't run, as all I did was add a third dimension. I am using a mesh file that has worked with other codes (specifically a 3d version of glued_penalty). I've tried running it with the contact formulation set to penalty, and also to default. As well, I've tried changing the solver petsc options you mentioned, and I get the same result either way. Any advice?

For reference, I'm running this in a folder I created within the modules > combined > tests folder, using modules-opt, which was created by running the Makefile in the modules > combined directory. If I move the 2d frictionless_kinematic.i (and its blocks_2d meshfile) into my working directory, it runs without a problem using modules-opt.

Thanks again. I'm guessing/hoping there will be something simple I'm missing. I've attached the input and mesh files I'm trying to work with. I've made sure the sidesets from the 2d file match those in my 3d mesh for BCs.

[Benjamin W Spencer]

Make sure you have appropriate BCS in the z direction. All rigid body translations and rotations must be constrained. 

Ben

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/0e21cea7-3788-442f-bc01-9f2a1a20bd8b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<blocks_3d2.e>

<frictionless_constraint3d.i>

[Rachel Waxman]

Thanks for the tip—I've added disp_z=0 BCs to the top and bottom of both blocks and the code now converges. Will be investigating further tomorrow. Appreciate the help.

[Derek Gaston]

"The reason I ask is that while we do have a limited capability frictional contact, it is somewhat rough around the edges still"

I see what you did there ;-)

Derek

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CANcsQPf4cAnFKoTEOPPf_Uby3GCG7LYZj75qF7JMXpf-0oTSQw%40mail.gmail.com.