Learning Forum

[Richard Smith]

I have an assembly that has a number of bolts in it that pretension to their preloaded state via an initial Dynamic Relaxtion phase.

I can then solve the subsequent analysis (quasi-static) explicitly with no issue.

I am interested however in performing this analysis with the implicit solver as a true static analysis however after the DR phase ends and imlicit starts (after i've modified deck to start implicitly) the job just errors out.

In general then, should it be possible to run a static implicit job from a preloaded state from DR phase?

I know implicit will not run with any free body rigid body modes but wouldn't my bolts be sufficiently restrained and have no rigid body modes?

How do i deal with true fasteners for implicit jobs, or is this not possible and i have to linearize with CNRB's etc?

Thanks.

[Jim Day]

In general, switching an analysis between explicit (which I assume is how you're running the DR phase, although there's the option to run the DR phase as implicit; see IDRFLG in *CONTROL_DYNAMIC_RELAXATION) to implicit is permitted. From your description, it's not clear why the implicit phase following DR errorred out. Look for the word "Error" in your mes* files. If the problem is a failure to converge, consider making the implicit analysis dynamic using *CONTROL_IMPLICIT_DYNAMICS. The solution will be more likely to converge in a dynamic implicit analysis. An advantage of implicit dynamic as compared to explicit is you can slow down the rate of loading so you may obtain quasi-static behavior.

[Richard Smith]

Hi Jim, thanks for the reply.

Turns out my I don't think my issue now has anything to do with DR phase or anything i mentioned above. 

To trial my job I simplified it, removed the bolts and made it totally linear with some fixed boundary surfaces (via SPC's) and just tried just running a simple modal analysis to see if anything else was up. The job still failed.

I'm running on a HPC and what I've now discovered (after the usual amount of pain) is that if I only run the job on a single core that this eigenvalue analysis solves perfectly well. As soon as i invoke more than one core it fails. These are just core(s) within one node and not across nodes.

The error doesn't give me any clues as to the problem. I know given it solves on one core that it isn't an input model issue. It always fails after the memory alert message (as seen below), leading me to think it's memory related. 

Usually for memory alocation I just use *KEYWORD 999999999 for all models running normal explicit but given this is an implicit job (which I'm not that familiar with in Dyna) this appears inadeqaute?

When, as suggested in message, I append "memory=7m memory2=6m" to the command line it still makes no difference and errors out. I can assign much more memory to both but nothing appears to fix the problem. The problem may not be memory related at all but no other clues are given in the output or the message files?

Any idea's?

Thanks.

 

 

[Jim Day]

I have no doubt that others on the forum can address this sort of problem better than I can.

 

Did you check all the mes**** files for the word "Error"?

 

It may be good to make a general test of your HPC installation of MPP LS-DYNA.  Try running a smaller implicit model using multiple cores, keeping in mind you don't want to assign a lot of cores to a small problem.  Start with two cores.   You can find examples at dynaexamples.com.   

[Richard Smith]

Hi Jim.

Seems like it is actually a solver version issue.

I went back and tried exactly the same model on V12dMPP and it ran fine.

So the unexpected halt above was on V14dMPP with no clue in any of the message files, strange....

Thanks Jim.

 

 

[Jim Day]

Version R14.1.0 will be released shortly. Hopefully, whatever ails R14.0.0 (which is what I assume you're using when you say V14), will be remedied in R14.1.0. The latest release of R13 is R13.1.1. You didn't happen to try that version, did you?