f2py functions remaining in math.f90 now uses assumed size arrays in order to have simpler interfaces. This is only working with python 2.7!
changed python pre- and postprocessing scripts.
If you encounter any problems whith core modules, try to remove the old core.so in the lib/damask
Mainly affected modules are IO and mesh. Most of the changes in mesh result from reordering the functions when grouping them depending on their solver.
Further advantage is that FE solver do not need FFTW and kdtree2 anymore. The include files for these two libraries moved to DAMASKROO/lib now as I figured out how to use a include path in the Makefile.
Put all the files I got when testing compilation with abaqus in a folder which to become the abaqus compilation test.
changed order of arrays in nearest neighbor search to make it fortran fast
constitutive.f90 and homogenization.f90 write state size out during initialization
setup/setup_processing.py is using byterecl to be compatible with binary files written out by solver
new concept of DAMASK for Python: Now using also IO.f90, debug.f90 etc. instead of mimicing their necessary function. This needs DAMASK_python.f90 and DAMASK_python_interface.f90 (At the moment more or less copies of respective spectral files).
polished and renamed the scripts for converging ang files
renamed voronoi_randomSeeding.py to spectral_randomSeeding.py
removed cut_off parameter for damask_spectral
removed outpot of derived divergence measures and added RMS output in brackets
added comments and options to the makefile
added compiler switches for gfortran and ifort to check for standard conformity
old gnu compilers <4.4 are not longer supported because they don't provide the c binding for fftw
additional output in DAMASK_spectral_interface.f90
132 character cut off in constitutive_nonlocal.f90
rounding error in math.f90 complex number initialization (1.0_pReal)*2.0_pReal*pi
new $DAMASK_NUM_THREADS warning in numerics.f90 / IO.f90
polishing in DAMASK_spectral.f90
renamed some math functions, so that we have a universal naming scheme: for matrix multiplications use an "x" (e.g. math_mul33x3); don't use the "x" to describe the shape of the tensor that the function is applied to (e.g. math_invert33 instead of math_invert3x3)
-removed to long lines
-restructured f2py modules and merged make_DAMASK2Python into setup processing
-setup_code.py now sets library path in makefile and asks for compile switches for spectral code
-substituted \ in format strings with $
restructured DAMASK_spectral:
-more logical output and structure of code
-better input for spectral debug parameters
Martin Diehl