Showing results for 
Search instead for 
Do you mean 
Reply

Evaluate peak stress in response simulation too slow

Hi,

 

I want to perform a peak contour stress evaluation in my model. It consists of approx. 150k elements. The excitation is a transient shock. It is modelled as an acceleration over time which is 0.1s long and has 200k points. I work with NX 8.0.

 

I usually only want to know the peak response acceleration on some nodes which works really fast and gives me good results. But for my report I also need the stress contour plot on every element. I tested the speed on a small part of my model with 1,5k element and it lasts already 3000s. When I start the evaluation on all elements it feels like it lasts forever. I estimated the time to 300,000s for the whole model, which is definitely too long.

 

I already looked into GTAC to find someone with a similar problem. I found a call where the solution was to increase the hypermatrix buffer size and the max array size in the customer defaults, but this had no effect on my calculation time.

 

It there a way to speed this the stress evaluation up?

7 REPLIES

Re: Evaluate peak stress in response simulation too slow

From experience the only ways are to

  1. Create small group of elements for each feature, part, etc and run them one at a time
  2. Do a few check with a few elements to see at what time the peak occur. You might find that the peak occur very quickly/early and "running" the analysis over the entire time signal (0.1s in your case) is irrelevant.

 

Thanks

Regards

Production: NX9.0.3.4, NX10.0.2.6
Development: VB.NET (amateur level !)

Re: Evaluate peak stress in response simulation too slow

Unfortunately, Response Sim's performance is inadequate to put it mildly.  It looks great with tutorials, but quite rapidly falls flat on its face.

 

While tweaking the memory might help not run out of it (i.e. fail), there's not much else you can do.  Every year we look at Response Sim hoping that finally something will happen, we get disapointed as nothing is being done to improve performance.  The poor guys at GTAC have to give this apologetic "use less elements" workaround, which really isn't a workaround... 

 

It is unfortunate as Response Sim. was a great product back in the I-DEAS days, and was promising when it was ported to NX, but since then, it looks like Response Simulation is not evolving...  For shock, a straight NASTRAN SOL103 solve works much faster (which is a shame)...  Same is true for SOL111 for random vibe, hours vs days with our models...

Re: Evaluate peak stress in response simulation too slow

Hi,

 

thank you for the answers so far.

 

The solution I used is to evaluate the shock stresses in frequency domain with a SRS signal and get all elements above a specified stress value in a group (about 5k to 15k elements). Afterwards evaluate the stress in time domain only on the elements in the created group. 

It is a workaround with fewer elements, but it works on my purpose.

Re: Evaluate peak stress in response simulation too slow

Hi Dimitri,

I'm not sure why you are solving the model twice, are SRS results not good enough?  Are you trying to show animated displacements?

Re: Evaluate peak stress in response simulation too slow

Hi,

 

when evaluete SRS events the peak results are very high (2-3 times higher then shock in time domain). This is also best practice in my company to calculate in time domain. The SRS was just to get the high stressed elements.

 

 

Re: Evaluate peak stress in response simulation too slow

SRS to Time signal. Is it not the case that there is 1 SRS profile for a given time history but an infinite (!) number of time history satisfing an SRS profile.

 

how do you decide on the duration of your re-constructed time history?

Production: NX9.0.3.4, NX10.0.2.6
Development: VB.NET (amateur level !)

Re: Evaluate peak stress in response simulation too slow

Hi,

 

like I said it is best practice in my company for several years. We do hardware tests on every! product to verify the results.

The duration is 0.1 s long.