Hi, this seems to be a bug in the code.
I will check it in detail, in the meantime, you can try to use another interface material.
You are not logged in. Please login or register.
OOFEM forum → Posts by nitramkaroh
Hi, this seems to be a bug in the code.
I will check it in detail, in the meantime, you can try to use another interface material.
Hi, The file runs fine after changing nsets from 16 to 12
Just a note that we use the Total Lagrangian formulation; thus, the coordinates of the integration points are not changed during the simlation.
Hi,
I get lots of warnings. e.g., Warning: Unread token(s) detected in the following record "beam3d 3436 nodes 2 1052 21 mat 1 crosses...": [printgps][1]
Warning: Unread token(s) detected in the following record "mitc4shell 2775 nodes 4 2930 940 2923 29...": [lcs1][3][-9.9512e-1][9.8696e-2][0e0]
What version of OOFEM are you using?
In the end, I got an error
Iteration did not converge
In IsotropicLinearElasticMaterial::giveRealStressVector_ShellStressControl, number: 2 (OOFEM/src/sm/Materials/structuralmaterial.C:246)
Thus, this might be the reason for not getting the VTK output. However, the error might be caused by the unread tokens on my side.vtk
Can you try a simpler example, e.g., one from tests? This can help isolate whether the problem is specific to your input file or a broader issue.
Hi, yes, it is possible. You can for example use Mazars model, see http://www.oofem.org/resources/doc/matl … ode44.html
This model introduces two damage variables, one for tension and one for compression.
Hi, You are right. The problem is related to DofToCondense. I don't have time now to check it, but you can use the master-slave concept instead, see http://www.oofem.org/forum/viewtopic.php?id=1571
In staticstructural, you need to add the keyword "reference" to your load, i.e.,
NodalLoad 2 loadTimeFunction 1 dofs 1 3 Components 1 1 set 3 referenceHi Peter, can you please upload the input file?
This error has nothing to do with the input file, it runs fine. Are you sure the input file is in the folder where you are located?
You need to compile it with OPENMP, so just specify USE_OPENMP ON in the cmake. Then you can use -t #nthreads
Hi, the input file works fine after removing # at the beginning of the second line. It seems that you are not specifying correct path to your input file.
IMHO, It doesn't make any sense to set refloadmode to 1 for calms. So my guess is that it should work fine.
Change refloadmode 1 to refloadmode 0; refloadmode 1 means that the load is calculated in an incremental way and since your load is constant, its increment is zero.
It seems to me that there is a bug, but I haven't found where exactly yet.
Hi Carlos, you can find explanation of ddtscheme parameter here http://www.oofem.org/resources/doc/oofe … l-problems
Hi Bernd, the problem is that you use just one integration point, i.e., NIP 1. Try to use NIP 4 that should help.
It is fine, the plastic strain can be negative.
Hi Marin, You are right, the convention is element Id, face Id.
Hi Marin, You are right, the convention is element Id, face Id.
Hi,I don't see why would you need to restart the analysis. You can use NonLinearStatic or StaticStructural, first applying the preload and after the preload is applied you can start applying your cyclic loading using appropriate load time functions.
Please upload your input file, so I can run it and see what is happening.
It is not possible to use LinearStatic together with large strain formulation, which leads to a nonlinear formulation. Switch to StaticStructural(or NonLinearStatic); they have more less the same functionalities and will be hopefully merged soon.
Yes, it should work. The function is used just to scale load, e.g., when you prescribe 0 at a certain point it means that you unloaded the structure. Whether you get zero displacement or stresses depends on type of model you used, e.g., for linear elastic material you will definitely get zero displacements and stresses no matter the load history.
Can you attach your input file?
Hi, I agree that this should be unified. However, the normal orientation is not defined just by interpolation, but also by element nodes numbering (clockwise vs. anti-clockwise). Should the element then throw a warning or error when the opposite numbering is used?
Note that this issue has been solved by adding OOFEM_EXPORT, i.e., __declspec(dllimport) keyword to appropriate class declarations.
OOFEM forum → Posts by nitramkaroh
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.