• gustel
  • Senior Member
  • Offline
  • Registered: 16-04-2007
  • Posts: 99

Topic: NlDEIDynamic

I have been trying to use the explicit dynamic analysis method to model concrete fracture with material model Concretedpm2. I use no damping. As a consequence I have to use very small time steps. The input line that I use is

NlDEIDynamic nsteps 20000 dumpcoef 0. deltat 0.0000001 nmodules 1

As a comparison, I use LSDYNA in which the same constitutive model is implemented. I am now running the same mesh with the same constitutive model on the same computer and the same timestep in OOFEM and LSDYNA.

Is there anything obvious that I am missing that could be used to speed up the analysis in oofem?

2 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,026

Re: NlDEIDynamic

Hi Peter,
hard question, but will try to answer:
- try to configure output record, so that output is not produced in every time step
- we can try to enable explicit dynamic to take advantage of multicore computer (could be straightforward for us to do in half a day)
- you can go for more aggressive compiler optimization and make sure you have debug off (when active, many checks (like array access) are performed)

Borek

bp's Website

  • gustel
  • Senior Member
  • Offline
  • Registered: 16-04-2007
  • Posts: 99

Re: NlDEIDynamic

Hi Borek

Thank you for your reply.

I will check output and compiler.
Yes, multicore use would be very good. Please let me know if I can assist in any way (even if it is only testing).

Some other small things that came up when I used it:

1) The internally calculated time step seems not always to result in stable solutions. Would it be possible to have as an input a reduction factor so that the calculated time step is reduced by this factor?

2) Is there a way to internally adjust the number of steps so that the provided time t=nSteps*deltaT is completed?
Normally, I don't know the required times step start the analysis, the step size is adjusted internally, but the number of steps is not changed, so that the overall time is not the intended one.

I am happy to give it try to add 1) and 2) if that makes sense to you.

  • Registered: 25-06-2013
  • Posts: 241

Re: NlDEIDynamic

Hi Peter,

both points make sense to me. I am working on a similar time control in nrsolver, so we can reduce time step in a case of convergence problems. In my case, I have introduced the final time as an input parameter instead of number of steps, but it is not in the official version yet.

5 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,026

Re: NlDEIDynamic

Hi Peter,
the critical time-step depends on the largest natural frequency, which has to be somehow estimated. In the present implementation, it is estimated on element by element basis as  largest natural frequency of individual elements. It is just an estimate and some safety factor should be applied. In my opinion, it makes much sense to get largest natural frequency estimated and enter just safety factor (smaller than 1) to reduce estimated critical time step. You can try.
Borek

bp's Website

  • gustel
  • Senior Member
  • Offline
  • Registered: 16-04-2007
  • Posts: 99

Re: NlDEIDynamic

Hi Borek and Martin

Thank you for your replies. I have now implemented the reduction factor and an adjustment of the number of steps. I will create a pull request for it and you can see if you want to take this on board.

By the way, is it possible to switch the output for timesteps at which no data is written. I select the output to be written for every 20000 steps, but I still obtain for every step a line in the output file, telling me about the step number and the time. How could I switch this off?

Cheers

Peter