Happy New Year!
I was wondering if OOFEM has native support for coupled pore flow-stress simulation.

Thanks,
Alireza

2

(3 replies, posted in Developers Discussion)

Hi Borek,

I was wondering how can element removal be done. Is it controllable at the material level?

Thanks
Alireza

3

(2 replies, posted in Developers Discussion)

Dear Borek,

You're right, the damping matrix will be diagonal any more. But there should be a way to improve the efficiency. For example LS-DYNA that's famous for its explicit solver, has both mass-proportional and Rayleigh  damping and switching the damping type does not change its efficiency.
I think first of all it uses the original stiffness to build the damping and would not update the damping matrix according to the change in the stiffness.
Then you can calculate the inverse of the damping matrix at the beginning and use that previously inversed matrix in all the time steps.

Cheers
Alireza

4

(2 replies, posted in Developers Discussion)

Dear Borek,

It seems that the damping implemented for the explicit dynamic is a mass-proportional damping that affects the low frequency modes specially the rigid body motion.
I use the explicit solver to solve the highly non-linear quasi-static problems. When you're dealing with a quasi-static problem, unless you apply the load/disp very slowly, you'll see a lot of (high-frequency) noise in the system (as shown in the attached figure).
And the global damping cannot damp these noises. I was wondering if in the next version of your could you could implement a stiffness proportional damping as well to solve this problem.

Thanks
Alireza

5

(6 replies, posted in Developers Discussion)

Sure, I'll send it to you as soon as I experience it again.

Alireza

6

(6 replies, posted in Developers Discussion)

I'm observing another minor problem in this new extractor.
Some times it seems that the program cannot see the end of file and it just keeps running forever.

7

(6 replies, posted in Developers Discussion)

Dear Borek,

Thanks for the reply. I'll change the code to this one.
Btw. I'm using Linux (86_64) not Windows.

Cheers
Alireza

8

(3 replies, posted in Developers Discussion)

Dear Boerk,

During this period, I worked on the first idea and applied the modifications to the existing non-local interface that allows orthotropic averaging scheme.
In future if I get the chance, I'll work on your second suggestion.

Cheers
Alireza

9

(6 replies, posted in Developers Discussion)

in the line #595 of extractor.py, I changed "infile = open(oofemoutfilename[:-1])" to "infile = open(oofemoutfilename[:-2])" and it worked

10

(6 replies, posted in Developers Discussion)

Hi Borek,

I used to use the old extractor but seems that it's incompatible with the arbitrary numbering.
So I switched to the new extractor.
The problem that I'm facing is  it seems that it has a problem to open the input file.
here is the error:

IOError: [Errno 2] No such file or directory: 'OCTHole1000.oofem.out\r'

It seems that it thinks the return character is included in the file name and because of that it cannot locate the file.

I would appreciate it if you could help me with this.
Alireza

11

(3 replies, posted in Developers Discussion)

Basically all the structural classes look at "StructuralNonlocalMaterialExtensionInterface".  so my "StructuralNonlocalOrthoMateiralExtensionInterface" is not recognized and called by teh structuralElement and cross section classes in the code.
then as the second option I tried to modify the NonlocalMaterialExtensionInterface class to make it capable of performing a non-uniform averaging. But the problem is that the whole class is written exclusively to deal with a uniform isoptropic averaging.
For example:
- The structure called "localIntegrationRecord" has a double variable as weight whereas I need a FloatArray;
- The "buildNonlocalPointtable" member is written to deal with scalar averagign,
etc.

Considering all this, what would be the best way to implement a non-uniform non-local scheme with a different wieght structure?

Thanks,
Alireza

12

(3 replies, posted in Developers Discussion)

Dear Borek,

I'm implementing my Orthotropic Averaging scheme in OOFEM.
To do so, I have made new nonlocal interface and structural nonlocal interface classes to deal with an array of weights not an scalar weight.

The problem is in the StructuralElement class, the "StructuralNonlocalMaterialExtensionInterface" class is called to handle the preparations for non-local averaging and this is not the interface that my non-local scheme belongs to.

I was wondering what's your suggestion.
Shall I modify the existing non-local interfaces and make them capable of dealing with both isotropic and orthotropic averaging?

Thanks
Alireza

I uploaded the file.

Hello,

It seems that there is a problem with the built-in materials idm1 and its non-local version. Both of these materials return

Error: (/home/IMuser/OOFEM/oofem-1.9--CODAM2.8-3/src/oofemlib/structuralmaterial.C:302)
Class: IsotropicDamageMaterial1, number: 1
giveSizeOfReducedStressStrainVector : unknown mode (_Unknown)

Using the debugger, I checked the values of variables related the Gp and they don't seem to be right. Like its numberOfGp=0 and materialMode=_Unknown!!

When I switch to any other material model, they work fine.

Regards,
Alireza

I tried the built-in nonlocal RCSD model and this model also shows a huge dependency of results on the number of integration points.

When I use the single integration scheme, damage initiates and grows much faster compared to fully integrated one.

Please note that my mesh size is about 0.5mm and the non-local radius is 2mm therefore there are plenty of integration points in the averaging zone even in the under integrated one.

I'm wondering if this indicates a problem in the averaging process or not!

Thanks
Alireza

Dear Borek,

I'm running the damage propagation problem with my own material model that uses non-local averaging.
The problem is when I use under integration in my explicit dynamic analysis the damage pattern changes significantly.

Since the results of fully integration totally makes sense both in terms of load-displacement that I get and the damage pattern, I was wondering if you have any idea how under integration would change the response that dramatically?
I have attached a figure showing the damage patterns in the fully integrated (top) and under integrated (bottom).

Thanks for your helps,
Alireza

Thanks Dear Borek,
Unfortunately, I'm not using the subversion software. I know I better switch to subversion soon to organize the work better.
Would you please tell me which file is modified so that I can download it from the repository and re-compile the code.

Cheers,
Alireza

Hi Borek,

I have a model where the node numbering has some gaps in it. When I tried to report the displacement and reactions in the output file, it didn't save the reactions.
It seems that the arbitrary numbering procedure doesn't work properly.
I have attached the input file and part of the output.

Regards,
Alireza

Output:

==============================================================
Output for time  0.00000000e+00
==============================================================
Output for domain   1


DofManager output:
------------------
Node        4972 (    4884):
  dof 1   d  0.00000000e+00   v  0.00000000e+00   a  0.00000000e+00
  dof 2   d  0.00000000e+00   v  0.00000000e+00   a  0.00000000e+00




Element output:
---------------
element 1000 (    1000) :
  GP  1.1  :  strains   0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00
              stresses  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00
status { kappa1 0.000000 ,kappa2 0.000000 ,kappa3 0.000000 ,kappa4 0.000000 ,kappa5 0.000000 ,kappa6 0.000000 ,kappa7 0.000000 ,kappa8 0.000000 ,kappa9 0.000000 ,kappa10 0.000000 ,}
status { d1 0.000000 ,d2 0.000000 ,d3 0.000000 ,d4 0.000000 ,d5 0.000000 ,d6 0.000000 ,d7 0.000000 ,d8 0.000000 ,d9 0.000000 ,d10 0.000000 ,}
status { Reduc1 1.000000 ,Reduc2 1.000000 ,Reduc3 1.000000 ,Reduc4 1.000000 ,Reduc5 1.000000 ,Reduc6 1.000000 ,Reduc7 1.000000 ,Reduc8 1.000000 ,Reduc9 1.000000 ,Reduc10 1.000000 ,}
  GP  1.2  :  strains   0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00
              stresses  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00
status { kappa1 0.000000 ,kappa2 0.000000 ,kappa3 0.000000 ,kappa4 0.000000 ,kappa5 0.000000 ,kappa6 0.000000 ,kappa7 0.000000 ,kappa8 0.000000 ,kappa9 0.000000 ,kappa10 0.000000 ,}
status { d1 0.000000 ,d2 0.000000 ,d3 0.000000 ,d4 0.000000 ,d5 0.000000 ,d6 0.000000 ,d7 0.000000 ,d8 0.000000 ,d9 0.000000 ,d10 0.000000 ,}
status { Reduc1 1.000000 ,Reduc2 1.000000 ,Reduc3 1.000000 ,Reduc4 1.000000 ,Reduc5 1.000000 ,Reduc6 1.000000 ,Reduc7 1.000000 ,Reduc8 1.000000 ,Reduc9 1.000000 ,Reduc10 1.000000 ,}
  GP  1.3  :  strains   0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00
              stresses  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00
status { kappa1 0.000000 ,kappa2 0.000000 ,kappa3 0.000000 ,kappa4 0.000000 ,kappa5 0.000000 ,kappa6 0.000000 ,kappa7 0.000000 ,kappa8 0.000000 ,kappa9 0.000000 ,kappa10 0.000000 ,}
status { d1 0.000000 ,d2 0.000000 ,d3 0.000000 ,d4 0.000000 ,d5 0.000000 ,d6 0.000000 ,d7 0.000000 ,d8 0.000000 ,d9 0.000000 ,d10 0.000000 ,}
status { Reduc1 1.000000 ,Reduc2 1.000000 ,Reduc3 1.000000 ,Reduc4 1.000000 ,Reduc5 1.000000 ,Reduc6 1.000000 ,Reduc7 1.000000 ,Reduc8 1.000000 ,Reduc9 1.000000 ,Reduc10 1.000000 ,}
  GP  1.4  :  strains   0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00
              stresses  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00  0.0000e+00
status { kappa1 0.000000 ,kappa2 0.000000 ,kappa3 0.000000 ,kappa4 0.000000 ,kappa5 0.000000 ,kappa6 0.000000 ,kappa7 0.000000 ,kappa8 0.000000 ,kappa9 0.000000 ,kappa10 0.000000 ,}
status { d1 0.000000 ,d2 0.000000 ,d3 0.000000 ,d4 0.000000 ,d5 0.000000 ,d6 0.000000 ,d7 0.000000 ,d8 0.000000 ,d9 0.000000 ,d10 0.000000 ,}
status { Reduc1 1.000000 ,Reduc2 1.000000 ,Reduc3 1.000000 ,Reduc4 1.000000 ,Reduc5 1.000000 ,Reduc6 1.000000 ,Reduc7 1.000000 ,Reduc8 1.000000 ,Reduc9 1.000000 ,Reduc10 1.000000 ,}




    R E A C T I O N S  O U T P U T:
    _______________________________



User time consumed by solution step 0: 0.566 [s]

19

(2 replies, posted in Developers Discussion)

Thanks Mikael, seems about right!

20

(2 replies, posted in Developers Discussion)

Hi Borek,

I was going through the "nonlocalmaterialext.C" using the KDE's KDevelop editor and also MSVS. It seems that 'buildNonlocalPointTable" member lacks a "}" at its end. This is version 1.9. Version 1.8 seems fine. Would you please take a look at it.
It's weird though since it compiles with no errors.

Many thanks,
Alireza

21

(1 replies, posted in Developers Discussion)

Dear Borek,

I was wondering if OOFEM calculates the kinetic and strain energies. I'm doing dynamic crack growth analysis and wanted to see the share of strain, damage and kinetic energies.

Many thanks and happy holidays,
Alireza

Thanks Borek, It worked!

Hello Borek,

I was trying to compile the oofem--1.9 using Intel's compiler and the following error showed up:

/home/IMuser/OOFEM/oofem-1.9--SOURCE/src/sm/compodamagemat.C(59): error: member function "CompoDamageMat::~CompoDamageMat" may not be redeclared outside its class
  CompoDamageMat :: ~CompoDamageMat();
                    ^

compilation aborted for /home/IMuser/OOFEM/oofem-1.9--SOURCE/src/sm/compodamagemat.C (code 2)
make[2]: *** [compodamagemat.o] Error 2
make[2]: Leaving directory `/home/IMuser/OOFEM/oofem-1.9--SOURCE/targets/ubc-oofem/lib/sm'
make[1]: *** [sm_mod] Error 2
make[1]: Leaving directory `/home/IMuser/OOFEM/oofem-1.9--SOURCE/targets/ubc-oofem'

I could compile the 1.8 version with icpc successfully!
And the 1.9 version compiles fine with g++

Alireza

Hello Everybody,

Recently, I tried Intel's icpc (the c++ compiler) to compile OOFEM. My experience was that it improved the running time performance of my code for about 10% (reduced the computation time by about 10% on an Intel64 based CPU). I know although Intel's compilers are free to download and install on Linux, but they're not open source and under GNU/GPL license. But I thought if you're using OOFEM for heavy and time consuming calculations, it might worth trying.

Cheers
Alireza

25

(4 replies, posted in Developers Discussion)

Thanks Borek,

I didn't know that oofem accepts time varying essential BC!. I thought the only way to perform displacement control is to use the way that I was using.
And I agree with your argument. Since in that approach the essential BC is not applied in strong sense, if the material model messes up, the equilibrium will be affected.
btw, I switched to Explicit for my notched specimen simulations since with my complicated material model and adding non-local to that getting convergence was impossible! Performing under integrated scheme really helps in explicit calculations.

Cheers
Alireza