Topic: Why time step reduce to a very small number?

(1) I use explict sovler: nldeidynamic and when I run my simulation, it shows the time step was reduced to a very small value: something around 10^-7. Anyone know why the issue here?

(2) I also want to know what the unit of the load when I use "NodalLoad" command. If I would like to apply 293 KN, what the number I should use in the "NodalLoad" command? Thanks.

Here is my input file. Thanks.

Post's attachments

Single_try.in 76.08 kb, 2 downloads since 2018-05-23 

You don't have the permssions to download the attachments of this post.

Re: Why time step reduce to a very small number?

Hi,

(1) the time step is reduced so as the stability of the integration method is achieved if you want to use larger steps you need to switch to implicit integration.
(2) OOFEM doesn't work with units. It is up to the user to decide the units of the input and interpret units of the output accordingly.

Re: Why time step reduce to a very small number?

Hi Martin,

Thanks for your reply.

I tried the implicit integration with DiiDynamic with the command:

diidynamic nsteps 5 dumpcoef 0.1 deltat 0.0001 nmodules 1

And I got this error:

Running simulation
==================

Selecting Three-point Backward Euler metod
Total number of solution steps     5
_______________________________________________________
Error: (/home/kun/femdem/oofem/source/src/oofemlib/floatarray.C:137)
In checkBounds:
array error on index : 1 > 0
_______________________________________________________
stack trace:
  /home/kun/femdem/include/liboofem.so : oofem::FloatArray::checkBounds(int) const+0x148
  /home/kun/femdem/include/liboofem.so : oofem::FloatArray::at(int)+0x20
  /home/kun/femdem/include/liboofem.so : ()+0x9d5897
  /home/kun/femdem/include/liboofem.so : ()+0x54a643
  /home/kun/femdem/include/liboofem.so : ()+0x52f41c
  /home/kun/femdem/include/liboofem.so : ()+0x51190b
  /usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.58.0 : boost::python::objects::function::call(_object*, _object*) const+0x26d
  /usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.58.0 : ()+0x297c8
  /usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.58.0 : boost::python::handle_exception_impl(boost::function0<void>)+0x73
Total 1 error(s) and 0 warning(s) reported
oofem exit code 1

Do you know what's the problem I have here? Thanks

Re: Why time step reduce to a very small number?

I know, we have already discussed the same issue here http://www.oofem.org/forum/viewtopic.php?pid=6964#p6964
Can you download the actual git version?

Re: Why time step reduce to a very small number?

Hi Martin,

I use now oofem 2.4 and If I directly run the oofem input file there is no such an error like I mentioned, it can be runned successfully but with the warning:

Warning: (/home/kun/femdem/oofem/source/src/oofemlib/oofemtxtinputrecord.C:555)
In finish:
Unread token(s) detected in the following record
"diidynamic nsteps 50000 dumpcoef 0.1 delta...":
[dumpcoef][0.1]

I am working on combine oofem with Yade. It works with "nldeidynamic" solver but when I use diidynamic or other implicit solver, it will come with the error I mentioned on my last post. Do you know what's the problem here and what should I modify in oofem source file? Thanks.

Re: Why time step reduce to a very small number?

Hi,


can you post the file that leads to the error? I tried implicit solver in oofem2.3 and 2.4 and both work fine.

Thanks,
M.

Re: Why time step reduce to a very small number?

Hi Martin,

I got a question about the unit of the nodaload.  If I use d = 2700 kg/m^3 as density and  E = 3e10  And I also want to apply vertical load with the value of  146 KN. I have the question:

(1) the value of the nodalload value should be 146000 or 146000 / (Number of the certain nodal) ?

Thanks.



nitramkaroh wrote:

Hi,

(1) the time step is reduced so as the stability of the integration method is achieved if you want to use larger steps you need to switch to implicit integration.
(2) OOFEM doesn't work with units. It is up to the user to decide the units of the input and interpret units of the output accordingly.