Learning Forum

[gcongdon]

I am running a large LS-DYNA model using R13.1 DP MPP executable. The model is of a masonry building represented primarily by inelastic solid elements connected with TIEBREAK (Option 7/Dycoss) contacts to represent the cracking/sliding in the mortar joints between bricks. Unfortunately the computational cluster I am using has a runtime limit significantly below the time which will be required for my model to run to completion. As such, I am attempting to run a series of sequential simple restart analysis models. I have had a variety of issues with the model, but have finally hit one regarding contact failure that I am unable to solve. Specifically, for the first analysis, all behavior in the model is as expected, though some cleanup/minor debugging is likely still needed. However, immediately after restarting the analysis, it appears that most (all?) of my contacts where the segment normal is not aligned with global Z are breaking when the model restarts.

Does anyone have any suggestions on how I can eliminate this erroneous restart behavior???

I have an image of just the masonry parts before and after the restart with magnified displacements shown below. In addition, I also have included the commandline syntax that I am using for the restart as well as the input data of my keyword file. The execution syntax works correctly for non-restart models and LS-DYNA runs to a normal termination condition with the syntax shown below. Unfortunately, the NOFULL command seems to be essential as the model will 'hang' after writing the d3full01 file and will neither terminate nor will it write the d3dump01.* files.

Execution Syntax:

mpiexec $EBROOTANSYS/v231/ansys/bin/linx64/lsdyna_dp_mpp.e memory=256M memory2=256M i=restart01.key r=d3dump01 o=main.otf g=main.ptf f=main.thf

Keyword (restart01.key):

$# LS-DYNA Keyword file created by LS-PrePost(R) 2024/R2(4.11.8)-25Jul2024
$# Created on Oct-28-2024 (00:39:25)
*KEYWORD
*TITLE
$#                                                                         title
NIST URM SPECIMEN I
*PARAMETER
$#   prmr1      val1     prmr2      val2     prmr3      val3     prmr4      val4
$R TERMNATE10.5
R TERMNATE3.0
*CONTROL_MPP_IO_NOFULL
*CONTROL_TERMINATION
$#  endtim    endcyc     dtmin    endeng    endmas     nosol
&termnate          0       0.0       0.0  1.0000E8         0
*END

Plot States:

[Reno Genest]

Hello,

You will find more information about restarts in LS-DYNA here:

https://ftp.lstc.com/anonymous/outgoing/support/FAQ_docs/restart.pdf

For a simple restart, you don't change anything to the model; not even the termination time. So, you don't need an input file (i=restart01.key is not needed on the command line). For a simple restart, your command line should be:

mpiexec $EBROOTANSYS/v231/ansys/bin/linx64/lsdyna_dp_mpp.e memory=256M memory2=256M r=d3dump01

You need to run in the same directory as the first run. If you stop the restarted run, LS-DYNA will create the d3dump02 which you can use to restart again:

mpiexec $EBROOTANSYS/v231/ansys/bin/linx64/lsdyna_dp_mpp.e memory=256M memory2=256M r=d3dump02

 

 

Let me know how it goes.

 

Reno.

[gcongdon]

Hi Reno,

Thanks for the reply. I used the document that you linked in conjunction with the Restart chapter in the user keyword manual. I believe that technically I am using a small restart analysis as I am changing the termination time in between runs. I followed the suggestions that you made precisely regarding running in the same directory. The restarted model does run to completion creating d3dump02.* files. However, as you can see in the image I attached in the thread, the contacts do not appear to be initializing properly as the are nearly all open, when all should be closed. Do you have any suggestions about what could be causing the issues with the contacts after the model has "successfully" restarted?

[Reno Genest]

Hello,

Have you tried doing a simple restart instead  of a small restart? Why do you need to change the termination time? Set the termination time to the value you need from the beginning and do simple restarts.

It is difficult to say what is causing the contact problem that you see in your small restart. You will have to do some testing. Here is what I would do:

• Remove all contacts, run the model and perform the restart. Do you still see a weird behavior before and after restart? If the results are similar, then contacts are most likely the problem.
• Replace all tiebreak contacts with *CONTACT_TIED_SURFACE_TO_SURFACE contacts. Does it work? If so, then the problem is with the tiebreak contacts.
• Try other tiebreak contact options (2, 9, etc.). and see if you can identify the problem to a tiebreak option.

 

Note that Ansys employees are not allowed to download and upload files on the Ansys Forum. You can still post  your model and other users may be able to look at it and help you.

If you are a commercial customer, please create a support case on the Ansys Customer Support Space (ACSS) and we will be able to look at your model and help you better:

customer.ansys.com

 

Let me know how it goes.

 

Reno.

[gcongdon]

Hello again,

It appears that this may be a bug. I did as you suggested and tried simple restart, small restart, and I also tried a full restart. I consistently eperienced failure/erroneous restart behavior with each type. After this I started doing a sensitivity analysis with contact parameters. It appears that the issue is with the MORTAR contact specification:

• If I specify all contacts as *CONTACT_AUTOMATIC_SURFACE_TO_SURFACE_TIEBREAK_ID, I am not having issues with restarting models.
• If I specify all contacts as *CONTACT_AUTOMATIC_SURFACE_TO_SURFACE_TIEBREAK_MORTAR_ID I have erroneous behavior.

Do you have any suggestions as to how I can proceed?